УПРАВЛЕНИЕ
ПРОГРАММНЫМ!
llrUtnlHMn
ДОСТИЖЕНИЕ
ОПТИМАЛЬНОГО
If UUCP YD A
ХДЧШВА
шшшшшл ш шипи иидм шш*
Иг Я ИгаПияМУЯпС
ЗАТРАТ

Таблица 18.4. Таблица категорий рисков
Факторы риска и L — Low Risk Evidence M — Medium Risk Evidence H —High Risk Evidence Рейтинг Коммен-
категории риска (Низкая очевидность риска) (Средняя очевидность риска) (Высокая очевидность риска) (HTML) тарии
I
II
III
IV
VI
Задачи и целевые факторы
Соответствие проек- Непосредственно поддержи-
ту вает задачи и/или цели
организации
Рабочий поток Небольшие изменения в
рабочем потоке либо они
вообще отсутствуют
Факторы, связанные с управлением организацией
Организационная В менеджменте или в структу-
стабильность ре отсутствуют изменения или
же изменения небольшие и
ожидаемые
Команда подобрана,
изменения не предвидятся либо
незначительны
Политики разработки и
стандарты определены и
тщательно соблюдаются
Основательная, активная
заинтересованность в успехе
проекта
Проверяемые цели
выполнения, обоснованные
требования
Непрямые влияния одной или Отсутствует поддержка в аспекте
нескольких целей задач или целей организации
Изменяются некоторые аспек- Существенные изменения рабоче-
ты или рабочий поток имеет го потока или метода его органи-
небольшую эффективность зации
Ожидаются определенные
изменения в менеджменте
или реорганизация
Менеджмент или организационная
структура постоянно и быстро
изменяются
Стабильность
команды
разработчиков
Политики и
стандарты
Поддержка
менеджмента
Цели выполнения
Команда подобрана, но неко- Команда не подобрана, нет едино-
торые члены могут заменяться го мнения по поводу ее состава
Разработка политик и
стандартов проводится своевременно,
но недостаточно активно или
не столь тщательно
Периодическая
заинтересованность, не имеющая
всеобщего характера
Некоторые цели
выполняются, меры по их реализации
могут носить спорный
характер
Отсутствуют политики или
стандарты либо они неверно
определены и не используются
Слабая или отсутствует
Нет установленных требований
к выполнению или требования не
ограничиваются

УПРАВЛЕНИЕ
ПРОГРАММНЫМИ
ПРОЕКТАМИ
ДОСТИЖЕНИЕ
ШНММШГ1
LIS IIIIV
ПРИ МИНИМУМЕ
ЗАТРАТ
Роберт Т. Фатрепп
Пональд Ф. Шафер
Пинда И. Шафер
ш
Издательский дом "Вильяме "
Москва * Санкт-Петербург * Киев
2003

ЬБК 88.5Я75
ШЗО
УДК 681.3.07
Издательский дом "Вильяме"
Зав. редакцией С.Н. Тригуб
Перевод с английского А. Бойко, А.И. Мороза,
А.П. Сергеева, Т.А. Шамренко, Ю.А. Шпака
Под редакцией А.П. Сергеева
По общим вопросам обращайтесь в Издательский дом "Вильяме" по адресу:
info@williamspublishing.corn, http://www.williamspublishing.com
Шафер, Дональд, Ф., Фатрелл. Роберт, Т., Шафер. Линда, И.
ШЗО Управление программными проектами: достижение оптимального
качества при минимуме затрат. : Пер. с англ. — М. : Издательский дом "Вильяме",
200Н. — 1136 с.: ил. - Парал. тит. англ.
ISBN 5-8459-0413-7 (рус.)
Эта книга посвящена вопросам, возникающим на различных стадиях подготовки
программных проектов, начиная с разработки программного обеспечения и
завершая рассмотрением юридических вопросов, связанных с процессом создания и
внедрения программ. Теоретические вопросы иллюстрируются многочисленными
практическими примерами, взятыми из реальной жизни. Материал книги
соответствует сертификационным программам менеджмента качества программных проектов
Института качества программного обеспечения (Техасский университет, г. Остин), а
также программе подготовки на получение звания сертифицированного инженера
от Американского общества качества. Книга будет полезной руководителям
программных проектов, программистам-разработчикам, специалистам из
консалтинговых фирм, желающим улучшить качество, уменьшить сроки выполнения и расходы
на этапах разработки и внедрения проектов.
ББК 88.5Я75
Все названия программных продуктов являются зарегистрированными торговыми марками
соответствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы
то ни было форме и какими бы то ни было средствами, будь то электронные или механические,
включая фотокопирование и запись на магнитный носитель, если на это нет письменного
разрешения издательства Addison-Wesley Publishing Company, Inc.
Authorized translation from the English language edition published by Addison-Wesley Publishing
Company. Inc. Copyright © 2002
All lights reserved. No part of this book may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording or by any information storage re-
tiieval system, without permission from the Publisher.
Russian language edition published by Williams Publishing House according to the Agreement with
RM Kntei prises International, Copyright © 2003
ISBN 5-8459-0413-7 (рус.) © Издательский дом "Вильяме", 2003
ISBN 0-134)91297-2 (англ.) © Addison-Wesley Publishing Company, Inc, 2002

Оглавление
Глава 1. Введение 31
Глава 2. Практическое занятие. Обзор 76
Глава 3. Краткий обзор процессов 92
Глава 4. Выбор жизненного цикла разработки ПО 121
Глава 5. Управление процессами предметной области 180
Глава 6. Отбор команды разработчиков проекта 202
Глава 7. Определение цели и области действия
программного проекта 238
Глава 8. Создание структуры пооперационного перечня работ 256
Глава 9. Идентификация задач и действий 275
Глава 10. Оценка размера и возможности повторного
использования ПО 313
Глава 11. Оценка длительности и стоимости разработки ПО 364
Глава 12. Распределение ресурсов 418
Глава 13. Выбор организационной формы 436
Глава 14. Учет зависимостей 459
Глава 15. Формирование рабочего графика 475
Глава 16. Формулирование требований 501
Глава 17. Спецификация требований к ПО 549
Глава 18. Определение рисков, связанных с выполнением
проекта 577
Глава 19. Введение в программный инжиниринг 613
Глава 20. Обеспечение надежности ПО 669
Глава 21. Метрические показатели, применяемые при оценке
размера программ 692

6 Оглавление
Глава 22. Методы анализа и разработки проекта 749
Глава 23. Аттестация и верификация 843
Глава 24. Использование инструментов 931
Глава 25. Отслеживание и контроль в процессе
выполнения проекта 966
Глава 26. Непрерывное совершенствование процессов
разработки ПО 1001
Глава 27. Прерывание выполняемого проекта 1002
Глава 28. Анализ эффективности выполнения проекта 1003
Глава 29. Отчетность и общение 1004
Глава 30. Обеспечение качества ПО 1005
Глава 31. Менеджмент конфигурации ПО 1006
Глава 32. Правовые вопросы, возникающие при разработке ПО 1007
Глава 33. Резюме 1008
Приложение А. Организации, поддерживающие разработку ПО 1062
Приложение В. Реальные проекты 1063
Приложение С. Создание бизнес-плана 1064
Приложение D. Основы системного инжиниринга 1065
Приложение Е. Дистанционное управление проектами 1066
Приложение F. Шаблоны компонентов проекта 1067
Приложение G. Организация совместной разработки
приложений 1068
Словарь терминов 1069
Литература 1081
Предметный указатель 1117

Содержание
Вступление 24
Предисловие 27
Используйте это руководство в качестве учебного пособия 30
Благодарности 30
Глава 1. Введение 31
Тридцать четыре необходимые компетенции. Введение 34
Некоторые основные термины 37
Определение "менеджмента программных проектов" 37
Определение инжиниринга ПО 39
Определение проекта 39
Определение программы 41
Определение управления проектами 42
Некоторые другие полезные определения 43
Определение процесса 43
Определение задач и действий 44
Определение фазы 46
Определение системы 46
Методики разработки продукта 47
Область действия компетенций продукта 48
Краткое описание навыков, непосредственно связанных с выпуском продуктов 49
Навыки менеджмента проектов 57
Область действия компетенций проекта 57
Краткое описание навыков менеджмента проектов 58
Навыки менеджмента персонала 65
Область действия навыков менеджмента персонала 65
Краткое описание навыков менеджмента персонала 67
Резюме 72
Контрольные вопросы 75
Глава 2. Практическое занятие. Обзор 76
Основные сведения о железнодорожной системе Китая 77
Перспективы китайских железных дорог 79
Среда китайского бизнеса 81
Энергетический контракт Вестингауза 81
Негосударственная группа в займе IFC 82
Система Глобалстар 82
Приоритеты минеральных ресурсов 82

8 Содержание
Описание проекта 83
Ваша ситуация с управлением проектом 83
Вы и ваша корпорация 85
Поставляемые продукты вашего проекта 86
Ваш график 88
Ваши конкуренты 89
Ваша проектная команда 89
Заключительное примечание: потенциальный рынок для ПО 89
Дополнительные сведения в Internet 89
Глава 3. Краткий обзор процессов 92
Ключевые вопросы, рассматриваемые в главе 3 94
Стадии жизненного цикла разработки продукта 95
Связь главы 3 с 34 компетенциями 95
Учебные цели главы 3 97
Третий уровень модели СММ SEI 98
Центр организационного процесса 98
Определение организационного процесса 99
Менеджмент процесса начинается с установки интерфейса 100
Определенный менеджмент процесса 101
Менеджмент процесса 101
Стандарт IEEE 1074 — карта обработки для процесса жизненного цикла
разработки ПО 104
Методы использования стандарта 1074 108
Прикладной стандарт 1074 115
Настраиваемый процесс разработки ПО 116
Жизненный цикл организации, управляющей программными проектами 117
Резюме 117
Контрольные вопросы 119
Практическое занятие 119
Литература 119
Дополнительные сведения в Internet 120
Глава 4. Выбор жизненного цикла разработки ПО 121
Стадии жизненного цикла разработки продукта 122
Связь главы 4 с 34 компетенциями 123
Учебные цели главы 4 123
Определение жизненного цикла разработки ПО 124
Ключевое значение жизненных циклов разработки ПО 125
Выбор и адаптация жизненных циклов разработки ПО 129
Модель SEI СММ и жизненные циклы 129
Определение процесса на уровне организации 131
Интегрированный программный менеджмент 132
Международная организация по стандартизации (ISO)/IEC 12207 132
Модели жизненного цикла разработки ПО 135
Каскадная модель жизненного цикла разработки ПО 135
V-образная модель жизненного цикла разработки ПО 141
Фазы V-образной модели 142

Содержание 9
Модель прототипирования жизненного цикла разработки ПО 144
Определения прототипирования 145
Описание структурной модели эволюционного прототипирования 145
Модель быстрой разработки приложений жизненного цикла разработки ПО 151
Инкрементная модель жизненного цикла разработки ПО 155
Спиральная модель жизненного цикла разработки ПО 159
Адаптированные модели жизненного цикла разработки ПО 164
Выбор приемлемой модели жизненного цикла разработки ПО 169
Отличительные категории проекта 169
Подгонка модели жизненного цикла разработки ПО 173
Резюме 175
Контрольные вопросы 175
Практическое занятие 177
Литература 178
Дополнительные сведения в Internet 178
Глава 5. Управление процессами предметной области 180
Стадии жизненного цикла разработки продукта 182
Связь главы 5 с 34 компетенциями 182
Учебные цели главы 5 182
Определение процессов предметной области 183
Модели выбора проектов 192
Менеджмент проектов 196
Финансовые аспекты 199
Резюме 200
Контрольные вопросы 201
Практическое занятие 201
Дополнительные сведения в Internet 201
Глава 6. Отбор команды разработчиков проекта 202
Стадии жизненного цикла разработки продукта 203
Связь главы 6 с 34 компетенциями 203
Учебные цели главы 6 204
Отбор команды разработчиков проекта 205
Принцип 7 — коллегиальность 206
Принцип 8 — самосовершенствование 206
Совокупность отдельных частей образует единое целое 208
Индивидуальные типы личностей 209
Применение моделей 213
Культурные влияния 214
Личная мотивация 215
Факторы, обеспечивающие совместную работу 218
Привлечение в группу и обучение навыкам 218
Реестр шаблонов рабочих стилей Мак-Флетчера 219
Динамика развития группы 221
Распознание признаков разрушения команды 222
Создание каркаса—необходимое условие совместной работы 223
Взаимодействие и количество участников команды 224

10 Содержание
Взаимодействие в команде 224
Дисперсия команд 227
Структура и ритуал 228
Обеспечение всеобъемлющего решения 229
Управление творческой деятельностью 230
Когда следует руководить, а когда—управлять 230
Резюме 233
Контрольные вопросы 234
Практическое занятие 237
Литература 237
Дополнительные сведения в Internet 237
Глава 7. Определение цели и области действия программного
проекта 238
Стадии жизненного цикла разработки продукта 238
Связь главы 7 с 34 компетенциями 239
Учебные цели главы 7 241
Планирование проекта 24]
Этан "Почему?" 243
Этап "Что?" 243
Этап "Как?" 244
Этап "Выполнение" 244
Этап "Сделано" 244
Определение цели 245
Определение четко сформулированных заданий 247
Определение рабочей области 248
Определение граничных условий 249
Техническое задание проекта 250
Содержимое технического задания проекта 251
План управления программным проектом (SPMP) 252
Основные элементы плана SPMP 252
Взаимосвязь между плановыми документами проекта 253
Резюме 254
Контрольные вопросы 254
Практическое занятие 254
Литература 254
Дополнительные сведения в Internet 254
Глава 8. Создание структуры пооперационного перечня работ 256
Стадии жизненного цикла разработки продукта 257
Связь главы 8 с 34 компетенциями 257
Учебные цели главы 8 259
Определение структуры пооперационного перечня работ 259
Методы создания структуры WBS 263
Определение стадий проекта 267
Проектирование рабочих пакетов 267
Создание структуры WBS при разработке ПО 268
Действия, связанные с разработкой ПО 269

Содержание 11
Поиск структуры WBS для произвольной системы высшего уровня 269
Определение программной архитектуры WBS 270
Указание сведений для программной архитектуры WBS 271
Определение категорий затрат для ПО 271
Пять этапов построения структуры WBS 271
Резюме 272
Контрольные вопросы 273
Практическое занятие 273
Литература 273
Дополнительные сведения в Internet 274
Глава 9. Идентификация задач и действий 275
Стадии жизненного цикла разработки продукта 276
Связь главы 9 с 34 компетенциями 276
Учебные цели главы 9 278
Характеристики задач и действий 278
Значимая метка 279
Оптимальный размер действий 279
Источники 280
Идентификатор действия процесса 281
Адаптация действий, выполняемых в жизненном цикле разработки ПО,
к общим ситуациям 281
Действия жизненного цикла по разработке ПО 284
Действия, выполняемые в каскадной модели разработки ПО 287
Действия, выполняемые в V-образной модели разработки ПО 289
Действия, выполняемые в структурированной модели эволюционного
быстрого прототипирования 291
Действия, выполняемые в модели быстрой разработки приложений (RAD) 295
Действия, выполняемые в спиральной модели разработки ПО 301
Резюме 311
Контрольные вопросы 311
Практическое занятие 311
Литература 311
Дополнительные сведения в Internet 312
Глава 10. Оценка размера и возможности повторного
использования ПО 313
Стадии жизненного цикла разработки продукта 314
Связь главы 10 с 34 компетенциями 314
Учебные цели главы 10 316
Модель СММ SEI и процесс оценивания 316
Цели модели SEI СММ уровня 2, ключевая область процесса (КРА):
планирование программного проекта (РР) 317
Выполненные действия 317
Проблемы и риски, связанные с оцениванием размера ПО 318
Проблемы, возникающие в процессе оценивания 318
Риски оценивания 320

12 Содержание
Начальный этап определения размеров программного продукта: оценивание
начинается с планирования 321
Разбиение проекта на отдельные задачи (WBS) 322
Примеры единиц измерения 324
Влияние эффектов повторного использования на размер ПО 355
Будьте особенно внимательны при повторном использовании кода 358
Оценка трудозатрат 359
Резюме 359
Контрольные вопросы 361
Практическое занятие 361
Литература 362
Дополнительные сведения в Internet 363
Глава 11. Оценка длительности и стоимости разработки ПО 364
Стадии жизненного цикла разработки продукта 364
Связь главы 11 с 34 компетенциями 365
Учебные цели главы 11 367
Модель СММ Института SEI и процесс оценивания 367
Цели модели SEI СММ уровня 2, ключевая область процесса (КРА):
планирование программного проекта (РР) 368
Оценивание трудозатрат 371
Этапы оценивания 374
Этап 1. Достижение целей, связанных с оценкой затрат 374
Этап 2. Разработка плана действий при оценивании; план распределения
ресурсов 375
Этап 3. Определение требований по разработке ПО 375
Этап 4. Учет максимального количества деталей 375
Этап 5. Использование нескольких независимых методик 375
Этап 6. Сравнение, понимание и последовательный просмотр оценок 375
Этап 7. Обзор точности оценивания 376
Регрессионная модель СОСОМО 377
Общее описание регрессионных моделей 377
Режимы модели СОСОМО 377
Уровни модели СОСОМО 379
Базовая модель СОСОМО 380
Промежуточная модель СОСОМО 385
Детализированная модель СОСОМО 396
Составление графика с помощью модели СОСОМО 397
Подгонка модели СОСОМО 398
Преимущества модели СОСОМО 398
Недостатки модели СОСОМО 398
Некоторые типичные проблемы, влияющие на выполнение графика или
уменьшение трудозатрат 400
Модель СОСОМО II 400
Математическая модель SLIM 402
Преимущества модели SLIM 407
Недостатки модели SLIM 409
Резюме 409

Содержание
Контрольные вопросы 414
Практическое занятие 415
Ссылки 415
Литература 416
Дополнительные сведения в Internet 416
Глава 12. Распределение ресурсов 418
Стадии жизненного цикла разработки продукта 419
Связь главы 12 с 34 компетенциями 420
Учебные цели главы 12 421
Организационное планирование 421
Идентификация и документирование ролей и навыков, необходимых
для осуществления проекта 422
Типы ролей 422
Характеристики ролей 423
Назначение обязанностей для отдельных исполнителей 424
Учет начальных и заключительных операций 425
Стратегия распределения ресурсов 425
Подбор исполнителей, соответствующих ролям 426
План управления персоналом, участвующим в выполнении проекта 428
Отчеты о взаимосвязях 430
Матрица распределения обязанностей 430
Выравнивание распределения ресурсов 433
Действия по управлению ресурсами проекта во время его выполнения 433
Резюме 434
Контрольные вопросы 434
Практическое занятие 435
Литература 435
Дополнительные сведения в Internet 435
Глава 13. Выбор организационной формы 436
Стадии жизненного цикла разработки продукта 436
Связь главы 13 с 34 компетенциями 436
Учебные цели главы 13 439
Определение организации 439
Возникновение организаций 439
Изменяются ли организационные стили? 441
Характеристики организации 442
Обобщенная модель организации 443
Имеет ли значение размер организации? 444
Рассеянные и сосредоточенные организации 444
Относительные полномочия менеджера проекта 446
Организационная зрелость 446
Организационные структуры 447
Функциональные организации 448
Матричные организации 451
Проективные организации 452
Применение организационной структуры 454

14 Содержание
Резюме 457
Контрольные вопросы 457
Практическое занятие 458
Ссылки 458
Литература 458
Дополнительные сведения в Internet 458
Глава 14. Учет зависимостей 459
Стадии жизненного цикла разработки продукта 460
Связь главы 14 с 34 компетенциями 460
Учебные цели главы 14 462
Определение зависимости 462
Типы зависимостей, возникающих при разработке ПО 463
Внешние и внутренние зависимости 463
Зависимости, связанные с ресурсами и действиями 465
Возможные взаимосвязи между зависимостями 466
Специальные типы взаимосвязей 467
"Мозговой штурм" при поиске зависимостей и действий 470
Номинальная групповая техника 470
Процесс, применяемый при определении новых зависимостей 471
Резюме 473
Контрольные вопросы 473
Практическое занятие 474
Литература 474
Дополнительные сведения в Internet 474
Глава 15. Формирование рабочего графика 475
Стадии жизненного цикла разработки продукта 475
Связь главы 15 с 34 компетенциями 475
Учебные цели главы 15 477
Зачем нужен график? 478
Игра 478
Неопределенность при составлении рабочего графика 479
Психология оценивания 480
Основы формирования рабочих графиков 483
Таблица 483
Диаграмма Ганта 484
Сетевая диаграмма 485
Построение рабочих графиков с применением методов PERT и СРМ 487
Метод PERT 488
Метод СРМ 490
Перераспределение ресурсов 492
Привязка рабочего графика к реальному календарю 493
Построение рабочих графиков с применением метода критической цепи 495
Завершение построения реального рабочего графика 498
Резюме 499
Контрольные вопросы 499
Практическое занятие 500

Содержание 15
Литература 500
Дополнительные сведения в Internet 500
Глава 16. Формулирование требований 501
Стадии жизненного цикла разработки продукта 501
Связь главы 16 с 34 компетенциями 502
Учебные цели главы 16 504
Основы управления требованиями 504
Управление требованиями и модель SEIСММ 506
Цели 507
Выполняемые действия 507
Критические факторы успеха 507
Определение требований к ПО 508
Типы требований к ПО 508
Определение "хорошего" требования к ПО 509
Методы определения требований 512
Интервью 513
Сеансы "мозгового штурма" 517
Метод упрощенной спецификации приложения (FAST) 526
Совместная разработка приложений 527
Пользовательский сценарий и сеансы разработки схем выбора 532
Советы по определению требований к качеству ПО 536
Проблемы, возникающие при определении требований 538
Требования и внедрение функций определения качества 540
Приоритетность требований 543
Резюме 545
Контрольные вопросы 546
Практическое занятие 547
Литература 547
Дополнительные сведения в Internet 548
Глава 17. Спецификация требований к ПО 549
Стадии жизненного цикла разработки продукта 550
Связь главы 17 с 34 компетенциями 550
Учебные цели главы 17 552
Вопросы, решаемые с помощью спецификаций SRS 552
Преимущества спецификации SRS 555
Разработка документа SRS 556
Титульный лист 557
Оглавление 557
Раздел 1. Введение 557
Раздел 2. Общее описание 558
Раздел 3. Специфические требования 559
Раздел 4. Информация о поддержке 567
Оценка спецификации SRS для проекта 570
Корректность 570
Однозначность 570
Завершенность 571

16 Содержание
Согласованность 572
Упорядочивание элементов согласно их важности и/или устойчивости 572
Степень устойчивости 572
Степень необходимости 573
Возможность верификации 573
Способность к изменению 573
Возможность трассировки 574
Полезные советы 574
Резюме 574
Контрольные вопросы 575
Практическое занятие 575
Литература 575
Дополнительные сведения в Internet 576
Глава 18. Определение рисков, связанных с выполнением
проекта 577
Стадии жизненного цикла разработки продукта 578
Связь главы 18 с 34 компетенциями 578
Учебные цели главы 18 580
Определение управления рисками 580
Модели управления рисками 584
Проектные риски и Институт SEI 587
Идентификация рисков 588
Качественные и количественные методики оценки риска 591
Контроль рисков, проявляющихся при разработке ПО 593
Категории риска 596
Этапы разработки плана по управлению рисками 598
Этап 1 599
Этап 2 599
Этап 3 599
Этап 4 609
Этап 5 609
Резюме 610
Контрольные вопросы 610
Практическое занятие 611
Дополнительные сведения в Internet 612
Инструменты, обеспечивающие управление рисками 612
Литература 612
Глава 19. Введение в программный инжиниринг 613
Стадии жизненного цикла разработки продукта 614
Связь главы 19 с 34 компетенциями 615
Учебные цели главы 19 616
Определение программного инжиниринга в модели SEI СММ 616
ПО, инжиниринг и программный инжиниринг 619
Основы знаний в области программного инжиниринга 623
Документ SWEBOK и модель SEI СММ 627

Содержание 17
Документ SWEBOK и 34 компетенции, связанные с управлением программными
проектами 639
Документ SWEBOK и управление качеством программных проектов 655
Резюме 666
Контрольные вопросы 666
Практическое занятие 666
Литература 667
Дополнительные сведения в Internet 668
Глава 20. Обеспечение надежности ПО 669
Стадии жизненного цикла разработки продукта 672
Связь главы 20 с 34 компетенциями 675
Учебные цели главы 20 675
Термины, используемые при определении надежности ПО 676
Прогнозирование ошибок 677
Предотвращение сбоев 680
Устранение ошибок 681
Отказоустойчивость 683
Инструменты, обеспечивающие надежность ПО 685
План обеспечения надежности ПО 686
Резюме 688
Контрольные вопросы 689
Практическое занятие 690
Стандарты 690
Инструменты 691
Литература 691
Дополнительные сведения в Internet 691
Глава 21. Метрические показатели, применяемые при оценке
размера программ 692
Стадии жизненного цикла разработки продукта 693
Начало работы над проектом и этап планирования 693
Мониторинг и управление проектом 694
Управление качеством ПО 696
Аттестация и верификация 696
Процесс обучения 696
Связь главы 21 с 34 компетенциями 696
Учебные цели главы 21 697
Определение метрического показателя 698
Классы измеряемых программных объектов 699
Измерительные шкалы 700
О значении метрических показателей в программных проектах 702
Метрические показатели и модель SEI СММ 704
Второй уровень модели SEI СММ — повторяемый 70:
Ключевая область процесса — управление программными требованиями 705
Ключевая область процесса: планирование программного проекта 705
Ключевая область процесса: отслеживание и реализация контроля за
выполнением программного проекта 706
а

18 Содержание
Третий уровень модели SEIСММ — определенный 706
Ключевая область процесса — программа обучения 706
Ключевая область процесса — программный инжиниринг 706
Чстверт ый уровень модели SEI СММ — управляемый 707
Полезные метрические показатели 709
Парадигма Бейзили — цель/вопрос/метрический показатель 710
Этап 1 GQM — определение набора целей 711
Этап 2 GQM — определение набора вопросов, характеризующих цели 714
Этап 3 GQM — определение метрических показателей, необходимых для
получения ответа на вопросы 715
Этап 4 GQM — разработка механизмов сбора данных 717
Этап 5 GQM — сбор, подтверждение и анализ данных в реальном времени
для поддержки обратной связи между корректирующими действиями
и проектами 718
Этап 6 GQM — анализ данных с использованием подпрограммы для оценки
соответствия целям и рекомендации для дальнейшего совершенствования 721
Этап 7 GQM — поддержка "обратной связи" для организаторов проекта 721
Начальный набор основных метрических показателей 726
Трудозатраты 727
Обзоры 730
О чем могут "рассказать" данные обзора? 731
Запросы на изменение 734
Какую информацию содержат данные об измененных запросах? 736
Данные о трудозатратах и запросах на изменения 738
Аспекты измерений, отражающие качество ПО 738
План выполнения измерений 742
Резюме 742
Контрольные вопросы 744
Практическое занятие 744
Литература 744
Дополнительные сведения в Internet 748
Глава 22. Методы анализа и разработки проекта 749
Стадии жизненного цикла разработки продукта 750
Связь главы 22 с 34 компетенциями 750
Учебные цели главы 22 752
Анализ/разработка проекта и модель SEI СММ 753
Структурный анализ/разработка проекта (SA/SD) 755
Структурный анализ SA/SD: модели данных 759
Структурный анализ SA/SD: модели процессов 774
Структурированная разработка проекта SA/SD: структурные диаграммы 792
Диаграмма Чейпина: модель для разработки на нижнем уровне 808
Объектно-ориентированный анализ/разработка проекта(ООА/ООБ) 812
Унифицированный язык моделирования 816
Объектно-ориентированный анализ 817
Объектно-ориентированная разработка проекта 826
Общие черты анализа SA/SD и OOA/OOD 833
Резюме 834

Содержание 19
Обзор: этапы структурного анализа и разработки проекта 834
Обзор: этапы объектно-ориентированного анализа/разработки проекта 836
Контрольные вопросы 837
Практическое занятие 839
Литература 840
Дополнительные сведения в Internet 842
Глава 23. Аттестация и верификация 843
Обзоры, инспекционные проверки и сквозной контроль 844
Тестирование 845
Стадии жизненного цикла разработки продукта 847
Связь главы 23 с 34 компетенциями 848
Учебные цели главы 23 850
Статическое тестирование: обзоры 850
Экспертные оценки и модель SEIСММ 851
Определения, применяемые в процессе статического тестирования 852
Для чего нужен обзор? 854
Цели обзора 863
Когда выполняется обзор? 865
Кто принимает участие в проведении обзоров? 865
Как выполняется обзор? Что представляет собой процесс обзора? 866
Метрические показатели обзора 873
Обзоры и анализ тенденций 874
Риски, связанные с невыполнением обзоров 874
Оценка качества инспекционной проверки ПО 876
Вопросы, рассматриваемые при осуществлении обзоров 877
Резюме по статическому тестированию с применением обзоров 878
Динамическое тестирование 879
Цель тестирования 880
Разработчики и процесс разрушения 880
Отладка 881
Непрерывный процесс тестирования 882
Выполнение тестирования в рамках V-образного жизненного цикла
разработки ПО 882
Определения, применяемые в процессе динамического тестирования 884
Типы тестов 889
Направленный потоковый граф: анализ цикломатической сложности Мак-Кейба 901
Ребра - узлы + 2 903
Подсчет ограниченных зон 903
Предикативные узлы + 1 904
Описание утверждений 907
Выбор решений 907
Проверка условий 908
Проверка и принятие решений/условий 908
Проверка множественных условий 909
Приемочное испытание пользователем и тестирование практической пригодности 910
Требования практической пригодности 911
Обратная связь с пользователями 912

20 Содержание
Выполнение идеального тестирования 913
Процесс тестирования 917
Команды тестеров 919
Тестовая документация 920
Динамическое тестирование: оценка, составление отчетов и принятие решений 921
Метрические показатели тестирования 922
Решения, связанные с необходимостью проведения тестирования 923
< Кн.сктно-ориентированное тестирование 923
. подка по динамическому тестированию 924
i'-uuMe 925
i' г |»>льныс вопросы 926
.ч; шческое занятие 926
ч нратл'ра
927
'!• и1».1Ш1тслы1ые сведения в Internet 929
; лава 24. Использование инструментов 931
i ■[ адии жизненного цикла разработки продукта 934
N чебиые цели главы 24 935
11нструмепты по определению требований к ПО 936
Моделирование требований — модель СММ, второй уровень и выше 936
Трассировка — модель СММ, второй уровень и выше 937
11нструменты по разработке проекта ПО 937
Моделирование проекта — модель СММ, третий уровень и выше 938
Верификация проекта — модель СММ, четвертый уровень и выше 938
Оптимизация проекта — модель СММ, четвертый уровень и выше 938
1 Inn рументы по конструированию ПО 938
Редакторы программного кода — модель СММ, первый уровень и выше 939
Компиляторы — модель СММ, первый уровень и выше 939
Интерпретаторы — модель СММ, первый уровень и выше 939
Отладчики — модель СММ, первый уровень и выше 940
Инструменты по выполнению тестирования 940
Генераторы тестов — модель СММ, первый уровень и выше 940
Схемы выполнения тестов — модель СММ, первый уровень и выше 942
Оценка тестов — модель СММ, второй уровень и выше 942
Управление процессом тестирования — модель СММ, второй уровень и выше 943
Анализ производительности — модель СММ, третий уровень и выше 943
Инструменты по сопровождению ПО 945
Обеспечение понимания — модель СММ, пятый уровень 945
Повторный инжиниринг — модель СММ, пятый уровень 947
Инструменты по управлению конфигурацией программ — модель СММ,
второй уровень и выше 947
11пструмспты, применяемые в процессе программного инжиниринга в
жизненном цикле разработки ПО 948
Инструменты, связанные с процессом программного инжиниринга 948
Управление процессом — модель СММ, четвертый уровень и выше 949
Моделирование процесса — модель СММ, третий уровень 950
Интегрированные CASE-среды — модель СММ, четвертый уровень 950

Содержание 21
Среды программного инжиниринга с центрированными процессами —
модель СММ, пятый уровень 95]
Инструменты по обеспечению качества ПО 951
Контроль — модель СММ, третий уровень и выше 951
Статический анализ — модель СММ, четвертый уровень и выше 951
Инструменты по управлению разработкой ПО 952
Планирование и отслеживание проекта — модель СММ, второй уровень и выше 952
Управление рисками — модель СММ, второй уровень и выше 952
Измерение — модель СММ, второй уровень и выше 953
Инструменты поддержки инфраструктуры 95.3
Межличностные взаимодействия — модель СММ, первый уровень и выше 953
Выборка информации — модель СММ, второй уровень и выше 953
Системное администрирование и поддержка — модель СММ, второй уровень
и выше 953
Дополнительные вопросы применения инструментов 954
Методики интеграции инструментов — модель СММ, третий уровень и выше 954
Мета-инструменты — модель СММ, первый уровень и выше 954
Инструментальная оценка — модель СММ, третий уровень и выше 955
Минимальные наборы инструментов 956
Резюме 9fi0
Контрольные вопросы 960
Практическое занятие 901
Инструменты 962
Литература 964
Дополнительные сведения в Internet 964
Глава 25. Отслеживание и контроль в процессе выполнения
проекта 966
Стадии жизненного цикла разработки продукта 966
Связь главы 25 с 34 компетенциями 966
Учебные цели главы 25 968
Контролирующие системы 968
Контроль, управление и составление отчетов о процессе 969
Информационная система управления проектами 970
Менеджмент области действия проекта 97]
Матрица гибкости 973
Управление графиком 973
Перечни стадий 974
Устранение и быстрое отслеживание 974
Управление затратами 977
Базовая линия стоимости 977
Построение базовой линии стоимости 984
Управление качеством 985
Менеджмент выполняемых работ 986
Менеджмент прибавочной стоимости 986
Оценка критической цепи 997
Управление рисками 999
Резюме 999

22 Содержание
Контрольные вопросы 999
Практическое занятие 999
Литература 1000
Дополнительные сведения в Internet 1000
Глава 26. Непрерывное совершенствование процессов
разработки ПО 1001
Глава 27. Прерывание выполняемого проекта 1002
Глава 28. Анализ эффективности выполнения проекта 1003
Глава 29. Отчетность и общение 1004
Глава 30. Обеспечение качества ПО 1005
Глава 31. Менеджмент конфигурации ПО 1006
Глава 32. Правовые вопросы, возникающие при разработке ПО 1007
Глава 33. Резюме 1008
Методики, применяемые при разработке программных продуктов 1009
Процесс 1009
Жизненные циклы 1010
Предметная область 1016
Спецификации требований к ПО 1018
Программный инжиниринг 1019
Анализ и разработка проекта 1020
Инструментальные средства разработки ПО, включая менеджмент
конфигураций 1025
Постоянное совершенствование процесса разработки программ 1027
Навыки но управлению проектом 1029
Определение целей проекта 1029
Оценивание затрат и масштабов проекта 1034
Риск, связанный с проектом, и обеспечение качества 1034
Надежность 1047
Аттестация и верификация 1047
Завершение проекта 1048
Навыки но управлению персоналом 1052
Отбор команды разработчиков 1052
Оценивание длительности и стоимости проекта 1052
Распределение обязанностей 1053
Выработка технических требований к программному продукту 1054
Метрические показатели, относящиеся к ПО 1056
Правовые вопросы 1057
Практическое занятие 1061
Приложение А. Организации, поддерживающие разработку ПО 1062
Приложение В. Реальные проекты 1063
Приложение С. Создание бизнес-плана 1064

Содержание 23
Приложение D. Основы системного инжиниринга 1065
Приложение Е. Дистанционное управление проектами 1066
Приложение F. Шаблоны компонентов проекта 1067
Приложение G. Организация совместной разработки
приложений 1068
Словарь терминов 1069
Словари терминов по управлению качеством 1069
Словари терминов по программному инжинирингу 1069
Словари терминов по управлению проектами 1069
Словарь терминов, используемых в книге 1070
Литература 1081
Книги 1081
Дополнительные сведения в Internet 1099
Анализ и разработка проектов 1099
Создание пооперационного перечня работ 1100
Модель зрелости возможностей и непрерывное совершенствование процесса
разработки 1100
Менеджмент конфигурации 1101
Оценка затрат и трудозатрат 1101
Вопросы лидерства 1102
Управление субподрядчиками, интеллектуальная собственность и другие
юридические вопросы 1102
Формы и шаблоны 1103
Общие вопросы 1103
Взаимодействие и общение 1104
Основные выводы 1105
Жизненные циклы 1105
Метрические показатели 1106
Управление проектами: документирование планов проектов, составление
графика, мониторинг процесса разработки и отслеживание хода выполнения
проекта 1107
Команды разработчиков проектов 1108
Журналы 1108
Вопросы обеспечения качества 1108
Надежность 1109
Требования 1110
Риски 1111
Программный инжиниринг — определение продукта и понимание действий
по разработке 1111
Стандарты 1112
Инструменты 1112
Аттестация и верификация 1115
Предметный указатель 1117

Вступление
Несколько лет назад коллега из консалтинговой фирмы, предоставляющей
консультации по вопросам управления проектами, пригласил меня выступить на
ежемесячном собрании местного отделения софтверной компании. Оказалось, что это
приглашение имело скрытую подоплеку. Фирма выполняет работу в рамках большого
проекта для солидного заказчика, поэтому его представители хотели бы посетить мое
выступление.
В частном разговоре меня проинформировали о возникновении некоторой
неоднозначной ситуации. Суть проблемы заключалась в том, что фирма пользуется услугами
множества программистов, аналитиков, специалистов по сетям, разработчиков баз дан-
пых и другого технического персонала, задействованного в проекте. Причем заказчик
оплачивает результаты их труда, ие задавая лишних вопросов. Но когда он услышал
о том, что требуются услуги менеджера проекта, а также некоторого персонала,
выполняющего вспомогательные работы в рамках менеджмента проекта, то предпочел
проигнорировать это предложение. При этом выражались сомнения по поводу
целесообразности выполнения подобных действий. Описанная ситуация достаточно типична,
поскольку заказчик выражает распространенное мнение относительно того, что
менеджмент проектов не имеет особого практического смысла. Как оказалось, задача
моего выступления заключалась в том, чтобы доходчиво рассказать о важности
менеджмента проектов, мотивируя необходимость оплаты подобных услуг.
Возможно, что если бы эта ситуация сложилась в середине 1960-х годов, ничего
удивительного в этом не было бы. В конце концов, как отмечают в первой главе книги
Фатрелл и Шафер (Futrell, Shafer), подобная ситуация была типичной вплоть до 1968
года. Именно тогда состоялась известная конференция NATO, посвященная
проблемам программного инжиниринга. Один из результатов этой конференции проявился
is том, что проблема управления проектами получила некоторый резонанс в
обществе, особенно после того, как разразился так называемый "кризис ПО". Даже в 1975
или 1985 году встречались менеджеры компаний, которые не осознавали того
простого факта, что для успешного внедрения программных проектов требуется нечто
большее, чем армия умных и технически грамотных людей. Я столкнулся с этой
проблемой уже и конце XX века и подозреваю, что она периодически возникает и сейчас.
Именно это обстоятельство привело к появлению книги Управление программными
проектами: достижение оптимального качества при минимуме затрат.

Вступление 25
Иллюзия о ненужности управления проектами для успешного выполнения
программного проекта не намного опаснее, чем традиционное представление о том, что
управление проектами является простым и легко осваиваемым делом. Причем со всем
этим может справиться любой "чайник". В результате беглого просмотра
содержимого Web-узла Amazon. com можно обнаружить около полдюжины книг на эту тематику,
названия которых практически не отличаются. Скорее всего, при написании этих
книг преследовались вполне конструктивные цели, хотя лично я весьма сомневаюсь в
том, что 22-летний программист, специализирующийся на Java и обладающий
двухлетним опытом работы в своей области, которому "светит" повышение до менеджера
проекта, сможет преуспеть в условиях разработки нетривиального проекта (при
условии освоения материала подобной книги).
Процесс служебного роста до уровня настоящего менеджера проекта является не
столь уж быстрым и простым. Поэтому позвольте мне высказать мнение
относительно того, что звание менеджера программного проекта вовсе не означает
достижение высокого уровня профессионализма при освоении такого программного
продукта, как Microsoft Project. Эта специфическая программа, подобно дюжине
других подобных продуктов, является лишь чрезвычайно полезным
инструментарием, обеспечивающим выполнение некоторых планирующих действий,
предпринимаемых в ходе осуществления проекта. Авторы книги описывают процесс
менеджмента проектами до мельчайших подробностей. Здесь можно найти не только
описание процесса построения диаграмм PERT и Ганта. Согласно утверждению
авторов, менеджеры проекта должны быть хорошо осведомлены о 34 ключевых
компетенциях в области управления проектами. Конечно, если позволяют
обстоятельства разработки проекта, можно не владеть одной/двумя компетенциями, однако
существует множество областей, знание которых просто необходимо для
претендентов на гордое звание "менеджеров проектов" в сложной предметной области
проектирования вычислительных и программных систем.
Авторы книги принимали участие в программе сертификации управления
программными проектами Института качества ПО, относящегося к Техасскому
университету в Остине. В идеале организациям, занимающихся разработкой программных
проектов, следовало бы командировать "неоперившихся" менеджеров проектов с
целью "погружения" в учебный курс менеджмента. Подобное обучение не помешает п
опытным менеджерам проектов (большинство из которых имеют лишь
поверхностные знания о 34 ключевых компетенциях, причем этот опыт был получен
непосредственно на рабочем месте). Но для тех, у кого нет времени, или чьи руководители не
располагают достаточным объемом средств или не прислушиваются к собственном
интуиции, лучшим выходом является изучение книги Управление программными пром.
томи: достижение оптимального качества при минимуме затрат.
Вряд ли стоит прочесть эту книгу за "один присест". Она не относится к категории
бестселлеров, призванных скрашивать скуку трансатлантических перелетов. Это
даже не "книга выходного дня", уместная где-либо на пляже. Вам придется
пожертвовать часом/двумя каждый вечер в течение нескольких недель или месяцев с целью
освоения всех руководящих принципов, контрольных списков, процедур и советов,
предоставляемых высококвалифицированными практиками, исследующими вопросы
управления программными проектами. Также придется воспользоваться
информацией, находящейся на Web-узле, и дополнительными ресурсами, указанными авторами.
В результате вы постепенно придете к осознанию того факта, что этому искусству
можно учиться вечно.

26 Вступление
Когда я начинал свою карьеру в качестве программиста (в середине 60-х годов XX
века), мне хотелось стать лучшим в мире программистом на языке ассемблера. Хотя
компьютер, на котором я работал в то время, уже давно перешел в разряд
антиквариата, приобретенные в тот период навыки программирования, тестирования либо
проектирования баз данных до сих пор служат мне добрую службу. В любом случае
многие из нас осознают, что управление проектами является не менее важным, чем
технические навыки, способствующие реализации этих проектов на практике.
Достаточно поработать с несколькими проектами, чтобы осознать, что успех или неудача
при реализации проекта на практике в гораздо большей степени определяются
проблемами, возникающими в процессе менеджмента, чем чисто техническими
проблемами. Лично мне потребовалось почти десятилетие для изменения имеющихся
предпочтений и приоритетов. Простого желания стать менеджером проекта
недостаточно. К сожалению, в свое время у меня не было под рукой подобной книги, которая
позволила бы заложить базу для приобретения навыков и умений, которые в
противном случае пришлось бы добывать "потом и кровью". Что же касается вас, дорогой
читатель, радуйтесь — в вашем распоряжении имеется подобная книга, и если вы ее
внимательно читаете и тщательно изучаете, то процесс обучения не только
ускорится, по для вас будут исключены некоторые досадные промахи, случающиеся в
процессе разработки проектов!
Эд Иордон (Ed Yourdon)
Сентябрь, 2001 г.

Предисловие
Книга Управление программными проектами: достижение оптимального качества при
минимуме затрат была написана практиками и предназначается для профессионалов
в области разработки ПО, которые нуждаются в практическом руководстве,
позволяющем быстро и безошибочно выполнять задачи менеджмента программных
проектов. Структура книги напоминает успешную программу сертификации управления
программными проектами проектов (Software Project Management, SWPM),
принадлежащей Институту качества ПО, относящегося к Техасскому университету в Остине
(отделение Центра непрерывного технического образования технического колледжа
(Center for Lifelong Engineering Education, CLEE)).
Менеджеры программных проектов и возглавляемые ими команды разработчиков
играют решающую роль в реализации успешного функционирования современных
фирм и предприятий, независимо от того, относятся или не относятся они к
категории высокотехнологичных. Профессионалы, владеющие надежными методами
менеджмента реализации полного цикла разработки ПО, а также внедрения улучшений
и совершенных технологических процессов, могут определять успех или неудачу
бизнеса в каждой отдельно взятой организации.
Тенденция к повышению качества ПО привела к распространению новых
стандартов, гарантирующих соответствие процессов разработки ПО определенным
характеристикам. Сертификаты соответствия стандартам становятся все более
привычными, поскольку покупатели требуют выполнения более жесткого контроля
качества. Менеджеры, руководящие разработкой программных проектов, должны быть
ознакомлены с имеющимися стандартами. В данном случае может идти речь,
например, о стандартах Института инженеров по электротехнике и электронике (Institute
of Electrical and Electronics Engineers, IEEE), а также о непрерывно появляющихся
методиках, частично обеспечиваемых моделью зрелости возможностей (Capability
Maturity Model, CMM), которая разработана Институтом программного инжиниринга
(Software Engineering Institute, SEI). Также следует учитывать то, что в последнее
время проявляется тенденция в направлении менеджмента небольших по размеру
проектов.
Именно с учетом этих тенденций технический колледж Техасского университета
и относящийся к нему Институт качества ПО (Software Quality Institute, SQI) в 1993
году разработали программу сертификации SWPM. С тех пор сотни менеджеров

:iti Предисловие
программных проектов прошли курс обучения в рамках этой программы. Благодаря
этому они начали применять "оптимальные методы" в целях преодоления
ограничений, связанных с недостатком рабочей силы, а также с учетом адаптации к быстро
изменяющимся потребностям заказчиков на современном рынке,
характеризующимся высоким накалом конкурентной борьбы. Здесь вы найдете "конгломерат" учебных
материалов, связанных с упомянутой выше программой сертификации.
В дополнение к знанию принципов разработки ПО, менеджеры программных
проектов должны обладать навыками по управлению персоналом, продуктами и
процессами. Учитывая эти обстоятельства, при написании настоящей книги
применялись два взаимосвязанных принципа, разработанных такими известными
организациями, как Институт управления проектами (Project Management Institute, PMI,)
и Американская организация по обеспечению качества (American Society for Quality,
ASQ_). Инструкторы по обеспечению качества ПО (SQI instructors), многие из
которых являются сертифицированными инженерами по обеспечению качества ПО
;(.citified Software Quality Engineer, CSQE) и профессионалами в области управления
проектами (Project Management Professional, PMP), детализируют материал,
наработанный этими двумя организациями, и привносят в него свой собственный опыт,
полученный благодаря применению наиболее современных методов, которые в течение
десятилетий применяются в промышленности. Качество, практичность,
своевременность, мобильность и доходность являются главными параметрами, которым уделяет-
1 и основное внимание в программе сертификации SWPM и в этой книге, в основу ко-
1 орой положены основные концепции программы.
Принципы программного инжиниринга и задачи обеспечения качества ПО
являют! я необходимыми, но не достаточными условиями, позволяющими быть на уровне
: реноваций современного рынка. При этом необходимо сокращение длительности
производственных циклов, а также минимизация требуемых ресурсов. Необходима
i пепельная адаптация программных продуктов в соответствии с определенными
■ {^нкцнональными требованиями заказчиков. Разработчики ПО и менеджеры,
имеющие дело с серьезными и зачастую противоречивыми целями, должны иметь
высокую квалификацию в деле планирования, координации и руководства
программными проектами. Им следует знать о технологиях применения лучших методов при
выполнении текущих проектов, а также воспользоваться преимуществами прошлого
опыта работы при подготовке планов будущих проектов. Надлежащая оценка
производительности при разработке проектов необходима в той же степени, что и навыки
лидерства в команде. Кроме того, менеджеры программных проектов должны видеть
"общую картину" проекта, поскольку с этим напрямую связаны перспективы их
профессионального роста.
Книга Управление программными проектами: достижение оптимального качества при
минимуме затрат является практическим результатом основанной на опыте фана-
1 ичиой веры авторов в то, что при определенном подходе разработка
качественного ПО может быть вполне предсказуемой. Как показано на рис. 0.1, методы,
инструменты и технологии взаимосвязаны с помощью сложных и детерминированных
методов. При этом требуется внедрение процесса, позволяющего достичь
требуемого баланса. Перечисленные три фактора оказывают серьезное влияние на
качество, ПО и управления проектами в целом. В связи с этим они будут упоминаться на
протяжении всей книги. Метод определяется как образ действий, средства или
процесс, применяемый для выполнения каких-либо действий. Инструмент определен как

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

30 Предисловие
Несмотря на то, что эта книга основана на материалах курса SWPM, она не
представляет собой продукт простой компиляции этих материалов. Определенный
совместный опыт авторов книги (составляющий почти 100 лет) чувствуется на каждой
странице книги. При написании этого руководства была предпринята попытка
создания единого "сплава", сочетающего идеи и мысли тридцати инструкторов. В каждой
главе книги можно найти практические занятия, в ходе выполнения которых
читатель сможет решить большинство проблем общего характера, встречающихся при
разработке программных проектов. Сценарий разработки проекта отражает все
более настоятельную потребность в ускорении разработки ПО, диктуемой эпохой
"всеобщей глобализации".
Используйте это руководство в качестве
учебного пособия
Если вы участвуете в интерактивных или в аудиторных занятиях по программе
сертификации управления программными проектами Института качества ПО
Техасского университете в Остине, эта книга сможет стать вашим главным учебным
пособием. Если вы — профессор или преподаватель курсов программистов, материал
книги обеспечит проведение семестрового курса по разработке программ наравне с
курсом управления проектами. Здесь представлены основы управления проектами,
программного инжиниринга и технологии обеспечения качества ПО. Материал этой
книги признан несколькими профессиональными организациями (IEEE, SEI, PMI,
ASQ). Если вы— студент группы, специализирующейся на управлении проектами и
программном инжиниринге, вам будет приятно узнать о том, что эта книга принад-
лелсит перу настоящих профессионалов и ветеранов в области программирования.
Благодарности
Мне бы хотелось лично поблагодарить сотрудников Техасского университета в
Остине, Центра непрерывного технического образования, персонал Института
качества ПО за их энергичную, последовательную и постоянную помощь. Они
предоставили нам последние одиннадцать документов программы сертификации управления
программными проектами. Также они смогли оказать нам профессиональную,
разумную и эффективную помощь при разрешении многих практических вопросов.
Большое спасибо Кэнди Уолсэр-Берри (Candy Walser-Berry), Мэрилин Робертсон (Marilyn
Robertson), Терезе Лестинги (Theresa Lestingi), Хизер Вагнер (Heather Wagner),
Джейн Тьюн (Jayne Tune), Кэролайн Старк (Carolyn Stark). Практическое занятие,
посвященное исследованию экономических показателей работы Китайской железной
дороги, стало реальным благодаря оригинальной работе Джека Одома (Jack Odom), a
также участию Джона Макнейла (John McNeill). Представители компании Athens
Group предоставили материал для приложения В, а также снабдили нас обширным
массивом метрических данных. Инструкторы, которые занимались подготовкой курса
SWPM, заслуживают особой похвалы — многие из них упоминаются в ссылках
отдельных глав. Мы признательны представителям SQI Board of Advisors, которые
посвятили свое время (начиная с 1993 года) разработке программы по достижению высокого
уровня качества. Спасибо Полю Петралия (Paul Petralia) и Дженнифер Блэкуэлл
(Jennifer Blackwell) из издательства Prentice Hall, а также Барри Баслеру (Barry Busier)
из IBM. Мы также ценим и благодарим наших детей за поддержку нашей группы.

В октябре 1968 года в немецком городе Гармиш (Garmish) прошла конференция
подкомитета NATO по науке и технике. На этой конференции присутствовало
пятьдесят профессиональных разработчиков ПО из одиннадцати стран. Наряду с тем, что
большинство обсуждений было сосредоточено на технических аспектах
проектирования, производства, реализации, распространения и поддержки программ, также
рассматривались отчеты о "трудностях планирования встреч и заданий в больших
программных проектах". Это, возможно, было первое общественное признание
важности управления программными проектами. Вскоре после этого в Хедсор Парк
(Hedsor Park), уединенном местечке вблизи Лондона, собрались двадцать два
руководителя из различных стран, которые курировали разработку ПО в академиях, научно-
исследовательских лабораториях и на предприятиях. На этой встрече упоминалось
о конференции NATO, а также производился анализ будущих направлений развития
процесса разработки ПО. Здесь специалисты впервые серьезно заговорили о
надвигающемся "кризисе ПО". Он был связан со все более усиливающимся воздействием
ПО на жизнь людей, вследствие чего процессы разработки требовали постоянного
усовершенствования. В рамках этого была предложена концепция жизненного
цикла разработки ПО (Software life cycle, SLC). Эта модель реализует
последовательность событий, происходящих при разработке ПО. Определение цикла SLC, равно
как и споры относительно смысла его существования, было предметом многих бесед
и публикаций, связанных с индустрией ПО. Накопившиеся к концу 70-х годов
прошлого века противоречия привели к появлению лозунга: "Остановите жизненный
цикл, я хочу выйти!" Несмотря на существование различных точек зрения,
потребность в документально подтвержденном процессе разработки ПО осталась столь же
актуальной. В 1970 году У.У.Ройс (W.W.Royce) произвел идентификацию нескольких
стадий в типичном цикле SLC. Именно Ройс и Барри Боэм (Barry Boehm)
предположили, что осуществление контроля каждой стадии процесса разработки приведет
к улучшению качества ПО, а также к увеличению производительности при разработке
программ. Например, работа по проектированию интерфейсов программного модуля

32 Глава 1
может быть отложена до тех пор, пока не будут определены конечные требования.
Благодаря этому сокращается количество возможных переделок. В этом случае идет
речь о каскадной модели цикла SLC (см. рис. 1.1). Действия по разработке ПО
"протекают" на графике последовательно, от блока к блоку.
Исследование
концепции
Исследование
системы
Требования
Разработка
проекта
Внедрение
Установка
Эксплуатация
и поддержка
Сопровождение
Вывод из
эксплуатации
Рис. 1.1. Каскадная модель жизненного цикла разработки ПО (SLC)
На самом деле, большинство действий в ходе выполнения проектов не происходят
по линейному закону. Зачастую разработчикам бывает необходимо возвратиться к
предыдущей стадии, чтобы выполнить задачи, которые не были в свое время
разрешены соответствующим образом. Если на стадии разработки обнаруживается
отсутствие или неправильное формулирование требований, разработчик не продвигается
вперед, а возвращается назад — к стадии спецификаций требований. После
завершения и коррекции спецификаций требований повторно вводится и начинает
выполняться стадия разработки. Чтобы отобразить повторяющийся характер разработки
ПО. в графике рис. 1.1 были добавлены обратные стрелки, в результате чего получил-
с я график стандартного жизненного индустриального цикла, показанный на рис. 1.2.
И настоящее время многие пользователи пришли к выводу, что каскадная модель
старомодна, упрощена и не отражает современных требований. Уже само ее название

Введение 33
Исследование
концепции
Исследование
системы
Требования
Разработка
проекта
Внедрение
Установка
Эксплуатация
и поддержка
Сопровождение
Вывод из
эксплуатации
Рис. 1.2. Повторяющаяся каскадная модель жизненного цикла разработки ПО (SLC)
вызывает противоречивые чувства, поскольку вода в каскаде не может
"перемещаться" вверх в соответствии с обратными стрелками. Как правило, все новые
модели разрабатывались с целью лучшего отображения устройства реального мира с
л'четом большой скорости разработок ПО, либо для вовлечения клиентов в процесс
разработки с целью улучшения функциональных возможностей создаваемых
программ. Для решения этих проблем появилась спиральная модель, быстрая
эволюционная модель прототипирования, V-образная модель, а также некоторые другие
модели. Большинство практиков вполне согласны с тем, что на сегодняшний день
существует настолько много различных типов проектов, что в рамках одномерной модели
SLC они вряд ли могут быть описаны. Современная точка зрения заключается в том,
что необходимо использовать уникальные модели или комбинации моделей для
уникальных проектов. Выбор соответствующих моделей SLC или модифицированных
версий моделей SLC рассматривается в главе 4. В главе описываются несколько
современных моделей SLC, а также принципы их выбора. Кроме того, в главе 4 будут
рассмотрены группы процессов из руководства Основы знаний в области управления
проектами {Project Management Body of Knowledge®, PMBOK®)— процессы инициализации,

34 Глава 1
планирования, выполнения и завершения. Также анализируется, каким образом эти
процессы представлены на стадии жизненного цикла разработки ПО.
Для упрощения дальнейшего изложения действия, выполняемые в рамках проектов,
будут описываться в каждой главе этой книги с их привязкой к общей модели жизненного
цикла, реализованной в виде каскадной модели с повторениями. Хотя многие
программные приложения значительно изменились по сравнению с 70-ми годами прошлого века,
десятки тысяч разработчиков осваивали язык первого цикла SLC, включив его в своего
свой общий словарь. Термины фаза, повторение, критерии ввода и вывода, исследование
концепции, сопровождение и т.д., были унаследованы последующими поколениями аналитиков,
проектантов и программистов. Независимо от программного проекта, его масштаба или
характеристик, реализуются фазы исследования концепции с учетом процесса "вывода из
эксплуатации". "Старый добрый" цикл SLC "фотографирует" фазы проекта, независимо от
их продолжительности. Здесь также описывается, каким образом каждая из глав книги
может применяться в процессе разработки ПО.
Тридцать четыре необходимые
компетенции. Введение
На ранних стадиях управления программными проектами на роли менеджеров
проектов выдвигались лучшие программисты. Это было связано с тем, что они
демонстрировали компетентность в вопросах, касающихся, использования инструментов (языки
программирования, компиляторы и т.д.) или приложений, выполняющихся в режиме
реального времени. Но зачастую они не преуспевали в этой должности, поскольку не
были подготовлены к возникновению ситуаций, не относящихся к их предметной
области. Сегодня каждом)' менеджеру программного проекта требуются навыки, далеко
выходящие за пределы познаний о принципах программирования. Опыт в деле
разработки ПО, конечно, необходим, но хороший менеджер также должен превосходить
друтих специалистов в навыках управления персоналом и проектами.
Мы составили перечень компетенций, используемых менеджерами наиболее
успешных программных проектов и разбили их на три категории: продукт, проект и
персонал, как показано на рис. 1.3. Этот перечень основывается на опыте многих
практикующих менеджеров программных проектов, которые вносили вклад в
программу сертификации менеджмента программных проектов (SWPM) в Техасском
университете с 1993 по 2001 годы. Этот перечень содержится в документе Body of
Knowledge (SQI BOK), разработанный Институтом качества ПО.
Каждая из этих категорий более подробно обсуждается в оставшейся части
вводной главы, а затем будет показано, как использовать каждую из этих компетенций в
различных ситуациях. Многие из этих методов и компетенций будут также
проиллюстрированы в различных историях и анекдотах.
Методики разработки продукта
1. Процессы оценивания — определение критериев для обзора.
2. Знание стандартов процесса — понимание стандартов процесса.
3. Определение продукта— идентификация клиентской среды и требований,
выдвигаемых к продукту.
4. Оценка альтернативных процессов — оценка различных подходов.

Введение 35
Управление программными проектами
Продукт
1. Процессы оценивания
2. Знание стандартов процесса
3. Определение продукта
4. Оценка альтернативных
процессов
5. Управление требованиями
6. Управление субподрядчиками
7. Выполнение начальной оценки
8. Отбор методов и инструментов
9. Подгонка процессов
10. Отслеживание качества
продукта
11. Понимание действий по
разработке продукта
Проект
12. Создание структуры
пооперационного перечня работ
13. Документирование планов
14. Оценка стоимости
15. Оценка трудозатрат
16. Менеджмент рисков
17. Отслеживание процесса разработки
18. Составление графика
19. Выбор метрических показателей
20. Отбор инструментов менеджмента
проектов
21. Отслеживание процессов
22. Отслеживание хода разработки
проекта
Персонал
23. Оценка производительности
24. Вопросы интеллектуальной
собственности
25. Организация эффективных
встреч
26. Взаимодействие и общение
27. Лидерство
28. Упраеление изменениями
29. Успешное ведение переговоров
30. Планирование карьерного роста
31. Эффективное представление
32. Набор персонала
33. Отбор команды
34. Создание команды
Рис. 1.3. Тридцать четыре компетенции, которыми должен владеть каждый менедзкер
программного проекта
5. Управление требованиями — мониторинг изменений требований.
6. Управление субподрядчиками— планирование, управление и осуществление
контроля.
7. Выполнение начальной оценки— оценка степени трудности, рисков, затрат и
создание графика.
8. Отбор методов и инструментов — определение процессов отбора.
9. Подгонка процессов — модификация стандартных процессов с целью
удовлетворения требований, выдвигаемых проектами.
10. Отслеживание качества продукта— контроль качества в процессе разработки
продукта.
11. Понимание действий по разработке продукта— изучение цикла разработки ПО.
Навыки менеджмента проектов
1. Создание структуры пооперационного перечня работ— создание структуры
WBS для проекта.
2. Документирование планов — идентификация ключевых компонентов.
3. Оценка стоимости — оценка стоимости завершения проекта.
4. Оценка трудозатрат — оценка трудозатрат, необходимых для завершения проекта.
5. Менеджмент рисков — идентификация, определение воздействия и обработка
рисков.
6. Отслеживание процесса разработки — контроль процесса разработки ПО.
7. Составление графика — разработка графика и ключевых стадий проекта.

36 Глава 1
8. Выбор метрических показателей — выбор И использование соответствующих
метрических показателей.
9. Отбор инструментов менеджмента проектов— методики, используемые при
выборе инструментов менеджмента проектов.
10. Отслеживание процессов — мониторинг совместимости среди членов команды
разработчиков.
11. Отслеживание хода разработки проекта — мониторинг хода разработки проекта
с помощью выбранных метрических показателей.
Навыки менеджмента персонала
1. Оценка производительности— оценка действий команды, направленных на
улучшение ее производительности.
2. Вопросы интеллектуальной собственности — понимание степени влияния
критических проблем.
3. Организация эффективных встреч— планирование и проведение
эффективных встреч.
4. Взаимодействие и общение— взаимодействие с разработчиками, высшим
руководством и другими командами.
5. Лидерство — обучение проектных команд для получения оптимальных
результатов.
6. Управление изменениями — обеспечение эффективного управления
изменениями.
7. Успешное ведение переговоров — разрешение конфликтов и успешное ведение
переговоров.
8. Планирование карьерного роста— структурирование и управление ходом
реализации карьеры.
9. Эффективное представление — эффективное использование письменных и
устных навыков.
10. Набор персонала — успешная вербовка и собеседование с членами команды.
11. Отбор команды — отбор высококомпетентных специалистов.
12. Создание команды— формирование, руководство и поддержка эффективной
команды.
Вариации описанных компетенций рассматриваются во всех главах книги.
■ главы привязаны к последовательности действий в жизненном цикле
разработки ПО;
■ каждая глава в этой книге начинается с указания, на какой фазе (фазах)
предмет обсуждения будет использоваться в жизненном цикле SLC. Например,
в главе 16 указывается, что рассматриваемое действие происходит, прежде
всего, на стадии формулирования требований, хотя оно может начинаться уже
на стадии исследования концепции и продолжаться при осуществлении стадии
разработки проекта;
■ ссылки на многие компетенции содержатся в каждой главе.

Введение 37
Некоторые основные термины
Перед объяснением категорий продуктов, процессов и персонала, в рамках
которых группируются 34 компетенции в области менеджмента (управления)
программных проектов (project management, PM), полезно определить несколько основных
терминов. Для лучшего понимания последующего материала будут представлены
описания и практические разработки ПО, управления проектами и процессами, в
дополнение к важным определениям, приведенных в примечании 1.1.
Примечание 1.1. Важные определения, относящиеся к управлению проектами
Некоторые термины могут быть не совсем понятными. Например, большинство
из 34 компетенций, описанных в этой книге, одинаково хорошо можно применять
и к проектам, и к программам. Поэтому эти термины можно использовать различным
образом. В зависимости от контекста сокращение МП может означать: менеджер
проекта, менеджмент проектов, программный менеджер или менеджмент программ.
Определение "менеджмента программных проектов"
Эта книга посвящена практике использования ПО, проекта и менеджмента. Какой
из этих терминов важнее, и что фактически означают эти слова? И как упомянутые
34 компетенции вписываются в эту концепцию? В последние годы многие авторы
занимались изучением этих вопросов. Для дальнейшего изложения материала
потребуются некоторые определения.
Ниже приводится их упрощенная интерпретация.
ПО -это программа (программы), которая является конечным продуктом проекта
(программного инжиниринга) (см. примечание 1.2.) В этом случае воспользуемся
терминологией, предложенной Институтом программного инжиниринга (Software
Engineering Institute, SEI) и Институтом инженеров по электротехнике и электронике
(Institute of Electrical and Electronics Engineers, IEEE). При этом мы также будем
использовать сведения, имеющие отношение к вопросам обеспечения качества. Эта
информация предоставляется Национальным институтом стандартов и технологий
(National Institute of Standards and Technology, NIST), Международной организацией

38 Глава 1
стандартов (International Organization for Standards, ISO), Американским
национальным институтом стандартов (American National Standards Institute, ANSI) и
Американским обществом обеспечения качества (American Society for Quality, ASQ).
Примечание 1.2. Определение ПО
Источник: www i'bart leby. com
no '"■'.,*'
I t*»*rtft &п/К*ъ*$^к „,# v ^У-»#«*^»>
Программы, процедуры и символические языки? которые управляют функциони
рованием аппаратных средств. ■» * <— л^л^^йз^,^» #*fiH^$nW*#f**v*waf
Проект— это большое или важное действие (или последовательность действий),
которое было запланировано заранее. "Схема" такого наименования кажется
несколько примитивной (см. примечание 1.З.). Для определения проекта используем
определение, данное Институтом управления проектами (Project Management
Institute®, PMI®) и Институтом IEEE.
Примечание 1.3. Определение проекта
Источник: www .m-w. com/cgi-b£n/di^tjorS^'rjfC Ж^-У^тИ'' |4S
Пр ект < - ^ •- у, \ г^&.Ижк,
1. Определенный план или pa3pa6oTKaiteoei^:fCXEMA£$&
2. Запланированное действие: (а) определеннымЪбразо^я'^ой
исследования; (b) большое, обыздо поддержанное пратштельс^
v днями действие; (с) задача или проблема? обычйб Поставленная nc'pjrf^рущЩ"'
студентов, которая затем выносйтсянаа)дага^нмймиввгги5й^^^^^^^.^^^
Менеджмент - это практика выполнения и управления проектом (см.
примечание 1.4). Для определения менеджмента вернемся к PMI® и общей практике
менеджмента в том аспекте, в каком она преподается в курсе на получение степени Магистра
управления бизнесом (Master of Business Administration, или MBA).
Примечание 1.4. Определение менеджмента
шшшшштт^ш
1. Акт или искусство менедж^ен^:П£р|да
^ случае с бизнесом). ;rW. Ф^;^,^тШ^^Ш^Ш^ФЩ1Ш^Ш^ФШ
2. Разумное использование средств7дая-Д.6ст^
8. Коллективный орган упр^влякщйк rij|<^^
Простое на первый взгляд понятие менеджмент (управление) программным проектом
предполагает наличие многих необходимых навыков. Как показано на рис. 1.8,
рассматриваемые 34 компетенции, а также термины продукт, проект и навыки
менеджмента персонала, коррелируют с терминами в названии этой книги — ПО, проект и
менеджмент, соответственно. Хотя термин качество присутствует в названии,
отсутствует отдельная категория компетенций, используемых при оценке качества, поскольку
они включены в полный набор компетенций.

Введение 39
Определение инжиниринга ПО
Согласно Барри Боэму (Barry Boehm), инжиниринг ПО - это практическое
применение научных знаний при разработке и создании компьютерных программ и
связанной с ними документации, необходимой для их разработки, использования и
поддержки . Институт IEEE определяет этот термин как систематический подход к
развитию, действию, поддержке и прекращению эксплуатации ПО . А Стефен Шах
(Stephen Scliach) описывает программный инжиниринг как дисциплину, целью
которой является создание качественного ПО, которое завершается вовремя, не
ведет к превышению выделенных бюджетных средств, а также удовлетворяет
выдвигаемым требованиям .
В книге будет использована "смесь" этих определений, позволяющая отразить
точку зрения менеджера программного проекта: инжиниринг ПО- это
регламентированный, системный подход к разработке, оперированию, обслуживанию и
прекращению эксплуатации ПО с помощью практического применения научных
знаний и процессов.
Определение проекта
А теперь перейдем к рассмотрению понятия менеджмент (управление) программными
проектами.
В двух упомянутых авторских учебниках по МВА и в специализированных курсах
по менеджменту проектов представлены следующие определения проекта.
Гарольд Керцнер (Harold Kerzner) определяет проект как произвольный ряд
действий или задач, имеющий определенную цель, которая будет достигнута в рамках
выполнения некоторых заданий, характеризующихся определенными датами начала
и окончания, пределами финансирования (в случае прикладного проекта) и
ресурсами (деньги, трудозатраты, оборудование) .
Джеймс Льюис (James Lewis) рассматривает проект как одноразовую работу,
которая имеет определенные даты начала и окончания, ясно определенные цели,
возможности и, как правило, бюджет. Это действия, отличающиеся от повторяющихся
операций, таких как производство, обработка заказа и т.д. В данном случае идет речь
о специфическом действии, имеющем определенные тактические цели .
Зная эти определения, можно увидеть, каким образом конструируется широко
известный "треугольник ПМ" (рис. 1.4). В ходе осуществления проекта ставится задача
поставок продукта с определенной областью действия, стоимость которого остается в
заданных пределах, выдерживается определенный график выполнения, а также
достигается определенная степень качества. Задача менеджеров проекта состоит в том,
1 Boehrn В. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1976. — p. 16.
2 Institute of Electrical and Electronics Engineers. IEEE Std 610.12-1990 Standard Glossary of
Software Engineering Terminology. Software Engineering Standards Collection. NY: Institute of Electrical
and Electronics Engineers, 1983. — p. 76.
Schach Stephen R. Classical and Object-Oriented Software Engineering, 4th ed. Boston, MA: McGraw-
Hill, 1999. - p. 4.
Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 6th ed.
NY: John Wiley & Sons, 1998. - p. 2.
Lewis James P. Project Planning, Scheduling, and Control: A Hands-On Guide to Bringing Projects in on
Time and on Budget, rev ed. Chicago, IL: Irwin, 1995. — pp. 2-3.

40 Глава 1
Затраты
чтобы уравновешивать производительность (область действия), время (график) и
ресурсы (стоимость). И все же нередко бывает так, что график, бюджет и качество
не выдерживаются на требуемом уровне. Поэтому руководители вынуждены
выбирать в качестве первичной цели только один или два параметра качества. Это
действие известно на профессиональном жаргоне как "треугольник хорошо-быстро-
дешево — выбери два из них".
Согласимся с известным гуру в области
анализа обеспечения качества Джозефом Джура-
ном (Joseph Juran) в том, что проект — это
проблема, намеченная для решения.
j §/ /± дЛ\ I Янмръ Институт управления проектами, который
|^f| 'Jf/J^'ja^^L^'\:2. jlES^i" специализируется не только на производстве
ПО, приводит в своем Руководстве РМВОК®
неплохо сформулированное определение.
Согласно PMI®, проект рассматривается как
временное усилие, предпринятое для того, чтобы
создать уникальный продукт или услугу с
определенной датой начала и окончания действия,
отличающегося от продолжающихся,
повторных действий и требующего прогрессивного
совершенствования характеристик .
Эти определения проекта имеют несколько
общих характеристик.
Цель. У проекта должна быть четко
определенная цель или ряд целей. В ходе
осуществления проекта должен быть получен какой-либо результат. Если проект имеет много
целей, то они должны быть связаны между собой и не конфликтовать друг с другом.
Момент начала и завершения действия. Проект — это продукт временного
приложения усилий. Он должен иметь четко определенное начало и конец
действия, обычно выражаемое в виде каких-либо дат. Поддержка ПО обычно
представляет собой продолжающееся действие и не является проектом, но может включать
строго очерченные проекты, которые происходят в его пределах, например, как
отдельные версии.
Уникальность. Проект — одноразовая сущность, не всегда повторяющая один и
тот же путь. Но это не значит, что повторяющаяся работа не является проектом.
Постройка дома обычно классифицируется как проект даже в том случае, когда
подрядчики уже до этого сконструировали миллионы зданий. Хотя образец и процесс в
основном те же самые (шаблон), имеется достаточное количество различий в каждом
доме (участок земли и его местоположение, варьирующиеся материалы, изменения
программы и разработки проекта). В противном случае речь будет идти о поточной
линии, когда идентичные части выполняются аналогичным образом. То же самое
справедливо и для профессионалов в области разработки ПО — они никогда не
создают какую-либо идентичную программную систему, хотя могут ее копировать или
переносить произвольным образом.
Рис. 1.4. Треугольник менеджмента
проектов
" Project Management Institute. A Guide to the Project Management Body of Knowledge. Sylva, NC: PMI
I'ubliration Division. 1996. — p. 167.

Введение 41
Ограничения. Проект имеет ограничения по стоимости, графику и качеству
выполнения. Они формируют "большую тройку" треугольника ПМ, который для
достижения успеха должен быть сбалансирован и управляем.
Итак, практическое определение термина "проект" в терминах разработки ПО
таково: проект - это уникальное, временное действие с определенными датами
начала и конца, направленное на то, чтобы достичь одной или нескольких целей
и пределах ограничений стоимости, графика и качества выполнения.
Определение программы
Программа подобна проекту, и зачастую эти понятия путают. Хотя многие люди
относятся к ним как к равноценным, но эти термины различаются, главным образом,
споим масштабом. А теперь рассмотрим некоторые существующие определения, как
дто было сделано в случае с проектом.
Керцнер (Kerzner) определяет программу как необходимые системные элементы
первого уровня (в контексте теории систем); распределенную по времени
подсистему: относительный ряд действий, которые продолжаются в течение определенного
периода времени (обычно годы), предназначенные для достижения
широкомасштабной технической или научной цели в дальней перспективе (определение,
позаимствованное у специалистов из NASA) .
Дон Шафер (Don Shafer) в своих лекциях, которые он читает в Институте качества
ПО в Остине, описал программу как широкомасштабное усилие, направленное на
достижение комплексной цели. Причем программа может включать множество
проектов; например, Американская пилотируемая космическая программа Джемини
(Gemini) предусматривала использование посадочного лунного модуля, космического
челнока, орбитальной лаборатории и некоторые другие моменты.
Американским обществом обеспечения качества (The American Society for
Quality™, ASQ™) сертифицируются инженеры по качеству ПО путем проведения
экзамена на звание Сертифицированного инженера по качеству ПО (Certified
Software Quality Engineer, CSQE). Совет по качеству штата Индиана издает учебник,
предназначенный для осуществления подготовки к экзамену (CSQE Primer). В этом
учебнике описывается программа, представляющая собой группу связанных между
собой проектов. При этом могут формулироваться коллективные интересы и
стратегические цели, в процессе достижения которых может предприниматься ряд
повторяющихся или циклических действий.
В документе PMI® приводится следующее краткое определение: программа — это
группа взаимосвязанных проектов, управляемых координированным способом.
Программы обычно включают элемент продолжающегося действия .
Эти определения схожи в том, что программа является:
■ большой — программы обычно больше по размеру, чем проекты, и часто
включают несколько проектов;
' Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 6th ed.
XY: John Wiley & Sons, 1998. - p. 70.
Project Management Institute. A Guide to the Project Management Body of Knowledge. Sylva, NC: PMI
Publication Division, 1996. — p. 167.

42 Глава 1
■ длинной— программы обычно рассчитаны на длительные периоды времени и
простираются за рамки сроков действия проектов;
■ общей — программы могут иметь только "область действия" и конечные даты и
цели, определенные для них. Зачастую цель, преследуемая программой, носит
общий характер (например, требуется создать класс программного продукта).
Итак, наше определение приняло следующий характер: программа— это большое и
продолжительное предприятие с нечетко сформулированными датами окончания и
целями, состоящее из взаимосвязанных и совместно управляемых проектов.
Определение управления проектами
В документе PMI® менеджмент (управление) проектами определяется как набор
проверенных принципов, методов и методик, применяемых для эффективного
планирования, составления графика, управления и отслеживания (результатов) работы,
ориентированной на успешное выполнение, а также определяющих базис для
планирования проектов.
Керцнер (Kerzner) определяет управление проектами как планирование,
организацию, контроль и управление ресурсами компании (функциональный персонал),
выделенными в рамках определенного проекта. Эти ресурсы предназначаются для
достижения краткосрочной цели, которая также была установлена для удовлетворения
определенных целей и намерений.
Общие концепции в этих утверждениях таковы:
■ управление — умения в области менеджмента (управления) проектами
представляют собой подмножество общих умений в области менеджмента;
■ навыки — навыки в области управления проектами представляют собой
применение умений в области менеджмента для достижения целей проекта. Они
включают планирование, организацию, составление графика, контроль,
управление и отслеживание.
Каким же образом управление проектами связано с основами знаний (Body of
Knowledge)? В документе PMI описываются основы знаний в области управления
проектами (например, анализ критического пути и структура пооперационного
перечня работ) как пересекающие общую область управления знаниями МВА
(например, планирование, организацию, комплектование персоналом, выполнение и
управление действиями продолжающегося предприятия), и обе эти области
пересекаются с областью знаний проекта (строительство, биологические науки, заключение
правительственных контрактов, консультации, и т.д.), как показано на рис. 1.5. Для
проектов по разработке ПО эта часть обычно представляет собой некоторую
специальность, относящуюся к области информационных технологий или технической
области (платежная ведомость, электротехническая, автомобильная отрасли или
программы, выполняемые в режиме реального времени).
Итак, мы получили определение управления (менеджмента) программными
проектами: управление проектами- специализация общего менеджмента, определяющая
применение стандартных руководящих навыков планирования, организации,
комплектования персоналом, продвижения, а также управления и контроля для
достижения определенных целей проекта.

Введение 43
Основы знаний
менеджмента
проектов
Знание
Знание V._v_^ -^'—-J предметной
MBA ,' \ Ч-^ч у<^ / ч области
Общие '^—_Л_----''Знания \
знания / \ и практика Г
У и практика У ' прикладной '
\ менеджмента X области /
"^-^ -- ^-. ^
Рис. 1.5. Сегмент, являющийся областью пересечения
РМВОК с областью знаний МВА и областью знаний
управления проектами
Конечно, это же определение пригодно и в случае управления программными
проектами.
Некоторые другие полезные определения
В дополнение к терминам ПО, проект, менеджмент, управление программными
проектами, программный инжиниринг, программа и управление проектами применяются
некоторые другие понятия, которые неоднократно будут использоваться при дальнейшем
изложении материала. А сейчас будут кратко рассмотрены термины процесс, задача,
действие, фаза и система.
Определение процесса
В PMI управление проектами определяется как некий конгломерат, состоящий из
проверенных принципов, методов и методик. Наиболее часто методы и методики
включают рабочие процессы, поддерживаемые со стороны инструментов.
Определение процесса согласно Мерриам-Вебстеру (Merriam-Webster) приведено
в приложении 1.5.
Приложение 1.5. Определение процесса
HcTOHHHK.www.xn-w.com/cgi-bxn/dictxonary r . ,, 4; , , ,
Процесс ..• - -ь. ^-^ -,*, ^ * ' 1 ''
1. Что-либо происходящее -> f •*-' '•&*' '', ,
.2.. Естественное явление, отмеченное постепенными* изменениями, котррьхе
приводят к особому результату: естественная непрерывная деятельность или
,i функция.' ... , i У J , , 1
3. Ряд действий или операций, приводящих к результату; например, непрерывное.
у действие или обработка, особенно в производстве * * ',"»"'
Габриэль Полл (Gabriel Pall) определяет термин управление процессом обеспечения ка-
чествакж. ограниченный набор взаимосвязанных действий, который использует одно

44 Глава 1
или большее количество видов входных данных и создает имеющие ценность для
клиента продукты посредством одного или большего количества преобразований'.
А в документах IEEE утверждается, что процесс представляет собой
последовательность шагов, направленных на достижение определенной цели.
На рис. 1.6. проиллюстрированы взаимосвязи между вводом, преобразованием и
выводом, определяющими процесс.
В дальнейшем в книге будет использоваться следующее определение: процесс - это
ряд действий, которые преобразуют набор входных данных в какой-либо результат.
Для обслуживания управления программными проектами определяются два типа
процессов, проекта и продукта, как показано в табл. 1.1.
Таблица 1.1. Процессы проекта и продукта
Процессы проекта Процессы продукта
Описание и организация работы Определяет и создает продукт проекта
в рамках проекта
Чаще всего применимые в тече- Определяется используемым жизненным циклом
ние большей части времени
Определенное Институтом PMI® Изменяются в области приложения
Руководство РМВОК®
Определяется документом Основы знаний (Body of
Knowledge, или ВОК), используемыми сертифицированными
инженерами обеспечения качества ПО (CSQE)
Американского общества обеспечения качества (ASQJ
Определение задач и действий
Термины задача и действие зачастую являются взаимозаменяемыми, вследствие
чего иногда возникает некоторая путаница в их употреблении. До сих пор в рядах
сообщества, выполняющего задачи по управлению программными проектами,
отсутствует согласие при определении отношений между действиями и задачами. В
одних областях действия состоят из задач, в других — задачи состоят из действий.
Согласно опыту авторов книги, действия имеют более высокий порядок, чем
задачи, и именно они состоят из задач. Конечно, действительно важным является
то, чтобы работа была ясно определена для членов команды, независимо от того,
как она называется.
Как более низкие элементы в иерархии, задачи относительно короче по
продолжительности, чем действия, стадии, проекты или программы. Обычно в
проекте задачи представляют собой элементы работы низшего порядка, хотя
некоторые менеджеры программных проектов выполняют их дальнейшее разбиение
на подзадачи.
Существует множество определяющих характеристик задач и действий. Задачи
обычно представляют собой выделенную часть работы, которая должна быть
завершена в течение некоторого периода времени. Действия зачастую определяют
группировку задач, которые могут быть выполнены одним человеком или организацион-
Позаимствовано из книги Pall Gabriel A. Quality Process Management. Englewood Cliffs, NJ:
I'rent ice-Hall, 1987

Введение 45
ной единицей, и (или) которые производят отдельный рабочий продукт. Согласно
Вебстеру, задачи и действия имеют следующие характеристики:
■ задача — обычно назначаемая часть работы, которая зачастую должна завершиться
в течение некоторого времени; она подразумевает работу, выделенную
полномочной персоной, предпринимателем или появившуюся в силу сложившихся
обстоятельств;
■ действие— организационная единица, предназначенная для выполнения опреде-
... , „ „10
ленной функции, а также составные части или функции действии .
Величина ввода
Определенный
результат
Величина выхода
1
Больше чем
Рис. 1.6. Ввод, преобразование и выход процесса
Другие авторитетные определения из документа РМВОК выглядят следующим
образом:
■ действие— элемент работы, выполненной в течение проекта; действие обычно
имеет ожидаемую продолжительность, ожидаемую стоимость и ожидаемые
требования к ресурсу, а также может быть подразделено на задачи;
■ задача — общий термин для работы, которая не включена в структуру
пооперационного перечня работ, но потенциально может быть осуществлено дальнейшее
разбиение работы индивидуумами, ответственными за эту работу; кроме того,
„ и
предполагается самый низкий уровень трудозатрат в рамках проекта .
Квинтэссенция этого определения заключается в том, что под задачами
подразумевается что-нибудь "отслеживаемое", не входящее в состав WBS. Подобные знания
могут приобретаться в ходе профессионального обучения. Именно поэтому не все
может уподобиться "шагам младенца", описываемым в учебнике по компьютерном)'
программированию. На протяжении многих лет велась дискуссия относительно того,
задачи. В издании РМВОК за 2000 год вносится ясность по этому вопросу.
При рассмотрении вопросов управления программными проектами в книге будут
использоваться следующие определения.
Задача - общий термин для работы, которая не включена в структуру
пооперационного перечня работ, но потенциально допускает дальнейшее разбиение работы
"' www.m-w. eom/cgi-bin/dictionary- Merriam-Webster's Collegiate® Dictionary Online.
" Project Management Institute. A Guide to the Project Management Body of Knowledge. Sylva, JC: PMI
Publication Division, 2000. — pp. 43, 55.

46 Глава 1
лицами, ответственными за эту работу. В этом случае определяется наиболее низкий
уровень трудозатрат в проекте.
Действие - элемент работы, выполняемый на протяжении осуществления
проекта. Действие обычно имеет ожидаемую продолжительность, прогнозируемую
стоимость и ожидаемые требования к ресурсам. Действия могут быть разделены
на задачи.
Определение фазы
Любой большой и сложный проект может быть легко разбит на явное количество
задач и действий, необходимых для его завершения. Достаточно удобным является
разделение проекта на группы задач, благодаря чему облегчается понимание и
организация выполнения этих задач. Действия будут рассматриваться как группы задач, а
фазы — как группы действий. Согласно Вебстеру, фаза определяется как отдельная
часть курса, процесса разработки или цикла. Институт SEI определяет фазу как период
времени. В PMI фаза проекта описывается в виде собрания логически связанных
проектных действий, обычно достигающих кульминации при завершении главного
комплектующего узла. С целью поддержки общего словаря, фазы представлены на
рис. 1.2 и на рис. 1.17.
Организация задач вокруг поставляемых продуктов имеет смысл и служит
логической контрольной точкой перед переходом к другому набору задач. Связывание шагов
производства поставляемых продуктов и продуктов работы с задачами,
сгруппированными в действия, и действиями, сгруппированными в виде отдельных фаз, не
является обязательным, хотя в этом случае обеспечивается хороший способ
структурирования большого количества задач.
Итак, при рассмотрении управления программными проектами можно
использовать такое определение: фаза - это собрание связанных действий или задач, в
процессе выполнения которых реализуется производство рабочего или
поставляемого продукта.
Определение системы
Как и слово "вещь", которое является наиболее неоднозначным словом в
английском языке, слово "система" может означать в терминологии ПО практически все,
что угодно. Исторически эта неоднозначность была основной причиной проблем в
понимании требований по отношению к ПО. Во избежание двусмысленности при
дальнейшем рассмотрении необходимо определить этот термин.
Полезно знать общее определение из теории деловых систем.
Керцнер (Kerzner) определяет систему как группу элементов, организованных и
распределенных так, чтобы элементы могли выступать как единое целое при
достижении общей цели. Систему можно представлять в качестве совокупности
взаимодействующих подсистем, имеющей границы, которые определяют ее в качестве
открытой (взаимодействующей с ближайшим окружением) или закрытой (которая
изолирована от близлежащего окружения) .
" Kerzner, Harold. Project Management: A Systems Approach to Planning Scheduling, and Conrolling, 6th
ed. NY: John Wiley & Sons, 1998. - pp. 69-72.

Введение 47
Институт IEEE определяет систему как собрание компонентов,
организованных таким образом, чтобы обеспечивалось выполнение определенной функции
или ряда функций.
Это означает, что любая совокупность организованных элементов,
ориентированных на достижение цели, может выступать в качестве системы. В процесс
менеджмента ПО может вовлекаться множество систем: система управления
внесением изменений, система управления стоимостью, система конфигурационного
управления, информационная система менеджмента проектов и система оценки
производительности.
Программные продукты, входящие в состав проектов, будут представлены как
системы, зачастую состоящие из аппаратных средств, ПО и процессов.
Важным свойством систем является то, что им присущи границы, и они могут
взаимодействовать либо не взаимодействовать с близлежащим окружением. Если они
могут отделяться и функционировать независимо, речь идет о закрытых системах.
Если же для эффективного функционирования системы они должны взаимодействовать
с окружением, их можно отнести к категории открытых систем.
Независимо от того, являются ли продукты, произведенные в рамках проекта по
разработке ПО, закрытыми или открытыми системами, сами программы и проекты
практически всегда относятся к классу открытых систем. Это связано с тем, что
большая часть деятельности менеджера проекта включает взаимодействие с другими
людьми и системами в деловом окружении.
В дальнейшем определение этого термина будет таким: система - это
организованная группа элементов, которая имеет границу, определяющую ее открытость или
закрытость, и которая действует как единое целое для достижения общей цели.
Для менеджеров программных проектов важно осознавать общий характер систем
в силу специфики их деятельности.
Теперь в нашем распоряжении имеется унифицированный язык, включающий
основной набор терминов из области менеджмента проектов. Вскоре мы подойдем к
кратким описаниям необходимых навыков менеджмента программных проектов
(SWPM), а также укажем порядок обращения с ними в данной книге. Каждая фаза
цикла SLC требует использования более одного навыка, а каждый навык используется
более чем в одной стадии. Главы расположены в порядке следования навыков в
последовательности цикла SLC, причем каждая глава связана с применяемыми навыкам
в области менеджмента проектов. Как указывалось ранее в этой главе, в центре
внимания будут находиться качество, ПО, проект и менеджмент. Качество лежит в
основе всего. Итак, мы начнем с краткого описания компетенций ПО (продукта).
Методики разработки продукта
Менеджеры программных проектов зачастую вынуждены решать проблемы,
связанные с его доставкой. Так как создание продукта является первостепенной целью,
то методы его разработки будут рассмотрены в первую очередь, до рассмотрения
проектными навыков и тех из них, которые касаются менеджмента персонала.
Методики разработки продукта, компетенции с 1 по 11, показаны в табл. 1.2. Далее будет
следовать краткое описание каждой компетенции, а более полное описание
приводится в последующих главах этого руководства.

48 Глава 1
Таблица 1.2. Компетенции продукта (ПО)
Компетенция продукта
Описание
Глава или приложение,
содержащие описание
этой темы
1. Процессы оценивания
2. Знание стандартов процесса
3. Определение продукта
4. Оценка альтернативных
процессов
5. Управление требованиями
6. Управление
субподрядчиками
7. Выполнение начальной
оценки
Н. Отбор методов и
инструментов
9. Подгонка процессов
10. Отслеживание качества
продукта
11. Понимание действий по
разработке продукта
Определение критериев для
выполнения экспертных оценок
Понимание стандартов процесса
Идентификация клиентской
среды и требований, связанных с
продуктом
Оценка различных подходов
Отслеживание изменяющихся
требований
Планирование, менеджмент и
отслеживание производительности
Оценка степени трудности,
рисков, затрат и графика
Определение процессов отбора
Изменение стандартных
процессов с учетом достижения целей
проекта
Отслеживание качества
разрабатываемого продукта
Изучение цикла разработки ПО
11,25,26,30
Приложение А
7
4, 7,13
16,17
6.12, 32
9,10, 11.18
24, 31, приложение D
4.13, 14
30
4,5
Область действия компетенций продукта
Существует множество подходов к "последовательности" событий, которые
составляют процесс разработки, контроля, менеджмента (управления), улучшения и
поддержки ПО. Слово "последовательность" заключено в кавычки, поскольку процесс может не
носить линейный характер, — зачастую происходят повторения внутри и между фазами
(пли шагами) процесса. Шаги процесса могут быть и последовательными — на
протяжении любого заданного периода времени может выполняться более одной задачи, а
участник разрабатываемого проекта может распределять время между многими задачами.
Различные типы проектов требуют наличия моделей процессов, имеющих
разные типы. Для ПО, управляющего раскрытием подушки безопасности автомобиля
или медицинским исследованием при помощи компьютерной томографии,
требуется экстраординарное тестирование, поскольку под угрозой может оказаться
человеческая жизнь. Л для ПО системы выполнения заказов с помощью Internet-
каталога, содержащего перечень изделий из фарфора и серебра, больше внимания
следует уделить пользовательскому интерфейсу, т.к. именно эта часть системы в
данном случае имеет важное значение. Потребности в обеспечении безопасности

Введение 49
последней упомянутой системы минимальны по сравнению с предыдущими
системами, и в данном случае отсутствует необходимость в усиленном тестировании.
Различные степени испытания — это всего лишь одна из многих причин,
определяющих различные жизненные циклы разработки ПО.
В главе 4 будут описаны некоторые из наиболее популярных или широко
используемых моделей. В ней также будет описано, как узнать, какие из этих моделей можно
использовать в исходном виде, а какие — в качестве базиса для подгонки под нужды
определенного проекта. Поскольку для успешного обсуждения требуется общая
структура, здесь будут использоваться простые термины каскадной модели с
повторениями (рис. 1.2), вместо более новых терминов, используемых в специализированных
моделях, описывающих жизненные циклы SLC.
Краткое описание навыков, непосредственно
связанных с выпуском продуктов
Компетенции продукта с 1 по 11 кратко описаны в следующих разделах.
Компетенция продукта 1: определение критериев для
выполнения экспертных оценок (обзора)
В обзоре описывается действие оценивания или приводится оценка конечных
продуктов работы. Зачастую обзоры требуются и на некоторых стадиях выполнения
проекта, и особенно — на заключительных стадиях фаз. Как только определяется
соответствующий жизненный цикл, становятся известны его фазы, благодаря чему можно
определить, когда производятся обзоры продукта в конце фаз. Обзоры также могут и
должны иметь место в ходе осуществления процесса. В главе 30 описывается случай,
когда определяется уместность, субъект и порядок выполнения обзора. Также
существуют аспекты контроля качества, на которые должны быть направлены обзоры,
такие как стоимость обеспечения качества и подсчет дефектов. Треугольники,
позаимствованные из каскадной модели IEEE 1074 (рис. 1.7), демонстрируют, что команда
разработчиков должна передать обзор только что завершенной фазы перед
переходом к выполнению следующей фазы. Внутренний и внешний поставляемые продукты
внутри каждой фазы, в дополнение к обзорам продукта в конце фаз, также являются
кандидатами на роль обзора. Выполнение ранних обзоров оценок трудозатрат и
стоимости приведет к улучшению суммарной подтвержденной оценки
стоимости/графика проекта, как описано в главе 11.
В главе 25 подробно рассматривается, что в состав объектов, которые подлежат
обзору, также включены результаты сравнения реальной и оценочной стоимости,
реального и оценочного графика, приводится процент завершения проекта, результаты
оценки степени риска и многие другие измерительные "барометры" проекта.
И наконец, в процессе оценки формируется основа для постоянной оценки того
порядка функционирования в выбранной среде разработки определенных
эффективных и подходящих процессов (см. главу 26). Обзоры будут сосредоточены на
оценке и усовершенствовании производительности, уменьшении времени цикла и
других моментах, связанных с выполянемым процессом.
Компетенция продукта 2: понимание стандартов процесса
В приложении А изложен материал по стандартам, влияющих на успешную
деятельность менеджера проекта. Профессиональные организации предоставляют ме-

50 Глава 1
иеджерам проектов специальные руководства по реализации тех или иных проектов,
анализу, разработке, кодированию, тестированию и т.д.
Организации, поддерживающие процесс разработки ПО, отвечают за многие из
этих стандартов. Список некоторых из этих организаций представлен в табл. 1.3.
Исследование
концепции
Исследование
системы
Требования
Разработка
проекта
Внедрение
Установка
Эксплуатация
и поддержка
Сопровождение
Вывод из
эксплуатации
Рис. 1.7. Обзоры фаз повторяющегося жизненного цикла разработки ПО в каскадной модели
Таблица 1.3. Организации, поддерживающие процесс разработки ПО
с применением промышленных стандартов
Сокра- Организация
теине
Основная цель Связь с SWPM
URL-ссылка
PMI® Институт управле- Общий менедж-
иия проектами мент проектов
(Project Management
Institute®)
Руководство Основы знаний www.pmi. org
в области управления
проектами (Project Management
Body of Knowledge,
PMBOK)

Введение 51
Окончание табл. 1.3
Сокра- Организация
щение
Основная цель Связь с SWPM
URL-ссылка
ASQ
IEEE
ТМ Американское об- Улучшение каче-
ISO
вдество обеспечения ства производи-
качества (American мых продуктов
Society of Quality"")
Стандарты
инжиниринга
Институт
инженеров по
электротехнике и электронике
(Institute of Electrical
and Electronics
Engineers)
Международная
организация по
стандартизации
(International Organization
for Standardization)
ANSI Американский на- Американские на-
Международные
стандарты
циональныи
институт стандартов
(American National
Standards Institute)
NIST Национальный
институт стандартов и
технологий
(National Institute of
Standards and
Technology)
SEI Институт
программного
инжиниринга (Software
Engineering Institute)
циональные
стандарты
Технология,
измерения и
стандарты,
применяемые в
американской
промышленности
Программный
инжиниринг
Основы знаний в области
инжиниринга
качественного ПО
(Сертифицированный инженер по
качеству ПО [CSQJE] ВОК)
Собрание стандартов
в области программного
инжиниринга
Стандарты качества ISO
9000; стандарт процесса
жизненного цикла ПО
ISO/ТЕС 12207 IT
Руководство,
определяющее применение
стандартов 1SO/IEC 12207 по
отношению к управлению
проектами программного
инжиниринга
Национальная премия
Малкольма Балдриджа за
отличное качество работы
(Malcolm Baldrige National
Quality Award for
Performance Excellence,
MBNQA)
Модель зрелости
возможности в применении к
разработке ПО, версия 1.1
(Capability Maturity Model,
СММ™)
www.asq.org
www.ieee.org
www.iso.ch
www.ansi.org
www.nist.gov
www.sei.emu.
edu
Компетенция продукта З: идентификация клиентской среды
и требований, связанных с разрабатываемым продуктом
Описание процесса, управляющего этими действиями, приводится в главе 7.
Менеджер проекта должен быть осведомлен относительно клиентских запросов и
общих требований, связанных с разрабатываемым продуктом. При этом продукт
определяется как результат усилий команды разработчиков.

52 Глава 1
Это определение продукта учитывает наличие поставляемых продуктов проекта,
продемонстрированных в приложении F. В этом приложении описываются
стандартные продукты индивидуальной проектной работы, а также связывающие их
отношения и планы: менеджмента программных проектов (software project
management plan, SPMP), управления рисками, коммуникации, менеджмента
конфигурации НО (Sofivvarc configuration management plan, SCM), план обеспечения качества
1 К ) (software quality assurance plan, SQA) и план тестирования.
1ккле завершения разработки этих планов менеджер проекта, команда
разработчиков и клиент будут иметь общее представление относительно определения продук-
. ; ll'ianiii создаются согласно шаблонам, предоставленным организациями стандар-
■ .- и перечисленным в табл. 1.3.
Компетенция продукта 4: оценивание различных
применяемых подходов
Для mm чтобы организовать деятельность персонала разработчиков проекта су-
.;<-< тв\ст столько способов, сколько имеется разновидностей ь стандартном жизнен-
:■ >м iitiK.it- каскадной модели. Способность выбирать среди изобилия инструменталь-
ь.ч ( ре дети означает проведение "оценки различных подходов". Проекты уникальны
■ и i .прелелепню — это та характеристика, которая отличает их от текущих операций.
i'. i ич\ .л oii мшкальности каждый проект может иметь различные цели, задачи, стан-
..ijMi.i раз. жизненные циклы и структуры команды. Наиболее значительная компе-
и пция для менеджеров программных проектов заключается в том, что они должны
■ ч.111. способны оценивать различные альтернативы и выбирать из них наиболее
подходящие для каждого проекта.
Существуют следующие методы, с помощью которых менеджер проекта может
оценивать альтернативные процессы: выбор жизненного цикла (глава 4), определе-
:.< стандартов разработки, основанных на утвержденном техническом задании, це-
1, \ и возможностях (глава 7), атакже выбор организационной формы.
Компетенция продукта 5: контроль изменений требований
Клжпоп и труднейшей частью формирования корректных требований являет-
■ -л их форматирование с учетом привлечения всех заинтересованных лиц. Про-
Г> ммы контактов, изменение уровня ожиданий, отличие потребностей и многие
другие барьеры усложняют работу. В главе 16 описано несколько методов
получения и формулирования реальных требований для спецификации требований к
ПО и определения ценности каждого из них. Методы выявления требований, ко-
юрые будут рассмотрены ниже, включают: опрос, учет случаев использования и
анализ сценария, ролевую игру, работа с архивными документами, формирование
опрашиваемых групп, использование разбиения на отдельные фрагменты,
создание опытных образцов/моделирование, использование совместной разработки
приложения (Joint Application Design®, JAD) и других подобных методов,
использование программных средств автоматизации коллективной работы, мозговой
штурм и компактификация идеи, а также отбор соответствующих методик
выявления требований.
Определение корректных требований является, возможно, наиболее важной ча-
i iT.io нрограммн< го проекта. В главе 17 описывается разработка документа специфи-
• .ниш фебоваш Л ПО (Software requirements specification, SRS), начиная с исследова-

Введение 53
тельских действий по предоставлению помощи клиенту в определении его истинных
желаний и потребностей. В связи с рассмотрением данной компетенции будет описан
порядок разработки требований, сбора требований с использованием модели
объекта, а также представление шаблона SRS с последующей разработкой документа SRS.
В главе 23 описаны методики аттестации фактического содержания документа SRS
после того, как требования были собраны и зарегистрированы в шаблоне
спецификаций. Они представляют собой другой пример того, где должно использоваться
действие по выполнению обзора. Многие из них будут описаны в обзорах, посвященных
реализации процессов программного проекта (главы 19 - 24). Также будут описаны
порядок и область применения этих и подобных им методик. Рассматривается
порядок выполнения экспертных оценок (процедуры экспертизы, ее формы и т.д.),
опытные образцы, развертывание функции обеспечения качества (quality function
deployment, QFD) и инструменты — ряд систем поддержки методов и процессов.
Компетенция продукта 6: планирование, управление
и осуществление контроля за деятельностью субподрядчиков
Управление субподрядчиками начинается в тот момент, когда менеджер проекта
принимает решение о том, что для выполнения проекта или некоторой его части
будут заключены субдоговора с другими фирмами. Ясно, что эта компетенция критична
для успеха проекта в то время, когда испытывается недостаток ресурса персонала.
Обзор этой компетенции начинается в главе 6, которая содержит учебный материал,
позволяющий изучить процесс укомплектования персоналом групп разработчиков
проектов. В ней представлены некоторые основные модели индивидуальностей,
позволяющие обеспечить подбор персонала для создания высокоэффективной
команды, и описаны методики набора персонала и создания таких команд. Они включают
идентификацию и понимание индивидуальностей, знание характеристик
эффективной команды проекта по разработке ПО, отбор членов команды в рамках
определенного процесса, а также заключение контракта при подборе персонала.
В главе 12 рассматривается этап, наступающий после отбора команды
разработчиков проекта. Ресурсы включают персонал, ПО, аппаратные средства, средства
поддержки и все, что еще необходимо для выполнения планов проекта. В главе будут
рассмотрены такие проблемы, как: использование упомянутых ресурсов наравне с
обобщенными метками; балансирование между платежными возможностями и степенью
полезности; определение методов распределения ресурсов по уровням; разработка
версий продукта и порядок принятия решений о покупке (создание продукта внутри
организации либо закупка имеющегося в наличии коммерческого продукта
(commercial-off-the-shelf, COTS) и заключение субдоговора наравне с разработкой
продукта средствами компании.
Каждый менеджер программного проекта должен быть компетентным в основных
юридических вопросах, связанных с разработкой ПО. В главе 32 рассматриваются
основные принципы торгового права в применении к контрактам, лицензиям и
интеллектуальной собственности. Здесь также рассматриваются различные проблемные
вопросы, касающиеся контрактов, например, о приобретении и идентификации,
управлении и защите интеллектуальной собственности (патенты, торговые марки,
торговые секреты, авторские права и подготовка торговли) '.
Материал этой главы описывает правовые аспекты, актуальные для США, хотя в эпоху
всеобщей глобализации он будет полезным и для русскоязычных читателей. — Прим. редактора.

54 Глава 1
Компетенция продукта 7: оценивание трудностей, рисков,
затрат и графика
В главе 9 рассматриваются задачи по разработке ПО в пределах каждого процесса
жизненного цикла разработки продукта. Здесь также приводятся ссылки на обычные
и общепринятые составные процессы, используемые в рамках управления проектом.
При оценке трудностей запуска программного проекта должны осваиваться такие
области, как управление проектами, обеспечение качества ПО, тестирование элементов
и систем, управление конфигурацией, управление контрактами, коммуникации и
генерирование отчетности.
Ключ к успешному планированию программного проекта — хорошо выполненная
оценка. Обычно продолжительность выполнения задачи в области разработки ПО
зависит от размера создаваемого программного продукта. В главе 10 описываются
полезные методики оценки, позволяющие выполнить калибровку ПО, включая меры
подсчета, и повторное использование ПО. Также подчеркивается важность
понимания методов его оценки.
Продолжительность разработки и понесенные при этом затраты можно
оценить, имея данные о размере, а также некоторые статистические данные. В главе 11
подробно описываются существующие элементы оценки стоимости, а также
методика выполнения самой оценки. Она включает оценку трудозатрат, стоимости
компонентов, точность оценки, измерения производительности, а также
параметрические модели.
Здесь же описывается, как проанализировать разработанный план рисков, а также
создать главный поставляемый продукт проекта— план управления (менеджмента)
рисками. В главе обсуждаются принципы управления рисками, модели,
идентификация рисков, указывается, где следует искать риски, производится их анализ,
описываются инструменты дискретизации, разработка ответных рисков, определение
( гонмости и упорядочивание рисков, подготовка плана управления ими, а также
периодических отчетов относительно изменений рисков.
Компетенция продукта 8: определение процессов отбора
Применение менеджерами проектов тех или иных методов разработки ПО,
методик и инструментов совместно с методами менеджмента проектов определяет успех
или неудачу организации.
Упомянутые концепции используются на протяжении всего рассматриваемого
руководства. С целью последовательного изложения материала эти три концепции
будут представлять определения, используемые для каждой стороны треугольника
на рис. 1.8. При этом следует иметь в виду, что метод- это способ, средства или
процесс выполнения чего-либо, инструмент- орудие или механизм, используемый для
выполнения работы или решения задачи, а технология - применение научного знания
в промышленности или бизнесе.
В главе 24 обсуждается использование некоторых общих инструментов, доступных
дли планирования и управления программными проектами. Основное внимание в
этой главе уделяется важным характеристикам инструментов, используемых в
процессе SWPM, неспецифическим программным продуктам, причем материал
предназначен для практического использования. Отдельные приложения обсуждаются в
остальных главах. Так, будут рассмотрены: инструменты автоматизированного проек-

Введение 55
Рис. 1.8. Взаимоотношения между
методами, инструментами и
технологией
тирования и создания программ (Computer aided software engineering, CASE) и в
объектно-ориентированных (Object-oriented, ОО), и в структурированных средах; оценка
размера ПО и инструменты оценки, такие как конструктивная стоимостная модель
(Constructive cost model, COCOMO) и SLIM. Также рассматриваются инструменты
планирования, отслеживания и контроля проекта, составления графика и отчетов о
трудозатратах и равномерного распределения ресурсов. Многие из этих
инструментов могут использоваться при работе в Internet.
С самого начала необходимо предусмотреть
систему менеджмента конфигурации (Configuration
management, CM), причем она должна быть
доступной на всех этапах разработки проекта. Каждый
отдельный поставляемый продукт проекта, начиная с
исследования концепции и документирования
устанавливаемых требований, должен сохраняться при
контроле конфигурации. В главе 31 рассматриваются
проблемы и основы стандартной системы
менеджмента конфигурации программных проектов:
принципы, основные требования, планирование и
организация, инструменты, а также внутренние и
внешние факторы. В этой предметной области также
находятся в компетенции управления проектами.
Материал из приложения D предлагает
рассмотрение "изнутри" системного инжиниринга, что
является необходимым условием при разработке любого продукта. Ключевые области,
охваченные в этом приложении, — процесс инжиниринга систем, жизненные
циклы и методы. Они зачастую несколько отличаются от тех же областей для
программных систем.
Компетенция продукта 9: изменение стандартных процессов
в целях удовлетворения требований проекта
В разделе, посвященном рассмотрению компетенции 1, уже упоминалось о том,
что часто весьма уместно корректировать процессы, процедуры и жизненные циклы
с тем, чтобы отвечать определенным требованиям проекта. Обычно подгонка
начинается с того, что менеджер проекта выбирает наиболее подходящий для проекта
жизненный цикл. В главе 4 рассматриваются характеристики различных жизненных
циклов программных проектов, а также содержатся указания по отбору цикла,
подходящего для данного программного проекта.
Типичные организационные структуры вряд ли могут применяться по отношению
ко всем программным проектам. Поэтому для руководителя менеджера проекта
жизненно важным является определение типа организационной структуры, наиболее
подходящего для этого проекта, путем изучения рабочей среды. Формы организации,
определенные в главе 13, включают использование функционального работника,
диспетчера, координатора проекта и матрицу. Каждая из этих форм будет определена
и рассмотрена с точки зрения предоставляемых ею преимуществ и неудобств.
Подгонка проектных процессов и среды должна производиться с учетом всех
имеющихся зависимостей. Большинство задач не выполняются в изоляции от
проекта. Корректная идентификация имеющихся зависимостей является
ключевым условием в деле построения рабочего графика. В главе обсуждаются некоторые

5G Глава 1
из "настраиваемых" зависимостей, которые являются обычными в программных
проектах, включая: расширенную поддержку на уровне компании, управление
конфигурацией, менеджмент проектов и план SQA. Здесь также рассматривается
потенциальная проблема идентификации — высокий коэффициент объединения
по входу или выходу, циклические взаимосвязи, определение критического пути,
критическая цепь, замыкающая уникальные ресурсы, а также ограничивающие
ы.шмоснязи.
IS этом случае отсутствуют готовые предписания, а имеют место лишь
предложения относительно того, каким образом модификация испытанных и истинных мето-
дон может принести пользу проекту в целом, т.е. для результативности и
эффективности проекта зачастую требуется гибкость и нестандартное мышление.
Компетенция продукта 10: отслеживание качества
разрабатываемого продукта
За качество продукта несет ответственность вся команда разработчиков.
Менеджер проекта должен распределять процессы таким образом, чтобы контролировать
качество продукта по мере его развития на всех этапах жизненного цикла разработки
продукта. Задача "Идентификация потребностей по улучшению качества"
проиллюстрирована на рис. 1.17 (раздел "Менеджмент качества ПО "). Поскольку эта задача
весьма актуальна на всех фазах разработки ПО, она относится к категории
"существенных" задач.
В главе 30 рассматриваются основы процесса улучшения качества в контексте
реализации проекта. При атом рассматриваются следующие темы: определение качества,
его характеристики и критерии; краткая история динамики развития качества— Шу-
члрт (Shewhart), Деминг (Deming), Дюран (Juran) и Косби (Crosby); понимание
важных концепций обеспечения качества— непрерывное усовершенствование и цикл
контроля Деминга "планировать-делать-проверять-действовать" (plan-do-check-act,
РПСА): управление изменением— реализация эффективного генератора изменений;
обеспечение качества ПО; ознакомление с проблемами индустрии ПО.
Также рассматриваются вопросы обеспечения качества ПО (Software Quality
Assurance, SQA) с акцентом на: определение качества ПО, отслеживание качества
процесса и продукта, понимание процессов оценки и гарантирование качества
(подготовка инструментов определения стоимости процесса обеспечения качества и
ознакомление с планом IEEE SQA).
Компетенция продукта 11: изучение цикла по разработке ПО
Как и в случае с компетенциями 1 и 9, каскадная модель является типичной
отправной точкой в изучении цикла разработки ПО. Каждый из описанных процессов —
начинающийся с исследования концепции и заканчивающийся выводом системы из
эксплуатации — требует определенных компетенций. Конечно каскадная модель — не
самая лучшая модель жизненного цикла для всех программных проектов. И это уже
установленный факт. Однако эта модель предоставляет форму для поддержки
основных фаз, встречающихся в каждом программном проекте.
Наряду с простым изучением моделей жизненного цикла, менеджер проекта по
разработке ПО должен понимать основные процессы в области, для которой
разрабатывается программа. Простое понимание информатики или процесса разработки
ПО означает лишь то, например, что инженер-строитель понимает лишь принципы

Введение 57
устройства и работы бульдозера. Инженеры-программисты и ученые-компьютерщики
могут концентрироваться лишь на понимании устройства и принципах работы
инструментов. Но для того чтобы быть успешным менеджером проекта, важно знать
область, по отношению к которой будет применяться этот инструмент. В главе 5
описывается, как следует идентифицировать эту область, а также как нужно управлять
специфическими для данной области процессами. Менеджер проекта действует как
"связующий мост" между разработчиками и потребителем. Он должен быть способен
попять клиента и среду продукта в контексте того, как они соотносятся с
программными продуктами, а также определить продукт в технической терминологии ПО.
Теперь, когда был рассмотрен разрабатываемый программный продукт, настало
время выяснить, как он будет создаваться. Здесь очень важно понимание того, что
каждому продукту требуется его определение (требования), пересмотр (управление
требованиями) и "встраивание" в организационную инфраструктуру. Эта
инфраструктура включает планирование процессов и стандартов, методов и инструментов,
которые будут использоваться в дальнейшем. Знание того, как оценивать
альтернативные процессы и подгонять их к выбранным процессам, приводит нас к
соответствующей инфраструктуре. При наличии метода управления подрядчиками и
определения начальных проектных рисков, затрат и графика можно установить стадию
фактического развития продукта. Как только вся эта информация систематизирована,
команда по разработке проекта использует более скоростные методы разработки и
идентифицирует процедуры отслеживания качества, после чего наступает этап
реализации. Компетенции проекта определяют все, что связано с использованием
навыков по разработке продукта.
Навыки менеджмента проектов
Кроме навыков работы с продуктом, в этой книге будет рассмотрен каждый из
навыков проектного менеджмента, относящихся к упомянутым 34 компетенциям. Эти
навыки проиллюстрированы в табл. 1.2 (компетенции с 12 по 22). Краткое описание
каждой компетенции будет приведено в этом разделе, а более полное описание —
приводится в последующих главах.
Область действия компетенций проекта
В этом разделе будут рассмотрены навыки, необходимые для достижения
компетентности при управлении программными проектами. Здесь будет
представлено краткое объяснение навыков менеджмента проектов, описаны компетенции с
12 но 22, выступающие в качестве сетевого графика и как руководство для обзора.
Главы, в которых более подробно описывается каждая компетенция,
перечислены в табл. 1.4.
Таблица. 1.4. Компетенции проекта
Компетенция проекта Описание Глава
12. Создание структуры поопераци- Создание структуры пооперацион- 4,8,9
онного перечня работ ного перечня работ для проекта
13. Документирование планов Идентификация ключевых компо- 4, 7, 17, 28, 30, 31
нентов приложение А

58 Глава 1
Окончание табл. 1.4
Компетенция проекта
Описание
Глава
11. Оценка затрат
1Г>. Оценка трудозатрат
10. Менеджмент рисков
17. Отслеживание процесса
разработки
18. Составление графика
19. Отбор метрических показателей
20. Отбор инструментов управления
проектами
21. Отслеживание процессов
22. Отслеживание хода выполнения
проекта
Оценка затрат, необходимых для 10, 11, 12, 16
завершения проекта
Оценка трудозатрат, требуемых для 10, 11, 12, 16, 17
завершения проекта
Определение степени воздействия 18,21
и устранение влияния рисков
Отслеживание процесса разработки 24, 25, 26, 30
ПО
Разработка графика и ключевых 7, 14, 15
метрических показателей
Выбор соответствующих метриче- 21, 24, приложе-
ских показателей ние А
Основы выбора инструментов 24
управления проектами
Отслеживание деятельности коман- 5, 21, 25, 26, 30
ды разработчиков проекта
Контроль выполнения с примене- 21, 30
нием метрических показателей
Компетенции проекта, перечисленные в табл. 1.4, — это как раз те, о которых
Go 1ЫИИИСТВ0 людей думает как о навыках менеджмента (управления) проектами.
Однако это лишь отчасти так, поскольку еще очень важны компетенции, касающиеся
продуктов и персонала. Кроме того, эти компетенции не обособлены, а вписываются
в более глобальное представление. На рис. 1.9 показано, как жизненный цикл
разработки проекта вписывается в пределы стадий жизненного цикла разработки
продукта, который, в свою очередь, является частью стадий, находящихся в типичном пол-
i юм деловом жизненном цикле.
Краткое описание навыков менеджмента проектов
Компетенции проекта, с 12 по 22, кратко описаны в последующих разделах.
Компетенция проекта 12: разработка цикла WBS для проекта
Основу любого проекта составляет структура пооперационного перечня работ
(work breakdown structure, WBS). Здесь описываются шаги, необходимые для
выполнения проекта, а также их взаимосвязи. Создать хорошую структуру
пооперационного перечня работ, которая является полезной и пригодной к
употреблению, не так просто, как кажется на первый взгляд. В главах 8 и 9 описаны навыки
менеджмента проектов, необходимые при создании WBS. Эта тема также
рассматривается в главе 4.
В главах 19 - 24 описано, каким образом следует использовать структуру WBS в
качестве инструмента менеджмента проектов. Использование других полезных
метрических инструментов описано в главе 25.

Введение 59
Деловой жизненный цикл
Планирование
политики
Идентификация
потребностей
Концепция
проекта
Осуществление
Продукт в / Вывод
обслуживании /из эксплуатации
Жизненный цикл продукта \
Выполнимость
Приобретение
Эксплуатация Дзэк^ации
Жизненный цикл проекта |
Концепция
Разработка
Внедрение
Завершение
< ^ >
Стоимость/преимущества коэффициента ROI, вычисленная для каждого проекта
Рис. 1.9. Жизненные циклы бизнеса, продукта и проекта
Источник: Project Management Institute. A Guide to the Project Management Body of Knowledge.
Sylva, NO. PMI Publication Division, 1996.
Компетенции продукта и проекта необходимы, но не достаточны для успешной
реализации проекта. Лучшие на планете аналитики процесса, "умельцы" в деле
постановки требований, "кузнецы-инструментальщики", проектировщики, кодировщики и
менеджеры проектов не могут успешно реализовать проект без учета компетенций
персонала. Разработчики и клиенты — это не абстрактные проблемы, а люди с
обычными потребностями. Они любят, чтобы ими руководили, их инструктировали, с
ними советовались, их вербовали и отбирали с должным достоинством. Спросите
любого специалиста в области разработки ПО, были ли они когда-нибудь на
неэффективной встрече, работали а непроизводительной команде, игнорировались ли когда-либо
их карьерные устремления, и вы, вероятно, услышите утвердительный ответ на
каждый вопрос подобного рода. Управление проектами — это не только дисциплина, в
которой изучается процесс разработки продукта, а также рассматривается
управление процессами, определяющими выполнение технологических карт. Как известно,
продукты не могут разрабатываться без участия персонала. Составители
рассматриваемых 34 компетенций полагали, что все связанные с людьми действия — это
составные задачи, используемые на протяжении всего жизненного цикла разработки ПО.
Компетенция проекта 13: идентификация ключевых
компонентов планов
Зачастую такой важный аспект менеджмента проектов, как документирование
планов и других проектных компонентов, забывается или игнорируется. Как правило,
процесс документирования распространяется от анализа кода программ и
инженерного анализа традиционных систем до функциональных спецификаций, руководств
пользователя и проектных планов.
Обычно у программистов, являющихся хорошими специалистами в области
разработки ПО и поддержки приложений заказчика, нет ни навыков, ни желания разрабатывать
руководства пользователя. Программисты, вынужденные заниматься подобной рутинной
работой, делают это на уровне, слишком сложном для понимания среднего пользователя.
К сожалению, пользовательская документация зачастую непонятна, не может быть
найдена в общем комплекте документации, на Web-узле или вообще отсутствует.

60 Глава 1
Тщательность, логическая организация и пошаговые инструкции обеспечивают
создание пригодной для работы документации. Часто бывает так, что создание
документации откладывается до конца проекта, хотя допускать этого нельзя.
Для успешного осуществления любого проекта, большого или маленького,
необходимо несколько основных документов. Основным документом является план
управления проектом — карта перемещения команды по технологическому
маршруту проекта. Также понадобятся другие документы в зависимости от характеристик и
требований проекта. Они включают техническое задание проекта, деловое
обоснование, план .менеджмента рисков и конфигурации, план SQA, общения,
спецификации требований и разработки проекта, план тестирования, инструмент приемки и
погтпроцессный анализ. Навыки управления проектами, необходимые при
подготовке каждого из упомянутых документов, обсуждаются в книге в последующих
главах и разделах, поскольку они применяются на каждой фазе жизненного цикла
разработки продукта.
Мы будем обращаться к документации, по крайней мере, в десяти главах. В ходе
осуществления практики иллюстрируются различия между проектом, "дрейфующим"
па неясных воспоминаниях, и проектом, построенном на документальном основании.
Компетенция проекта 14: оценка стоимости проекта
Прогнозирование затрат и управление ими, наряду с графиком и областью
действия, представляют собой основные и весьма необходимые навыки. Эти компетенции
достаточно сложны для понимания— как говорится, единственной вещью, которая
труднее, чем прогноз будущего, является изменение прошлого.
Знание размера ПО — условие первостепенное, поскольку оно является основой
дчя оценки стоимости и трудозатрат. В главе 10 исследуются методы оценки размера
программ. Точность оценки размера программного продукта обеспечивает материал,
. ребуемый для точной оценки трудозатрат (см. главу 11). Оценка трудозатрат может
быть связана с оценкой других затрат, например, стоимости материалов и накладных
расходов. В результате можно вычислить полную стоимость программного проекта.
На рис. 1.10 демонстрируется предполагаемая тенденция использования услуг
главных проектантов при осуществлении программного проекта.
Старшие дизайнеры
Человеко-часы
300
I
millL
9
16
23
30
Январь
6
13
20
27
Февраль
6
13
20
27
Март
3
10
17
24
Апрель
1
В
15
22
Май
Рис. 1.10. Оценка трудозатрат

Введение 61
Размер ПО в значительной степени зависит от требований, которые будут
рассмотрены в главе 16.
В главе 12 будет показано, каким образом распределения ресурсов могут
существенно повлиять на проектные затраты посредством таких факторов, как
сверхурочное время, льготы и уровень опытности персонала.
Компетенция проекта 15: оценка трудозатрат
Для оценки затрат основным фактором является приблизительная оценка
трудозатрат, требуемых для создания программного продукта. Конечно, оценка
трудозатрат зависит от оценки размера ПО, которая, в свою очередь, зависит от наличия
полнело понимания требований, выдвигаемых при разработке программного
продукта. На рис. 1.10 показан экран, отображаемый в результате выполнения одного из
многих графических инструментов, который может помочь менеджерам проектов в
прогнозировании и отслеживании трудозатрат.
В главах 16 и 17 описывается порядок формирования корректных требований. Для
получения полной картины оценки можно воспользоваться материалами из глав 10 и 11.
Компетенция проекта 16: менеджмент рисков
Как уже отмечалось ранее, лучшие менеджеры проектов являются хорошими
менеджерами в области управления рисками. Устранение рисков — это ключевой навык
для любого руководителя, но он опасен для менеджеров программных проектов,
поскольку проекты по разработке ПО являются более сложными, поскольку продукт
неосязаем и поэтому его трудно проверить или оценить. Т.е. любой риск в этой
ситуации может привести к опасным последствиям.
В главе 18 будут рассмотрены некоторые модели, применяемые для менеджмента,
идентификации и контроля риска. Изучение этих моделей позволит получить
руководство, обеспечивающее нахождение наилучшего выхода в некоторых практических
ситуациях. В главе 21 будет показано, как могут использоваться методы измерения
программных проектов при контроле проектных рисков.
Компетенция проекта 17: отслеживание
процесса разработки ПО
Когда команда приступает к началу разработки ПО, менеджер проекта может
контролировать процесс производства несколькими способами. Здесь "вступает в игру"
производство ПО и методы оценки качества, данные о трудозатратах и стоимости, о
полученных затратах, а также степень усовершенствования процесса.
В данном случае навык управления проектами заключается в знании того, что
контролировать, когда и где измерять, а также в оценивании требуемых трудозатрат.
Также важно иметь сведения о зависимостях программного кода и персонала.
Немногие действия могут быть менее продуктивными, чем ожидание выделения нужных
ресурсов. R главе 21 и 22 многие из этих проблем обсуждаются подробнее. В главе 25 эти
проблемы связываются с целями проекта.
Компетенция проекта 18: разработка графика и ключевых
стадий для выполняемого проекта
Разработка графика выполняется на основе структуры WBS. Готовый график
содержит описания продолжительности этана, важных стадий, любых производимых

62 Глава 1
рабочих продуктов. Кроме того, он содержит информацию о том, за что отвечает тот
или иной специалист. Обычно представляемый в форме диаграммы Гантта, график
является таким же полезным, как и таблица. Он добавляет "плоть" к основе структуры
WBS, "вдыхая" в проект жизнь.
Хорошее календарное планирование требует определенной методики, подобной
той, что используется при разработке структуры WBS. Оно начинается с определения
области действия проекта (главы 7 и 14). В главе 15 рассматриваются параметры,
необходимые при создании графика проекта по разработке ПО.
Компетенция проекта 19: выбор и использование
соответствующих метрических показателей
Метрические показатели обеспечивают критерий для проекта разработки ПО.
Они выступают в роли своего рода системы "раннего оповещения". Если ход
разработки проекта отклоняется от намеченного курса, методы измерения "системы
оповещения" позволяют внести корректировки прежде, чем процесс станет
неуправляемым. Когда возникает необходимость в усовершенствовании процесса, методы
измерения могут использоваться с целью изменения точки зрения таким образом, чтобы
акцентировать внимание на обоснование трудозатрат, что обосновывается
имеющимися данными. На рис. 1.11 приводится пример отслеживания дефектов — одна из
областей применения инструментальных методов измерения.
120
100
1 80
™ 60
40
20
Рис. 1.11. Метрические показатели, применяемые
при разработке ПО
R главе 21 рассматриваются концепции, лежащие в основе метрических
показателен, наиболее часто используемых при разработке ПО. Также здесь будет
рассматриваться проблема выбора подходящей концепции для данного проекта. Способы
поддержки и необходимые ресурсы, используемые в этом случае, обсуждаются в
приложении Л. В главе 24 будет показано, как использовать некоторые инструменты с
целью контроля выбранного метода измерения. Эти навыки будут рассмотрены на
примере конкретного практического занятия.

Введение 63
Компетенция проекта 20: принципы выбора инструментов
управления проектами
Каждый менеджер проекта должен владеть критериями отбора и использования
соответствующих инструментов управления программными проектами.
Использование инструментов не будет гарантировать создания качественного ПО, соблюдения
сроков разработки или соответствия выделенным бюджетным средствам. Эти
инструменты могут выполнять лишь вспомогательную роль. Не существует панацеи,
способной заменить действия, требующие затрат времени на решение проблем, на
применение соответствующих инструментов, на реализацию плана работы с ними, а
также на обучение пользователей.
Диапазон действия основных инструментов простирается от простых
персональных администраторов потоков информации (Personal information manager, PIM) до
инструментов централизованного управления ресурсами в масштабе предприятия,
инструментов отслеживания и разработки графика. Также существуют
инструменты менеджмента конфигурации, которые ранжируются от простых исходных
систем управления версиями до полных систем менеджмента технологическими
данными для выпускаемых продуктов (Product data management, PDM) и
интегрированных CASE-инструментов. Критерии выбора и классификация инструментов
представлены в главе 24.
Компетенция проекта 21: отслеживание совместимости
действий команды разработчиков проекта
Этот навык является частью функции обеспечения качества ПО и включает
отслеживание проекта в отношении определенных процессов, определение
отклонений и способов их обработки.
В главах 5 и 21 рассматривается, каким образом можно определять и управлять
процессами проекта, обрабатывать результаты измерения, в то время как в главах 25,
26 и 30 рассматриваются навыки, необходимые для осуществления контроля
соответствия проектной команды, используемой в рамках определенных процессов.
Компетенция проекта 22: отслеживание хода разработки
проекта с применением метрических показателей
К сожалению, при разработке многих проектов несмотря на затраченные усилия
результат не соответствует ожиданиям. Ключевым навыком менеджмента проектов
управления является способность к отслеживанию реального хода выполнения
проекта, а не только понесенных затрат. Этот навык касается выбора метода измерения и
контроля разработки, а также включает анализ добавочной стоимости и организацию
буферизации данных проекта.
На рис. 1.12 и 1.13 демонстрируются два из многих инструментов отслеживания
ПО, где в графическом виде изображен ход разработки проекта. Как показано на
рис. 1.17, отслеживание хода разработки проекта — это интегральная задача, которая
охватывает жизненный цикл.
В главах, посвященных управлению программными проектами B5 и 26),
представлены методы и инструменты, используемые для отслеживания хода
разработки проектов. Глава 25 полностью посвящена отслеживанию и контролю проекта.
Здесь демонстрируется, каким образом следует использовать описанные
инструменты для оценки реального хода выполнения проекта, реализуемого проектной

64 Глава 1
командой. На практике используется лишь несколько методик отслеживания хода
выполнения проекта, поэтому предполагается, что для проектов характерно 90-
нроцентное выполнение.
Критическое отношение заработанной суммы (SPI*CPI)
Выборка из проекта Т638 от 19.07.97
2.0
1.9
1.8
1 7
1.6
1.5
1.4
1.3 -
1.2 -
1.1
1.0
0.9 -
0.8 -
0.7
0.6
0.5 -
0.4 -
0.3
0.2
0.1 hi
0.0
Mill
I I I I I I I I I I I I I I I I II
0.76
,— t— i— OOOOOOOOOOOOO»
■oooooooooooooooo
CR-ключ
0.9<CR< 1.1 Хорошо
0.8 < CR < 1.2 Проверка
0.6<CR<1.4 Проблема
/•"не. 1.12. Отслеживание хода разработки ПО
Проект А
Время
Ключ:
Проектируемый
Фактический
Рис. 1.13. Отслеживание хода
выполнения проекта

Введение 65
Навыки менеджмента персонала
Наравне с навыками, касающимися продукта и проекта, в этой книге будет описан
каждый из навыков менеджмента персонала, включенный в состав рассматриваемых 34
компетенций. Эти навыки показаны в табл. 1.5, где они выступают в качестве
компетенций (от 23 до 34). Краткое описание каждой из упомянутых компетенций будет
представлено в этом разделе, а более подробные сведения можно будет найти в
последующих главах книги.
Область действия навыков менеджмента персонала
А теперь будут вкратце рассмотрены навыки менеджмента персонала, которые
описываются компетенциями под номерами от 23 до 34. В представленной таблице
будет рассмотрена каждая компетенция. Главы книги, в которых более подробно
описывается каждая компетенция, перечислены в табл. 1.5.
Таблица 1.5. Компетенции персонала
Компетенция персонала
Описание
Глава
23. Оценка производительности
24. Вопросы интеллектуальной
собственности
25. Проведение эффективных
встреч
26. Взаимодействие и общение
27. Лидерство
28. Управление изменениями
29. Успешное ведение переговоров
30. Планирование карьерного роста
31. Эффективное представление
32. Набор персонала
33. Отбор команды
31. Создание команды
Оценка действий команды, направ- 29
ленная на улучшение ее работы
Понимание воздействия
критических проблем
Планирование и проведение
эффективных встреч
82
3-32
3-32
Работа с разработчиками, высшим
руководством и другими командами
Тренировка проектных команд для 6, 25, 26, 29
получения оптимальных результатов
Создание эффективного агента из- 29
менений
Разрешение конфликтов и успешное 6, 7, 12, 13, 16, 24,
ведение переговоров
Структурирование и определение
руководства карьерой
Эффективное использование
письменных и устных навыков
Успешное привлечение и
собеседование с членами команды
29,32
6, 12, 28, 29
7.17, 18, 25, 27,
29,32
6, 12, 29
Отбор высококомпетентных команд 6, 29
Формирование, руководство и под- 12, 13, 25, 26, 29
держка эффективной команды

66 Глава 1
Хотелось бы подчеркнуть важность компетенций, необходимых для отбора и
создания проектной команды, вселения чувства энтузиазма у ее членов, поощрения их за
решение трудных проблем и помощи каждому члену в планировании его карьеры.
Рассматриваемые в качестве интегрированных задач, навыки менеджмента
персонала необходимы для успешного завершения каждой фазы цикла SLC. Для тех людей,
которым не присуша врожденная способность к лидерству, ведению успешных
переговоров с целью создания взаимовыгодных ситуаций, будет полезно знать, что
каждому из этих навыков можно научиться.
В этом введении будет представлено краткое описание каждого из упомянутых 12
навыков менеджмента персонала, а также будет рассмотрено, как они связаны с
другими 22 компетенциями. Что - это какой проект и компетенции продукта
поддерживаются каждым из навыков менеджмента персонала. Когда— это на какой фазе
жизненного цикла разработки ПО применяются навыки управления. Вопросы из
категории почему и как для каждого из навыков менеджмента персонала будут более
подробно рассмотрены в последующих главах, как показано на рис. 1.14.
Менеджмент персонала, рассматриваемый
зачастую как более гибкая сторона управления
программными проектами, может быть
фактически наиболее важной частью структуры "ПО-
проект-поддержка: персонал, процесс, продукт"
(см. рис. 1.14). Общеизвестно, что организация
быстро перестанет соответствовать
требованиям бизнеса, если не будет создавать
программный продукт, как и то, что ПО не будет
соответствовать требованиям, ему не будет присуще
высокое качество или, возможно, даже не смо-
Ihic. 1.14. Навыки менеджмента персо- жет воплотиться в реальности, если команда
нала в перспективе разработчиков проекта не будет стремиться
к общему видению проекта и не будет иметь
эффективного лидера. Организация может соответствовать уровню 5 по
классификации Института SEI, но успешное выполнение проекта будет невозможным без
квалифицированной команды. Исследователям может принадлежать превосходное
изобретение, но продукт никогда не будет выпущен без организации
взаимодействия, эффективного представления и встреч, навыков ведения переговоров и
управления изменениями.
Поскольку навыки менеджмента персонала используются на каждой фазе
выполняемого проекта, жизненного цикла разработки ПО и в ходе постоянной поддержки
качества, трудно четко привязать каждый навык менеджмента персонала к
определенной фазе процесса выполнения проекта PMI, стадии SLC, или компетенции SQL
Поэтому здесь будет описано, где могут применяться многие навыки, а также то,
какие навыки могут быть особенно важны для завершения процесса или стадии
разработки продукта.
Например, для переговоров и управления изменениями могут постоянно требоваться
два навыка менеджмента персонала, тогда как выбор команды, очевидно, имеет место
только в начале выполнения проекта, например, в проекте PMI, как правило, на стадии
планирования проекта (который соответствует стадии жизненного цикла разработки ПО,
исследования концепции и/или исследования системы), как показано на рис. 1.15.

Введение 67
Исследование
концепции
N
V
Исследование
системы
—
i „
ч
Требования
i
1 .
\
Разработка
проекта
_
Л ^ -.
о юор команды ■*
к
i'
V
Внедрение
L .
к
<'
\
Установка
,
i я
\
' Г
■V
Эксплуатация
и поддержка
\
Сопровождение
к
i'
\.
Вывод из
эксплуатации
Рис. 1.15. Отбор команды разработчиков проектов
Зачастую во время любой осуществления любой фазы жизненного цикла
требуются многие компетенции. Причем одна компетенция SQI может поддерживать другие
компетенции. В ходе менеджмента персонала, задействованного в программных
проектах, зачастую требуется применение навыков управления персоналом,
инжиниринга ПО и познания в области разработки программ, а также интеллектуального
управления проектами. Пока происходит процесс освоения каждого навыка, вполне
логично использовать несколько навыков одновременно. В книгу включен раздел,
посвященный описанию процесса обучения каждому из навыков менеджмента
персонала. Также предполагается, что менеджеры проектов нуждаются в применении
одного или большего количества навыков менеджмента персонала.
Краткое описание навыков
менеджмента персонала
Компетенции, имеющие отношение к персоналу (с 23 до 34), кратко описаны в
следующих разделах.

68 Глава 1
Компетенция персонала 23: оценка действий команды
с целью повышения ее отдачи
Каким же образом можно узнать, правильно ли сформирована команда — как
единая команда, или же в виде группы разрозненных индивидуумов? Необходимо
добиться того, чтобы команда четко осознавала основные стадии проекта. Когда
команда находится на стадии "выполнения", исполнители должны утвердиться в своих
соответствующих ролях. В этот момент каждый член команды может оценивать
действия других членов. Как управляющий и сборщик информации, менеджер
проекта сможет непосредственно увидеть исполнителей высокого и низкого уровня и
назначить поддерживающий штат, воодушевленный на работу в команде и
ориентированный на достижение цели.
Оценка действий команды будет рассмотрена в главах 29-32.
Компетенция персонала 24: понимание степени воздействия
вопросов интеллектуальной собственности
Каждый менеджер программного проекта должен знать основные нормы права,
связанные с разработкой ПО. В этом разделе обсуждаются основные принципы законов,
касающихся заключения контрактов, лицензий и интеллектуальной собственности.
Вопросы интеллектуальной собственности будут обсуждены в главе 32.
Компетенция персонала 25: планирование и проведение
эффективных встреч
Плохая организация проведения встреч приводит к гораздо большим убыткам,
чем все другие негативные события, связанные с проектом. Это также может
привести к неэффективным контрактам, заключенных в рамках проекта. Всего лишь
несколько основных навыков и позиций требуется при проведении неофициальных
внутренних сеансов "мозгового штурма", формальных обзоров проекта, встреч, на
которых регистрируются результаты осмотра, или даже обсуждений решения
проблемы "один на один". Этот интегральный навык невероятно полезен на всем
протяжении жизненного цикла проекта. Если начало встречи, посвященной обсуждению
проекта, выдерживается в неконструктивном ключе, оставшаяся часть ее может быть
также неудачной. У вас будет возможность познакомиться с удачными и неудачными
вариантами проведенных встреч.
Методики проведения эффективных встреч будут рассматриваться в главе 29.
Компетенция персонала 26: сотрудничество с разработчиками,
высшим руководством и другими командами
Навыки взаимодействия применяются на любом уровне, но особенно они важны
при выполнении формальных отчетов и в общении со спонсорами, клиентами и
высшим руководством. Для эффективного управления взаимодействием среди всех
исполнителей проекта необходимо четкое понимание, по крайней мере, одной
модели индивидуальности (например, показатель типа Майерса-Бриггса, Myers-Briggs Type
Indicator®). Если индивидуумы не признаны, не поняты, а их характеристики
эффективно не обработаны, могут возникнуть серьезные проблемы с персоналом,
вследствие чего появляется дополнительный риск в ходе осуществления проекта. К счастью,
это именно та область, которой уделялось большое внимание начиная с 1940-х годов,

Введение 69
и на данный момент существует множество методик, позволяющих избежать
отрицательных факторов во время реализации проекта.
В качестве упражнения попробуем ответить на вопрос о том, что произойдет со
связями и взаимодействиями в случае, когда команда увеличивается от четырех до шести
членов. В этом случае количество связей/способов взаимодействия увеличивается от пяти до
шестнадцати. В чем же здесь проблема? В этом случае менеджеру проекта можно
посоветовать обеспечить дополнительные возможности по проведению общения (рис. 1.16).
Рис. 1.16. Сложность взаимодействий
Компетенция персонала 27: обучение команд разработчиков
проекта для получения оптимальных результатов
Лидеры умеют направлять потоки эмоциональных энергий в своих или в чьих-
либо интересах, осуществляют революции и воспитывают других лидеров. Они
постоянно тренируют и учат; они способны организовать свои идеи и мысли таким
образом, что те превращаются в легко усваиваемые понятия. Их ценности, например,
честность, прямота и священные договорные обязательства явно проявляются в их
собственном поведении. Лидеры действуют, а не только говорят.
Существует "целый мир" различий между менеджером и лидером. Лидер на уровне
интуиции видит, что может общаться с командой, а также получает гарантии того,
что команда разделяет его взгляды и желает работать для их воплощения на практике.
Видение — это долгосрочная стратегическая цель, которая может быть достигнута
путем выполнения ряда краткосрочных тактических действий. Истинный лидер
способен составить карту, используемую командой, чтобы передвигаться "отсюда" до
момента наступления видения, а также может удерживать команду на курсе, проходящем
через ряд "тактических стадий". В некоторых случаях ответ на вопрос "Каким
образом Вы определяете лидера?" звучит так: "Оглянитесь вокруг и посмотрите, имеет ли
он или она последователей". Последователи появляются в случае наличия
отношений, построенных на доверии.
Проблемы лидерства обсуждаются в главах 29-32.
Компетенция персонала 28: роль эффективного
генератора изменений
Общеизвестно, что изменения неизбежны: "Единственная вещь, которая остается
постоянной — это изменение". В индустрии ПО нельзя игнорировать это
обстоятельство, даже если сильно хочется, — технология развивается очень быстрыми темпами.

70 Глава 1
В то же время, изменения неприятны для многих людей, включая
высококвалифицированных разработчиков ПО, поскольку они выводят их из их зоны комфорта.
Менеджер проекта должен знать, как проложить "неотмеченные на карте маршруты",
связанные с изменениями. Область действия изменений простирается от
относительно небольших масштабов, например, переход к более новой версии
операционной системы или перестановка в офисе, до огромных изменений, например,
основание новой серии изделий. Большие проекты взаимосвязаны, что позволяет
наблюдать за круговоротом членов команды. При этом возникают потребности в
реагировании на потерю/приобретение нового члена команды.
Как и в случае со всеми остальными навыками менеджмента персонала, менеджер
проекта может освоить роль эффективного генератора изменений. Он может
приобрести "инструменты", необходимые для того, чтобы распознать, когда изменение
"появляется на горизонте", какие члены команды и каким образом будут наиболее
подвержены его воздействию, и как передать энергию и подготовить команду. К
счастью, психиатры и физиологи изучили эффекты изменения в течение десятилетий, и
теперь есть богатый материал исследований, который можно позаимствовать. Так, за
последние несколько лет несколько выдающихся людей взялись за изучение роли
генератора изменения в индустрии ПО.
Компетенция персонала 29: разрешение конфликтов
и успешное ведение переговоров
Переговоры зачастую являются ключом к повышению эффективности действия
остальной части навыков и методик. Они универсально применимы и абсолютно
необходимы для большинства взаимодействий — формальных или неофициальных. При
управлении недостаточными ресурсами, при возрастающих требованиях и
увеличивающейся нехватке времени неизбежен конфликт, и менеджер проекта в этой
ситуации должен стать "миротворцем". Далее будут рассмотрены некоторые примеры
правильного и неправильного ведения переговоров.
Навыки ведения переговоров будут рассматриваться в главе 29.
Компетенция персонала 30: структурирование и определение
руководства карьерным ростом
"Выбирайте работу, которую вы любите, и вам никогда не придется работать и дня".
Возможно ли обучить штат сотрудников тому, как следует любить выполняемую ими
работу? Возможно. Когда члены команды участвуют в выборе своего места в организации,
они могут с нетерпением ожидать "жизни после проекта". Неопределенность
относительно следующего назначения, особенно на заключительных стадиях проекта,
является одним из наиболее сложных аспектов менеджмента персонала. Менеджеры проектов
должны обладать тонким искусством индивидуальной оценки работы сотрудника и
уметь выделять каждого человека. Каждое усилие, направленное на то, чтобы
индивидуальные навыки и склонности соответствовали проектным ролям, должно
предприниматься в рамках здравого смысла и в пределах организационной политики. Некоторые
исследователи организационных структур полагают, что не существует как таковой
"проблемы индивидуальности" в команде разработчиков проекта, а бывают частые
случаи несоответствия человека и занимаемой им должности. Какой бы ни была причина,
чувство разочарования в отношении карьерного роста часто проявляется в виде
вспышек немотивированного гнева или даже путем саботажа проекта.

Введение 71
Компетенция персонала 31: эффективное использование
письменных и устных навыков
От менеджеров проектов требуется давать представления о "состоянии проекта"
на многих уровнях. Создание представлений— это интегральная задача, стоящая в
одном ряду с осуществлением общения. Краткое и эффективное представление
информации, направленное на то, чтобы она была получена и понята правильно,
является критически важным навыком в деле менеджмента персонала. В связи с этим
обсуждаются основные принципы графического дизайна, публичного общения, деловой
переписки и однозначного представления чисел и статистики. И хорошие, и плохие
примеры использования этих инструментов приводятся в практическом занятии.
Например, неправильно используемая статистика может привести к искажению
фактического хода реализации проекта. В случае успешного представления проекта
руководству особенно важной представляется встреча, на которой осуществляется обзор
статуса проекта. В любом случае, краткие, коммуникативные и точные графики или
текст практически всегда оказываются действенными.
Навыки осуществления представления будут рассматриваться в главе 29.
Компетенция персонала 32: успешное привлечение
и собеседование с членами команды
Собеседование с потенциальными членами команды — это реальный процесс
отбора членов команды, включающий определение навыков, необходимых для
выполнения задачи, и подразумевающий поиск с помощью резюме и телефона. В процессе
интервью опытный менеджер по персоналу умеет благодаря эффективным вопросам
даже без полученных ответов распознавать характерные черты кандидата.
Неоднократно отмечалось, что лучший способ находить членов команды—
использовать разветвленную "сеть". Иногда это срабатывает, и специалисты в
индустрии ПО формируют подобщности программистов баз данных, государственных и
правительственных деловых аналитиков, экспертов по языкам программирования,
Internet-программистов и множество других "субкультур", поставляющих таланты.
Слухи быстро распространяются, и специалистов, имеющих хорошую репутацию,
приглашают участвовать в проектах повторно. Но в большинстве случаев менеджеры
проектов должны полагаться на рекламу или рекрутинговые фирмы при поиске
талантов. Данные в файлах претендента иногда имеют большой объем, но очень мало
полезной информации. Поэтому при проведении интервью с потенциально
хорошими кандидатами приходится рассматривать параметры, количество которых
превышает количество чисто технических навыков. Организатор интервью может
использовать методики, такие как активное прослушивание и поведенческий опрос для
определения того, будет ли подходить кандидат другим членам команды, а также сможет
ли он поддерживать точку зрения группы.
Привлечение персонала и проведение интервью рассматривается в главе 6.
Компетенция персонала 33: отбор
высококомпетентных команд
Для укомплектования проектного персонала требуется способность к пониманию
людей в контексте высокоэффективной команды. Для этого полезно знать основные
модели индивидуальностей, а также владеть основами вербовки и создания команд.
Поскольку идентификация и понимание индивидуальностей являются важным
аспектом отбора команд, поэтому будут описаны психологические модели, например, модели

72 Глава 1
Основная модель жизненного цикла системы
• Отчет о разрешенной проблеме ■
■Основной расширенный отчет о проблемах !
■ Проанализированный отчет о возникших проблемах
Рис. 1.17. Модель жизненного цикла разработки программного продукта согласно
стандарту ШЕЕ 1074

Введение 73
Ллан
обеспечения
качества
• Планобеспе-j
чения качест- \
ваПО
Менеджмент качества ПО
Разработка
метрических
показателей
оценки качества
i • Метрические i
показатели ■
_|_
Менеджмент качества ПО
• Оценки качества проекта
I
»
Идентификация потребности в улучшении качества
• Рекомендации по улучшению качества
Аттестация и верификация ПО
Аттестация и верификация
* План аттестации и верификации ПО
Выполнение задач по аттестации и верификации
• Отчеты об оценках
t
• Отчеты о результатах анализа [
Сбор и анализ данных измерений
Тестирование плана
j ■ Планы тестирования
Разработка спецификации
тестирования
• Спецификации тестирования t
Выполнение
тестирования
План менеджмента конфигурации
■ План менеджмента конфигурации ПО
Разработка схемы идентификации конфигурации
■ Схема идентификации конфигурации
Итоговой отчет о тестировании i
Протестированное ПО }
i i
i i
Менеджмент качества ПО
• Состояние изменения
Выполнение контроля конфигурации
Учет состояния выполнения
■ Отчеты о состоянии
Документирование плана
i * План документирования
i I
Разработка документации
Документированив внедрения
■ Документы i
• Опубликованные документы
Документирование производства и распределения
Программа обучения
• Учебный план
Процесс обучения
Разработка
учебных
материалов
Руководство
по обучению
Учебный
материал
Внедрение учебной программы
Утвержденная учебная программа
■ Обновленные учебные материалы t
■ Обученный персонал
Рис. 1.17. Модель жизненного цикла разработки программного продукта согласно стандарту
ШЕЕ 1074 (продолжение)

74 Глава 1
индивидуальности Майерса-Бриггса (Myers-Briggs Personality Type). Модель другого
типа называется "сортировщиком характера" доктора Кирси (David W. Kiersey Kiersey
Temperament Sorter, 1997-2001) и набором эннеаграмм.
Независимо от того, насколько эффективной является команда, она должна быть
способной выполнять любую работу. Команда программистов на Java, например,
сможет разработать очередное приложение-киллер, но они могут оказаться неспособными
автоматизировать деятельность дневного детского сада (что в настоящее время
является весьма прибыльным бизнесом), если в команде отсутствует грамотный деловой
аналитик. Предполагая, что может быть определена оптимальная "смесь" талантов,
руководитель должен уметь определять компетентность всей команды в целом и каждого ее
члена в частности. Доктор Билл Куртис сообщает о том, что показатель
производительности очень изменяется для "наилучших" и "наихудших" программистов, в зависимости
от их опыта, знания предметной области и врожденного интеллекта .
Эти вопросы подробнее обсуждаются в главе 6.
Компетенция персонала 34: формирование, руководство
и поддержка эффективной команды
При создании команды необходимо стремиться к оптимальному сочетанию
индивидуальностей. Модель развития команды будет обсуждаться на основе пяти
классических стадий: формирование, штурм, приведение к норме, деятельность и роспуск.
Существует ряд успешных методов, обеспечивающих превращение группы
индивидуумов в настоящую команду.
Если все члены команды отличаются хорошей совместимостью, они будут
вспоминать проект как приятный период в их жизни, но они могут помнить и "неудачу",
связанную с этим проектом. Так же, как необходимо наличие песка в устрице для
появления жемчуга, некоторые споры среди членов команды зачастую порождают
оригинальные идеи. Лучше всего, если команда состоит из интровертов и экстравертов,
чувствительных и интуитивных типов, думающих и чувствующих людей. Постоянное
и полное согласие по всем проблемам скучно, непроизводительно и даже
способствует вырождению. Команды эффективны, когда в них могут происходить живые
конструктивные споры, не наносящие вреда личным чувствам.
Существует несколько хорошо известных структур команд разработчиков ПО.
Преимущества и недостатки этих структур будут рассмотрены в главе 6.
Резюме
Теперь, после краткого описания содержания книги на основе областей
применения каждой компетенции в IEEE-стадиях жизненного цикла разработки ПО, можно
перейти к обсуждению введения, планирования, выполнения, управления и закрытия
проекта по разработке ПО. На рис. 1.17 приводится модель жизненного цикла
разработки программного продукта согласно стандарту IEEE 1074. Она идентифицирует
упомянутые стадии и перечисляет для каждой из них определенные действия по
разработке ПО. Это главная модель жизненного цикла разработки продукта,
используемая на протяжении всего этого практического руководства.
11 Curtis Bill, Herb Krasner, and Neil Iscoe. "A Field Study of the Software Design Process for
Large Systems." Communications of the ACM, 1988. - 31A1): 1268-1287.

Введение 75
Контрольные вопросы
1. Расположите следующие понятия в иерархическом порядке от высшего уровня к
низшему: действие, фаза, программа, проект, система, задача.
2. После усвоения материала главы определите своими словами следующие термины:
34 компетенции, действие, менеджмент, навыки менеджмента персонала, фаза,
треугольник ПМ, процесс, навыки продукта, программа, проект, менеджмент проекта,
проектные навыки, ПО, разработка ПО, жизненный цикл разработки
программного обеспечения, менеджмент программного проекта (SWPM), система, задача.
3. Посетите Web-узлы трех из перечисленных организаций по поддержке стандартов.
Каким образом представление материалов, разработанных в организации, помогает
вам в усвоении стандартов? Каким образом Web-презентации сокращают срок
адаптации? Основываясь на представленной информации, сравните и
противопоставьте стандарты, выдвинутые каждой из трех упомянутых организаций.
4. Если бы вы захотели настраивать процессы, выполняемые в вашей организации,
то как повлияли бы на ваши решения методики альтернативных процессов и
действий развития?
5. Приведите примеры методов, инструментов и технологий, которые пользователь
применяет в своих ежедневных деловых действиях.
6. Посетите Web-узел www.pmi. org и просмотрите РМ1 РМВОК. Откройте главу 3 и
просмотрите, каким образом в этой книге приспосабливается жизненный цикл
разработки ПО к ПМ-стадиям начала выполнения, планирования, выполнения,
контроля и закрытия.
7. Попробуйте найти в Web описания некоторых из инструментов, используемых
для выявления основных типов индивидуальности. В ходе осуществления
типичного поиска по ключевому слову MBTI (Myers-Briggs Type Indicator) возвращаются
следующие ссылки:
www.personalityt.ype. com/'quiz, html
www.teamtechnology.со.uk/tt/h-articl/mb-simpl.htm
keirsey.com/

Практическое занятие.
Обзор
Метод обучения на практических примерах использовался в течение всего курса
управления проектами для подготовки студентов к решению реальных задач. В книге
широко используется метод практического обучения на примере системы
резервирования мест, применяемой на Китайской железной дороге. При использовании
подобного метода обучения возможно моделирование ситуаций, возникающих при
обслуживании клиентов. Поскольку в данном случае идет речь лишь о моделировании,
можно смело утверждать, что реальные системы могут содержать большее
количество данных, чем опытные образцы. На практике могут возникать неоднозначные
ситуации, влекущие за собой некоторую противоречивость обрабатываемой
информации. Многие фрагменты данных будут представлены без адекватного обсуждения (как
в реальной жизни). Метод обучения на практических примерах будет полезен для
преподавателей в качестве классификационного проекта. Система резервирования
мест (Passenger Reservation System), применяемая на Китайской железной дороге,
будет упоминаться в каждой главе (причем она будет служить источником дальнейшей
информации и новых клиентских задач).
Второе расширенное практическое занятие, связанное с системой управления
лифтом, будет использоваться в качестве примера в приложении F. Здесь будет
рассмотрен полный набор параметров, используемых при управлении проектами.
Пример с лифтом применяется в тех ситуациях, когда сравниваются технические аспекты
инжиниринга ПО (например, в случае сравнения классического и объектно-
ориентированного моделирования).
Прототип системы резервирования мест на Китайской железной дороге скорее
всего не слишком связан с вашей страной (разумеется, если вы не живете в Китае).
Поэтому некоторые из ограничений будут отличаться от тех, к которым вы
привыкли. Возможность усовершенствования этого прототипа позволит получить
экспертную оценку, необходимую для того, чтобы сформировать финальный проект. Для
того чтобы стать одним из претендентов, который будет создавать реальную
информационную систему, желательно располагать успешно реализованным прототипом.

Практическое занятие. Обзор 77
Первый шаг на пути к этому заключается в том, чтобы выиграть состязание с другими
организациями в деле создания прототипа, наилучшим образом моделирующего
реальную систему.
Представьте себе, что в вашем распоряжении находится команда, позволяющая
разработать план проекта по разработке ограниченного прототипа системы
резервирования мест на Китайской железной дороге. Ниже приводится список известных
условий, соблюдение которых обеспечивает выполнение работы:
■ ни один человек из вашей команды не говорит на местном языке, поэтому
потребуется воспользоваться услугами переводчиков;
■ вам пе позволят командировать своих программистов или аналитиков в эту
страну для работы над проектом. В вашем распоряжении окажется лишь команда,
выполняющая менеджмент проекта. Работать придется с персоналом и
оборудованием, предоставленными Министерством путей сообщения Китая (Chinese Rail-
roar] Ministry, CRM);
■ местные программисты имеют довольно солидную подготовку в области
информатики, но у них отсутствуют общие навыки инжиниринга ПО. Они также слабы
в области объектно-ориентированного проектирования (хотя всячески
стараются преуспеть в этой области) и телекоммуникаций. Только недавно Китай
получил возможность приобретать телекоммуникационное ПО из США и других
западных стран;
■ министерство путей сообщения Китая располагает современными аппаратными
средствами и ПО. Хотя это не совсем соответствует действительности, но все же
стоит отметить, что в распоряжении этой организации имеются ресурсы
аппаратных и программных средств, достаточные для реализации на практике клиент-
серверной архитектуры на основе автоматизированных рабочих мест. Даже если
учитывать наличие доступных пакетов по разработке объектно-ориентированного
ПО, следует отметить, что персонал министерства путей сообщения Китая не
имеет опыта в разработке объектно-ориентированных систем;
■ ранее министерство путей сообщения Китая уже предпринимало попытку по
разработке достаточно развитой системы резервирования мест на
транспорте, но результат был неудовлетворительным. Это было до того, как стали
доступны хорошие технологии телекоммуникаций, поэтому исходные условия
были несложными;
■ вам позволят опрашивать клиентов, служащих и менеджеров, которые помогут
вам и корректном формулировании плана разработки проекта.
Основные сведения о железнодорожной
системе Китая
Общая длина железных дорог в Китае превышает 52 тысячи километров. Услугами
железной дороги ежедневно пользуются около 3,7 миллионов человек. Обширная
железнодорожная сеть охватывает все области страны, кроме Тибета. Обычно
билеты на поезд в Китае можно купить в отделениях Китайского бюро
международных путешествий (China International Travel Service, CITS), находящихся в крупных
туристических гостиницах. На вокзалах больших городов существуют также службы

78 Глава 2
предварительной продажи билетов или отделения для обслуживания иностранцев.
В зависимости от дальности поездки, билеты могут быть действительны на срок от
одного до семи дней: 250 км — 2 дня, 500 км — 3 дня, 1000 км — 3 дня, 2000 км — 6 дней.
Покупка железнодорожного билета в Китае может оказаться забавным, но не всегда
успешным предприятием. Граждане других стран должны принять это к сведению и
планировать покупку билетов заранее или пользоваться услугами одного из офисов
CITS, открытых во многих странах. Обратите внимание на карту Китая (рис. 2.1) и
примечание 2.1, где приводится необходимая контактная информация, имеющая
отношение к бюро CITS.
Рис. 2.1. Карта Китая
Источник: Карта, составленная ЦРУ и помещенная на Web-странице Техасского
университета штата Техас в собрании карт библиотеки Пэрри-Кастанеда в г. Остине
(www.lib.utexas.edu/maps/cia99/china_sm99.jpg).
Примечание 2.1. Контактная информация CITS
Адрес: 6 East С^^^^Ъ^ЩЩЩ^^^Щ^^
Телефон: 8S-1-5128931, желёзнодрр^^^зЩ!^
В Китае железнодорожные билеты подразделяются согласно четырем различным
категориям посадочных мест: твердый сидячий вагон, твердый спальный вагон,
мягкий сидячий вагон и мягкий спальный вагон. Перечисленные категории мест бывают
далеко не в каждом поезде. Условия поездки в разных поездах будут различными. Все
поезда, вагоны и места пронумерованы, и соответствующие номера должны быть
указаны в билете. Твердое сидячее место представляет собой оббитое войлоком место в
пассажирском вагоне, который, как правило, самый шумный и наиболее
переполненный. Иностранцам не рекомендуется брать подобные билеты, однако, этот вариант
может быть приемлем для коротких дневных поездок. Твердый спальный вагон
состоит из бездверных купе. В каждом купе находятся двухъярусные полки, причем
нижние места используются в роли сидячих в дневное время суток. Мягкие места

Практическое занятие. Обзор 79
обычно продаются на более дальних маршрутах. Мягкий спальный вагон разделен на
закрывающиеся отдельные купе с четырьмя полками в каждом. Здесь национальная
железная дорога обеспечивает относительно неплохие условия проезда, которые
включают чистые туалетные комнаты, ковры и кондиционирование воздуха. Такие
вагоны обычно располагаются в центральной части поезда.
Вагоны-рестораны обычно включаются в состав поездов дальнего следования A2 или
более часов в пути). При наличии вагона-ресторана пассажирам предлагается горячий
завтрак, обед и ужин. Проводники мягких вагонов подают горячий чай. Вагон-ресторан
находится обычно в середине поезда. Продовольствие иногда можно купить прямо на
станциях по 1гути следования поезда. Для более длинных поездок следует запастись на
дорогу собственным провиантом. На крупных станциях есть комнаты ожидания
первого и второго классов, а на относительно небольших станциях имеются специально
отведенные залы ожидания. На табло высвечиваются объявления с номером поезда и
пунктом назначения. Почти на всех станциях есть камеры хранения.
Цены зависят от класса обслуживания и дальности поездки. Практикуется доплата
за экспресс-обслуживание. Цена билетов, купленных в офисе CITS (для иностранцев),
гораздо выше, чем цены на обычные билеты для граждан Китая. Однако покупка
более дешевых билетов в обычной кассе может превратиться в настоящее приключение
и рекомендуется коммивояжерам, у которых есть свободное время. Туристический
билет в твердый спальный вагон скорого поезда от Пекина до Шанхая A462 км) стоит
приблизительно 46 юаней E,75 фунтов стерлингов или почти 10 долларов).
Обычно по номерам поездов можно узнать кое-что относительно их типов:
■ поезда с номерами от 1 до 90 — скорые поезда, предлагающие все классы
обслуживания. Имеется доплата за обслуживание и скорость;
■ поезда с номерами от 100 до 350 чаще останавливаются и имеют меньшее
количество спальных мест. Существует небольшая разница в ценах по сравнению со
скорым поездом;
■ поезда с номерами от 400 до 500 являются медленными и устаревшими и
останавливаются "возле каждого столба". Здесь предлагается ограниченный набор выбор
классов и услуг;
■ нумерация пригородных поездов начинается с 700 и выше.
Перспективы китайских железных дорог1
Главная проблема, стоящая перед Китаем в этом году заключается в
необходимости сохранения темпов экономического роста (8 % в год) на фоне серьезного
экономического кризиса, охватившего многие страны Юго-Восточной Азии. Внутренняя
стимуляция спроса, особенно вливание массивных инфраструктурных инвестиций,
является частью решения этой проблемы. К числу положительных факторов также
относится крупномасштабное строительство железных дорог.
29 марта 2001 года Государственный совет одобрил девятый пятилетний план
развития народного хозяйства Китая. Было решено инвестировать 30 миллиардов
долларов в строительство железной дороги в течение последующих пяти лет, что
www. capitolwebservices. com/china2thou/9805p3.htm. Chunlei Zhao. "Railroad
Building as a Locomotive for Growth." China 2000: The Monthly Newsletter. May, 1998.

80 Глава 2
на 11 миллиардов долларов больше, чем было предусмотрено восьмым пятилетним
планом. Планируется построить 5340 км новых железных дорог и 2580 км
двухколейных железных дорог (расширение возможностей существующих линий),
электрифицировать 4400 км железных дорог и построить 1000 км местных железных дорог. Все
это приведет к увеличению общей эксплуатационной длины национальной железной
дороги до 68000 км к третьему году пятилетки и более чем 70000 км к пятому,
завершающему году пятилетки.
Поскольку Китай — это страна с обширной территорией и огромным населением,
железные дороги играют решающую роль в его транспортной системе. В настоящее
время в Китае имеется 65000 км действующих железных дорог, из которых более чем
11000 км электрифицированы. На службе у Китайской железной дороги находятся
более 15000 локомотивов, 34000 пассажирских поездов и 540000 товарных вагонов.
Полный ежегодный грузопассажирский оборот составляет 920 миллионов человек
(объем грузовых перевозок оценивается в 162 миллиарда тонн).
Однако железнодорожная система все еще не в состоянии играть роль двигателя
модернизации страны и стимулятора международной торговли. Фактически,
плотность перевозок по главным железным дорогам превысила точку насыщения, а
использование железной дороги достигло предела грузовой пропускной способности.
Низкая плотность железных дорог и неправильное расположение первоначальной
железнодорожной сети в центральных и западных частях страны долго
препятствовали эффективной эксплуатации огромных природных ресурсов. Таким образом,
отсталая национальная железнодорожная система стала главным "тормозом" для
быстро развивающейся экономики Китая.
Учитывая эти обстоятельства, можно прийти к выводу, что ускоренное
расширение железнодорожной системы будет играть существенную роль в повышении
экономического роста в национальном масштабе, приводя к более равномерному развитию
различных регионов, поглощая избыток рабочей силы и расширяя потенциал
объединенного национального рынка.
Как известно, строительство железной дороги требует огромных
капиталовложений и вовлекает длинную цепь взаимосвязанных отраслей промышленности.
Крупные инвестиции в этой области будут стимулировать развитие большого количества
вторичных отраслей промышленности, таких как производство чугуна и стали,
машин, энергии, строительных материалов и электронного оборудования.
Важные проекты развития инфраструктуры в наступающей пятилетке будут
следующими:
■ ускоренное строительство пассажирских линий с акцентом на создании или
технической модернизации тех линий, которые связывают главные экономические
зоны, расширяя таким образом сеть транзитных маршрутов. Особое внимание
будет уделено юго-западу Китая, где транспортный дефицит особенно ощутим;
■ ускоренное строительство новых, универсальных железных дорог с акцентом на
центральные и западные области страны;
■ реконструкция существующих железных дорог путем дальнейшей модернизации
оборудования с использованием преимуществ самых последних достижений
высоких технологий;
■ назначение приоритета высшего уровня данным проектам с целью максимизации
их социального и экономического воздействия.

Практическое занятие. Обзор 81
План девятой пятилетки предусматривает создание железнодорожной сети
Т-формы. Большая артерия, ведущая с востока на запад, будет построена по реке Янцзы
(Чанцзян), начиная с провинции Сычуань на юго-западе Китая. Она будет связана с
другой магистральной дорогой — с севера на юг, проходящей по восточному
побережью, начиная от города Харбина на северо-востоке Китая.
Этот план соответствует замыслам Сун Ят Сена (Dr. Sun Yat Sen), изложенным в
его национальной программе строительства несколько десятилетий тому назад.
Строительство грандиозной железнодорожной сети Т-формы ускорит экономическое
развитие обширных районов на юго-западе Китая, удаленных от промышленных и
культурных центров.
Тем временем, на повестке дня будет также строительство первой
высокоскоростной железной дороги, связывающей Пекин и Шанхай. Завершение строительства
новой железной дороги, длиной 1300 км, обеспечивающей движение со скоростью до
250 км в час, запланировано через десять лет. Ее строительство значительно
улучшило бы ситуацию с транспортным обслуживанием в обширном регионе,
расположенном между двумя главными городами Китая.
Расширение национальной железнодорожной системы Китая в таком
беспрецедентном масштабе за текущие пять лет должно заложить твердый фундамент для
продвижения всей экономики Китая к новым высотам. По счастливому совпадению, это
послужит той же самой цели, что и строительство шести трансконтинентальных
железных дорог в Соединенных Штатах в прошлом столетии. Этот локомотив будет
тянуть поезд Китая к осуществлению давно лелеемой национальной мечте о
модернизации экономики.
Среда китайского бизнеса2
Энергетический контракт Вестингауза
Во время визита заместителя министра Отдела торговли Дэвида Аарона (David
Aaron) в Пекин, компания Вестингауз Пауэр Дженерейшн (Westinghouse Power
Generation) объявила 16 апреля 2001 года о подписании $ 170-миллионного контракта,
связанного со строительством электростанции в Китае. В соответствии с контрактом,
Вестингауз и его партнеры по консорциуму Блэк и Вэтч (Black & Veatch) из города
Канзас-Сити, США, Штат Канзас, и СМЕС Китая будут проектировать и строить
турбинный и бойлерный цех для 700-мегаваттной, двухблочной, работающий на угле
электростанции Юджоу (Yuzhou) в провинции Хайнань (Не Nan). В обязанности
фирмы Вестингауз входит поставка турбогенераторного оборудования и управление
консорциумом. Проект финансируется Азиатским банком реконструкции и развития.
В настоящее время фирма Вестингауз имеет восемь совместных предприятий в Китае
и со своими лицензиями и партнерами по совместным предприятиям вырабатывает
более 50000 мегаватт электроэнергии по всему региону. Ожидается, что
строительство в рамках проекта начнется в конце этого года, а электростанция начнет
функционировать через три года.
" www. china2thou. com. Business Briefs. China 2000: The Monthly Newsletter. May 1988.

82 Глава 2
Негосударственная группа в займе IFC
Международная финансовая корпорация (International Finance Corp., IFC),
отделение финансирования частного сектора Мирового банка, подписала 27 марта 2001
года беспрецедентный проект сотрудничества, включающий Китайский
негосударственный финансовый дом (Chinese non-state financing house). Сделка заключена в
рамках 30-миллионной ссуды IFC (в долларах) для Восточной финансовой корпорации
(Orient Finance Co.) — члена Восточной группы и первой негосударственной
финансовой компании в Китае. Менеджер IFC по операциям в Восточной и Юго-Восточной
Азии Джейвсд Хамид (Javed Hamid) заявил, что этот проект отражает острый интерес
IFC к поддержке развития рынка капитала Китая и его частных секторов. Хамид
сказал, что компания будет активнее поддерживать частный бизнес, участвуя в реформе
государственных фирм. Корпорация IFC, которая уже предоставила 1,15 миллиардов
долларов в виде ссуд и инвестиций для Китая, планирует предоставить еще 400
миллионов долларов в первом году девятой пятилетки. Хамид заявил, что фирма IFC
также стремится принимать участие в развитии финансового рынка Китая, сотрудничая
е местными налоговыми фирмами, банками, страховыми компаниями и брокерами
ценных бумаг.
Система Глобалстар
21 апреля 2001 года корпорация Глобалстар (Globalstar) объявила, что
Гонконгская компания с ограниченной ответственностью Чайна Телеком Груп Лтд. (China
Telecom Group Ltd.) согласилась инвестировать 37,5 миллионов долларов, чтобы
стать полноправным партнером в проекте Globalstar L.P.. China Telecom вместе с
('I IINJ.YSAT (сокр. от China Telecommunications Broadcast Satellite Corporation —
Спутниковая радиовещательная телекоммуникационная корпорация Китая) имеет
исключительные права на предоставление услуг Глобалстар в Китае. Как ожидается, обе
компании будут полностью находиться в собственности недавно сформированного
Министерства информационной индустрии Китая (Ministry of Information Industry,
МП) и контролироваться им. Бернард Л. Шварц (Bernard L. Schwartz) председатель и
; л.шпый администратор Globalstar L.P. и Лорал Спэйс энд Коммьюникейшнз (Loral
Space and Communications) и крупнейший владелец акций Глобалстара заявил:
"Присоединение China Telecom как полноправного партнера укрепляет
обязательство Глобалстара по выполнению обещания относительно обеспечения мобильных
спутниковых коммуникаций для 1,2 миллиардов граждан Китая". China Telecom и
CHIXASAT будут управлять всеми операциями Глобалстара в Китае. Система
Глобалстар включает 48 спутников на низких околоземных орбитах (low-earth-orbiting, LEO)
п глобальную сеть наземных станций. Она обеспечивает в областях с недостаточной
мчи отсутствующей инфраструктурой телекоммуникаций возможность посылать или
получать запросы, а также передавать данные. Первые четыре спутника системы
Глобалстар были успешно запущены 14-ого февраля 2001 года.
Приоритеты минеральных ресурсов
Привлечение иностранных инвестиций в сектор горнодобывающей
промышленности Китая и повышение стандарта управления природными ресурсами
страны остаются приоритетами для нового Министра управления земельными и
природными ресурсами. Согласно высказыванию Чжоу Йонгканга (Zhou Yongkang):
"Цель непрерывного экономического развития требует, чтобы мы искали рынки и

Практическое занятие. Обзор 83
источники поставки дома, и за рубежом. Создание Министерства управления
земельными и природными ресурсами будет способствовать использованию
природных ресурсов, а также помогать иностранным инвесторам более эффективно
проводить свою деловую деятельность в Китае". В течение нескольких прошлых лет,
иностранные инвестиции были ограничены основными секторами, такими как
разведка нефти и добыча угля.
Описание проекта
Министерство путей сообщения Китая (CRM) сформулировало запрос о создании
прототипа системы автоматического резервирования мест на железной дороге
(automated railway reservation system, ARRS). Краеугольным камнем этого
предложения станет план проекта. Проектный план будет оцениваться по его достоинствам,
таким как выполнимый план разработки и описание процесса. Возникла серьезная
конкуренция между предполагаемыми поставщиками. Если какая-либо организация
сможет убедить министерство CRM в реальности прототипа и представить удачную
систему ARRS, то ей будет отдано предпочтение при разработке полномасштабной
системы ARRS.
Пока что вы не располагаете преимуществами, проявляющимися в форме
завершенного анализа требований или проекта. Предоставленная здесь информация
предназначена для того, чтобы дать вам достаточное количество данных для оценки
требуемых усилий и создания начального плана проекта.
Представленные планы оцениваются по применяемому в них подходу к
управлению и пригодности для находящегося под рукой проекта. При этом CRM ожидает,
что побеждающая фирма-поставщик модернизирует свой план, поскольку проект
постоянно совершенствуется.
Ниже приведена некоторая общая статистика, касающаяся железных дорог в Китае:
■ в Китае построено более 10000 железнодорожных вокзалов;
■ некоторые важные линии отличаются чрезвычайно высокой степенью
загруженности. Количество пассажиров, проезжающих ежемесячно между Пекином и
Шанхаем, исчисляется в миллионах;
■ в некоторых отдаленных регионах периодичность курсирования поездов
составляет один раз в неделю;
■ предполагается, что каждый житель Китая пользуется поездом, по крайней мере,
один раз в год (в Китае проживает 1,2 миллиарда человек).
Ваша ситуация с управлением проектом
Вы — менеджер команды разработки проекта, которая создает ограниченный
прототип системы резервирования пассажирских мест на Китайской железной дороге.
Ниже приводится список известных условий, которые следует учитывать в работе:
■ ни один человек из вашей команды не говорит на китайском языке, поэтому
придется воспользоваться услугами переводчиков;
■ вам не позволят привезти своих программистов или аналитиков в Китай для
работы над проектом. Вы будете ограничены в рамках собственной команды,
реализующей менеджмент проекта. А работать придется с персоналом и оборудованием,

84 Глава 2
предоставленными Министерством путей сообщения Китая (Chinese Railroad
Ministry. CRM). В качестве менеджера проекта, вы входите в группу специалистов,
которым разрешено работать в Китае;
■ местные программисты имеют довольно солидную подготовку в области
информатики, но у них отсутствуют наиболее типичные навыки по инжинирингу ПО.
Они слабы в вопросах объектно-ориентированной разработки (лишь
ознакомлены с разработками в рамках ОО) и телекоммуникаций. Только недавно Китай
получил возможность приобретать телекоммуникационное ПО в США и других
западных странах;
■ специалисты из CRM имеют современные аппаратные средства и ПО. Имеются
достаточные аппаратные средства ЭВМ и ПО, позволяющие реализовать
клиент-серверный подход при создании автоматизированных рабочих мест. Даже
учитывая то, что имеются доступные готовые пакеты по разработке объектно-
ориентированных программ, мало кто из персонала CRM имеет опыт по
разработке объектно-ориентированных систем:
■ министерство CRM ранее уже предпринимало попытку создания достаточно
развитой системы резервирования, но она потерпела неудачу. Это было до того, как
( r.i'iii доступны современные телекоммуникационные технологии, так что
начальные условия были достаточно простыми;
и нам позволят опрашивать клиентов, служащих и руководителей, что необходимо
для тщательной разработки плана проекта.
Ресурсы
Министерство CRM высказало пожелание, чтобы в этом проекте использовались
их собственные программисты. Это означает, что побеждающая организация-
поставщик будет действовать как команда управления и ей будет позволено привезти
в < трапу только свою команду. Поскольку CRM обеспечена также превосходными ре-
< \|>гами оборудования, организация-поставщик не может завезти в страну дополни-
[(■ п.поо производственное оборудование.
Вы будете работать с 26 профессионалами в области программирования:
■ один менеджер в области разработки программ, хорошо говорящий и пишущий на
английском языке;
и три аналитика, имеющих обширный опыт в разработке приложений, ни один из
которых не говорит по-английски, хотя все читают и удовлетворительно пишут по-
английски;
■ один программист/аналитик, который имеет обширные навыки в области
телекоммуникаций и довольно хорошо общается по-английски;
■ одиннадцать программистов, имеющих 5-летний опыт в разработке обширных
приложений, три из которых превосходно общаются по-английски;
■ десять программистов с опытом работы не менее пяти лет. Министерство
чрезвычайно заинтересовано, чтобы эти люди прошли обучение на рабочем месте.
Только два из них могут общаться по-английски.
Министерство CRM также предоставит помощника, который будет содействовать
в переговорах с i равительственными властями, договариваться о поездках и
выступить в роли принимающей стороны в Китае.

Практическое занятие. Обзор 85
Вы и ваша корпорация
Ваша корпорация приносит миллиард долларов дохода в год от продажи
телекоммуникационного оборудования и ПО. Она имеет коммерческие офисы по всей
Азиатско-Тихоокеанской экономической зоне (Asia Pacific, или AsiaPac), сборочный завод
сотовых телефонов в Гуанчжоу и является совладельцем завода по производству
полупроводников в Тайване. Ощущается, что ваша компания имеет достаточный опыт и
глубокие культурные знания, позволяющие ей преуспеть в любом
высокотехнологичном Китайском проекте. И хотя ваша компания рассматривается главным образом как
компания но производству аппаратных средств, ваша инициативная команда по
разработке ПО поддержала группу по разработке модели зрелости возможностей
(Capability Maturity Model, CMM) пятого уровня Института инжиниринга ПО (SEI) в
Бангалоре (Bangalore), Индия, и компанию, занимающуюся проектированием ПО в
Австралии. Вы также только что приобрели высококлассную инструментальную
компанию, выполняющую автоматизированное проектирование и создание программ
(Computer aided software engineering, CASE). Основное внимание вашей компании
было уделено этому приобретению, поскольку корпоративная группа планирования
убедила исполнительную команду менеджмента в том, что инструменты этой
компании смогут поднять класс разработчиков ПО всей корпорации, по крайней мере, до
четвертого уровня. За этим обязательством стояла корпорация, требуя, чтобы все
новые проекты использовали CASE-инструменты и его объектно-ориентированную
методологию развития в представлении унифицированного языка моделирования
(Unified modeling language, UML), а также текущую версию программы на языке Java.
Теперь все организации, связанные с разработкой ПО, имеют учебный бюджет,
определяемый американскими организациями разработчиков, которые будут обучаться
первыми. Все организации по разработке ПО, обучаемые во всем мире, будут
располагать учебными планами в течении следующих 15 месяцев. Организации AsiaPac
будут последними из тех, кто проходит обучение.
Предположим, что вы были приняты на работу впервые в компанию по
разработке аппаратных средств. После окончания технической школы со степенью
бакалавра по электротехнике, вы пришли на работу в компанию, которая создавала
промышленные инструменты автоматизации. После пяти лет работы в компании
вам предложил работу теперешний работодатель. Вы работали как разработчик ПО
и менеджер проекта по разработке программных инструментов в течение семи лет
с вашим нынешним работодателем. Шесть месяцев назад вы прослушали курс
сертификации на звание профессионала-менеджера проектов при Институте
менеджмента проектов, успешно сдали экзамены и получили квалификацию РМР. После
приобретения звания РМР, вы перешли в объединяющую организацию,
выполняющую управление программными проектами, задачей которой является тесное
сотрудничество с международными маркетинговыми группами и использование
всех возможностей аппаратных средств и ПО в пределах корпорации с целью
достижения успехов в международном бизнесе.
Проект CRM идеально подходит для вашей нынешней организации (см. рис. 2.2).
Он также получит высокий уровень исполнительной поддержки и будет тщательно
исследован. Изначально ваша организация специализируется лишь на менеджменте
проектов, вследствие чего в ее штат не входят инженеры. Вы— один из 10
профессиональных менеджеров проектов, но только двое из числа этих менеджеров
специализируются исключительно на программных проектах. Остальные из 28 профессио-

86 Глава 2
палов вашей организации — специалисты по маркетингу. Также в организации
наличествуют 12 человек из штата поддержки, специализирующиеся на маркетинговых
коммуникациях., подготовке документации и управлении маркетинговой справочной
библиотекой. Руководителем вашей организации является вице-президент
корпорации, оплата услуг которого осуществляется за счет маркетинговых отчислений
корпорации- И хотя работа организации не оценивается по показателю прибыль-убытки,
работа вице-президента, по существу, ежегодно оценивается по количеству проектов,
которые были запущены в производство. Все ежегодные премии штата,
занимающегося маркетингом, привязаны к запуску в производство проектов.
Управляющий маркетинговым отделом
Исполнительный вице-президент
Руководитель
маркетингового отдела
Руководитель
службы маркетинга

Азиатско-Тихоокеанский регион
Менеджер службы
маркетинга
по региону AsiaPac
Руководитель
менеджеров проектов
Руководитель отдела
менеджмента проектов
Менеджер поддержки
Менеджер
служб поддержки
Европа
Менеджер службы
маркетинга
в Европе
ПС
Менеджер службы
маркетинга
по остальным странам
Программное
обеспечение
Менеджер
программных
проектов
1
Менеджер программных
проектов для Министерства
путей сообщения (Китай)
Ihic. 2.2. Организационная диаграмма компании
1. Маркетинговые переговоры
3 ассистента
2. Документация
4ассистента
3. Сопровождение справочной
библиотеки
2 ассистента
Аппаратные средства
Менеджер проектов
по разработке
аппаратных средств
1
4 менеджера проектов
по разработке
аппаратных средств
Запуск в производство
Менеджер
по запуску проекта
в производство
Менеджер проектов
по разработке
телекоммуникационных
систем
Поставляемые продукты вашего проекта
Для оценки того, будет ли ваша компания одним из претендентов на
окончательный проект, CRM требует предоставления полного плана проекта. Подобного рода
оценку будет осуществлять команда, реализующая управление деятельностью CRM.
Причем результаты оценки будут переданы непосредственно министру путей
сообщения Китая. Для проектного плана не предусмотрен предопределенный формат.

Практическое занятие. Обзор 87
Команда по разработке проекта должна предоставить для демонстрации в Китае
не только проектный план, но и прототип, на базе которого демонстрируются
функциональные требования для системы. Чиновники из министерства CRM
хотели бы получить рабочий прототип в течение одного месяца с момента прибытия
представителей организации-поставщика в страну. Следующим этапом является
описание системы в режиме реального времени: прототип должен реализовать
систему резервирования, объединяющую три города. Поезда выходят из Гуанчжоу
или из Шанхая и проходят через Нанкин, где подсаживаются пассажиры.
Подробная карта маршрутов приведена на рис. 2.3.
Рис 2.3. Подробная карта района
железнодорожной системы
Источник: См. рис. 2.1. Часть увеличенной карты с подробным районом железнодорожной
системы, добавленной авторами.
Министерство путей сообщения Китая (CRM) хотело бы проверить прототип в
реальных условиях при невысокой степени загрузки. При этом имеются следующие
предпосылки:
■ каждый день из Гуанчжоу или Шанхая отправляются пять поездов и столько же
поездов прибывают каждый день в город Гуанчжоу или Шанхай. Каждый день в
Нанкине останавливаются двое из поездов, едущих из Гуанчжоу или Шанхая, и
один поезд, едущий в Гуанчжоу или Шанхай. В Нанкине поезда не формируются;
■ поезда всегда переполнены в "час пик" (распространенная проблема);
■ существует пять категорий билетов:
1. спальные (мягкие) — купейные вагоны с 4 местами для пассажиров в купе;
2. спальные (твердые) — купейные вагоны с 6 местами для пассажиров в купе;
3. сидячие (мягкие) — обычные вагоны первого класса;
4. сидячие (твердые) — вагоны туристического класса;

88 Глава 2
5. стоячие (только твердые и мягкие сидячие места);
■ распределение мест производится во время резервирования;
■ резервирование мест должно быть разрешено за месяц до фактической поездки.
В будущем этот период будет увеличен;
■ билеты, зарезервированные по телефону, должны быть выкуплены лично
заказчиком в течение 24 часов после резервирования. Не допускается резервирование
менее чем за 48 часов до поездки;
■ в течение последних 48 часов до поездки, билеты на оставшиеся места будут
проданы в порядке живой очереди;
■ списки пассажиров предоставляются проводникам каждого вагона для каждого
поезда па каждой остановке по пути следования поезда;
■ порой поезда CRM могут стать непригодными для эксплуатации. На маршрут будет
выпущен новый поезд, но может произойти задержка до нескольких дней;
■ поезда формируются неизменным образом: два мягких спальных вагона (по 12
купе п каждом), два твердых спальных вагона (по 12 купе в каждом), два мягких
твердых нагона F0 мест) и девять твердых вагонов (по 80 мест в каждом).
Хотя перепродажа билетов по завышенной цене является весьма
распространенной, CRM хочет препятствовать подобной практике и поэтому способствует тому,
чтобы продажа билетов отслеживалась покупателем.
Министерство путей сообщения нуждается в некоторых отчетах по менеджменту,
;i именно:
1. количество актов резервирования, выполненных для каждой даты отправле-
иия/поезда;
2. количество клиентов, не сумевших взять билет из-за отсутствия свободных мест в
поезде, для каждого отправления/ поезда;
3. количество не явившихся пассажиров для каждого отправления;
4. количество и имена людей, которые оказались без резервирования для каждого
отправления;
5. списки "крупных покупателей" (возможных спекулянтов) билетов на поезд и
количество купленных ими билетов и датой действия этих билетов.
Количество резервирований в течение испытательного периода может составлять
около 25000 в день. Эта величина может значительно изменяться в зависимости от
времени суток, дня и сезона.
Ваш график
На еженедельном совещании C0 дней назад) вам сообщили о том, что менеджер
но маркетингу AsiaPac общался с одним из менеджеров по вопросам автоматизации
Министерства путей сообщения. При этом обговаривался потенциальный контракт
па проведение работ по автоматизации, который будет реализовываться в
дальнейшем. На сегодняшней встрече исполнительный менеджер отдела маркетинга и
менеджер из отдела маркетинга AsiaPac информировали команду о том, что ваш
проект действительно будет воплощен на практике, а вы назначены его
менеджером. Проекту назначается наивысший приоритет в рамках организации, а в глазах

Практическое занятие. Обзор 89
исполнительского менеджмента проект обрисовывается как тот, "который должен
победить". Согласно распоряжению менеджера по маркетингу, проектный план и
прототип должны быть готовы в течение 90 дней. Причем у руководства возникает
мнение, что это легко выполнимо, поскольку будет использоваться недавно
приобретенная CASE-технология.
Ваши конкуренты
Отдел маркетинга работает над полным анализом конкурентоспособности
проекта, который будет завершен через 45 дней. В это время они не видят
никакой другой столь же квалифицированной компании, которая могла бы завершить
данную работу.
Ваша проектная команда
Вашим "клиентом" в рамках данного проекта является менеджер по маркетингу из
AsiaPac. Вы можете обращаться к нему, чтобы получить требуемое исследование, а
также налаженные контакты в Китае. В вашем распоряжении имеются три аналитика
в центре разработки ПО в Бангалоре (Bangalore), менеджер Австралийского центра
проектирования, два специалиста по документации из вашей организации и три
менеджера по полевым приложениям из офиса на Тайване. Если вам нужны любые
другие ресурсы, то необходимо лишь послать запрос, и исполнитель из вашей
организации предоставит все, что вам требуется для работы.
Заключительное примечание:
потенциальный рынок для ПО
Ваш менеджер по маркетингу только что завершил написание диссертации на
соискание степени МВА. Его интуиция подсказывает, что другим странам Юго-
носточной Азии также понадобится этот вид системы резервирования. Чтобы
окупить маркетинговые инвестиции при разработке прототипа необходимо
гарантировать, что он также применим к Тайским, Вьетнамским, Кампучийским и Бирманским
железным дорогам. Он установил дату в 90 дней с настоящего времени до момента,
когда вы продемонстрируете пример реализации ПО для одного из министерств
путей сообщения этих стран. Вы также должны получить картину моста на реке
Квай (Kwai) в качестве фоновой заставки, используемой при открытии
презентации PowerPoint.
Дополнительные сведения в Internet
home.tronet.de/joachim.fabry/htmI/body_asien.htmI. Этот Web-узел посвящен
описанию железных дорог в Китае, включает фотографии и карты; предоставлено Алленом Цагелем
(Allen Zagel).
info-s.com/traueii.htmi. Служба информации — экскурсия по топографическим картам
Китая (информация для туристов).
viad.tribnet.com/2000/page/china.titml. Новости Владивостока: китайская страница,
Роберт Фрост (Robert Frost) однажды заметил: "Хорошие заборы делают хороших соседей". Для России
и Китая, которых разделяет граница длиной в 4300 километров, построить хороший забор нелегко.
Граница между этими двумя странами на северо-востоке Азии открылась со времени распада
Советского Союза.

90 Глава 2
www. china2thou.com/9805p3. htm. Китай 2000— строительство железных дорог, май 1998.
Строительство железной дороги: основные инвестиции в этом секторе направлены на
удовлетворение ключевых потребностей в транспорте и призваны компенсировать рост перевозок.
www. china2thou.com/9805p4. htm. Китай 2000— Туризм: прогресс в туристическом бизнесе
Китая был достигнут, начиная с 1978 года, когда Китай еще оставался фактически закрытым для
оста ii.Horo мира.
www. chinavista .com/business/ciec/en/ciecl9990518. html. Экономическая сводка— агент-
стно Синьхуа рассматривает туризм как инструмент, приводящий к стимулированию экономики.
www. chinesebusinessworld. com/tourism. Финансовые вопросы, связанные с перевозками —
Китай — города Китая — взгляд на Китай — Китайская Национальная администрация туризма.
www. frommers .com/features/articles/9803_lb. html. Журнал, в котором
рассматриваются финансовые вопросы, связанные с перевозками, Артур Фроммер (Arthur Frommer): Статьи за
март I *H8 года — Путешествия по Китаю.
www. lib.utexas.edu/Libs/PCL/Map_collection/map_sites/cities_sites.
html. Web-страиицы карт городов. Собрание карт библиотеки Пэрри-Кастанеда Университета штата
Техас- п г. Остине, обновлено 14.02.2000.
www. Iinks2jo.com/more/severn.dmu.ac.uk/~mlp/crsg.html. Links2Go: Домашняя страница
железных дорог Китая, ссылки и темы, связанные с домашней страницей железных дорог Китая.
www. lonelyplanet .com/letters/nea/chi_pc.htm. Одинокая планета— Рассказы
путешественников о Китае.
www.netlizard.com/travel/ltravel .html. Безостановочный путеводитель: Всемирная
интерактивная служба информации о путешествиях, всесторонняя интерактивная информация о пу-
гешс-ствнях.
www.netscout. net/oneworldZcountries_a-c.htm. Нации в интерактивном режиме: страны
мира Л-С — Республика Китай, Китайская Национальная администрация туризма — web-страница Ки-
гамского туризма — Китайский информационный центр глобальной сети Internet.
www.newpaltz.edu/geography/links.html. Государственный университет Нью-Йорка, От-
дс-'i географии Пью Пальц (New Paltz), ссылки на web-страницы — Национальная администрация
тури i\ia — Всемирная география; Латинская Америка; Китай и другие.
www. odd" .gov/cia /publications/ factbook/geos/ch. html. 2000, Книга мировых фактов,
lii'V. Исходные данные: в течение большей части своей 3500-летней истории Китай был мировым
лидером в сельском хозяйстве, ремеслах и науке. Отставание началось с 19-го столетия, когда инду-
с грнальная революция дала Западу явное превосходство в военных и экономических делах. В первой
половине 20-го столетия Китай продолжал страдать от повсеместного голода, гражданских волнений,
посинело поражения и иностранной оккупации. После окончания Второй мировой войны в Китае
победил коммунистический режим во главе с Мао Цзэдуном. В результате Китай обособился от всего
остального мира, был наложен строгий контроль на все аспекты жизни, и жертвами этого режима стали
десятки миллионов людей. После 1978 года, преемник Мао, Ден Сяопин, децентрализовал принятие
экономических решений; а объем производства вырос в четыре раза в течение следующих 20 лет.
Политический контроль остается жестким, в то время, когда экономический контроль ослаблен.
Существующие проблемы: включение Гонконга в Китайскую систему, закрытие неэффективных
предприятий, принадлежащих государству, модернизация военной отрасли, борьба с коррупцией,
обеспечение работой десятков миллионов безработных.
www.tradeport.org/ts/countries/china/isa/isar0014.html. Китай: розничный
сектор Количество пользователей глобальной сети Интернет в Китае — Понимание вашего выбора
параметров финансирования экспорта с Sanwa.
www.wanghuhotel.com/8e.htm. Путешествие на поезде по Китаю во время каникул.
Транспортное агентство Гуанчжоу Вангу (Hangzhou Wanghu) — это специализированное агентство при
гостинице Гуанчжоу Вангу. Его главная задача состоит в том, чтобы организовывать и привлекать
местных и иностранных туристов для осмотра достопримечательностей в Гуанчжоу и других частях
страны. Оно также предоставляет услуги для конференций и экскурсии после конференций.
Учитывая большой экономический потенциал и прекрасную репутацию гостиницы Вангу и ее тесные

Практическое занятие. Обзор 91
отношения с крупными местными гостиницами, транспортными агентствами, аэропортами и
железнодорожными станциями, транспортное агентство Гуанчжоу Вангу может со временем расширить
спектр предоставляемых услуг для гостей. Высококлассные удобства гостиницы и энергичный и
преданный своему делу профессиональный контингент агентства обеспечивают его уникальные
преимущества в сфере обслуживания туристов. Основанное на привлечении гостей и на том, что
репутация превыше всего, транспортное агентство Вангу надеется сотрудничать с коллегами,
занимающимися тем же самым бизнесом, и людьми из всех слоев общества.
www. zhuhai . com.cn/projects/english/1/railway.htm. Жухай (Zhuhai) Гуанчжоу-Жухайс-
кая железная дорога, предприниматель проекта железной дороги Гуанчжоу-Жухай: Гуанчжоу-
Жухайская железнодорожная компания, Краткое введение в проект.

Краткий обзор
процессов
Менеджмент процессов — это один из видов деятельности, который следует учи-
! милть всем менеджерам проектов перед тем, как начинать любую работу. В процессе
-niii деятельности устанавливается структура методов, используемых при оценке
ргллп.ыции проекта. Авторы этой книги воспользовались процессами в ходе
разбиения материала книги на главы, для представления и рецензирования текста, а также
■ .;■ передачи подготовленного текста в издательство с целью создания завершенной
j.sinru. Менеджмент процессов гарантирует корректное выполнение процедур, стра-
■I >•! пи н модели жизненного цикла организации. В этом случае, например, может воз-
никать вопрос: "Были ли протестированы и проверены по качеству все файлы перед
ич передачей клиенту?" В ходе осуществления менеджмента процессов выполняется
\ ip.iiiлеиис действиями по разработке ПО. Например, может происходить проверка
•■•.л предмет выполнения запроса на изменение, который был одобрен, после чего на-
( пинл черед фиксации. При этом гарантируется, что связанный с этим процесс
проектирования, документирование и обзорные действия были завершены еще до того,
как поступило разрешение на повторную "проверку" кода.
< )прсдсление термина "процесс" производится в примечании 3.1.
Примечание 3.1. Определение процесса
Процесс представляет собой действия, инструменты, методы и технологии, в ходе
осуществления которых преобразуются входные объекты (сырье) в выходные
объекты (готовые продукты), как показано на рис. 3.1. Согласно стандарту IEEE 610 процесс
определяется как "последовательность этапов, выполняемых с целью достижения
конкретной цели, — например, типичным является процесс разработки ПО". В своей

Краткий обзор процессов 93
книге Менеджмент процесса разработки ПО (Management the Software Process), Уотте
Хэмфри (Watts Humphrey) пишет:
"Разработка ПО может быть чрезвычайно сложной, и зачастую существует
множество а/1ътерпативных способов, предназначенных для выполнения различных задач.
Определенный процесс может помочь профессионалам в области программного
инжиниринга решить проблему выбора с помощью какого-то определенного способа. Благодаря
наличию фиксированного определения процесса они могут лучше понимать, что им
следует делать, что следует ожидать от своих сотрудников, и что они, как
ожидается, обеспечат в свою очередь. Это позволяет сосредотачиваться на выполнении своей
работы... Однако разработка ПО не похожа на обычный вид деятельности, который
может быть структурирован и упорядочен как повторяющееся производство или
конторская процедура. В данном случае рассматривается интеллектуальный
процесс, который должен динамически адаптироваться к творческим потребностям
профессионалов и их задачам. При этом требуется достижение компромисса между
индивидуальной потребностью в гибкости и организационной потребностью в
стандартах и последовательностью ".
Некоторые из факторов, которые следует учитывать в данном случае,
приводятся ниже.
1. Поскольку программные проекты носят самый различный характер, процессы,
применяемые в ходе осуществления программного инжиниринга, также должны
различаться.
2. В условиях отсутствия универсального процесса разработки ПО организации и
проекты должны определить процессы, которые удовлетворяют их собственным
уникальным потребностям.
3. В ходе осуществления процесса, используемого для реализации данного проекта,
должен учитываться уровень опыта членов команды, текущий статус продукта, а
также доступные инструменты и возможности .
Информация
+ Материалы
+ Энергия
Величина входа
t
Определенный
результат
Величина выхода
Больше чем
Рис. 3.1. Поток процесса
Humphrey Watts. Managing the Software Process, 1st ed.; reprinted with corrections August 1990.
Reading, МЛ: Addison-Wesley, 1989.

94 Глава 3
В главе описываются основы менеджмента процессов, а также демонстрируется,
каким образом он может интегрироваться в интерфейс жизненного цикла проекта.
Основными ключевыми документами по менеджменту процесса являются
стандарты IEEE 1074 и 1074.1. Особое внимание в этой главе будет уделено определенному
пониманию и применению документов IEEE 1074 и 1074.1 при разработке
жизненного цикла проекта. Жизненные циклы, использующиеся в этом руководстве
практического специалиста, являются прямыми "потомками" структур, описанных в
документе 1074.
Ключевые вопросы, рассматриваемые
в главе 3
В ходе выполнения процесса определяется достигаемый уровень качества. Однако
при отсутствии определенного процесса субъект менеджмента отсутствует.
Процесс и качество не являются свободными от конкретного объекта. При установке
управляемого и периодического процесса проявляются свои издержки. Как
менеджеры проектов мы должны постоянно задавать себе вопросы: "Почему так важно
обеспечивать качество?" и "Что является оптимальным уровнем качества?" Что является
"достаточно хорошим показателем качества"? Утверждение об уровне качества,
равном 99.9 %, действительно звучит хорошо, но, как показано в примечании 3.2, когда
под угрозой оказывается человеческая жизнь или здоровье, подобный показатель не
может быть достаточно хорошим.
Примечание 3.2. Что такое "достаточно хорошо"?
Если бы уровень качества 99,9 % считался "достаточно,хороц1им", > ,
то в мире происходило бы следующее: ., „,^ ^^ ы ^ ^
» каждый час терялось бы около 27800 предметов, пересылаемых помочг^лрщ tp-
• каждый месяц мы потребляли бы питьевую воду плохого качества в т^енй'е¥ч?м^ц5
• каждый год выписывалось бы 3000000 неправильных рецептов^на ле^кар^тва^.^-
• каждый день ошибочно бы выписывалось 9703 банковских чеков*:. > U3
• каждый день врачи роняли бы 370 новорожденных детейлэо время родов ;) > - ft
• ежегодно заканчивались бы катастрофой $605 авйареисрв . ^^«вч*>»»1 'L* t ЧЙйЧ^
"www. usps. com/Aistory/an^tOO/j.nde«I,ftt№/Kaatfl«it'^eHi<'l«bi имеем дело сф68»шл-
лионами предметов, пересылаемых по почте1"' " *4*-УН'т* . i' <~ * . " «-,*
www.nacds.org/user-documerits/2OOl^roj0Ctiojis.Pp^}^wum&^^^it^pbb^
выписано в 2001 году. '« ' :4^3?***i Ц *£«$&
' www. calacreefc. com/consumer/bank гпд/chk£tkxxu. ftt^. ДС^5ОЦ,вйи|%«Т5 2ж&*В£й&
году выписано 85 миллиардов банковских чеков, * 9 £ "'Т "*"а"" " *% ^?*S? iv^'i^ev^
' www. р rb. о rg/Сол t en t/Na viga tionMen u/Qtbez^reporbsfZQqp ~20С^^]^рЩ -"btrnJ^"
cwww.bts.gov/publications/airactstats/AAS^f9$6.pdf ' < , >£'**
Специалисты из сети менеджеров программных проектов (www. spmn. com)
составили перечень из 16 лучших методов, применяемых на практике. Эти методы
относятся к управленческим и техническим, и, согласно оценкам Министерства обороны

Краткий обзор процессов 95
США, обеспечивают наивысший показатель коэффициента возврата инвестиций
(return on investment, КОИ (ROI)) в области разработки и поддержки
крупномасштабных, преимущественно программных систем. Ниже приводится краткий
перечень этих методов.
1. Формальный менеджмент рисков.
2. Эмпирическая стоимость и оценка графика.
3. Управление проектами, основанный на использовании метрических показателей.
4. Отслеживание прибавочной стоимости.
5. Отслеживание дефектов на фоне целей достижения качества.
6. Менеджмент программ, ориентированных на персонал.
7. Менеджмент действий по выполнению конфигурации.
8. Трассировка промежуточных требований.
9. Проектирование ПО, основанного на системной архитектуре.
10. Способность к взаимодействию данных с базой данных.
11. Формальное определение и контроль интерфейсов.
12. Видимая и контролируемая разработка.
13. Повторное использование, оправданное соображениями цены и качества.
14. Формальные проверки.
15. Тесты менеджмента, реализуемые в виде активов.
16. Частое компилирование и проверка работоспособности простым запуском.
Описанные 16 лучших методов рассматриваются в последующих главах этого
практического руководства. В этой же главе рассматривается, каким образом происходит
объединение всех описанных методов в рамках единого менеджмента процессов.
Стадии жизненного цикла разработки
продукта
В настоящее время мы находимся в самом начале жизненного цикла разработки
программного продукта. Менеджмент процессов начинается с выбора жизненного
цикла, используемого для проекта, как показано на рис. 3.2.
Связь главы 3 с 34 компетенциями
В главе рассматриваются компетенции, связанные с персоналом и продуктами.
Первые две компетенции, которые должны быть освоены менеджерами
проектов, — это оценка процессов и знание стандартов процесса. Другие необходимые
компетенции продуктов, которые должны быть освоены в процессе изучения,
имеют номера 8 (выбор методов и инструментов) и 9 (подгонка процессов). Каждый
проект является уникальным. Менеджер проекта должен уметь оценивать текущее
состояние организационных процессов и изменять их с тем, чтобы приспособить к
потребностям проекта.

96 Глава 3
Исследование
концепции
•Формули-"
рование

потребности
Исследование
системы
■ Спецификация''
интерфейса
системы
Требования
• Спецификация
требований
к ПО
Разработка
проекта
'Описание

разработки ПО
Идентификация
циклов SLC
Внедрение
■ Циклы SLC
■ План

тации/верификации ПО
Выбор модели
Установка
■ Модель цикла SLC
Установка
соответствия
между задачами
и циклами SLC
с помощью IEEE 1074
■Отчет об ат-
тестации/ве-
рификации
Эксплуатация
и поддержка
• Цикл SLC
'
Пользовательская
документация
Сопровождение
Распределение
ресурсов
1 Документация
по
сопровождению
1 Бюджет
Вывод из
эксплуатации
• Архивный
отчет
Hue. 3.2. Локализация точки жизненного цикла разработки продукта, где происходит
подгонка процесса
Также потребуется освоить 21 компетенцию проекта (отслеживание процессов). Для
того чтобы организация повысила уровень освоения процессов потребуется найти способ
оценки продуктов и методов их разработки. Подобный процесс должен включаться в
полный процесс разработки изначально, в результате чего станет возможным сбор данных о
методах измерения процесса. Определение процессов разработки продукта организации
является критически важной компетенцией для менеджеров проектов.
Менеджмент процессов связан со следующими шестью компетенциями.
Методы разработки продукта
1. Процессы оценивания — определение критериев для обзора.
2. Знание стандартов процесса — представление о стандартах процесса.
3. Отбор методов и инструментов — определение процессов отбора.
4. Подгонка процессов— изменение стандартных процессов для удовлетворения
проекта.

Краткий обзор процессов 97
Навыки менеджмента проектов
1. Отслеживание процессов— отслеживание соответствия определенным
критериям членов команды разработчиков проекта.
Навыки менеджмента персонала
1. Управление изменениями— способность выступать в качестве эффективного
генератора изменений.
Учебные цели главы 3
После изучения материала главы читатель должен уметь выполнять следующее:
■ определять процесс;
■ объяснить важность использования процессов в индустрии ПО;
■ описывать основы подгонки программных процессов;
■ объяснить, почему усовершенствование процесса приводит к улучшению продукта.
Согласно оценкам Института SEI, процессы могут разрабатываться и
поддерживаться посредством методов, которые аналогичны методам разработки и поддержки
продуктов. При этом должно формулироваться следующее:
■ требования, определяющие описываемый процесс;
■ архитектура и план, поддерживающие информацию о методах определения
процесса;
■ реализация схемы процесса в проектной или организационной ситуации;
■ утверждение описания процесса путем измерений;
■ развертывание процесса с созданием широко распространенного действия в
пределах организации или проекта, для которого предназначен процесс.
Активы процесса разработки ПО, поддерживаемые организацией с учетом
использования проектов при разработке, настройке, поддержке и осуществлении
соответствующих программных процессов, обычно включают:
■ стандартный процесс разработки ПО в масштабах организации (включая
архитектуру и элементы процесса разработки ПО, как определено в глоссарии);
■ описания жизненных циклов разработки ПО, общепринятых для использования
(этот вопрос будет подробно обсуждаться в главе 4);
■ руководящие принципы и критерии подгонки стандартного процесса создания
ПО на уровне организации;
■ база данных процесса разработки ПО организации;
■ библиотека документации, связанная с процессом разработки ПО.
Зрелый процесс разработки ПО в рамках модели СММ (Capability Maturity Model),
при которой достигается максимум возможностей, эффективен при создании
организационного потенциала. Этот процесс может определяться, документироваться,
изучаться, реализоваться, поддерживаться, сохраняться, контролироваться,
проверяться, утверждаться, измеряться, а также усовершенствоваться.

98 Глава 3
Третий уровень модели СММ SEI
Процесс разработки ПО как в разрезе действий по менеджменту, так и с точки
зрения инжиниринга документирован, стандартизирован и интегрирован в процесс
разработки программного обеспечения в масштабе всей организации. Все проекты
используют зарегистрированную и утвержденную версию процесса уровня
организации с целью разработки и поддержки программного обеспечения. Две ключевых
области процесса (Key process area, KPA) для третьего уровня модели SEI связаны
непосредственно с процессом.
Центр организационного процесса
Назначение организационного центра процесса заключается в установке
организационной ответственности за действия при реализации процесса разработки ПО,
повышающие общий потенциал процесса разработки программного обеспечения
организации. Этот потенциал включает разработку и поддержку понимания
организационных и проектных процессов разработки ПО, а также координирование действий
для оценки, разработки, поддержки и улучшения этих процессов.
Цели
1. Координирование действий по разработке и усовершенствованию процесса
разработки ПО по всей организации.
2. Идентификация сильных и слабых мест используемых процессов разработки ПО,
руководствуясь стандартом процесса.
3. Планирование действий по разработке и усовершенствованию процесса на
уровне организации.
Действия
1. Периодическая оценка процесса разработки ПО и развитие планов действия
таким образом, чтобы способствовать получению результатов.
2. Разработка и поддержка плана действий организации в области разработки и
усовершенствования процесса создания ПО.
3. Координирование действий на уровне организации с целью разработки и
усовершенствования процессов создания ПО.
4. Координирование на организационном уровне применения базы данных,
используемой процессом разработки ПО на уровне организации.
5. Проверка, оценка и (если требуется) передача в другие подразделения
организации новых процессов, методов и инструментов, использующихся в ограниченных
пределах внутри организации.
6. Координирование по всей организации обучения в рамках процессов создания
ПО на уровне организации и проекта.
7. Информирование групп, вовлеченных в реализацию процессов создания
программного обеспечения, относительно действий организации и проекта в
целях развития и усовершенствования процесса разработки ПО.

Краткий обзор процессов 99
Определение организационного процесса
Цель определения организационного процесса заключается в том, чтобы
развивать и поддерживать пригодный к употреблению набор активов процесса создания
ПО. Благодаря этому улучшается выполнение процесса для всей совокупности
проектов, а также предопределяются достижения совокупных, долгосрочных
преимуществ для всей организации. Организационный процесс включает разработку и
поддержку стандартного процесса разработки ПО на уровне организации, наряду с
определенными активами процесса, такими как описания жизненных циклов
разработки ПО, руководящие принципы и критерии процесса настройки, базы данных
процесса создания ПО на уровне организации и библиотека документации,
связанной с процессом разработки.
Цели
1. Разработка и поддержка стандартного процесса создания ПО на уровне
организации.
2. Сбор, просмотр и создание доступной информации, связанной с использованием
стандартного процесса разработки ПО на уровне организации в рамках
программных проектов.
Действия
1. Развитие и поддержка стандартного процесса создания ПО на уровне
организации в соответствии с документированной процедурой.
2. Документирование стандартного процесса разработки ПО на уровне организации
согласно установленным организационным стандартам.
3. Документирование и поддержание описаний жизненных циклов разработки ПО,
утвержденных для использования в рамках проектов.
4. Разработка и поддержка руководящих принципов и критериев для подгонки
проектов стандартного процесса создания ПО на уровне организации.
5. Установка и поддержка базы данных процесса создания ПО на уровне организации.
6. Установка и поддержка библиотеки документации, связанной с процессом
создания ПО.
( Продует J
/ Главные \
/ детерминанты \
Стоимости программного^
/ обеспечения, графика \
у*— —-^и качества работы /--— s.
( Процесс у*. р4 Технология )
^- ^— ^ Рис. 3.3. Детерминанты успеха проекта
На рис. 3.3 показан треугольник, сформированный персоналом, технологией и
детерминантами программного процесса и успеха продукта. Эти три главных элемента
определяют стоимость разработанного ПО, выполнение проекта по графику, а также

100 Глава 3
качество финального продукта. Наряду с прикладными элементами, относящимися
к 34 компетенциям, в этой главе будут рассмотрены инструкции к следующим двум
инструментам.
1. Эволюция цикла "планировать-делать-проверять-действовать" в модель, которая
используется для оценки всех областей знания и процессов менеджмента и
инжиниринга ПО (в результате определяется, что находится на своем месте, а что
нуждается в предварительном определении дальнейших действий).
2. IEEE 1074-1997— "стандарт, определяющий процессы жизненного цикла
разработки ПО", который является универсальным инструментом, служащим для
определения жизненного цикла разработки ПО и сопутствующих процессов
поддержки.
Менеджмент процесса начинается
с установки интерфейса
Менеджмент процесса начинается с определения проектного (организационного)
подхода к разрабатываемым продуктам. Внешний интерфейс процесса, показанный
на рис. 3.4, охватывает всю информацию, которая может использоваться для
определения процесса. Для сложившейся организации при этом обеспечивается
представление основ знаний предыдущего проекта, методов измерений продукта и других
параметров. Для новой организации или организации, которая является "новой" в
рамках процесса, интерфейс представляет области, которые следует "посетить" с целью
сбора информации и данных, необходимых для запуска процесса разработки
продукта. Исходя из того, что в данном случае определяются циклы анализа развития
процесса, этот рисунок будет использоваться в дальнейшем для демонстрации настройки
основных процессов для организации.
Рис. 3.4. Внешний интерфейс процесса

Краткий обзор процессов 101
Определенный менеджмент процесса
Менеджмент процесса представляет собой дисциплину, в которой определяются,
реализуются и поддерживаются рабочие процессы в организации. Цель менеджмента
процесса заключается в создании среды, обеспечивающей улучшение качества и
производительности. Основой успешной системы менеджмента процесса является
определенная структура, которая удовлетворяет целям и культуре организации. Создание
системы менеджмента процесса представляет собой прогрессивную итеративную
задачу, которая требует наличия стратегических обязательств со стороны организации.
Фундаментальная предпосылка менеджмента процесса утверждает, что "качество
продукта (например, программной системы) определяется качеством процесса,
используемым для его производства". Эта фундаментальная предпосылка в сочетании с
определением процесса дает нам определение менеджмента процесса. Таким образом,
процесс определяется как парадигма управления, обеспечивающая улучшение качества
с помощью:
1. формального определения процесса;
2. измерения процесса;
3. обратной связи и контроля;
4. усовершенствования;
5. оптимизации.
Менеджмент процесса
У. Эдварде Деминг (W. Edwards Deming) позаимствовал первую легко узнаваемую
структуру для менеджмента процесса во время своей работы в Японии после Второй
мировой войны. Деминг поощрял японцев применять систематический подход к
решению проблем, который впоследствии стал известным как цикл Деминга или цикл
"планировать-делать-проверять-действовать" (Plan-Do-Check-Act, PDCA). Однако
Деминг называет его циклом Шухарта, по имени своего преподавателя ВА.Шухарта
(W.A.Shewhart). Впоследствии он заменил слово проверка на изучение, поскольку это
слово более точно отражает фактическое положение дел. Деминг также натолкнул
старших менеджеров на мысль о том, чтобы они активно включались в программы
борьбы за качество в своих собственных компаниях. К его наибольшим достижениям
во время работы в Японии относят статью, описывающую типичную деловую систему.
В этом труде утверждалось, что потребители образуют важнейшую часть
производственной цепочки. Удовлетворение и избыточное удовлетворение требований
заказчиков представляет собой ту задачу, за выполнение которой должен отвечать каждый
член организации. Кроме того, система управления должна позволять каждому
отвечать за качество своей продукции перед своими внутренними клиентами.
Четыре этапа Деминга предназначались для выполнения следующих задач.
1. Планирование краткосрочной цели:
- определение выделенного интервала времени;
- принятие решения относительно требуемых данных;
- определение личного вклада каждого участника в трудозатратах всей команды.
2. Делать то, что требуется по плану:

102 Глава 3
- собирать данные;
- разрабатывать учебные курсы или методы;
- обучать персонал сбору данных и анализу.
3. Проверять, чтобы увидеть эффект выполнения плана:
- сравнивать учебные курсы с планом;
- если план не был выполнен, добиться его выполнения;
- поиск уроков с намерением применения в будущем;
- обсуждение корректировок при различных подходах;
- определение курсов действия и изменений.
4. Действовать по рекомендациям команды:
- настройка позиций, корректировок и тому подобных элементов;
- сообщения другим участникам команды о необходимых изменениях;
- улучшение межпроцессного взаимодействия.
Как видно из рис. 3.5, Каору Ишикава (Kaoru Ishikawa) увеличил количество
исходных четырех этапов Деминга до шести:
Действие
Проверка
Предпринять
соответствующее
действие
Проверка
эффектов
реализации
Определение \. План
целей / \
и задач /' \
у'Определение \
/ методов \
/ достижения целей 4
\. Участие 1
\^ в образовании /
N. и обучении /
Внедрение \. /
рабочего Х/выпол
процесса /
Рис. 3.5. Цикл Деминга/Шухарта/Ишикавы
Источник: Ishikawa К., D.J.Lu. trans. What is Total Quality Control? The Japanese Way.
Englewood Cliffs, NJ: Prentice Hall, 1988.
Планирование:
1. выполнение целей и задач;
2. определение методов достижения целей.
Выполнение:
3. участие в образовании и обучении;
4. выполнение работы.

Краткий обзор процессов 103
Проверка:
5. проверка эффективности.
Действие:
6. выбор соответствующего действия.
А теперь с помощью описанных шести этапов начнем проектирование
собственного определения процесса разработки программного продукта. Управление
программными проектами отличается от управления другими проектами наличием
осязаемых поставляемых продуктов. Следует отметить, что на самом деле различие будет
еще большим при рассмотрении ряда жизненных циклов процессов. Можно
определить несколько основных областей знаний инжиниринга ПО, которые необходимо
исследовать: планирование управления программными проектами, базы данных
методов измерений, библиотеки спецификаций и проектных планов, анализы КОИ
(ROI) завершенных проектов и планы анализа рисков завершенных проектов. Все
упомянутые основные области знаний будут рассматриваться сквозь призму
определенных процессов в области разработки ПО: планирование, оценка, обучение,
менеджмент конфигурирования выполнения, качество поддержки и уменьшение риска
при выполнении. В этом случае основной цикл Деминга/Шухарта/Ишикавы будет
трансформирован в предварительный цикл процесса. В этом случае основные этапы
процесса несущественны для процессов, связанных с разработкой ПО и основными
областями знаний. Вернемся к рис. 3.4, где эти шесть новых этапов отображаются на
оригинальном цикле PDCA следующим образом:
■ планирование отображается в план;
■ выполнение отображается в исследование, наблюдение и анализ;
■ проверка отображается в адаптацию;
■ действие отображается в улучшение.
Напомним, что процесс — это парадигма менеджмента, позволяющая улучшить
качество путем A) формального определения процесса, B) измерения процесса, C)
обратной связи и контроля, D) усовершенствования и E) оптимизации.
Рассматриваемый интерфейс процесса поддерживает структуру для этапов, выполняемых в
рамках достижения высокого уровня качества.
1. Формальное определение процесса производится с помощью модели внешнего
интерфейса процесса, используемый при анализе текущего процесса,
применяемого при разработке программных продуктов в организации менеджера проекта.
Модель внешнего интерфейса процесса выступает в роли своего рода
фокусирующего механизма, призванного способствовать получению наилучших
практических приемов из основы базы знаний, существующей вне организации, для
новых продуктов и проектов, возникающих в ходе разработки ПО.
2. Оценка процесса может происходить сразу после его определения.
Предварительный процесс и любой результирующий жизненный цикл разработки ПО
выступают в роли "карты процесса", призванной обеспечить осуществление
измерений. Для достижения требуемого уровня качества метрические показатели
программы должны определяться таким образом, чтобы использовать процессы,
действия, поставляемые продукты и переходы как точки, в которых следует
производить измерения всего процесса.

104 Глава 3
3. Обратная связь и контроль реализуются после того, как был выполнен ряд
циклов, а также собраны и проанализированы результаты. Формальное определение
процесса имеет свои собственные встроенные петли обратной связи, где может
осуществляться контроль, основанный на результатах измерения процесса.
4. Усовершенствование определяет цель, присущую любому процессу разработки
ПС). Способность повторять успешные процессы, а также изменять процессы,
которые не оправдывают ожиданий, — это одно из преимуществ обеспечения
качества в ходе выполнения формального процесса.
5. Оптимизация проявляется в форме усовершенствований, реализуемых для
повторяемых процессов. Формальный процесс эволюционирует в сторону
оптимизации, поскольку получаемые результаты измерений позволяют менеджерам
проекта и процесса непосредственно изменять сам процесс, в результате чего
достигается наивысшее качество.
Стандарт IEEE 1074 — карта обработки для
процесса жизненного цикла разработки ПО
Документ IEEE 1074 обеспечивает поддержку процесса жизненного цикла
разработки ПО (Software life cycle process, SLCP). Процесс SLCP определен как характерное
для проекта описание процесса, который основывается на жизненном цикле ПО
проекта (SLC), а также на интегральных процессах и процессах менеджмента,
используемых организацией. Интегральные процессы включают менеджмент конфигурации,
метрические показатели, обеспечение качества, уменьшение степени риска, действия
по оценке, планированию и обучению. Разработка процесса SLCP для данного
программного проекта входит в обязанности менеджера и архитектора проекта.
Рис. 3.6. Получение производного жизненного цикла разработки ПО

Краткий обзор процессов 105
Реализация подобной методологии начинается с выбора соответствующей модели
жизненного цикла разработки ПО (Software life cycle model, SLCM) с целью ее
применения в рамках определенного проекта. Затем создается цикл SLC, используя
отобранную модель SLCM и действия, описанные в табл. 3.1. Используемая в данном
случае методология заключается в приращении SLC с применением процессов
поддержки уровня организации с целью проектирования процесса SLCP. Действия,
описанные в таблице отображения стандарта 1074, охватывают полный жизненный
цикл проекта ПО от исследования концепции до возможного прекращения процесса
эксплуатации программной системы. Стандарт 1074 не обращается к действиям не
программного характера, типа заключения контракта, приобретения или разработки
аппаратных средств. Он также не дает полномочий для использования определенной
модели SLCM. В стандарте 1074 предполагается, что менеджер проекта и архитектор
процесса уже знакомы с разнообразием процессов модели SLCM, с критериями их
выбора, а также с критериями определения признаков и ограничений конечной
системы и среды разработки, которые влияют на этот выбор. Пример создания
производного жизненного цикла приводится на рис. 3.6.
Таблица 3.1. Отображение процесса согласно стандарту IEEE 1074
Категория
Процесс
Действие
I. Процесс модели А. Модель жизненного цик-
жизненного
цикла
разработки ПО
II. Процессы
менеджмента
проекта
ла разработки ПО
1. Идентификация моделей кандидатов
в циклы SIX
2. Выбор модели проекта
А. Начало выполнения про- 1. Отображение действий на модель SLC
2. Локализация проектной информации
3. Установка среды проекта
4. Планирование менеджмента проекта
1. Анализ рисков
Б. Мониторинг и
управление проектом
В. Управление качеством
ПО
2. Планирование непредвиденных
обстоятельств
3. Управление проектом
4. Сохранение записей
5. Метод отчета о реализации проблемы
1. Планирование управления качеством
ПО
2. Определение метрических показателей
3. Управление качеством ПО
4. Идентификация потребностей в
улучшении качества

106 Глава 3
Продолжение табл. 3.1
Категория
Процесс
Действие
III. Этапы
предварительной
разработки
процесса
А. Исследование концепции 1. Идентификация идей или
потребностей
2. Формулирование потенциальных
подходов
3. Изучения реализуемости поддержки
4. План разработки системы
5. Уточнение и придание окончательной
формы идее или потребности
1. Анализ функций
2. Разработка структуры системы
3. Разложения требований системы на со-
IV Процессы
разработки
Б. Распределение системы
А. Требования
Б. Разработка проекта
В. Внедрение
V. Процессы
сопровождения
А. Установка
ставные части
1. Определение и разработка требований
к ПО
2. Определение требований к интерфейсу
3. Распределение по приоритетам и
интеграция требований к ПО
1. Разработка проекта архитектуры
2. Разработка баз данных
3. Разработка проекта интерфейсов
4. Выбор или разработка алгоритмов
5. Выполнение детализованной
разработки проекта
1. Создание тестовых данных
2. Создание источника
3. Генерация кода объекта
4. Создание рабочей документации
5. Планирование интеграции
6. Осуществление интеграции
1. Планирование установки
2. Распространение ПО
3. Установка ПО
4. Приемка ПО в эксплуатационной среде
Б. Эксплуатация и поддержка 1. Использование системы
2. Обеспечение технической помощи
и консультаций

Краткий обзор процессов 107
Окончание табл. 3.1
Категория
Процесс
Действие
В. Сопровождение
Г. Вывод из эксплуатации
VI. Интегрирован- А. Аттестация и верифика-
ные процессы ция
3. Поддержка журнала запроса поддержки
1. Повторное обращение к жизненному
циклу разработки ПО
1. Уведомление пользователя
2. Выполнение параллельных действий
3. Вывод системы из эксплуатации
1. План аттестации и верификации
2. Выполнение задач аттестации и
верификации
3. Сбор и анализ данных и
4. Планирование тестирования
5. Разработка требований к тестам
6. Проведение тестирования
Б. Менеджмент конфигура- 1. Планирование менеджмента конфигу-
ции программных рации
средств
2. Разработка методов идентификации
конфигурации
3. Осуществление контроля конфигурации
4. Выполнение учета состояния
В. Разработка документации 1. Планирование документации
2. Внедрение документации
3. Создание и распространение
документации
Г. Обучение 1. Планирование учебной программы
2. Разработка обучающих материалов
3. Утверждение программы обучения
4. Внедрение учебной программы
Стандарт 1074 полезен для любой организации, которая является ответственной за
управление и реализацию программных проектов. Он может использоваться там, где
ПО образует завершенную систему или является частью большей системы. Он пригоден
для организаций, занимающихся только программными продуктами, отделов, в
обязанности которых входит разработка внутренних информационных технологий,
консультантов в области ПО и организаций, занимающихся только менеджментом
проектов, которые доставляют и реализовывают имеющиеся в наличии коммерческие
(commercial-off-the-shelf, COTS) программные продукты. Продукт 1074 — это цикл SLCP,
который требуется для выполнения определенного программного проекта.

108 Глава 3
Хотя стандарт 1074 описывает разработку отдельного, полного процесса SLCP,
который должен применяться для проекта, пользователь этого стандарта должен
признать, что SLCP может сам по себе включать низкоуровневые жизненные циклы
разработки ПО. Здесь используется та же самая концепция, что и при менеджменте
конфигурации, когда отдельный элемент конфигурации может включать зависимые
ее элементы. Этот стандарт одинаково пригоден к разработке процесса SLCP на
любом уровне.
Стандарт 1074 включает шесть основных категорий процесса:
1. процесс модели жизненного цикла разработки ПО;
2. процессы менеджмента проектов;
3. процессы предварительной разработки;
4. процессы разработки;
5. процессы, выполняемые после разработки;
6. интегральные процессы.
Также существует 17 подпроцессов и 65 действий, входящих в состав
подпроцессов. Все эти объекты приводятся в таблице, описывающей стандарт 1074.
Стандарт 1074 не отождествляется с определенным процессом модели SLCM. Он
не может существовать без определенных циклов SLC организации. Стандарт 1074 не
предполагает использования определенной методологии разработки ПО и даже не
рекомендует ее. Он не является самодостаточным, т.е. могут быть добавлены в случае
необходимости более строгие требования. В табл. 3.1 приведена карта категорий
IEEE 1074 для процессов и действий.
Методы использования стандарта 1074
Стандарт 1074 представляет собой пошаговое руководство, в котором
описывается реализация девяти шагов, которые определяют методы выполнения процессов
SLCP. Учитывая природу настройки данного стандарта IEEE, практики пришли к
выводу, что определенные в стандарте инструкции могут быть в дальнейшем упрощены
до следующих шести этапов.
Этап 1. Выбор модели SLCM. На данный момент времени менеджер проекта
может выбирать модель жизненного цикла между той, с которой он имеет больший
опыт работы (предложена организацией), и моделью, требуемой клиентом, или
новой моделью, которая, как показало исследование, может принести хорошие
результаты в деле улучшения качества. В текущем описании будет выбрана для реализации
простейшая модель— основная каскадная модель, показанная на рис. 3.7.
Сначала менеджер проекта или архитектор процесса должны
идентифицировать цикл модели SLCM, в соответствие которому будут поставлены действия. Этот
этан включает расположение, оценку, отбор и получение цикла модели SLCM.
Организация может иметь множество моделей жизненного цикла разработки ПО.
Однако для проекта должна быть отобрана только одна модель. Смешение моделей в
пределах проектов приводит к беспорядку и получению недетерминированного
набора методов измерений проектов. Предполагается, что для оценки и выбора
модели SLCM архитектор процесса или менеджер проекта будут придерживаться
следующих пяти этапов.

Краткий обзор процессов 109
, 1
Гребования ^
Разработга^фоекга ^
'
Внедрение
1
\
■вотирован*»
\
Установка
и отладка , '
\
■ ■ ■ 'с -•
Эксплуатация ^■1-
исопровоздениё'*
Рис. 3.7. Этап 1— рассмотрение
основной каскадной модели процесса
1. Идентифицировать все циклы модели SLCM, которые являются доступными при
разработке проекта.
2. Идентифицировать признаки, которые применяются для желаемой
окончательной системы и среды разработки.
3. Идентифицировать любые ограничения, которые могли бы быть наложены на
выбор.
4. Оцепить различные циклы модели SLCM на основе предыдущего опыта и
организаторских способностях.
5. Выбрать цикл SLCM, который лучше всего удовлетворяет атрибутам и
ограничениям проекта.
Этап 2. Сравнение действий с требованиями модели SLCM. После выбора
SLCM, менеджер проекта составляет подробный документ, описывающий
взаимосвязь между действиями и моделью SLCM. Он включает сопоставление
действий по отношению к главным фазам SLCM. На этом этапе составляется
контрольный список, обеспечивающий отображение всех действий, а также охват всех
требований SLCM при выполнении одного или большего количества действий.
Самый простой способ выполнения этих действий заключается в том, чтобы,
используя карту 1074, добавлять столбцы для каждой из главных фаз модели SLCM.
Используя основную каскадную модель, можно добавить столбцы: Требования,
Разработка проекта, Внедрение, Тестирование, Установка и отладка, а также
Эксплуатация и сопровождение, как показано на рис. 3.8. В каждую ячейку, в
которой помещено действие стандарта 1074 в фазе жизненного цикла, выполняется
проверка. Когда все действия проанализированы на предмет того, в каком месте
они соответствуют фазе, таблица сортируется таким образом, чтобы действия без
проверок ячейки фазы находились внизу. Не удаляйте их из таблицы. При
осуществлении данного повторяющегося процесса они могут понадобиться на более
поздних этапах.

Категория
1. Процесс модели жизненного
цикла ПО
II. Процессы управления
проектом
Действия в рамках стандарта 1074
Процесс
А. Модель жизненного
цикла ПО
А. Инициирование проекта
Б. Контроль и мониторинг
проекта
В. Менеджмент качества
ПО
Действие
1. Идентификация моделей-кандидатов
в циклы SLC
2. Выбор модели проекта
1. Установка соответствия между
действиями и моделью SLC
2. Распространение проектной
информации
3. Установка проектной среды
4. План управления проектом
1. Анализ рисков
2. Выполнение планирования
непредвиденных обстоятельств
3. Управление проектом
4. Сохранение записей
5. Реализация метода отчетности
о проблеме
1. Планирование менеджмента
качества ПО
2. Определение метрических показателей
3. Управление качеством ПО
4. Идентификация потребностей
в улучшении качества
Фаза жизненного цикла
Требования
Разработка
проекта
Кодирование
Ux$ffi**i
\
\
>
г*т-Щ№
Тестирование
i
ajffilftglrj^
\
У.
Реализация
\
ч
ЯпВ|явв1|НИЯКк£1|
Рис. 3.8. Этап 2 - сравнение действия с требованиями модели SLCM

Краткий обзор процессов 111
В описываемый этап входят этапы 3 и 4, предусмотренные стандартом 1074. Этап
3 служит для разработки и подтверждения списка неиспользуемых действий. Во
время проведения сеанса обзора можно легко определить, что находится в списке, а
что — вне его (хотя это действие потребует дополнительных усилий). Практики
установили, что хранение подробных данных о причинах, из-за которых не были
отобраны определенные действия для определенного проекта, не помогает в ходе принятия
аналогичного решения для следующего проекта. Этап 4, определенный стандартом
1074, предназначен для внесения в список действий и обращений. Перечень действий
уже существует в модифицированной карте 1074. Обращения — это ни что иное, как
триггеры для процессов поддержки, таких как менеджмент конфигурирования,
используемых в ходе осуществления данной фазы.
Этап 3. Размещение действий во временной последовательности. Карта
действий с датами, помещенными в ячейку фазы, представлена в табл. 3.2. Порядок, в
котором будут выполняться действия, определяется тремя главными факторами.
1. Выбранный цикл SLCM определяет начальный порядок выполняемых действий.
По мере выполнения отображения устанавливается фактический порядок
выполняемых действий. Он обычно отличается от первоначального порядка действий
(из карты действий 1074).
2. Из-за ограничений графика может потребоваться отмена действий в цикле SLCM,
что, в свою очередь, окажет влияние на последовательность. В этом случае
действия могут скорее отображаться для параллельного, чем для последовательного
выполнения. В результате менеджер проекта в первую очередь обращает
внимание на выполнение графика.
3. На порядок действий могут влиять критерии входа и выхода взаимосвязанных
действий. Этот вопрос подробно рассматривается на этапе 4.
После завершения данного процесса таблица сортируется таким образом, чтобы
действия располагались в хронологическом порядке.
Этап 4. Проверка информационного потока. Входные и выходные
информационные таблицы стандарта 1074 определяют данные, которые должны
использоваться и порождаться каждым действием. На этом этапе проверяется, чтобы
информационный поток, направленный к действиям и от них, поддерживал
относительный порядок, в котором они были отображены. Хотя маловероятно, что это
приведет к серьезной перестановке или модификации отображения, поскольку
данная проверка требуется для того, чтобы убедиться в доступности необходимой
информации. На рис. 3.9 вышеизложенное демонстрируется в случае с действием
установки проектной среды.

Таблица 3.2. Этап 3 — размещение действий во временной последовательности
Фазы жизненного цикла
Категория Процесс Действие Требова- Проект Код Тести- Реали-
ния рование зация
I. Процесс модели жиз- А. Модель жизненного цикла 1. Идентификация 1 января
пенного цикла разра- разработки ПО моделей кандидата
ботки ПО на роль цикла SLC
II. Процессы менеджмента Б. Контроль и управление про- 1. Анализ рисков 15 января
проекта ектом
II. Процессы менеджмента В. Контроль и управление про- 2. Планирование не- 21 января
проекта ектом предвиденных
обстоятельств
I. Процесс модели жиз- А. Модель жизненного цикла 2. Выбор модели про- 1 февраля
ненного цикла разра- разработки ПО екта
ботки ПО
И. Процессы менеджмента В. Менеджмент качества ПО 1. Планирование ме- 1 марта
проекта неджмента
качества ПО
II. Процессы менеджмента В. Менеджмент качества ПО 2. Определение мет- 15 марта
проекта рических
показателей
II. Процессы менеджмента А. Начало выполнения проекта 4. Планирование ме- 15 апреля
проекта неджмента проекта
II. Процессы менеджмента А. Начало выполнения проекта 3. Установка проект- 30 апреля
проекта ной среды

Окончание табл. 3.2
Фазы жизненного цикла
Категория
Процесс
Действие
Требова- Проект Код Тести- Реали-
ния рование зация
II. Процессы менеджмента Б. Контроль и отслеживание
проекта проекта
II. Процессы менеджмента А. Начало выполнения проекта
проекта
И. Процессы менеджмента А. Начало выполнения проекта
проекта
И. Процессы менеджмента В. Менеджмент качества ПО
проекта
И. Процессы менеджмента Б. Контроль и отслеживание
проекта проекта
II. Процессы менеджмента Б. Контроль и отслеживание
проекта проекта
II. Процессы менеджмента В. Менеджмент качества ПО
проекта
5. Реализация метода 30 апреля
отчетности о
проблемах
1. Отображение дей- 1 мая
ствий на модель
SLC
2. Локализация
проектной
информации
4. Идентификация
потребностей
в усовершенствова
нии качества
3. Управление
проектом
4. Сохранение
отчетов
3. Менеджмент
качества ПО
1 июня
15 июля

114 Глава 3
Методологии
Стандарты
Инструменты
Библиотека ПО
Приобретенное ПО
Требования контракта
Анализ рисков
Жизненный цикл ПО
Определенные метрические показатели
Методы сбора и анализа
Распределения ресурсов
Формулирование потребности
Рис. 3.9. Этап 4 — проверка информационного потока
Этап 5. Назначение выхода действия для поставляемых продуктов. Каждый
процесс SLCM требует и определяет формат/содержание своего собственного
набора выходов. Эти продукты являются определенными компонентами, которые
поставляются в цикле SLCM. Обратите внимание, что термин компонент не подразумевает
специфической среды. На этом этапе сравнивается информация выхода, которая
порождается каждым действием, с компонентами, требующимися для циклов SLCM, в
состав которых она должна включаться. И снова может оказаться, что порядок ото-
бражения, на сей раз в силу требований этапа 4, придется изменить. Если в
выбранном цикле SLCM определено, что специфический артефакт должен быть создан в
специфической точке графика разработки, то все действия, которые вносят вклад в
то, чтобы информация была зарегистрирована в данном документе, должны иметь
возможность сгенерировать эту информацию.
Этап 6. Включение процессов поддержки жизненного цикла. Этот этап в
стандарте 1074 рассматривается как добавление организационного актива
процесса (Organizational process asset, OPA): стандарт 1074 определяет ОРА как
"компоненты, которые задают некоторую часть проектной среды ПО на уровне
организации". Практики определяют процессы поддержки жизненного цикла как
просктно-определенные процессы, основанные на SLC проекта, интегральных
процессах и процессах менеджмента, используемых организацией. Интегральные
процессы включают менеджмент конфигурации, метрические показатели,
обеспечение качества, снижение степени риска, а также действия по оценке,
планированию и обучению. Они уже включены в карту стандарта 1074 и ранее уже рас-
гмдтривались. Назначение этого этапа заключается в обеспечении того, что все
фазы цикла SLC будут адекватно определять трудозатраты, понесенные при
менеджменте проекта и осуществлении интегральных действий процесса. В ходе
выполнения этапа осуществляется дальнейшая контрольная проверка проектных
оценок и графика.
После завершения шестого этапа проект и организация получают готовый
процесс SLC. На рис. 3.10 показано, каким образом информация, используемая при
определении только что описанного процесса SLC, укладывается внутри организации.

Краткий обзор процессов 115
Процессы, изображенные на левой стороне рисунка, представляют собой все
действия, перечисленные на карте стандарта 1074. Как менеджер проекта вы можете
использовать эту карту, ссылки на модели усовершенствования процесса, типа модели
зрелости возможностей Института программного инжиниринга, а также отобранную
модель жизненного цикла для получения вашего цикла SLCM. На базе этой модели
можно получить определенный поднабор моделей для цикла SLC вашего проекта.
После этого можно начинать внедрять компоненты действий в поставляемые, такие как
план разработки ПО вашего проекта.
Процессы
СММ
Процессы
IEEE
РМР
и
Действие
До разработки
. Действие
Разработка
щ
Действие
После разработки
О
Действие
Интегральный
Действие
Менеджмент циклов
SLC организации
Объектно-
ориентированный
быстрый прототип
Эволюционные
Фазы
каскада
Инициирование
Действие
Концепция
Действие
Определение
и разработка проекта
Действие
Разработка
Действие
Установка
и эксплуатация
Действие
Рис. 3.10. Организационные отношения SLCM
Цикллы
SLC проекта
SDP
проекта
Х-фазы
проекта
Инициирование
Измененное
действие
Концепция
Дополнительное
действие
Определение
и разработка проекта
. Действие
Разработка
Действие
Установка
и эксплуатация
[ Одобрен ]
Ф
План
разработки
ПО
Прикладной стандарт 1074
Использование процесса, заданного в стандарте IEEE 1074, с целью определения
жизненного цикла разработки ПО — это один из наиболее ценных доступных
инструментов. Идея с разработкой собственного циклического жизненного цикла критична
для сокращения времени цикла и непрерывного усовершенствования процесса.
Парочка примеров применения позволят вам ознакомиться с открывающимися в этом
случае возможностями.

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

Краткий обзор процессов 117
Жизненный цикл организации,
управляющей программными проектами
Офис организации, выполняющей управление программными проектами,
включает менеджеров проектов, составителей технической документации и
минимального количества специалистов в области информационных технологий,
необходимых для формализации процесса выбора ПО. Работа в общественной организации с
сопутствующим надзором требует хорошо продуманного формализованного
процесса жизненного цикла. Для модели разработки COTS-продуктов в качестве
отправной точки использовалась каскадная модель, а также применялись карта и
этапы, соответствующие стандарту 1074.
На рис. 3.12 показаны подробности, реализуемые рассматриваемым офисом при
реализации карты 1074 по отношению к основной каскадной модели. Офис
применял в своей работе четыре основных процесса жизненного цикла: анализ
требований, определение структуры, интеграцию системы и тестирование, а также
модернизацию технологии. На каждой фазе определялись поставляемые продукты.
Большое внимание уделялось рассмотрению влияния в организации менеджмента и
интегральных процессов. Разработка прототипа происходила в два этапа.
Благодаря этому появлялась возможность поиска оптимальных программных решений,
оставаясь при этом в пределах структуры запросов информации со стороны
общественных агентств и запросов руководящих предложений. Особое внимание
уделялось области менеджмента конфигурации и документации, чтобы суметь передать
полную программную систему клиентам.
Резюме
Менеджеры проектов, которые берут на себя ответственность за менеджмент
процесса еще до начала выполнения проекта, будут находиться в более выгодном
положении. Структура поведения менеджера и команды, а также методов для измерения
продвижения к выполнению целей проекта будет хорошо определена, и ей легко
будет следовать на всем протяжении выполнения проекта. Чтобы лучше использовать
доступные инструменты управления разработкой ПО, определяются процедуры
организации, а также политика и модель жизненного цикла разработки проекта.
Команда также ознакомится с ними задолго до того, как начнет выполнение проекта
всерьез. Тогда никто из членов команды не должен будет заново продумывать то, каких
процессов он должен придерживаться, и каждый может сконцентрироваться на
определении требований системы.
Менеджмент процесса начинается с определения проектного или
организационного подхода к разрабатываемым продуктам. На рис. 3.13 приводится информация,
которая может использоваться для определения процесса. Действующая организация
представляет основы знания предыдущего проекта, методов измерений,
используемых в продуктах, и артефактов. Для новой организации или организации, плохо
знакомой с процессом, она представляет области, которые рассматривались бы в
качестве утверждаемых. Поскольку были определены циклы анализа для развития процесса,
этот рисунок будет снова использоваться, чтобы показать настройку основных
процессов для организации.

118 Глава 3
V0*/Точки обзора ^^^^Р Прототипы
План приобретения системы |
Требования ходатайства !
Спецификация требований !
системы !
Критерии оценки и план !
План развития поддержки !
Подтверждение плана !
концепции прототипа !
Подтверждение концепции i
прототипа !
Оценка широкой области !
решений !
Ж—ф
Интеграция ПО и спецификация
разработки проекта
Суженная предметная область
решений
План прототипа выполнимости пакета;
Прототип выполнимости пакета
Интеграция
и тестирование
системы
{интегрироаан-
I нов ПО
I Выбранное решение
!Учебныйплан !
I План развития поддержки
I Аттестованное и верифицирован-
t ноерешение i
-+-
План управления проектом
Инициирование и планирование проекта
Контроль и
мониторинг проекта
Обеспечение
качества
ПО
Менеджмент
конфигурации ПО
Разработка
документации
Планирование работы
с субподрядчиком
Анализ рисков
Управление проектом
Методы отчетности о наличии проблемы
Управление качеством ПО
План верификации
и аттестации
Верификация и аттестация
Выполнена задач по верификации и аттестации
_1_
Сбор и анализ данных измерений
Осуществление контроля конфигурации
Учет состояния
Реализация документации
Разработка формулировки
работы субподрядчика
Управление работой субподрядчика
Управление работой субподрядчика
Модернизация
технологии
I Эволюция под-
j держки
(Обучение поль-
I зоаателя
[План для системы
Модернизация
Обзор работы
субподрядчика
Рис. 3.12. Модель процесса разработки СОТ&продуктов
Конечным результатом применения менеджмента процесса является устранение
неопределенности интерфейса для любого проекта и быстрого продвижения к
определению концепции проекта, архитектур кандидатов, начальному рынку и
требованиям системы.

Краткий обзор процессов 119
Рис. 3.13. Результаты применения внешнего интерфейса проекта
Контрольные вопросы
1. Назовите активы процесса в вашей организации. Почему они считаются активами?
2. Кто должен отвечать за действия в рамках процесса создания ПО на уровне
организации?
Практическое занятие
Вы представили начальную оценку проекта внутреннему клиенту, менеджеру по
маркетингу AsiaPac. В результате были изменены оценки времени, требуемого для
получения карты базового процесса прототипа CRM из стандарта IEEE 1074.
Клиент никогда не использовал стандарт 1074, а применял модель
программирования eXtreme, поскольку, работая с ней, чувствует уверенность в своих силах. Через
пять дней он покинет страну и не одобрит часть плана вашего проекта, поскольку
вы можете просто воспользоваться моделью eXtreme, не слишком усложняя себе
задачу. Подготовьте докладную записку, убеждающую его, что фаза планирования
вашего проекта действительно важна, а проектные процессы — это больше, чем
модель программирования.
Литература
Deming W. Edwards. Out of the Crisis, 1st ed. Cambridge, MA: MIT Press, 2000
Deming W. Edwards. The New Economics: For Industry, Government, Education, 2nd ed. Cambridge, MA:
MIT Press, 2000.
Humphrey Watts. Managing the Software Process, 1st ed.; reprinted with corrections, August 1990. Reading,
MA: Addison-Wesley, 1989.

120 Глава 3
IEEE 1074-1997. "IEEE Standard for Developing Software Life Cycle Processes." New York, NY: The
Institute of Electrical and Electronics Engineers, 1998.
lshikawa K., Lu, DJ. trans. What is Total Quality Control? The Japanese Way. Englewood Cliffs, NJ: Prentice
Hall, 198Я.
Paulk Mark C, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis. The Capability Maturity Model- Guide-
Ihtajor Imprmiingthe Software Process, 1st ed. Reading, MA: Addison-Wesley, 1994.
Sliewhart Walter A., and W. Edwards Deming. Statistical Method from the Viewpoint of Quality Control, 1st ed.
New York, NY: Dover Pubs. 1986.
Дополнительные сведения в Internet
standards. ieee .org/. Ассоциация стандартов IEEE (IEEE Standards Association, IEEE-SA) —
международная организация, обслуживающая современные отрасли промышленности, предлагая
полный набор программных стандартов.
www. incose. org/. Международный совет по разработке систем (International Council on Systems
Engineering, INCOSE)— некоммерческая членская организация, основанная в 1990 году. INCOSE —
лшоритетный международный орган, продвигающий применение междисциплинарного подхода и
< редеть, чтобы давать возможность реализовыватьуспешные системы.
www.psmsc. com/. "Практические оценки ПО н систем: основа для объективного менеджмента"
была разработана для того, чтобы удовлетворить требованиям, выдвигаемым при разработке
современного ПО, а также при создании технических и управленческих систем. Здесь описывается
управляемый проблемой процесс измерений, который направлен на достижение уникальных технических
и деловых целей организации. Руководство в PSM представляет лучшие методы, используемые
профессионалами в области определения метрических показателей, относящихся к сообществам
приобретения программных и системных средств, а также осуществляющих инжиниринг ПО.
www. spmn .com/. Миссия сети программных менеджеров заключается в том, чтобы позволить
менеджерам крупномасштабной, преимущественно программной разработки или проектов
технической поддержки более эффективно управлять и добиваться успеха, идентифицируя и передавая для
управления лучшие методы, освоенные уроки и непосредственную поддержку.

Выбор жизненного
цикла разработки ПО
Проект— это уникальный процесс, в ходе выполнения которого получают
уникальный продукт. Таким образом, для разработки продукта в проекте, скорее
всего, должен применяться уникальный процесс. Как менеджер проекта определяет
соответствующий процесс или жизненный цикл, чтобы достичь поставленных
целей проекта? Вместо создания каждого проекта "с нуля", менеджер проекта
может воспользоваться обобщенной, проверенной на практике методикой,
адаптировав ее для конкретного проекта. Как правило, всегда есть возможность
выбора среди нескольких "начальных" жизненных циклов. В главе рассмотрены
некоторые из наиболее широко употребляемых жизненных циклов, приведены
основные принципы выбора соответствующего жизненного цикла, а также принципы,
которыми следует руководствоваться при адаптации выбранного цикла к
потребностям определенного проекта.
В главе 1 объясняется, как и почему авторы этой книги руководствуются
принципом жизненного цикла разработки программного продукта. Использование
данного метода позволяет в логическом порядке рассмотреть 34 компетенции,
относящиеся к программным продуктам, проектам и персоналу. Согласно
представленной нами схеме процесса (рис. 4.1), определение продукта (компетенция
продукта 3) предшествует оценке его стоимости (компетенция проекта 14),
поэтому на схеме сначала представлено определение, а затем оценка стоимости
продукта. Использование подобной схемы процесса подразумевает
необходимость руководствоваться пятью главными фазами выполнения проекта, которые
были опубликованы в руководстве "Основы знаний", изданной Институтом
управления проектами (Project Management Institute's Body of Knowledge, PMBOK):
инициализация, планирование, выполнение, контроль и завершение. Выбор
жизненного цикла разработки ПО и его адаптация к определенному проекту
происходит на этапе планирования PMI.

122 Глава 4
Стадии жизненного цикла
разработки продукта
Каково наше положение в модели жизненного цикла разработки программного
продукта, которая служит нам в качестве "дорожной карты"? Как показано на рис. 4.1, мы
находимся практически в начале цикла. Разрабатывая план менеджмента программного
проекта (Software project management plan, SPMP), менеджер принимает во внимание
действия, определенные на фазах, которые формируют сам метод разработки.
Представленную на рисунке каскадную модель удобно использовать в качестве
основы для рассмотрения 34 компетенций. Надеемся, у вас не возникнет
предположение, что мы рекламируем эту модель в качестве жизненного цикла разработки ПО для
всех новых проектов. При определенных обстоятельствах применение этой модели
действительно является эффективным, но зачастую она не представляет собой
наиболее приемлемую модель жизненного цикла, т.е. которая подходит для
произвольного программного проекта.
Исследование
концепции
•
Формулирование

потребности
Исследование
системы
' Спецификация
интерфейса
системы
Требования
' Спецификация
требований
к ПО
Разработка
проекта
Идентификация
циклов SLC
1 Описание

разработки ПО
•SLCs
Внедрение
Выбор
модели
■ План

тации/верификации ПО
1 Модель SLC
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
Выбор модели
жизненного цикла
разработки ПО
Установка
■ Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
•SLC
Распределение
ресурсов
1
Пользовательская
документация
Сопровождение
1 Бюджет
' Документация
по
сопровождению
Вывод из
эксплуатации
• Архивный
отчет
Рис. 4.1. Выбор жизненного цикла для проекта, происходящий в самом начале его осуществления

Выбор жизненного цикла разработки ПО 123
Не секрет, что не всем подходит один и тот же размер. У менеджера проекта в любом
случае возникнет желание исследовать и применить тот метод, который наиболее
подходит для разрабатываемого программного продукта, и делает он это в самом начале работы
над проектом. Самым лучшим выбором может оказаться каскадная модель, но существует
большая доля вероятности того, что будет применяться и более современная модель.
Связь главы 4 с 34 компетенциями
Выбор и адаптация жизненного цикла разработки проекта оказывает влияние на
методики разработки продукта, навыки менеджмента проектов и навыки менеджмента
персонала. Что касается методов разработки продукта, менеджер проекта должен прежде всего
иметь представление о стандартах процесса (компетенция 2), уметь оценить их
применимость по отношению к данному проекту (компетенция 1), оценить альтернативные
процессы (компетенция 4), и при необходимости адаптировать процесс жизненного цикла к
текущим потребностям (компетенция 9). На выбор методов и инструментальных средств
(компетенция 8) также может оказывать влияние выбор жизненного цикла.
Что касается навыков менеджмента проектов, здесь речь идет о компетенции 19
(выбор метрических показателей). Например, если менеджер проекта хочет
продемонстрировать, что выполнение критического анализа на ранних стадиях
жизненного цикла снижает общие затраты на разработку проекта, он должен отслеживать
результаты анализа. Управление рисками, т.е. компетенция 16, становится
составляющим компонентом процесса разработки особенно при использовании некоторых
современных моделей жизненного цикла разработки проекта, которые были созданы
специально для идентификации рисков и их контроля. Как мы увидим при
рассмотрении спиральной модели, оценка риска выполняется в конце каждой фазы
разработки. Использование жизненного цикла позволяет получить план для отслеживания
выполнения проекта. Например, если организации известно, что первые три фазы
выполняемого проекта завершены, и, как правило, трудозатраты при выполнении
этих фаз составляют 67% от общего объема трудозатрат, можно получить некоторое
представление о том, на каком этапе выполнения находится проект (в соответствии с
заранее составленным графиком). Фазы жизненного цикла зачастую представляют
собой совокупность действий из структуры пооперационного перечня работ на
высшем уровне (Work breakdown structure, WBS) (компетенция 12), которые затем
разбиваются на отдельные задачи. Что касается навыков менеджмента персонала,
жизненный цикл может оказаться полезным для менеджера проекта при оценке
деятельности одного из членов команды (компетенция 23). Например, если разработчику
поручено собрать системные спецификации на фазе определения потребностей, но
вместо этого он сразу переходит к фазе кодирования, для этого ему, возможно,
понадобится овладеть специальностью разработчика ПО.
Учебные цели главы 4
После изучения материала главы читатель должен уметь выполнять следующее:
■ описать несколько различных принципов построения жизненного цикла;
■ продемонстрировать умение выбрать модель жизненного цикла в соответствии
с параметрами проекта;
■ продемонстрировать умение адаптировать жизненный цикл под определенный
проект.

124 Глава 4
Определение жизненного цикла
разработки ПО
В главе 3 понятие процесса определено таким образом, как показано на рис. 4.2.
В главе также описано, насколько важно руководствоваться этим процессом при
выполнении любого программного проекта.
Схема процесса разработки ПО показывает, какие действия необходимо
выполнить на каждой фазе выполняемого проекта. Фазы жизненного цикла представляют
собой отдельные и следующие один за другим периоды с критериями входа и выхода.
Например, переход с фазы определения потребностей к фазе разработки проекта
предполагает, что все проектанты отвечают предъявляемым к ним требованиям на
данный момент времени. Это означает, что учитываются критерии выхода (по
крайней мере, некоторые их них) из фазы определения требований, а также критерии
входа (но крайней мере, некоторые их них) на фазе разработки проекта ' .
В главе 3 были рассмотрены стадии ввода и вывода, преобразования, контрольные
точки, а также стадии, которые, как правило, ассоциируются с определенной фазой
ныполняемого проекта. Однако, в этой схеме не представлен порядок или
последовательность, согласно которым будут выполняться фазы и действия. Модель
жизненного цикла разработки ПО является единственным видом процесса, в котором
представлен порядок его осуществления.
Модель жизненного цикла разработки ПО (Software life cycle model, SLCM)
схематически объясняет, каким образом будут выполняться действия по разработке
программного продукта, посредством описания "последовательности" этих действий.
Такая последовательность может быть или не быть линейной, поскольку фазы могут
следовать друг за другом, повторяться или происходить одновременно. На рис. 4.3
представлена простая обобщенная схема процесса. На ней показано, что в целом,
процесс состоит из основных фаз, которые включают в себя действия, в результате
выполнения которых создаются поставляемые продукты.
Управляющие механизмы
Вход
Инструкции
по приведению
в соответствие
требований к
материалам
и оборудованию
Выход
Программные продукты/службы
и информация
* Все программные компоненты
должны находиться под контролем
менеджмента конфигурации
Агенты
(люди, машины и ПО)
Рис. 4.2. Обобщенная фаза процесса
1 dictionary. Cambridge. org/. Cambridge University Press 2000.
" www.m-w. com/netdict. htin. Merriam-Webster's WWWebster Dictionary.

Выбор жизненного цикла разработки ПО 125
Процесс
Фаза
Действие
Поставляемые
продукты
Рис. 4.3. Обобщенная схема процесса
Модель SLCM — это схема (или основа) используемая разработчиком ПО для
определения повторяющегося процесса при создании программного продукта. Она
определяет точные инструкции, которые разработчик может использовать для
создания только высококачественных программных систем. Понятие жизненного
цикла разработки ПО относится ко всем программным проектам, причем
независимо от их размера.
Ключевое значение жизненных циклов
разработки ПО
Чтобы достичь успеха, менеджеры программных проектов, а также их
единомышленники, клиенты, персонал и администраторы должны располагать
коммуникационными средствами, такими как единая терминология и согласованный жизненный
цикл разработки. Жизненный цикл— это своего рода "карта-путеводитель" для всех
участников проекта, которая помогает им понять, не выходят ли они за
определенные для них границы.
Что касается карт вообще, то по этому поводу существуют точные высказывания
известных специалистов в этой области.
■ "Если вы не знаете, куда идете, вы, по всей вероятности, достигнете финиша где-
нибудь в другом месте". (Лоуренс Дж. Питер);
■ "Вам следует быть очень осторожными, если не знаете, куда идете, поскольку вы
можете попасть не туда, куда требуется". (Джоги Берра).

126 Глава 4
Доктор Барри Боэм, автор огромного количества мудрых аксиом, относящихся к
разработке программ, предоставил несколько "карт" процесса разработки ПО. Его
работа не потеряла свою актуальность и сегодня — форматы разработанных им карт
получили развитие или со временем были усовершенствованы. Критики каскадной
модели жизненного цикла были правы лишь в том, что еще в 1981 году согласно
высказываниям Боэма "...использование термина последовательный для описания фаз
разработки ПО является "удобным упрощенчеством". Боэм описывал прототипиро-
вание и инкрементную разработку как альтернативные варианты последовательной
каскадной модели. Как будет описано далее в этой главе, он первым предложил
известную спиральную модель. Начиная с каскадной, каждая из его моделей становилась
более совершенной и точной, чем предыдущая модель.
Боэм начал говорить о картах разработки программ после публикации своей
творческой работы под названием Software Engineering Economics. В этой книге он ссылался
па "целевую структуру инжиниринга ПО", подчеркивая, что успешная разработка ПО
зависит не только от получения удачного программного продукта, но также от
получения удачных процессов разработки ПО. Эта структура изображена на рис. 4.4.
Рис. 4.4. Целевая структура инжиниринга ПО Боэма
Взаимоотношения между участниками проекта, инжиниринг ресурсов и
программный инжиниринг являются необходимыми движущими категориями успеха,
причем как в процессе, так и продукте. В каждой категории продукт имеет
несколько характеристик, таких как простота в использовании (взаимоотношения между
участниками проекта), эффективность (инжиниринг ресурсов) и применимость
(программный инжиниринг). Один из таких процессов, а именно процесс разработки

Выбор жизненного цикла разработки ПО 127
ПО, также требует поддержки факторов успеха. Для обеспечения взаимоотношений
между участниками проекта необходимо учитывать планирование, организация,
кадровое обеспечение, направление, управление, автоматизация и использование
"модифицированного золотого правила". Работа менеджеров принципиально
отличается от работы программистов. Инжиниринг ресурсов процесса предполагает
анализ экономической эффективности, планирование и составление оценки, а также
управление графиками совещаний и бюджетом. Что же касается инжиниринга
программного процесса, здесь фактор успеха определяется степенью выполнимости
проекта, обоснованием требований, аттестацией и верификацией программного проекта,
процесса программирования, интеграции, внедрения, сопровождения, а также
выходом за пределы фаз и менеджментом конфигурации (Configuration management, CM).
Эти факторы программного инжиниринга становятся соответствующими фазами
жизненного цикла (за исключением СМ, которое является интегральной задачей),
как показано на рис. 4.5.
На данном этапе нас интересует тот факт, что для управления программным
проектом возникает необходимость в некотором роде карты для планирования
действий и хронологий их выполнения. Первые теоретические разработки Боэма,
посвященные достижению подцелей (рис.4.4) как необходимой составляющей
успешной разработки программного продукта, сохранили свою актуальность и на
сегодняшний день.
В стандарт, разработанный для немецких ИТ-систем, были включены описания
причин, объясняющие необходимость выполнения стандартизированного процесса.
Этот стандарт помогает достичь следующих целей.
■ Улучшение и обеспечение качества:
- с помощью стандартизированной процедуры можно наилучшим образом
гарантировать завершенность результатов, которые необходимо предоставить;
- определение промежуточных результатов обеспечивает возможность ускорить
выполнение оценочных процедур;
- контекст однородных продуктов облегчает их восприятие, а также работу с
процедурами оценки.
■ Возможность проверки затрат на выполнение полного жизненного цикла:
- упрощается процесс создания стандартов разработки для определенного
проекта и его оценка;
- стандартизированные процедуры повышает степень "прозрачности" операций
по определению затрат и позволяют более эффективно распознавать
возможные риски, связанные с затратами;
- одинаковые стандарты уменьшают риск возникновения разногласий между
клиентом и разработчиком, а также между главным разработчиком и
субподрядчиком;
- в случае применения стандартизированной процедуры становятся
"прозрачными" универсальные походы к методам решения, а следовательно, их можно
использовать повторно;
- нежелательный ход процесса разработки возможно выявить на ранней стадии;
- уменьшаются затраты на подготовку персонала.

128 Глава 4
Улучшается обмен информацией между различными сторонами,
участвующими в процессе разработки; происходит снижение зависимости клиента от
подрядчика:
- использование определенных терминов уменьшает разногласия, возникающие
между всеми задействованными в проекте сторонами;
- пользователь, покупатель и разработчик получают поддержку при
формулировании своих требований, а также при описании своих ролей или полученных
результатов;
- промежуточные/окончательные результаты стандартизируются таким
образом, что другие задействованные в проекте стороны или персонал других
компаний могут в случае необходимости подключиться к процессу разработки, не
прилагая при этом больших дополнительных усилий .
Аттестация
Аттестация
|Планы и требования,
формулируемые
при разработке ПО
Верификация
Тестирование
модуля
Продует
Тестирование
системы
Ал
Повторная
аттестация
Рис. 4.5. Основные свойства интерактивной каскадной модели, включающей процессы
аттестации и верификации
www. informatik.uni-bremen.de/uniform/gdpa/vmodel/vml .htm. Стандарт
разработки V-образной модели для ИТ-систем в Федеративной Республике Германии, С. 6-7.

Выбор жизненного цикла разработки ПО 129
Выбор и адаптация жизненных циклов
разработки ПО
Используя определенный процесс разработки ПО, организации получают
последовательную схему этого процесса, которую они могут адаптировать под
определенные потребности. С несовместимыми потребностями в адаптации и стандартизации
можно справиться, построив структуру процесса как состоящую из стандартных
модулей или "основных" этапов, а также правил, используемых для описания и
установки взаимоотношений между этими этапами. В таком случае адаптация достигается
путем их объединения в модели процесса .
Модель SEI CMM и жизненные циклы
Как правило, менеджмент качества программных проектов основывается на
знаниях из трех источников: программный инжиниринг (ACM, IEEE), менеджмент
проекта (PMI) и качество (ASQ). Институт программного инжиниринга (SEI, Software
Engineering Institute) в Университете Карнеги Мэллон объединяет все эти три
источника. Модель зрелости функциональных возможностей (Capability Maturity Model,
CMM), служит "каркасом" процесса разработки ПО, основанным на практических
действиях и отображающим лучшие результаты и определяющим ее потребности
индивидов, работающих над усовершенствованием процесса разработки ПО и
выполняющих оценочный анализ этого процесса. В последующих главах мы много раз
будем ссылаться на то, каким образом менеджмент качества программных проектов
соответствует модели CMM SEI. Поскольку модель СММ хорошо известна в
сообществах разработчиков ПО, нет особой потребности снова приводить ее
определение в этой главе. Мы представим лишь краткое ее описание, чтобы
продемонстрировать необходимость использования жизненного цикла в процессе разработки.
Ниже приведена краткая обобщенная характеристика уровней развития
функциональных возможностей модели СММ.
Модель СММ представляет собой схему, по которой этапы разработки
соответствуют пяти уровням развития функциональных возможностей, на основе которых
осуществляется непрерывное усовершенствование процесса разработки. Говорят об
уровне развития функциональных возможностей, обычно подразумевают строго
определенную стадию развития, направленного на получение законченного процесса
разработки ПО. При разделении модели СММ на пять уровней, показанных на
рис. 4.6, первостепенное внимание уделяется направленным на усовершенствование
действиям, необходимым для завершения работы над развитием функциональных
возможностей процесса. Эти пять уровней можно кратко описать, присвоив им
следующие характеристики:
Исходный. Процесс разработки ПО можно охарактеризовать как специальный,
подобранный для определенного случая процесс, а иногда и как хаотический.
Определить можно лишь небольшое количество процессов, и успех зависит от
приложенных индивидуальных усилий и предпринимаемых решительных действий.
Повторяющийся. Основные процессы управления проектом создаются для того,
чтобы отслеживать затраты, график работы и функциональные возможности. Здесь
1 Humphrey Watts. Managing the Software Process, 1-е издание, MA: Addison-Wesley, 1989.
Повторная редакция с исправлениями, август 1990, С. 167.

130 Глава 4
соблюдается необходимый порядок выполнения процесса, предназначенный для
повторения достижений, полученных ранее при выполнении подобных проектов.
Определенный. Во всех проектах используется испытанная, адаптированная вер
сия стандартного процесса разработки ПО данной организации.
Управляемый. Собираются детальные показатели процесса разработки ПО и
качественные характеристики продукта. Управление процессом разработки
программных продуктов осуществляется на количественном уровне.
Уровень оптимизации. Непрерывное усовершенствование процесса разработки
достигается с помощью количественной обратной связи, достигаемой при
осуществлении самого процесса, а также на базе новаторских идей и технологий .
Менеджмент изменений процесса
Менеджмент технологических изменений
Предотвращение дефектов
^mmr&s&
Менеджмент качества ПО
Менеджмент количественных процессов
Экспертные оценки
Координация деятельности групп
Инжиниринг программного продукта
Интегрированный менеджмент ПО
Учебная программа
Определение процесса организации
Выделение процесса организации
Менеджмент конфигурации ПО
Обеспечение качества ПО
Менеджмент процесса разработки ПО,
выполняемого субподрядчиками
Отслеживание и обзор программного проекта
Планирование программного проекта
Менеджмент требований
Начальный A)^-, - v
Рис. 4.6. Ключевые области процесса по уровням зрелости
согласно SEIСММ
' Paulk, Mark С Charles V. Weber, Bill Curtis and Mary Beth Chrissis. The Capability Maturity
Model: Guidelines for Improving the Software Process, 1-е издание. Reading, MA: Addison-Wesley, 1994. —
С 15-17.

Выбор жизненного цикла разработки ПО 131
Каждый уровень зрелости разбивается на несколько ключевых областей процесса,
указывающих на то, какие действия еще необходимо предпринять для
усовершенствования процесса разработки ПО. Каждая ключевая область процесса (Key process
area, KPA) определяет набор взаимосвязанных действий, необходимых для
оптимизации этого процесса.
Области КРА на уровне 2 относятся к возникающих при выполнении
программного проекта вопросов, которые связаны с созданием базовых средств управления
менеджментом проекта. Мы возвратимся к рассмотрению этого уровня при
рассмотрении компетенций проекта.
На данном этапе обсуждения нам необходимо знать, что повторяющийся процесс
(уровень 2) позволяет оптимизировать структуризацию и управление в организации.
Жизненные циклы, рассматриваемые в этой главе, представляют собой определение
того, что понимается под процессом, который необходимо выполнить, и продуктом,
который необходимо создать с помощью этого процесса. При наличии такого
определения формируется единый язык, и облегчаются переходные периоды при включении в
процесс разработчиков, особенно если у них недостаточно опыта в этой области.
Однако наличие повторяющегося процесса (уровень 2) заведомо не приводит к
хорошо разработанному процессу. В общем, усовершенствование процессов
происходит тогда, когда организация достигает уровня 3 (Level 3 или L3), разработанного
институтом SEI, то есть определенного уровня. Уровень 3 относится к решению как
связанных с выполнением проекта, так и организационных вопросов, поскольку
организация создает инфраструктуру, обеспечивающую эффективный программный
инжиниринг и менеджмент по всем проектам. Две области КРА, определение
организации процесса и интегрированный программный менеджмент, относятся к
предметной области жизненных циклов. При обсуждении этих двух областей КРА
упоминание жизненного цикла процесса разработки ПО будет выделено жирным
шрифтом. Описания КРА взяты из модели зрелости возможностей .
Определение процесса на уровне организации
Цель определения организационной структуры процесса области КРА на уровне 3
заключается в разработке и сопровождении удобной в употреблении совокупности
полезных свойств процесса разработки ПО, которые улучшают эффективность
процесса при выполнении ряда проектов. Определение процесса включает в себя
разработку и сопровождение стандартного процесса разработки определенной
организации, а также относящиеся к нему ценные свойства процесса, такие как описательные
характеристики жизненных циклов разработки ПО, руководящие принципы
адаптации процесса и его критерии.
Цель определения организационной структуры процесса заключается в
разработке и сопровождении стандартного процесса разработки ПО для данной организации.
Действия, формирующие процесс построения организационной структуры,
включают документирование и сопровождение описательных характеристик жизненных
циклов разработки ПО, которые одобрены для использования в проектах. В
качестве примеров таких циклов можно назвать каскад, перекрывающийся каскад,
спиральный, последовательный, а также однопрототипный/перекрывающийся каскад.
' См. сноску 5.
' См. сноску 5.

132 Глава 4
Руководящие принципы и критерии, применяемые для адаптации проектов в рамках
стандартного процесса разработки ПО в данной организации, получают путем разработки
и сопровождения. Руководящие принципы и критерии адаптации описывают выбор и
адаптацию жизненного цикла разработки ПО для данного проекта, а также адаптацию
стандартного процесса разработки данной организации с целью включения в него
жизненного цикла разработки ПО и характеристик данного проекта. Примерами адаптации
могут служить адаптация определенного процесса для новой серии программных
продуктов или окружения сетевого узла, приспособление процесса к определенному проекту или
классу проектов, а также разработка деталей и их внесение в процесс для активизации
получаемого в результате определенного процесса разработки в рамках данного проекта.
Интегрированный программный менеджмент
Цель интегрированного программного менеджмента области КРА на уровне 3
заключается в том, чтобы объединить программный инжиниринг и управленческую
деятельность в логически последовательный определенный процесс разработки ПО,
полученный в результате адаптации стандартного процесса разработки ПО в данной
организации и связанных с ним ценных свойств процесса, описанных в
"Определении процесса на уровне его структуры".
Цели, выдвигаемые в данном случае, состоят в том, чтобы превратить
определенный процесс разработки ПО в рамках данного проекта в адаптированную
разновидность стандартного процесса разработки данной организации, а также обеспечить
планирование и управление проектом в соответствии с определенными процессами
разработки ПО в рамках данного проекта. Действия, направленные на достижение
этих целей, включают в себя адаптацию стандартного процесса разработки данной
организации в соответствии с документально подтвержденной процедурой, которая
направлена на разработку определенного процесса разработки ПО в рамках данного
проекта. Эта процедура, как правило, определяет, что жизненный цикл разработки
ПО выбирается среди циклов, уже одобренных в организации, для соблюдения
договорных и эксплуатационных ограничений и в случае необходимости видоизменяется
в соответствии с принятыми организацией руководящими принципами и критериями
адаптации, а также документируется согласно стандартам организации.
Международная организация
по стандартизации (ISO)/IEC 12207
Институт программного инжиниринга (SEI) — не единственная организация,
которая занимается вопросами обеспечения качества или стандартов и изучением
процессов разработки ПО и жизненных циклов. Еще в 1989 году было признано, что
стандарт, предложенный военным и другим правительственным подрядчикам, и
называемый стандартом Министерства обороны США (Department of Defense
Standard — 2167A) не подходил в достаточной мере для использования в проектах,
в которых были задействованы методы объектно-ориентированного проектирования
(Object-oriented design, OOD) или быстрой разработки приложений (Rapid
Application Development, RAD). Создание нового военного стандарта 498 (Military Standard,
MIL STD) было направлено на исправление возникающих в результате использования
этих методов проблем. Третий подход, заключающийся в привлечении
международной организации по стандартизации 12207 (International Organization for
Standardization, ISO/IEC), который появился независимо от стандарта MIL STD 498, — это еще

Выбор жизненного цикла разработки ПО 133
один шаг вперед. При использовании этого подхода описываются основные
процессы, составляющие полный жизненный цикл разработки ПО, связующие звенья между
ними, а также отношения на высшем уровне, управляющие их взаимосвязями.
Обзор процесса инжиниринга
1 Г
Внедрение
процесса
Проект
Установка
ПО
Приемка ПО
Анализ
системных
требований

Проектирование
системной
архитектуры
Система
Интеграция
ПО
Тестирование
квалификации
ПО
Ч^
s*ps^
Анализ
системных
требований

Проектирование
системной
архитектуры
Тестирование
ПО
Интеграция
программного
обеспечения
Разработка

детализированного ПО
Кодирование
и тестирование
ПО
Га, ■■!!«;
ПО
».;■»•
#
«*..
';/_
'г -
'Л
■'г
>ГЩ;4
щ
\:tjk'-f
Н^
щ
■Л >*■*-, 1^
т
ШШт
Рис 4.7. Инженерный взгляд на JSO/IEC12207

134 Глава 4
Как показано на рис. 4.7, организацией ISO/IEC 12207 перечислено 12 действий
по инжинирингу, следующих за реализацией процесса, которые аналогичны фазам,
составляющим типичную модель SLCM:
1. анализ системных требований;
2. проектирование архитектуры системы;
3. анализ программных требований;
4. разработка проекта программной архитектуры;
5. рабочий план разработки ПО;
6. кодирование ПО;
7. интеграция ПО;
8. тестирование ПО;
9. интеграция системы;
10. тестирование системы;
11. установка ПО;
12. тестирование и приемка ПО.
Приведенный выше метод ISO/IEC 12207 описан как реализация цикла,
построенного по принципу "планирование-реализауия-проверка-действие" (PDCA, Plan-Do-Check-
Act), который был рассмотрен в главе 3.
Суть описанного выше метода заключается в том, что инженер сначала проверяет
данные, полученные в результате выполнения инженерной задачи, прежде чем
использовать их в качестве исходных для выполнения следующей задачи. "Действия,
составляющие процесс разработки ПО стандарта ISO/IEC 12207, не зависят друг от
друга... они не упорядочены по принципу каскадной модели, и ... в международном
стандарте отсутствуют требования, которые диктуют последовательность их
выполнения". На самом деле в параграфе 5.3.1.1. стандарта ISO/IEC 12207 четко указано,
что "эти действия и задачи могут перекрываться или взаимодействовать, а также
могут выполняться многократно или рекурсивно". В параграфе 1.5 определено, что
"этот международный стандарт не предписывает какую-либо определенную модель
жизненного цикла или метод разработки ПО". В параграфе 5.3.1.1 также определено,
что если используемая модель не оговорена в контракте в качестве особого условия,
"разработчику предстоит определить или выбрать модель жизненного цикла
разработки, которая соответствует размеру и сложности данного проекта. Действия и
задачи процесса разработки предстоит выбрать, а затем сопоставить с моделью
жизненного цикла". Назначение и цель языка, используемого в международном
стандарте, заключается в том, чтобы обеспечить гибкость при установке очередности
действий, а также в выборе моделей разработки во избежание каскадного смещения
8
других стандартов .
Отдельные лица и организации, проявившие себя в области разработки ПО и
управления проектами, а также в сфере улучшения качества, полностью согласны с
необходимостью существования процесса и, в частности, процесса жизненного
цикла. Институт PMI, Боэм, Немецкие ИТ-системы, институт SEI и организация
www.stsc.hil .af.mil/crosstalk/1996/aug/isoiec.asp. Gray, Lewis. "ISO/IEC
12207 Software Lifecycle Processes." Crosstalk, 1996.

Выбор жизненного цикла разработки ПО 135
ISO — все они рекомендовали и рекомендуют использовать жизненный цикл
разработки ПО, который получают путем тщательного отбора и последующей адаптации
под определенный проект.
Модели жизненного цикла разработки ПО
Наиболее известными и широко используемыми жизненными циклами
разработки ПО можно назвать следующие: каскад, V-образное эволюционное ускоренное про-
тотипирование, быстрая разработка приложений, инкрементная и спиральная
модели. В последующих разделах будет описана каждая из них, рассмотрены их
преимущества и недостатки, а также будут приведены примеры модифицированных моделей и
руководство по их адаптации. В табл. 4.1-4.4 будут приведены критерии, которые
могут пригодиться менеджеру проекта при выборе оптимальной модели жизненного
цикла для данного проекта.
Каскадная модель жизненного цикла разработки ПО
Классическая каскадная модель, несмотря на полученную в последнее время
негативную оценку, исправно служила специалистам по программному инжинирингу
многие годы. Понимание ее сильных сторон и недостатков улучшает оценочный анализ
других, зачастую более эффективных моделей жизненного цикла, основанных на
данной модели.
В первые годы практики программирования сначала записывался программный
код, а затем происходила его отладка. Общепринятым считалось правило начинать
работ)' не с разработки плана, а с общего ознакомления с продуктом. Без лишних
формальностей можно было спроектировать, закодировать, отладить и
протестировать ПО еще до того, как оно будет готово к выпуску. Это напоминало процесс,
изображенный на рис. 4.8. В структуре такого процесса есть несколько
"неправильностей" (или недостатков). Во-первых, поскольку изначально не существовало
официального проекта или анализа, невозможно было узнать о моменте завершения
процесса. Также отсутствовал способ определения соответствия требованиям
относительно достижения качества.
В 1970 году каскадная модель была впервые определена как альтернативный вариант
метода разработки ПО по принципу кодирование-устранение ошибок, который был широко
распространен в то время. Это была первая модель, которая формализовала структуру
этапов разработки ПО, придавая особое значение исходным требованиям и
проектированию, а также созданию документации на ранних этапах процесса разработки.
Что неправильно в этом процессе?
Рис. 4.8. Модель процесса "делать, пока не будет
сделано"

136 Глава 4
Начальный этап выполнения каскадной модели показан в левой верхней части
рис. 4.9. Продолжается процесса выполнения реализуется с помощью упорядоченной
последовательности шагов. В модели предусмотрено, что каждая последующая фаза
начинается лишь тогда, когда полностью завершено выполнение предыдущей фазы.
Каждая фаза имеет определенные критерии входа и выхода: входные и выходные
данные. В результате выполнения генерируются внутренние или внешние данные
проекта, включая документацию и ПО. Документы по анализу требований
впоследствии передаются системным специалистам, которые в свою очередь передают их
разработчикам программных систем более высокого уровня. Программисты передают
детальные технические характеристики программистам, которые уже представляют
готовый код тестерам.
Переход от одной фазы к другой осуществляется посредством формального обзора.
Таким образом, клиент получает общее представление о процессе разработки, кроме
того происходит проверка качества программного продукта. Как правило, прохождение
стадии обзора указывает на договоренность между командой разработчиков и клиентом
о том, что текущая фаза завершена и можно перейти к выполнению следующей фазы.
Окончание фазы удобно принимать за стадию в процессе выполнения проекта.
Исследование
концепции
Г
Исследование
системы
Требования
Разработка
проекта
" к
Внедрение
Установка
Эксплуатация
и поддержка
Сопровождение
Вывод из
эксплуатации
Рис. 4.9. Классическая каскадная модель с обратной связью

Выбор жизненного цикла разработки ПО 137
В результате завершения определенных фаз формируется базовая линия, которая в
данной точке "замораживает" продукты разработки. Если возникает потребность в их
изменении, тогда для внесения изменений используется формальный процесс изменений.
В критических точках каскадной модели формируются базовые линии, последняя
из которых является базовой линией продукта. После формирования
заключительной базовой линии производится обзор приемки.
Попытки оптимизации каскадной модели привели к возникновению других
циклов разработки ПО. Прототипирование программ позволяет обеспечить полное
понимание требований, в то время как инкрементные и спиральные модели позволяют
повторно возвращаться к фазам, соотнесенным с классической каскадной моделью,
прежде чем полученный продукт будет признан окончательным.
Отличительным свойством каскадной модели можно назвать то, что она
представляет собой формальный метод, разновидность разработки "сверху вниз", она состоит
из независимых фаз, выполняемых последовательно, и подвержена частому обзору.
Краткое описание фаз каскадной модели
Приведенная ниже характеристика представляет собой краткое описание каждой
фазы каскадной модели (включая фазы интеграции):
■ исследование концепции — происходит исследование требований на системном
уровне с целью определения возможности реализации концепции;
■ процесс системного распределения — может быть пропущен для систем по
разработке исключительно ПО. Для систем, в которых необходима разработка как
аппаратного, так и программного обеспечения, требуемые функции применяются
к ПО и оборудованию в соответствии с общей архитектурой системы;
■ процесс определения требований — определяются программные требования
для информационной предметной области системы, предназначение, линии
поведения, производительность и интерфейсы. (В случае необходимости в процесс
также включено функциональное распределение системных требований к
аппаратному и программному обеспечению.);
■ процесс разработки проекта — разрабатывается и формулируется логически
последовательная техническая характеристика программной системы, включая
структуры данных, архитектуру ПО, интерфейсные представления и
процессуальную (алгоритмическую) детализацию;
■ процесс реализации — в результате его выполнения эскизное описание ПО
превращается в полноценный программный продукт. При этом создается исходный
код, база данных и документация, которые лежат в основе физического
преобразования проекта. Если программный продукт представляет собой
приобретенный пакет прикладных программ, основными действиями по его реализации
будут являться установка и тестирование пакета программ. Если программный
продукт разрабатывается на заказ, основными действиями являются
программирование и код-тестирование;
■ процесс установки — включает установку ПО, его проверку и официальную
приемку заказчиком для операционной среды;
■ процесс эксплуатации и поддержки — подразумевает запуск пользователем
системы и текущее обеспечение, включая предоставление технической
помощи, обсуждение возникших вопросов с пользователем, регистрацию запросов

138 Глава 4
пользователя на модернизацию и внесение изменений, а также корректирование
или устранение ошибок;
■ процесс сопровождения— связан с разрешением программных ошибок,
неисправностей, сбоев, модернизацией и внесением изменений, генерируемых
процессом поддержки. Состоит из итераций разработки и предполагает обратную
связь по предоставлению информации об аномалиях;
• процесс вывода из эксплуатации — вывод существующей системы из ее активного
использования либо путем прекращения ее работы, либо благодаря ее замене
новой системой или модернизированной версией существующей системы;
■ интегральные задачи — включают начало работы над проектом, мониторинг
проекта и его управление, управление качеством, верификацию и аттестацию,
менеджмент конфигурации, разработку документации и профессиональную
подготовку на протяжении всего жизненного цикла.
Преимущества каскадной модели
Нетрудно заметить, что каскадная модель имеет множество преимуществ, если ее
использовать в проекте, для которого она достаточно приемлема. Ниже перечислены
эти преимущества:
■ модель хорошо известна потребителям, не имеющим отношения к разработке и
эксплуатации программ, и конечным пользователям (она часто используется другими
организациями для отслеживания проектов, не связанных с разработкой ПО);
■ она упорядоченно справляется со сложностями и хорошо срабатывает для тех
проектов, которые достаточно понятны, но все же трудно разрешимы;
■ она весьма доступна для понимания, так как преследуется простая цель —
выполнить необходимые действия;
■ она проста и удобна в применении, так как процесс разработки выполняется поэтапно;
■ ее структурой может руководствоваться даже слабо подготовленный в
техническом плане или неопытный персонал;
■ она отличается стабильностью требований;
■ она представляет собой шаблон, в который можно поместить методы для
выполнения анализа, проектирования, кодирования, тестирования и обеспечения;
■ она хорошо срабатывает тогда, когда требования к качеству доминируют над
требованиями к затратам и графику выполнения проекта;
■ она способствует осуществлению строгого контроля менеджмента проекта;
■ при правильном использовании модели дефекты можно обнаружить на более
ранних этапах, когда их устранение еще не требует относительно больших затрат;
■ она облегчает работу менеджеру проекта по составлению плана и комплектации
команды разработчиков;
■ она позволяет участникам проекта, завершившим действия на выполняемой ими
фазе, принять участие в реализации других проектов;
■ она определяет процедуры по контролю за качеством. Каждые полученные
данные подвергаются обзору. Такая процедура используется командой разработчиков
для определения качества системы;

Выбор жизненного цикла разработки ПО 139
■ стадии модели довольно хорошо определены и понятны;
■ ход выполнения проекта легко проследить с помощью использования временной
шкалы (или диаграммы Гантта), поскольку момент завершения каждой фазы
используется в качестве стадии.
Недостатки каскадной модели
Но при использовании каскадной модели для проекта, который трудно назвать
подходящим для нее, проявляются следующими недостатки:
■ в основе модели лежит последовательная линейная структура, в результате чего
каждая попытка вернуться на одну или две фазы назад, чтобы исправить какую-
либо проблему или недостаток, приведет к значительному увеличению затрат и
сбою в графике;
■ она не может предотвратить возникновение итераций между фазами, которые так
часто встречаются при разработке ПО, поскольку сама модель создается согласно
стандартному циклу аппаратного инжиниринга;
■ она пе отображает основное свойство разработки ПО, направленное на
разрешение задач. Отдельные фазы строго связаны с определенными действиями, что
отличается от реальной работы персонала или коллективов;
■ она может создать ошибочное впечатление о работе над проектом. Выражение
типа 5 процентов выполнено" — не несет никакого смысла и не является
показателем для менеджера проекта;
■ интеграция всех полученных результатов происходит внезапно в завершающей
стадии работы модели. В результате такого единичного прохода через весь
процесс, связанные с интегрированием проблемы, как правило, дают о себе знать
слишком поздно. Следовательно, проявятся не обнаруженные ранее ошибки или
конструктивные недостатки, повысить степень риска при небольшом задаче
времени на восстановление продукта;
■ у клиента едва ли есть возможность ознакомиться с системой заранее, это
происходит лишь в самом конце жизненного цикла. Клиент не имеет возможности
воспользоваться доступными промежуточными результатами, и отзывы
пользователей нельзя передать обратно разработчикам. Поскольку готовый продукт не
доступен вплоть до окончания процесса, пользователь принимает участие в процессе
разработки только в самом начале — при сборе требований, и в конце — во время
приемочных испытаний;
■ пользователи не могут убедиться в качестве разработанного продукта до
окончания всего процесса разработки. Они не имеют возможности оценить качество,
если нельзя увидеть готовый продукт разработки;
■ у пользователя нет возможности постепенно привыкнуть к системе. Процесс
обучения происходит в конце жизненного цикла, когда ПО уже запущено в эксплуатацию;
■ проект можно выполнить, применив упорядоченную каскадную модель, и
привести его в соответствие с письменными требованиями, что, однако, не гарантирует
его запуска в эксплуатацию;
■ каждая фаза является предпосылкой для выполнения последующих действий, что
превращает такой метод в рискованный выбор для систем, не имеющих аналогов,
так как он не поддается гибкому моделированию;

140 Глава 4
■ для каждой фазы создаются результативные данные, которые по его завершению
считаются замороженными. Это означает, что они не должны изменяться на
следующих этапах жизненного цикла продукта. Если элемент результативных данных
какого-либо этапа изменяется (что встречается весьма часто), на проект окажет
негативное влияние изменение графика, поскольку ни модель, ни план не были
рассчитаны на внесение и разрешение изменения на более поздних этапах
жизненного цикла;
■ все требования должны быть известны в начале жизненного цикла, но клиенты
редко могут сформулировать все четко заданные требования на этот момент
разработки. Модель не рассчитана на динамические изменения в требованиях на
протяжении всего жизненного цикла, так как получаемые данные "замораживаются".
Использование модели может повлечь за собой значительные затраты, если
требования в недостаточной мере известны или подвержены динамическим
изменениям во время протекания жизненного цикла;
■ возникает необходимость в жестком управлении и контроле, поскольку в модели
не предусмотрена возможность модификации требований;
■ модель основана на документации, а значит, количество документов может быть
избыточным;
■ весь программный продукт разрабатывается за один раз. Нет возможности
разбить систему на части. В результате взятых разработчиками обязательств
разработать целую систему за один раз могут возникнуть проблемы с финансированием
проекта. Происходит распределение больших денежных средств, а сама модель
едва ли позволяет повторно распределить средства, не разрушив при этом проект
в процессе его выполнения;
■ отсутствует возможность учесть переделку и итерации за рамками проекта.
Область применения каскадной модели
Из-за недостатков каскадной модели ее применение необходимо ограничить
ситуациями, в которых требования и их реализация максимально четко определены и понятны.
Каскадная модель хорошо функционирует при ее применении в циклах
разработки программного продукта, в которых используется неизменяемое определение
продукта и вполне понятные технические методики.
Если компания имеет опыт построения определенного рода системы —
автоматизированного бухгалтерского учета, начисления зарплаты, ревизии, компиляции,
производства, — тогда в проекте, ориентированном на построение еще одного продукта
такого же типа, возможно, даже основанного на существующих разработках, можно
эффективно использовать каскадную модель. Другим примером надлежащего
применения модели может служить создание и выпуск новой версии уже существующего
продукта, если вносимые изменения вполне определены и управляемы. Перенос уже
существующего продукта на новую платформу часто приводят в качестве идеального
примера использования каскадной модели в проекте.
При всей справедливости критики этой модели все же следует признать, что
модифицированная версия каскадной модели является в значительной степени менее
жесткой, чем ее первоначальная форма. Здесь включаются итерации между фазами,
параллельные фазы и менеджмент изменений. Обратные стрелки предполагают
возможность существования итераций между действиями в рамках фаз. Чтобы отобразить

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

142 Глава 4
Фазы V-образной модели
Ниже подано краткое описание каждой фазы V-обраэной модели, начиная от
планирования проекта и требований вплоть до приемочных испытаний:
■ планирования проекта и требований— определяются системные требования, а
также то, каким образом будут распределены ресурсы организации с целью их
соответствия поставленным требованиям. (В случае необходимости на этой фазе
выполняется определение функций для аппаратного и программного обеспечения);
■ анализ требований к продукту и его спецификации — анализ существующей на
данный момент проблемы с ПО, завершается полной спецификацией ожидаемой
внешней линии поведения создаваемой программной системы;
■ архитектура или проектирование на высшем уровне — определяет, каким
образом функции ПО должны применяться при реализации проекта;
■ детализированная разработка проекта — определяет и документально
обосновывает алгоритмы для каждого компонента, который был определен на фазе
построения архитектуры. Эти алгоритмы в последствии будут преобразованы в код;
■ разработка программного кода— выполняется преобразование алгоритмов, оп-
ределершых на этапе детализованного проектирования, в готовое ПО;
■ модульное тестирование — выполняется проверка каждого закодированного
модуля на наличие ошибок;
■ интеграция и тестирование — установка взаимосвязей между группами ранее
поэлементно испытанных модулей с целью подтверждение того, что эти группы
работают также хорошо, как и модули, испытанные независимо друг от друга на
этапе поэлементного тестирования;
■ системное и приемочное тестирование — вьтолняется проверка функционирования
программной системы в целом (полностью интегрированная система), после
помещения в ее аппаратную среду в соответствии со спецификацией требований к ПО.
■ производство, эксплуатация и сопровождение — ПО запускается в
производство. На этой фазе предусмотрены также модернизация и внесение поправок;
■ приемочные испытания (на рис. не показаны) — позволяет пользователю
протестировать функциональные возможности системы на соответствие исходным
требованиям. После окончательного тестирования ПО и окружающее его аппаратное
обеспечение становятся рабочими. После этого обеспечивается сопровождение системы.
Преимущества V-образной модели
При использовании V-образной модели при разработке проекта, для которого она
в достаточной мере подходит, обеспечивается несколько преимуществ:
■ в модели особое значение придается планированию, направленному на верификацию
и аттестацию разрабатываемого продукта на ранних стадиях его разработки. Фаза
модульного тестирования подтверждает правильность детализованного проектирования.
Фазы интеграции и тестирования реализуют архитектурное проектирование или
проектирование на высшем уровне. Фаза тестирования системы подтверждает
правильность выполнения этапа требований к продукту и его спецификации;
■ в модели предусмотрены аттестация и верификация всех внешних и внутренних
полученных данных, а не только самого программного продукта;

Выбор жизненного цикла разработки ПО 143
■ и V-образной модели определение требований выполняется перед разработкой
проекта системы, а проектирование ПО — перед разработкой компонентов;
■ модель определяет продукты, которые должны быть получены в результате
процесса разработки, причем каждые полученные данные должны подвергаться
тестированию;
■ благодаря модели менеджеры проекта может отслеживать ход процесса
разработки, так как в данном случае вполне возможно воспользоваться временной шкалой,
а завершение каждой фазы является контрольной точкой;
■ модель проста в использовании (относительно проекта, для которого она является
приемлемой).
Недостатки V-образной модели
При использовании V-обраэной модели в работе над проектом, для которого она не
является в достаточной степени приемлемой, становятся очевидными ее недостатки:
■ с ее помощью непросто справиться с параллельными событиями;
■ в ней не учтены итерации между фазами;
■ в модели не предусмотрено внесение требования динамических изменений на
разных этапах жизненного цикла;
■ тестирование требований в жизненном цикле происходит слишком поздно,
вследствие чего невозможно внести изменения, не повлияв при этом на график
выполнения проекта;
■ в модель не входят действия, направленные на анализ рисков.
Графически модель зачастую изображается (как показано на рис. 4.10) без
указания интегральных задач. Этот вопрос достаточно легко решается, он здесь
упоминается только для того, чтобы напомнить читателю о том, что интегральные задачи
имеют место при использовании всех моделей жизненного цикла.
С целью преодоления этих недостатков V-обраэную модель можно
модифицировать, включив в нее итерационные циклы, предназначенные для разрешения
изменений в требованиях за рамками фазы анализа.
Область применения V-образной модели
Подобно своей предшественнице, каскадной модели, V-образная модель лучше
всего срабатывает тогда, когда вся информация о требованиях доступна заранее.
Общераспространенная модификация V-образной модели, направленная на
преодоление ее недостатков, включает в себя внесение итерационных циклов для
разрешения изменения в требованиях за рамками фазы анализа.
Использование модели эффективно в том случае, когда доступными являются
информация о методе реализации решения и технология, а персонал владеет
необходимыми умениями и опытом в работе с данной технологией.
V-образная модель — это отличный выбор для систем, в которых требуется
высокая надежность, таких как прикладные программы для наблюдения за пациентами в
клиниках, а также встроенное ПО для устройств управления аварийными подушками
безопасности в автомобилях.

144 Глава 4
Модель прототипирования жизненного цикла
разработки ПО
Ставшее классикой произведение Фреда Брукса (Fred Brook) под названием
"Легендарный человек-месяц" (The Mythical Man-Month) сегодня столь же
актуально, как и в 1975 году. Технологии радикально изменили мир, но многие недостатки
менеджмента программных проектов по прежнему те же. Десятки лет тому назад
Брукс сказал:
"В большинстве проектов первая построенная система едва ли пригодна к
употреблению. Она может быть слишком медленной, слишком объемной, неудобной в
использовании или обладать всеми тремя перечисленными недостатками. Нет другого
выбора, кроме как начать с самого начала, приложив все усилия, и построить
модернизированную версию, в которой решались бы все три проблемы...
В случае, когда в проекте используется новая системная концепция или новая
технология, разработчик вынужден построить систему, которой впоследствии не
воспользуется, поскольку даже при наилучшем планировании невозможно предвидеть
достижение нужного результата.
Следовательно, вопрос менеджмента заключается не в том, создавать или нет
экспериментальную систему, которой затем не воспользуются. Вы в любом случае так и
сделаете. Единственный вопрос в том, нужно ли планировать создание продукта
одноразового использования заранее или обещать поставить его заказчикам..."'
Именно эта концепция построения экспериментальной, или прототипной
системы привела к возникновению "структурной", "эволюционной" модели быстрого
прототипирования (RAD), и спиральной модели. В своей боле поздней, в равной
степени полной плодотворных идей работе под названием "No Silver Bullet, the
Essence and Accidents of Programming" Брукс считает, что большинство ошибок,
возникающих при разработке ПО, все же связаны с неправильным пониманием
концепции системы, а не с синтаксисом или логикой. Разработка ПО всегда будет
трудной задачей, и мы никогда не найдем чудодейственную панацею или
"серебряную пулю". Он подчеркивает положительный момент в применении методов
быстрого прототипирования:
"Самой тяжелой составляющей процесса построения программной системы
является принятие однозначного решения о том, что именно необходимо построить. Ни
одна из остальных составляющих работы над концепцией не представляет собой
такую трудность, как определение детальных технических требований, включая все
аспекты соприкосновения продукта с людьми, машинами и другими программными
системами. Ни одна другая составляющая работы в такой степени не наносит ущерб
полученной в результате системе, если она выполнена неправильно. Именно эту
составляющую процесса разработки тяжелее всего исправить на более поздних этапах.
Следовательно, самая важная функция, которую выполняет разработчик
клиентских программ, заключается в итеративном извлечении и уточнении требований к
продукту. Ведь на самом деле клиент не имеет представления о том, что именно он
хочет получить.
На данный момент времени одной из самых обещающих среди технологических
попыток, сосредоточенных на сущности, а не на трудностях решения проблемы раз-
Brooks Fred. The Mythical Man-Month: Essays on Software Engineering, 1-е издание. Reading,
MA: Addison-Wesley, С 116, 1975.

Выбор жизненного цикла разработки ПО 145
работки ПО, является разработка методов и средств для ускоренного прототипиро-
вания систем как составляющей итеративной спецификации требований".
Уотте Хэмфри (Watts Humphrey), который известен как вдохновитель создания
модели СММ, разработанной Институтом SEI, поддерживает Брукса в его подходе к
важности требований и их разработки:
"В большинстве систем заключен основной принцип, который включает в себя
больше, чем незначительное эволюционное изменение. Система может изменить само
эксплуатационное окружение. Поскольку пользователи могут рассуждать о том или
ином явлении только в рамках известного им окружения, требования к таким системам
всегда формулируются в рамках текущего окружения. Следовательно, эти требования
непременно будут неполными, неточными и обманчивыми. Главной задачей для
системного разработчика является изобретение процесса разработки, с помощью которого
можно будет обнаружить, определить и разработать реальные требования. Этого
можно достичь только при максимальном включении пользователя в процесс разработки и
зачастую с помощью периодического тестирования прототипов или версий, получен-
Е1ых на ранних этапах разработки. Оказывается, что такие процессы всегда занимают
больше времени, но неизменно в конце приводят к разработке лучшей системы намного
быстрее, чем при использовании какой-либо другой стратегии".
Определения прототипирования
Согласно Джону Коннэллу (Connell) и Линде Шафер (Shafer), эволюционным
ускоренным прототипом является "легко поддающаяся модификации и расширению рабочая
модель предполагаемой системы, не обязательно представляющая собой все свойства
системы, благодаря которой пользователи данного приложения получают физическое
представление о ключевых частях системы до ее непосредственной реализации; это — легко
создаваемая, без труда поддающаяся модификации, максимально расширяемая, частично
заданная рабочая модель основных аспектов предполагаемой системы" .
Бернард Боар (Bernard Boar) определил прототип как "метод, предназначенный
для определения требований, при котором потребности пользователя извлекаются,
представляются и разрабатываются посредством построения рабочей модели
конечной системы — быстро и в требуемом контексте" '.
Описание структурной модели эволюционного
прототипирования
Прототипирование — это процесс построения рабочей модели системы. Протитип —
это эквивалент экспериментальной модели или "макета" в мире аппаратного обеспечения.
Выполнение эволюционных программ происходит в рамках контекста плана,
направленного на достижение предельно высокой производительности. Этот метод
также предполагает, что разработка инкрементов программы очевидна для
пользователя, который принимает участие в течение всего процесса разработки.
Brooks Fred. "No Silver Bullet — Essence and Accidents of Software Engineering." Information
Processing, North-Holland: Elsevier Science Publishers, A986).
" См. пункт 11
Conell John and Linda Shafer. Structured Rapid Prototyping: An Evolutionary Approach to Software
Development, 1-е издание. Englewood Cliffs, NJ: Prentice Hall, C. 23, 1989.
Board Bernard. Application Prototyping: A Requirements Definition Strategy for the 80's, 1-е
издание. New York, NY: John Wiley & Sons, С 7, 1984

146 Глава 4
"Быстрая" частичная реализация системы создается перед этапом определения
требований или на его протяжении. Конечные пользователи системы используют
м-кореннын прототип, а затем путем обратной связи сообщают о своем достижении
команде, работающей над проектом, для дальнейшего уточнения требований к сис-
1 емс. 11роцесс уточнения продолжается до тех пор, пока пользователь не получит
то, что ему требуется. После завершения процесса определения требований путем
разработки ускоренных прототипов, получают детальный проект системы, а
ускоренный прототип регулируется при использовании кода или внешних утилит, в ре-
i\ и. тате чего получают конечный рабочий продукт. В идеале можно вывести, при
чем без излишних затрат, модель прототипирования высокого качества, не
экономя па документации, анализе, проектировании, тестировании и т.д. Следовательно,
она получила название "структурной модели быстрого прототипирования", как
показано на рис. 4.П.
Рис. 4.11. Структурная эволюционная модель быстрого прототипирования
Начало жизненного цикла разработки помещено в центре эллипса. Пользователь и
программист разрабатывают предварительный план проекта, руководствуясь при этом
предварительными требованиями. Используя методы ускоренного анализа,
пользователь и программист совместно работают над определением требований и
спецификации для важнейших частей воображаемой системы. Планирование проекта— это пер
кос действие на этапе быстрого анализа, с помощью которого получают документ, опи-
■ ьшающпн и общих чертах примерные графики и результативные данные.

Выбор жизненного цикла разработки ПО 147
Таким образом, создается план проекта, а затем выполняется быстрый анализ,
после чего проектируется база данных, пользовательский интерфейс и разработка
функций. Второе действие — это быстрый анализ, на протяжении которого
предварительные опросы пользователей используются для разработки умышленно
неполной высокоуровневой модели системы на уровне документации. В результате
выполнения этой задачи получают документ, содержащий частичную спецификацию
требований, который используется для построения исходного прототипа, создаваемого на
последующих трех этапах. Дизайнер конструирует модель (используя для этого
инструментальные средства), то есть частичное представление системы, которое
включает в себя только те базовые свойства, которые необходимы для удовлетворения
требований заказчика. Затем начинается итерационный цикл быстрого прототипирова-
Е1ия. Разработчик проекта демонстрирует прототип, а пользователь оценивает его
функционирование. После этого определяются проблемы, над устранением которых
совместно работают пользователь и дизайнер. Этот процесс продолжается до тех
пор, пока пользователь не будет удовлетворен тем, каким образом система
отображает поставленные к ней требования. Команда разработчиков проекта продолжает
выполнять этот процесс до тех пор, пока пользователь не согласится, что быстрый
прототип в точности отображает системные требования. Создание базы данных
представляет собой первую из этих двух фаз. После создания исходной базы данных
можно начать разработку меню, после чего следует разработка функций, то есть
создается рабочая модель. Затем модель демонстрируют пользователю с целью
получения предложений по ее усовершенствованию, которые объединяются в
последовательные итерации до тех пор, пока рабочая модель не окажется удовлетворительной.
Затем получают официальное одобрение пользователем функциональных
возможностей прототипа. После этого создается документ предварительного проекта системы.
Основным компонентом является фаза итерации прототипа, на протяжении
которого при использовании сценариев, предоставленных рабочей моделью,
пользователь может разыграть роли и потребовать, чтобы последовательное уточнение
модели продолжалось до тех пор, пока не будут удовлетворены все функциональных
требования. Получив одобрение пользователя, быстрый прототип преобразуют
детальный проект, и систему настраивают на производственное использование.
Именно на этом этапе настройки ускоренный прототип становится полностью
действующей системой, которая заменяет собой частичную систему, полученную в
итерационном цикле прототипирования.
Детализированный проект можно также получить на основе прототипов. В этом
случае настройка прототипа выполняется при использовании кода или внешних
утилит. Дизайнер использует утвержденные требования в качестве основы для
проектирования производственного ПО.
При разработке производственной версии программы, может возникнуть
необходимость в дополнительной работе. Может понадобиться более высокий уровень
функциональных возможностей, различные системные ресурсы, необходимых для
обеспечения полной рабочей нагрузки, или ограничения во времени. После этого
следуют тестирование в предельных режимах, определение измерительных
критериев и настройка, а затем, как обычно, функциональное сопровождение.
Заключительная фаза представляет собой функционирование и сопровождение,
которые отображают действия, направленные на перемещение системы в стадию
производственного процесса.

148 Глава 4
Не существует "правильного" способа использования метода прототипирования.
Полученный результат может не пригодиться, может быть использован в качестве
основания для последующей модернизации или превращен в продукт,
используемого процесса и желаемого качества в зависимости от исходных целей. Понятно, что
при использовании эволюционного прототипирования снижаются затраты и
оптимизируется соблюдение графиков, поскольку каждый из его компонентов находит
снос применение.
Преимущества структурной эволюционной модели быстрого
прототипирования
При использовании структурной эволюционной модели быстрого
прототипирования для приемлемого проекта проявляются следующие преимущества:
■ коЕ1ечный пользователь может "увиДеть" системные требования в процессе их
сбора командой разработчиков; таким образом, взаимодействие заказчика с
системой начинается на раннем этапе разработки;
■ исходя из реакции заказчиков на демонстрации разрабатываемого продукта,
разработчики получают сведения об одном или нескольких аспектах поведения системы,
благодаря чему сводится к минимуму количество неточностей в требованиях;
■ снижается возможность возникновения путаницы, искажения информации или
недоразумений при определении системных требований, что несомненно
приводит к созданию более качественного конечного продукта;
■ в процесс разработки можно внести новые или неожиданные требования
пользователя, что порой необходимо, так как реальность может отличаться от
концептуальной модели реальности;
■ модель представляет собой формальную спецификацию, воплощенную в
рабочую модель.
■ модель позволяет выполнять гибкое проектирование и разработку, включая
несколько итераций на всех фазах жизненного цикла;
■ при использование модели образуются постоянные, видимые признаки прогресса
в выполнении проекта, благодаря чему заказчики чувствуют себя уверенно;
■ возможность возникновения разногласий при общении заказчиков с
разработчиками минимизирована;
■ ожидаемое качество продукта определяется при активном участии пользователя в
процесс на ранних фазах разработки;
■ возможность наблюдать ту или иную функцию в действии пробуждает очевидную
необходимость в разработке функциональных дополнительных возможностей;
■ благодаря меньшему объему доработок уменьшаются затраты на разработку;
■ благодаря том}' что проблема выявляется до привлечения дополнительных
ресурсов сокращаются общие затраты;
■ обеспечивается управление рисками;
■ документация сконцентрирована на конечном продукте, а не на его разработке;
■ принимая участие в процессе разработки на протяжении всего жизненного цикла,
пользователи в большей степени будут довольны полученными результатами.

Выбор жизненного цикла разработки ПО 149
Недостатки структурной эволюционной модели быстрого
прототипирования:
■ модель может быть отклонена из-за создавшейся среди консерваторов репутации
о ней как о "разработанном на скорую руку" методе;
■ разработанные "на скорую руку" прототипы, в отличие от эволюционных уско-
регшых прототипов, страдают от неадекватной или недостающей документации;
■ если цели прототипирования не согласованы заранее, процесс может
превратиться в упражнение по созданию хакерского кода;
■ с учетом создания рабочего прототипа, качеству всего ПО или долгосрочной
эксплуатационной надежности может быть уделено недостаточно внимания.
■ иногда в результате использования модели получают систему с низкой рабочей
характеристикой, особенно если в процессе ее выполнения пропускается этап подгонки;
■ при использовании модели решение трудных проблем может отодвигаться на
будущее. В результате это приводит к тому, что последующие полученные продукты
могут не оправдать надежды которые возлагались на прототип;
■ если пользователи не могут участвовать в проекте на итерационной фазе
быстрого прототипирования жизненного цикла, на конечном продукте могут
отразиться неблагоприятные воздействия, включая проблемы, связанные с его
качественной характеристикой;
■ на итерационном этапе прототипирования быстрый прототип представляет
собой частичную систему. Если выполнение проекта завершается досрочно, у ко-
нечного пользователя останется только лишь частичная система;
■ несовпадение представлений заказчика и разработчиков об использовании
прототипа может привести к созданию другого пользовательского интерфейса;
■ заказчик может предпочесть получить прототип, вместо того, чтобы ждать
появления полной, хорошо продуманной версии;
■ если язык или среда прототипирования не сочетаются с производственным
языком или окружением, всесторонняя реализация продукционной системы
может быть задержана;
■ прототинировагше вызывает зависимость и может продолжаться слишком долго.
Нетренированные разработчики могут попасть в так называемый цикл
"кодирование — устранение ошибок" (code-and-fix cycle), что приводит к
дорогостоящим незапланированным итерациям прототипирования;
■ разработчики и пользователи не всегда понимают, что когда прототип
превращается в конечный продукт, все еще существует необходимость в традиционной
документации. Если она отсутствует, модифицировать модель на более поздних
этапах может оказаться более дорогостоящим занятием, чем просто не
воспользоваться созданным прототипом;
■ когда заказчики, удовлетворенные прототипом, требуют его немедленной поставки,
перед менеджером программного проекта возникает соблазн пойти им навстречу;
■ на заказчиков могут неблагоприятно повлиять сведения об отличии между
прототипом и полностью разработанной системой, готовой к реализации;
■ на заказчиков может оказать негативное влияние тот факт, что они не
располагают информацией о точном количестве итераций, которые будут необходимы;

150 Глава 4
* m;i разработку системы может быть потрачено слишком много времени, так как
итерационный процесс демонстрации прототипа и его пересмотр могут продолжаться
бес конечно бе:» надлежащего управления процессом. У пользователей может
возникнуть стремление пополнять список элементов, предназначенных для прототи-
пироилппя, до тех пор, пока проект не достигнет масштаба, значительно
превышающей! рамки, определенные анализом осуществимости проектного решения;
ш при выборе инструментальных средств прототипирования (операционные
системы, языки н малопродуктивные алгоритмы) разработчики могут остановить свой
выбор на менее подходящем решении, только чтобы продемонстрировать свои
способности:
■ структурные методы не используются, чтобы не помешать выполнению анализа. При
прототннпроваппп необходимо провести "реальный" анализ требований, осуществить
проектирование и обратить внимание на качество с целью создания программы,
допускающем"! сопровождение, точно так же, как и в любой другой модели жизненного
цикла (хотя па эти действия может понадобиться меньше времени и ресурсов).
Область применения структурной эволюционной модели
быстрого прототипирования
Менеджер проекта может быть уверен в необходимости применения структурной
>iu> iiomioiinoii модели быстрого прототипирования, если:
■ i рсбонапия не известны заранее;
■ требования не постоянны или могут быть неверно истолкованы или неудачно
сформулированы;
■ с. к, (\ е г уточнить требования;
■ с \ mi с i н\ ст потребность в разработке пользовательских интерфейсов;
* нужна проверка концепции;
■ осуществляются временные демонстрации;
■ нос троенное по принципу структурной модели, эволюционное быстрое прототи-
ппрованпе можно успешно использовать в больших системах, в которых
некоторые- модели подвергаются нрототипированию, а некоторые— разрабатываются
бочее традиционным образом;
■ выполняется новая, не имеющая аналогов разработка (в отличие от эксплуатации
продукта па уже существующей системе);
* требуется уменьшить неточности в определении требований: т.е. уменьшается
риск создания системы, которая не имеет никакой ценности для заказчика;
* требования подвержены быстрым изменениям, когда заказчик неохотно соглаша-
ei'c я на фпке провапный набор требований или если о прикладной программе
отсутствует четкое представление;
* разработчики не уверены в том, какую оптимальную архитектуру или алгоритмы
с ндуст применять;
■ аи орнтмы пли системные интерфейсы усложнены;
* фебуегся продемонстрировать техническую осуществимость, когда технический
риск высок;

Выбор жизненного цикла разработки ПО 151
■ задействованы высокотехнологические системы с интенсивным применением
ПО, где можно лишь обобщенно, но не точно сформулировать требования,
лежащие за пределами главной характеристики;
■ разрабатывается ПО, особенно в случае программ, когда проявляется средняя и
высокая степень риска;
■ осуществляется применение в комбинации с каскадной моделью: на начальном
этапе проекта используется прототипирование, а на последнем — фазы каскадной
модели с целью обеспечения функциональной эффективности системы и качества;
■ прототипирование всегда следует использовать вместе с элементами анализа и
проектирования, применяемыми при объектно-ориентированной разработке.
Быстрое прототипирование особенно хорошо подходит для разработки
интенсивно используемых систем пользовательского интерфейса, таких как индикаторные
панели для контрольных приборов, интерактивные системы, новые в своем роде
продукты, а также системы обеспечения принятия решений, среди которых можно
назвать подачу команд, управление или медицинскую диагностику.
Модель быстрой разработки приложений жизненного
цикла разработки ПО
В 1980-х годах XX века в ответ на ограничивающий характер формальных методов,
таких как каскадная модель, компания IBM начала использовать метод быстрой
разработки приложений (Rapid Application Development, RAD). В книге Джеймса
Мартина под названием Rapid Application Development этот метод был представлен вниманию
разработчиков ПО. Благодаря методу RAD пользователь задействован на всех фазах
жизненного цикла разработки проекта—не только при определении требований, но
и при проектировании, разработке, тестировании, а также конечной поставке
программного продукта. Участие пользователя в процессе разработки становится столь
активным благодаря использованию средства разработки или среды, которое
позволяет дать оценку продукту на всех стадиях его разработки. Это обеспечивается
наличием средств разработки графического пользовательского интерфейса и
кодогенераторов. Таким инструментальным средствам, как Oracle Designer/2000, Java Jbuilder 3,
Linux, Visual C++, Visual Basic 6, SAS, и другим приложениям посвящено много книг,
в которых описывается их использование в качестве средств для быстрой
разработки приложений.
Характерной чертой RAD является короткое время перехода от определения
требований до создания полной системы. Метод основывается на
последовательности итераций эволюционной системы или прототипов, критический анализ
которых обсуждается с заказчиком. В процессе такого анализа формируются требования
к продукту. Разработка каждого интегрированного продукта ограничивается четко
определенным периодом времени, который, как правило, составляет 60 дней и
называется временным блоком.
Факторы, позволяющие создать систему за 60 дней, причем без ущерба качеству,
включают в себя использование мощных инструментальных средств разработки,
высокий уровень фактора повторного использования, а также осмысленные и
выделенные ресурсы.
Решающее ролевое участие конечного пользователя заключается в
перемещении процесса работы от программирования и тестирования к планированию и

152 Глава 4
проектированию. Пользователям приходится справляться с большим объемом
работы в начале жизненного цикла, но в награду они получают систему, построенную
лл более короткий промежуток времени.
Краткое описание фаз модели RAD
Модель RAD, показанная на рис. 4.12, демонстрирует этапы процесса разработки
жизненного цикла и отображает участие пользователя на всех этапах (кривая линия)
этого процесса:
■ этап планирования требований — сбор требований выполняется при
использовании рабочего метода, называемого совместным планированием требований
(Joint requirements planning, JRP), который представляет собой структурный
анализ и обсуждение имеющихся коммерческих задач;
■ нользовательское описание — совместное проектирование приложения (Joint
application design, JAD) используется с целью привлечения пользователей; на этой
фазе проектирования системы, tie являющейся промышленной, работающая над
проектом команда зачастую использует автоматические инструментальные
средства, обеспечивающие сбор пользовательской информации;
■ фаза конструирования ("до полного завершения") — эта фаза объединяет в себе
детализированное проектирование, построение (кодирование и тестирование),
а также поставку программного продукта заказчику за определенное время. Сроки
выполнения этой фазы в значительной мере зависит от использования
генераторов кода, экранных генераторов и других типов производственных
инструментальных средств;
■ перевод на новую систему эксплуатации — эта фаза включает проведение
пользователями приемочных испытаний, установку системы и обучение пользователей.
Время »»
Рис. 4.12. Модель быстрой разработки приложений

Выбор жизненного цикла разработки ПО 153
Преимущества модели RAD
При использовании модели RAD относительно проекта, для которого она в
достаточной степени приемлема, проявляются следующие преимущества:
■ время цикла разработки для всего проекта можно сократить благодаря
использованию мощных инструментальных средств;
■ требуется меньшее количество специалистов, поскольку разработка системы
выполняется усилиями команды, осведомленной в предметной области;
■ существует возможность произвести быстрый изначальный просмотр продукта и т.д;
■ благодаря сокращенному времени цикла и усовершенствованной технологии, а
также меньшему количеству задействованных в процессе разработчиков
уменьшаются затраты;
■ благодаря принципу временного блока уменьшаются затраты и риск, связанный с
соблюдением графика;
■ модель обеспечивает эффективное использование имеющихся в наличии средств
и структур;
■ привлечение заказчика на постоянной основе сводит до минимума риск того, что
он не будет удовлетворен разработанным продуктом, кроме того, это гарантирует,
что система будет соответствовать коммерческим потребностям, а сам
программный продукт будет надежен в эксплуатации;
■ в состав каждого временного блока входит анализ, проектирование и внедрение
(фазы отделены от действий);
■ интеграции констант предотвращают возникновение проблем и способствуют
созданию обратной связи с потребителем;
■ основное внимание переносится с документации на код, причем при этом
справедлив принцип "получаете то, что видите" (What you see is what you get, WYSIWYG);
■ в модели используются следующие принципы и инструментальные средства
моделирования: деловое моделирование (методы передачи информации, место генерирования
информационных потоков, кем и куда направляется, каким образом обрабатывается);
моделирование данных (происходит идентификация объектов данных и атрибутов, а
также взаимосвязей); моделирование процесса (выполняется преобразование
объектов данных); генерирование приложения (методы четвертого поколения);
■ в модели повторно используются компоненты уже существующих программ.
Недостатки модели RAD
Если эта модель применяется для проекта, для которого она не подходит в полной
мере, могут сказываться следующие недостатки:
■ если пользователи не могут постоянно принимать участие в процессе разработки
на протяжении всего жизненного цикла, это может негативно сказаться на
конечном продукте;
■ при использовании этой модели необходимо достаточное количество
высококвалифицированных и хорошо обученных разработчиков, умеющих
воспользоваться выбранными инструментальными средствами разработки для ускорения
времени разработки;

154 Глава 4
■ возникает потребность в системе, которая может быть смоделирована
корректным образом;
■ использование модели может оказаться неудачным в случае, если отсутствуют
пригодные для повторного использования компоненты;
■ могут возникать затруднения при использовании модели совместно с наследст-
нснными системами и несколькими интерфейсами;
■ для реализации модели требуются разработчики и заказчики, которые готовы к
быстрому выполнению действий ввиду жестких временных ограничений;
■ при использовании модели "вслепую" на затраты и дату завершения работы над
проектом ограничения не накладываются;
■ команды, разрабатывающие коммерческие проекты с помощью модели RAD, могут
"затянуть" разработку программного продукта до такой степени, что его поставка
конечному пользователю будет под большим вопросом;
■ существует риск, что работа над проектом никогда не будет завершена, — в связи с
этим менеджер проекта должен сотрудничать как с командой разработчиков, так и
с заказчиком, что позволит избежать появления замкнутого цикла;
■ для обеспечения быстрой реакции на информацию, поступающую в результате
налаженной обратной связи с пользователем, необходим эффективный ускоренный
процесс разработки.
Область применения модели RAD
Менеджер проекта может быть уверен в том, что модель RAD подходит для
применения в конкретной ситуации в случае, если имеются в наличии некоторые из
прицеленных ниже условий-причин:
■ в системах, которые поддаются моделированию (основанных на использовании
компонентных объектов), а также в масштабируемых системах;
■ п системах, требования для которых в достаточной мере хорошо известны;
■ в случаях, когда конечный пользователь может принимать участие в процессе
разработки на протяжении всего жизненного цикла;
■ когда пользователи хотят принимать активное участие в использовании
автоматических инструментальных средств;
■ при выполнении проектов, разработка которых должна быть выполнена в
сокращенные сроки, как правило, не более, чем за 60 дней;
■ в системах, которые можно поместить во временной блок с целью обеспечения
функциональных возможностей на последовательной основе;
■ когда пригодные к повторному использованию части можно получить из
автоматических хранилищ программных продуктов;
■ в системах, которые предназначены для концептуальной проверки, являются
некритическими или имеют небольшой размер;
■ когда затраты и соблюдение графика не являются самым важным вопросом
(например при разработке внутренних инструментальных средств);
■ в системах, в которых не требуются достижение высокой производительности,
особенно достигаемая посредством использования настройки интерфейсов;

Выбор жизненного цикла разработки ПО 155
■ при невысокой степени технических рисков;
■ в информационных системах;
■ когда команде, работающей над проектом, знакома предметная область и она
обладает достаточными навыками в использовании средств разработки и имеет
высокую степень мотивации при выполнении данного проекта.
Инкрементная модель жизненного цикла
разработки ПО
Инкрементная разработка представляет собой процесс частичной реализации
леей системы и медленного наращивания функциональных возможностей или
эффективности. Этот подход позволяет уменьшить затраты, понесенные до момента
достижения уровня исходной производительности. С помощью этой модели
ускоряется процесс создания функционирующей системы. Этом)' способствует
применяемый принцип компоновки из стандартных блоков, благодаря которому
обеспечивается контроль над процессом разработки изменяющихся требований.
Инкрементная модель действует по принципу каскадной модели с перекрытиями,
благодаря чему функциональные возможности продукта, пригодные к эксплуатации,
формируется раньше. Для этого может понадобиться полный заранее
сформированный набор требований, которые выполняются в виде последовательных, небольших
по размеру проектов, либо выполнение проекта может начаться с формулирования
общих целей, которые затем уточняются и реализуются группами разработчиков.
Боэм описывает инкрементный метод как процесс объединения элементов
последовательной линейной модели и прототипирования и является сторонником
разработки ПО по принципу наращивания функциональных возможностей продукта.
Согласно его словам, подобное усовершенствование каскадной модели одинаково
эффективно при использовании как в случае чрезвычайно больших, так и небольших
проектов. Л теперь будет рассмотрен небольшой пример продукта, разработанного в
результате выполнения трех инкрементных этапов. Здесь на инкременте 1
определяются базовые алгоритмы и выходные данные, на инкременте 2 добавляются
некоторые ценные возможности производственного типа, такие как возможность занесения
в файл и выборки результатов предыдущих прогонов программы, а на инкременте .4
добавляются различные полезные свойства к пользовательскому интерфейсу, а также
к заранее определенным вычислительным свойствам системы.
Инкрементная модель описывает процесс, при выполнении которого
первостепенное внимание уделяется системным требованиям, а затем их реализации в группах,
разработчиков. Как правило, со временем инкременты уменьшаются и реализуют
каждый раз меньшее количество требований. Каждая последующая версия системы
добавляет к предыдущей определенные функциональные возможности до тех пор. пока
не будут реализованы все запланированные возможности. В этом случае можно
уменьшить затраты, контролировать влияние изменяющихся требований и ускорить
создание функциональной системы благодаря использованию метода компоновки из
стандартных блоков.
Предполагается, что на ранних этапах жизненного цикла (планирование, анализ и
разработка проекта) выполняется конструирование системы в целом. На этих этапах
определяются относящиеся к ним инкременты и функции. Каждый инкремтт затем
проходит через остальные фазы жизненного цикла: кодирование, тестирование и ноставку.

156 Глава 4
Сначала выполняется конструирование, тестирование и реализация набора
функций, формирующих основу продукта, или требований первостепенной важности,
играющих основную роль для успешного выполнения проекта либо снижающих степень
риска. Последующие итерации распространяются на ядро системы, постепенно
учхчшая ее функциональные возможности или рабочую характеристику. Добавление
функции осуществляется с помощью выполнения существенных инкрементов с целью
комплексного удовлетворения потребностей пользователя. Каждая дополнительная
функция аттестуется в соответствии с целым набором требований.
Линейная последовательность может быть распределена согласно
календарному графику, причем в результате выполнения каждой последовательности
моле г создаваться результативный инкремент программного продукта, как
изображено на рис. 4.13.
Этот тип разработки можно комбинировать с другими моделями. Зачастую его
обьеднняют со спиральной, V-образной, а также каскадной моделями, что позволяет
i нпзнть затраты и риски при разработке системы.
Выполнимость
системы
П
План и
требования имеющие
отношение к ПО
^
Ыолупьж» Зерифтация
тестирование программного
продукта
*-1
1 кодаро- jrcnnz:
1 ванне [
Ji . 1 Интег
Интеграция
Системное
тесгироеаше
±1

Эксплуатация и
сопровождение
Повторная
аттестация
>г±-
м[цд Верификация
тестирование программного
±1
Системнее
тестирование
Внедрение
И

Эксплуатация и
сопровождение
Повторная
аттестация
Mr
5
Инкремент 2
Верификация
;
Детализированная разра-
, ботка проекта
2.
Модульное
тестирование

Кодирование
Верификация
программного
продукта
b',!mvtff.,w
Системное
тестирование

Эксплуатация и
сопровождение
Повторная
аттестация
Рис. 4.13. Инкременгпная модель
Преимущества инкрементной модели
Применяя ннкрементную модель при разработке проекта, для которого она
подходит в достаточной мере, можно убедиться в следующих ее преимуществах:
* не требуется заранее тратить средства, необходимые для разработки всего
проекта, поскольку сначала выполняется разработка и реализация основной функции
или функции из группы высокого риска;
■ и результате выполнения каждого инкремента получается функциональный продукт;
■ уроки, полученные в результате выполнения каждой инкрементной поставки,
могут способствовать усовершенствованию последующих доставок; заказчик
располагает возможностью высказаться по поводу каждой разработанной вер-
i ни системы;

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

158 Глава 4
Недостатки инкрементной модели
При использовании этой модели относительно проекта, для которого она
подходит не в достаточной мере, проявляются следующие недостатки:
■ в модели не предусмотрены итерации в рамках каждого инкремента;
■ определение полной функциональной системы должно осуществляться в начале
жизненного цикла, чтобы обеспечить определение инкрементов;
■ поскольку создание некоторых модулей будет завершено значительно раньше
других, возникает необходимость в четко определенных интерфейсах;
■ формальный критический анализ и проверку намного труднее выполнить для
инкрементов, чем для системы в целом;
■ может возникнуть тенденция к оттягиванию решений трудных проблем на
будущее с целью продемонстрировать руководству успех, достигнутый на ранних
этапах разработки;
■ заказчик должен осознавать, что общие затраты на выполнение проекта не будут
снижены;
■ использование на этапе анализа общих целей, вместо полностью
сформулированных требований, может оказаться неудобным для руководства;
■ для модели необходимы хорошее планирование и проектирование: руководство
должно заботиться о распределении работы, а технический персонал должен
соблюдать субординацию в отношениях между сотрудниками.
Область применения инкрементной модели
Менеджер проекта может быть уверен в целесообразности применения модели,
если для этого имеются следующие причины:
■ если большинство требований можно сформулировать заранее, но их появление
ожидается через определенный период времени;
■ если рыночное окно слишком "узкое" и существует потребность быстро поставить
на рынок продукт, имеющий функциональные базовые свойства;
■ для проектов, на выполнение которых предусмотрен большой период времени
разработки, как правило, один год;
■ при равномерном распределении свойств различной степени важности;
■ при разработке программ, связанных с низкой или средней степенью риска;
■ при выполнении проекта с применением новой технологии, что позволяет
пользователю адаптироваться к системе путем выполнения более мелких инкремент-
ных шагов, без резкого перехода к применению основного нового продукта;
■ когда при рассмотрении риска, финансирования, графика выполнения проекта,
размера программы, ее сложности или необходимости в реализации на ранних
фазах оказывается, что самым оптимальным вариантом является применение
принципа нофазовой разработки;
■ когда однопроходная разработка системы связана с большой степенью риска;
■ когда результативные данные получаются через регулярные интервалы времени.

Выбор жизненного цикла разработки ПО 159
Спиральная модель жизненного цикла разработки ПО
В спиральной модели, впервые представленной доктором Барри Боэмом и
опубликованной в журнале IEEE Computers 1988 году, учтены указанные выше недостатки,
вызванные использованием каскадной модели. Эта модель не способна адекватно разрешать
проблемы внесения изменений. В ней предполагается относительно стандартная и
упорядоченная последовательность стадий разработки, но в ней не предусмотрено использование
таких методов, как ускоренное прототипирование или языки высокого уровня.
Спиральная модель воплощает в себе преимущества каскадной модели. При этом в
нее также включены анализ рисков, управление ими, а также процессы поддержки и
менеджмента. Здесь также предусмотрена разработка программного продукта при
использовании метода прототипирования или быстрой разработки приложений
посредством применения языков программирования и средств разработки четвертого
поколения (и выше).
Модель отображает базовую концепцию, которая заключается в том, что каждый
цикл представляет собой набор операций, которому соответствует такое же количество
стадий, как и в модели каскадного процесса. Причем принимается во внимание каждая
составляющая часть продукта, и каждый уровень сложности, начиная с общей
формулировки потребностей и заканчивая кодированием каждой отдельной программы.
Как показано на рис. 4.14, в каждый квадрант модели входят целевые и
вспомогательные действия. Ниже перечислены эти квадранты.
Определение целей,
альтернатив и ограничений
Оценка альтернатив,
идентификация
и разрешение рисков
Планирование следующей фазы
Разработка продукта следующего уровня
Рис. 4.14. Спиральная модель

160 Глава 4
■ определение целей, альтернативных вариантов и ограничений. Выполняется
определение целей, таких как рабочая характеристика, выполняемые функции,
возможность внесения изменений, решающих факторов достижения успеха и
аппаратного/программного интерфейса. Определяются альтернативные способы
реализации этой части продукта (конструирование, повторное использование,
покупка, субдоговор, и т.п.); определяются ограничения, налагаемые на
применение альтернативных вариантов (затраты, график выполнения, интерфейс,
ограничения, относящиеся к среде и др.). Создается документация, подтверждающая
риски, связанные с недостатком опыта в данной сфере, применением новой
технологии, жесткими графиками, плохо организованными процессами и т.д;
■ оценка альтернативных вариантов, идентификация и разрешение рисков.
Выполняется оценка альтернативных вариантов, относящихся к целям и
ограничениям: выполняется определение и разрешение рисков (менеджмент рисков,
методика экономически выгодного выбора источников разрешения, оценка
остальных связанных с риском ситуаций, когда деньги могут быть потеряны из-за
продолжения разработки системы (решения о прекращении/продолжении работ над
проектом, и т.п.);
■ разработка продукта следующего уровня. Типичные действия, выполняемые
в этом квадранте, могут включать в себя создание проекта, критический анализ
проекта, разработку кода, проверку кода, тестирование и компоновку продукта.
Первая создаваемая версия продукта основывается на том, что попадает в поле
зрения заказчика. Затем начинается фаза планирования: программа возвращается
в исходное состояние с целью учета реакции клиента. Каждая последующая версия
более точно воплощает требования заказчика. Степень вносимых изменений от
одной версии программы к следующей уменьшается с каждой новой версией,
что в конечном счете приводит к получению функциональной системы;
■ планирование следующей фазы. Типичные действия в этом квадранте могут
включать в себя разработку плана проекта, разработку плана менеджмента конфи-
працией, разработку плана тестирования и разработку плана установки
программного продукта.
Чтобы лучше понять спиральную модель, изображенную на рис. 4.14, нужно
начинить г центра в квадранте 1 (определение целей, альтернативных вариантов и
ограничений), исследовать риски, составить план их разрешения, подготовиться к сле-
д\ ющей итерации и переместиться вправо.
Для каждой итерации следует определить цели, альтернативные варианты и
ограничения; установить и разрешить риски; дать оценку альтернативным вариантам;
разработать результативные данные для этой итерации и подтвердить их
правильность: спланировать следующую итерацию. Затем следует выбрать метод
осуществления следующей итерации в случае, если требуется ее выполнять.
Н квадрантах отсутствует заданное количество циклов. Их количество нужно
выбрать но необходимости, а итерации можно адаптировать под определенный проект.
Следует отметить тот факт, что кодирование выполняется значительно позже,
чем п других моделях. Смысл заключается в том, чтобы минимизировать риск посред-
сгвом последовательных уточнений требований, выдвигаемых пользователем. В
каждом "мини-проекте" (движении по спирали) рассматривается один или несколько
главных факторов риска, начиная с фактора наивысшего риска. Типичные риски

Выбор жизненного цикла разработки ПО 161
включают в себя неправильно истолкованные требования, архитектуру,
потенциальные проблемы, связанные с эксплуатацией продукта, проблемы в базовой технологии
и т.д. В главе 18 будут описаны самые распространенные риски, связанные с
разработкой программных проектов, и средства смягчения их влияния на процесс
разработки. Первая версия и первоначальная пригодность для эксплуатации (Initial
operational capability, IOC) — это первый шанс заказчика на тестирование системы, после
чего следует другой набор действий по планированию, приводящих к началу следующей
итерации. Важно также отметить, что эта модель не использует традиционных
структурных методов— эти методы появляются в конце (т.е. во внешнем цикле) спирали.
Версия, получаемая в результате проведения пользователям приемочных испытаний,
сдается перед наступлением стадии конечной пригодности для эксплуатации (Final
operational capability, FOC), т.е. точно так же, как это происходит в каскадной модели.
При использовании принципа прототипирования разработчики могут избегать
проверенных практических методов разработки системы и неправильно
использовать модель, мотивируя это причиной разработки "на скорую руку". Надлежащее
использование спиральной модели или одного из ее вариантов поможет избежать
"хакерства" и нарушения дисциплины. Как показано на рис. 4.14, после проведения
анализа и оценки рисков в большом объеме в "хвосте" спиральной модели
изображены этапы процесса, напоминающие каскадную модель.
Поскольку спиральная модель была разработана с большей тщательностью, чем
другие методики, в разработке по принципу спирали особое внимание уделено оценке
альтернативных вариантов и оценке рисков. Критический анализ, осуществляемый в
конце каждой фазы, обеспечивает переход к следующей фазе или в случае
необходимости определяет потребность в повторном выполнении каждой фазы.
Преимущества спиральной модели заключаются в том, что в ней особое внимание уделяется таким
процедурам, как анализ рисков, а также в возможности адаптировать ее к различным
принципам построения жизненного цикла. Если спиральная модель применяется при
демонстрациях, определении базовой линии и менеджменте конфигурации, можно
добиться непрерывного участия клиентов в процессе разработки и обеспечить упо-
14
рядочение процесса выполнения .
Преимущества спиральной модели
При использовании спиральной модели при выполнении проекта, для которого
она в достаточной мере подходит, проявляются следующие преимущества:
■ спиральная модель разрешает пользователям "увидеть" систему на ранних этапах,
что обеспечивается посредством использования ускоренного прототипирования в
жизненном цикле разработки ПО;
■ обеспечивается определение непреодолимых рисков без особых дополнительных
затрат;
■ эта модель разрешает пользователям активно принимать участие при
планировании, анализе рисков, разработке, а также при выполнении оценочных действий;
■ она обеспечивает разбиение большого потенциального объема работы по
разработке продукта на небольшие части, в которых сначала реализуются решающие
функции с высокой степенью риска, позволяющие устранить необходимость про-
1 Boehm Barry. Software Engineering Economics, 1-е издание. Englewood Cliffs, NY: Prentice Hall,
с 42, 1981.

162 Глава 4
должения работы над проектом (таким образом, в случае необходимости
становится возможным прекратить работу над проектом и уменьшаются расходы);
■ в модели предусмотрена возможность гибкого проектирования, поскольку в ней
воплощены преимущества каскадной модели, и в тоже время, разрешены
итерации по всем фазам этой же модели;
■ реализованы преимущества инкрементной модели, а именно выпуск инкрементов,
сокращение графика посредством перекрывания инкрементов, рассортированных
по версиям, и неизменяемость ресурсов при постепенном росте системы;
■ здесь не ставится цель выполнить невозможное — довести конструкцию до
совершенства;
■ обратная связь по направлению от пользователей к разработчикам выполняется с
высокой частотой и на ранних этапах модели, что обеспечивает создание нужного
продукта высокого качества;
■ происходит усовершенствование административного управления над процессом
обеспечения качества, правильностью выполнения процесса разработки,
затратами, соблюдением графика и кадровым обеспечением, что достигается путем
выполнения обзора в конце каждой итерации;
■ повышается продуктивность благодаря использованию пригодных для повторного
использования свойств;
■ повышается вероятность предсказуемого поведения системы с помощью
уточнения поставленных целей;
■ при использовании спиральной модели не нужно распределять заранее все
необходимые для выполнения проекта финансовые ресурсы;
■ можно выполнять частую оценку совокупных затрат, а уменьшение рисков связано
с затратами.
Недостатки спиральной модели
При использовании спиральной модели относительно проекта, для которого она
не подходит в достаточной мере, проявляются следующие недостатки:
■ если проект имеет низкую степень риска или небольшие размеры, модель может
оказаться дорогостоящей. Оценка рисков после прохождения каждой спирали
связана с большими затратами;
■ модель имеет усложненную структуру, поэтому может быть затруднено ее
применение разработчиками, менеджерами и заказчиками;
■ серьезная нужда в высокопрофессиональных знаниях для оценки рисков;
■ спираль может продолжаться до бесконечности, поскольку каждая ответная
реакция заказчика на созданную версию может порождать новый цикл, что отдаляет
окончание работы над проектом (принятие общего решения о прекращении
процесса разработки);
■ большое количество промежуточных стадий может привести к необходимости в
обработке внутренней дополнительной и внешней документации;
■ использование модели может оказаться дорогостоящим и даже недопустимым по
средствам, так как время, затраченное на планирование, повторное определение

Выбор жизненного цикла разработки ПО 163
целей, выполнение анализа рисков и прототипированиё, может быть
чрезмерным;
■ при выполнении действий на этапе вне процесса разработки возникает
необходимость в переназначении разработчиков;
■ могут возникнуть затруднения при определении целей и стадий, указывающих на
готовность продолжать процесс разработки на следующей итерации;
■ отсутствие хорошего средства или метода прототипирования может сделать
использование модели неудобным;
■ в производстве использование спиральной модели еще не получило такого
широкого масштаба, как применение других моделей.
Расценивая первоначальную спиральную модель как сложную, некоторые
пользователи этого метода разработали упрощенную версию, изображенную на рис. 4.15.
На рис. 4.16 можно увидеть еще одну версию, представляющую собой
модифицированную форму спиральной модели, которая была создана Консорциумом по
вопросам разработки ПО (Software Productivity Consortium).
Область применения спиральной модели
Менеджер проекта может быть уверен в целесообразности применения
спиральной модели, если для этого существует хотя бы одна из следующего перечня причин:
■ когда создание прототипа представляет собой подходящий тип разработки продукта;
■ когда важно сообщить, каким образом будет происходит увеличение затрат, и
подсчитать затраты, связанные с выполнением действий из квадранта риска;
■ когда организация обладает навыками, требуемыми для адаптации модели;
■ для проектов, выполнение которых сопряжено со средней и высокой
степенью риска;
■ когда нет смыла браться за выполнение долгосрочного проекта из-за
потенциальных изменений, которые могут произойти в экономических приоритетах, и когда
такая неопределенность может вызвать ограничение во времени;
■ когда речь идет о применении новой технологии и когда необходимо
протестировать базовые концепции;
■ когда пользователи не уверены в своих потребностях;
■ когда требования слишком сложные;
■ при разработке новой функции или новой серии продуктов;
■ когда ожидаются существенные изменения, например, при изучении или
исследовательской работе;
■ когда важно сконцентрировать внимание на неизменяемых или известных частях,
при чем сбор информации об изменяющихся частях еще не закончен;
■ в случае больших проектов;
■ для организаций, которые не могут себе позволить выделить заранее все
необходимые для выполнения проекта денежные средства, и когда в процессе разработке
отсутствует финансовая поддержка;
■ при выполнении затянувшихся проектов, которые могут вызывать раздражение у
менеджеров и заказчиков;

164 Глава 4
когда преимущества разработки невозможно точно определить, а достижение
успеха не гарантировано;
с целью демонстрации качества и достижения целей за короткий период времени;
когда в процесс вовлекаются новые технологии, такие как впервые применяемые
объектно-ориентированные принципы;
при разработке систем, требующих большого объема вычислений, таких как
систем, обеспечивающих принятие решений;
при выполнении бизнес-проектов, а также проектов в области аэрокосмической
промышленности, обороны и инжиниринга, где использование спиральной
модели уже получило популярность.
Планирование
I
Риск
Получение
начальных
требований
и планирование
проекта
Планирование, основанное
на комментариях заказчиков
Оценка
заказчиков
Анализ рисков, основанный
на начальных требованиях
Анализ рисков,
основанный
на реакции заказчиков
Принятие решения в рамках
парадигмы "идти/не идти"
направлению к завершенной системе
Начальный программный
прототип ^««^^
Прототип следующего уровня
Разрабатываемая система
Заказчик
> Процесс разделения на различные квадранты
> Выделяет "революционную" разработку
> Согласование с проверенными парадигмами качества
> Стрессовый формальный анализ рисков
Инжиниринг
Рис. 4.15. Упрощенная форма спиральной модели
Адаптированные модели жизненного цикла
разработки ПО
Иногда менеджер проекта выбирает модель жизненного цикла из какой-нибудь
книги и затем руководствуется ею в процессе разработки. В других случаях может
оказаться, что отсутствует именно та модель, которая в достаточной мере
соответствовала бы потребностям проекта. Предположим, что требуется жизненный цикл,
в котором предусмотрены возможные риски, но применение спиральной модели
неоправданно. В этом случае начните со спиральной модели и адаптируйте ее к
определенным потребностям. А если необходимо обеспечить функциональные
возможности на уровне инкрементов, но также необходимо принять во внимание
вопросы, связанные с надежностью системы? Тогда потребуется объединить инкре-
ментиую модель с V-образной моделью. Далее приведено несколько примеров
адаптированных моделей.

Выбор жизненного цикла разработки ПО 165
1. Понимание контекста
Контекст
обзора
Реализация стратегии
неприятия рисков
Подтверждение
обработки
5.Управление и планирование
2. Анализ рисков
Выполнение
плана
Обзор
технического
продукта
4. Разработка
продукта
Рис. 4.16. Измененный вариант спиральной модели
Источник: Software Productivity Consortium
Быстрое отслеживание. Методология построения жизненного цикла по
принципу быстрого отслеживания заключается в ускоренном прохождении или пропуске
одного или нескольких фаз жизненного цикла или процессов разработки. Многие или
большинство из стандартных стадий разработки выполняются в обычном режиме, в
то время как выполнение других стадий и их область действия могут быть сокращены.
Адаптация жизненного цикла необходима для реализации принципа быстрого
отслеживания, который эффективнее всего используется при выполнении
второстепенных проектов по разработке и приобретению ПО. Необходимость в применении
быстрого отслеживания может возникнуть в случае критической нехватки времени,
например, при необходимости первым поставить серийно выпускаемый продукт на рынок
или в случае возникновения угрозы национального характера для государственной
организации. Помимо сокращения жизненный цикл, адаптированный в целях быстрого
отслеживания, обычно является менее формальным. Полный срок службы
поставленного продукта может быть коротким, что указывает на короткую фазу эксплуатации.
К проектам, при выполнении которых используется принцип быстрого отслеживания,
должны прибегать лишь организации с повышенными дисциплинарными требованиями.
Официально установленная и определенная среда разработки сводит до минимума
возможные риски. При наличии четко выраженного постоянного набора требований и
метода, предусмотренного для внесения изменений, вероятность достижения успеха при
выполнении проектов за принципом быстрого отслеживания увеличивается.
Параллельный инжиниринг. Процесс параллельного инжиниринга (Concurrent
engineering, СЕ) заключается в создании продуктов более высокого качества за
меньших! период времени. Основной принцип использования этого метода заключается в

166 Глава 4
том, что все аспекты жизненного цикла проекта должны учитываться в процессе от
проектирования до производства как можно раньше. Благодаря раннему анализу
более поздних этапов жизненного цикла выявляются проблемы, которые возникнут
далее в процессе разработки, а значит, это будет способствовать принятию
продуманных и обоснованных решений на протяжении всего процесса разработки .
Хотя метод параллельного инжиниринга был позаимствован из других инженер
пых дисциплин, он успешно используется и для проектирования ПО. При
выполнении больших проектов отслеживание состояния на главных фазах жизненного цикла
может обеспечить создание в высшей степени упрощенной модели. В общих чертах
можно отметить, что, как правило, параллельный инжиниринг состоит из нескольких
действий (сбор требований, разработка проекта, кодирование, тестирование и т.д.),
которые осуществляются одновременно. Кроме того, внутренние или внешние
продукты проекта могут находиться в одном из нескольких состояний (в состоянии
разработки, анализа, проверки, ожидания следующей стадии и др.) При параллельном
инжиниринге все аспекты жизненного цикла рассматриваются как можно раньше.
Модели параллельного процесса позволяют получить точное представление о том, в
каком состоянии находится проект, а именно какие действия выполняются и каким
образом происходит создание продуктов.
При использовании этого метода следует оценить возможные технические риски,
чтобы определить, совместима ли разрабатываемая технология с методикой
ускоренной разработки, оставить свободное место в графике разработки, периодически
производить оценку технологического процесса для определения того, является ли он
по-прежнему совместимым с построенным планом, и чтобы, как и при использовании
более традиционных жизненных циклов, обеспечить основу для проведения оценки и
тестирования, поскольку игнорирование этих действия связано с крайним риском.
Спиральная модель, основанная на рассмотрении возможных рисков, очень хорошо
подходит для использования в управлении над параллельным проектированием
преимущественно тех программных систем, над разработкой которых работает несколько
лиц. В ней предлагается циклический принцип инкрементного возрастания
определения и реализации системы, а также предусмотрены анкерные контрольные точки для
обеспечения непрерывного участия в процессе разработки участников проекта.
Спиральная модель "Win-Win". Боэмом была также разработана
модифицированная спиральная модель под названием "спиральная модель win-win" (взаимный
выигрыш), изображенная на рис. 4.17. Она содержит в себе больше фаз, в которых
внимание сконцентрировано на участии заказчика в процессе разработки. Это достигается
путем добавления к начальной фазе каждого цикла так называемых действий Теории W
(Theory W activities). Теория W— это принцип менеджмента, при реализации которого
особое значение придается ключевым организаторам совместного дела,
выполняющим разработку системы (пользователь, заказчик, разработчик, наладчик, создатель
интерфейсов и т.д.), которые станут "победителями", если проект окажется
успешным. В этом методе, основанном на постоянном согласовании, циклы состоят из
следующих фаз или стадий: определение участников следующего уровня; определение
условий, необходимых для одержания участниками победы; согласование "победных"
условий; формулирование целей, ограничений и альтернативных вариантов следую-
15 http://itc.fgg.uni-lj.si/CARIS/LIST/msg00007.html. "The Application of Multi-
agent Systems to Concurrent Engineering." Описание "параллельного инжиниринга" на начальной
странице Concurrent Engineering: Research and Applications (CERA). West Bloomfield, MI: CERA Institute.

Выбор жизненного цикла разработки ПО 167
щего уровня; оценка альтернативных вариантов на уровне продукта и процесса,
разрешение рисков; определение следующего уровня продукта и процесса, включая
сегментацию; обоснование определений продукта и процесса; обзор и комментарии.
Важной стадией, которая не показана на рис. 4.17, является последующее
планирование следующего цикла и обновление плана жизненного цикла, включая
разделение системы на подсистемы, разработка которых осуществляется в ходе выполнения
параллельных циклов. Эта стадия может включать в себя план прекращения проекта,
если продолжение работы является слишком рискованным или невозможным. Также
необходимо обеспечить, чтобы продолжение работы над проектом со стороны
руководства осуществлялось согласно составленному плану.
Идентификация выигрышных
условий для участников
работ в рамках проекта
Идентификация
участников работ
в рамках проекта
на следующем уровне
Обзор и подтверждение
Аттестация
определений
продукта и процесса
Сверка выигрышных
условий
Достижение целей,
ограничений и альтернатив
следующего уровня
Оценка альтернатив
продукта и процесса
Устранение рисков
Определение следующего
уровня продукта и процесса,
включая разбиения
Рис. 4.17. Спиральная модель "vAn-vAn"
Спиральная модель "win-win" имеет следующие преимущества: более быстрая
разработка ПО благодаря содействию, оказываемому участниками проекта, уменьшение
стоимости программ благодаря уменьшению объема переработок и текущего
сопровождения, более высокий уровень удовлетворения со стороны участников проекта,
достигаемого до разработки самого продукта; более высокое качество ПО благодаря
использованию компромиссных качественно-атрибутивных моделей на уровне
архитектуры и исследование большого количества вариантов построения архитектуры на
ранних этапах разработки .
Эволюционный/инкрементный принцип. По своей природе разработка
программного продукта при использовании эволюционного/инкрементного принципа
часто затруднена. Вопросы возникают потому, что каждая инкрементная конструкция
реализует лишь небольшую часть возможностей разрабатываемой системы. Помимо
обычных критериев для принятия решений по разработки, может возникнуть
необходимость ответа на дополнительные вопросы:
■ является ли решение о разработке текущих функциональных свойств хорошей
идеей с учетом текущего объема финансирования?
10 Boehm Barry и др. "Using WINWIN Spiral Model: A Case Study." IEEE Computer, 31G): 33-44,
1998.

168 Глава 4
■ наступило ли уже время рассматривать функциональные возможности системы
(приоритеты пользователя, требования процесса эволюции)?
■ стоят ли добавленные функциональные возможности потраченных на них средств
(или "покрывается позолотой" лишь одна область функциональных возможностей
прежде, чем будут разработаны все необходимые характеристики системы)?
■ хватит ли у нас объема денежных средств на разработку требуемой системы в
полном объеме?
Принцип V-образной инкрементной модели. На рис. 4.18 изображена
комбинированная модель, разработанная Крейснером (Krasner). В книге под названием
"Разработка ПО высшего качества" (Constructing Superior Software) он подходит к
рассмотрению модели цикла разработки ПО, руководствуясь соображениями относительно
коллективной работы над проектом.
Разработка хорошей модели жизненного цикла проекта означает
заблаговременные капиталовложения например, создание традиционной V-образной модели,
сметанной с инкрементной, итеративной моделью разработки. В этой модели
предпринята попытка сбалансировать потребность в административном контроле с нуждами
и технической инновации и ситуативной динамике. Успешное использование V-
образной тесно связано с тем, что происходит в контрольных точках. Эти точки
представляют собой формальные механизмы, определяющие совместное принятие
определенных решений по переходу к следующей фазе со стороны менеджеров и
разработчиков. Вместе с периодическим проведением руководством обзоров и
предварительных просмотров, контрольные точки побуждают к обсуждению вопросов,
рисков и альтернатив. Значение каждой контрольной точки необходимо четко
определить в рамках всего процесса. За такой высокоуровневой моделью кроются
конкретные планы, основанные на точных предварительных оценках и четко
определенных контрольных точках проектирования, способствующих достижению успеха .
Объектно-ориентированное быстрое прототипирование. Часто многие
недоумевают, почему малейшие отличия между структурным быстрым прототипировани-
ем, быстрой разработкой приложений RAD и спиральными моделями имеют такое
большое значение, ведь во всех тех моделях предусмотрено привлечение
пользователя в процесс разработки и применение принципа эволюционного развития.
Каскадная, V-образная и инкрементная модели также имеют общие характеристики, такие
как критерии входа/выхода для фазы. Спираль можно представить как перекрытие
инкрементов с добавлением элементов менеджмента рисков. Все модели имеют
определенный тип области действия, сбора требований, проектирования, разработки,
тестирования и действий но внедрению.
Фактически большинство жизненных циклов представляют собой результат
адаптации и комбинации, и все ПО получают путем эволюционной разработки. Все
коммерческие программные продукты всегда эволюционируют, а в правительственных
учреждениях и ИТ-центрах возникающие на более поздних стадиях эволюционные
циклы получили название "сопровождение".
Менеджер проекта должен спокойно относиться к выбору и адаптации жизненного
цикла разработки ПО в соответствии с потребностями данного проекта, но он также
должен помнить о важности присвоения названий отдельным этапам и четко обозна-
Kraslier Herb. "Teamwork Considerations for Superior Software Development." Constructing
Superior Software, 1-е издание. Indianapolis, IN: Macmillan Technical Publishing, C. 180, 1999.

Выбор жизненного цикла разработки ПО 169
чить переход от "разработки" к "реализации". Важность существования линии
реализации или внедрения напрямую связано с контролем и менеджментом. При разработке
каждого программного продукта всегда возникает потребность в определенный момент
времени рассмотреть его "в производстве". В противном случае заказчики не имеют
представления о том, когда нужно будет оплатить счет, пользователи не уверены, когда
функциональные возможности продукта являются стабильными, а команда
разработчиков не сможет подготовить продукт для целей управления конфигурацией.
Выбор приемлемой модели жизненного
цикла разработки ПО
Выбор приемлемой модели жизненного цикла разработки ПО для проекта может
осуществляться в ходе использования следующего процесса.
1. Проанализируйте следующие отличительные категории проекта, помещенные в
таблицах 4.1-4.4:
Требования: таблица 4.1.
Команда разработчиков: таблица 4.2.
Коллектив пользователей: таблица 4.3.
Тин проекта и риски: таблица 4.4.
2. Ответьте на вопросы, приведенные для каждой категории, обведя кружочком
слова "да" или "нет".
3. Расположите по степени важности категории или вопросы, относящиеся к каждой
категории, относительно проекта, для которого выбирается приемлемая модель.
4. Воспользуйтесь упорядоченными категориями для разрешения противоречий,
возникающих при сравнении моделей, если общие полученные показатели
сходны или одинаковы.
Отличительные категории проекта
Ниже приводится краткое описание характеристик и требований к команде
разработчиков, коллективу пользователей, типу проекта и рискам. В табл. 4.1-4.4 приведен
набор матриц, предназначенных для использования на стадиях 1-5 процесса выбора
модели жизненного цикла, описание которого было приведено в предыдущем разделе.
Требования. Категория требований (таблица 4.1) состоит из вопросов
относительно требований, которые предъявляет пользователь к проекту. В терминологии их
иногда называют свойствами системы, которая будет поддерживаться данным проектом.
Таблица 4.1. Выбор модели жизненного цикла на основе характеристик
требований
Требования Каскад- V-образ- Прототи- Спираль- RAD Инкре-
ная ная пирование пая ментная
Являются ли требования лег- Да Да Нет Нет Да Нет
ко определимыми и/или
хорошо известными?

170 Глава 4
Окончание табл. 4.1
Да
Нет
Нет
Нет
Да
Да
Нет
Да
Да
Да
Нет
Да
Да
Нет
Нет
Нет
Нет
Да
Да
Да
Да
Нет
Да
Да
Да
Требования Каскад- V-образ- Прототи- Спираль- RAD Инкре-
ная пая пирование ная ментная
Могут ли требования заранее Да
определяться в цикле?
Часто ли будут изменяться Нет
требования в цикле?
Нужно ли демонстрировать Нет
требования с целью
определения?
Требуется ли для демонстра- Нет Нет Да Да Да Нет
ции возможностей проверка
концепции?
Будут ли требования отражать Нет
сложность системы?
Обладает ли требование Нет
функциональными
свойствами на раннем этапе?
Команда разработчиков. По возможности, в состав команды разработчиков
лучше всего отобрать персонал еще до того, как будет выбрана модель жизненного
цикла. Характеристики такой команды (таблица 4.2) играют важную роль в процессе
выбора, поскольку она несет ответственность за удачное выполнение цикла и может
оказать помощь в процессе выбора.
Таблица 4.2. Выбор модели жизненного цикла на основе характеристик
участников команды разработчиков
Команда разработчиков Каскад- V-образ- Прототи- Спираль- RAD Инкре-
проекта ная ная пирование ная ментная
Являются ли проблемы пред- Нет Нет Да Да Нет Нет
метной области проекта
новыми для большинства
разработчиков?
Является ли технология Да Да Нет Да Нет Да
предметной области проекта
новой для большинства
разработчиков?
Являются ли инструменты, Да Да Нет Да Нет Нет
используемые проектом,
новыми для большинства
разработчиков?
Изменяются ли роли участии- Нет Нет Да Да Нет Да
ков проекта во время
жизненного цикла?

Выбор жизненного цикла разработки ПО 171
Окончание табл. 4.2
Команда разработчиков
проекта
Каскад- V-образ- Прототи- Спираль- RAD Инкре-
ная ная пирование ная ментная
Могут ли разработчики про- Нет
екта пройти обучение?
Является ли структура более Да
значимой для разработчиков,
чем гибкость?
Будет ли менеджер проекта Да
строго отслеживать прогресс
команды?
Важна ли легкость распреде- Да
ления ресурсов?
Приемлет ли команда равно- Да
правные обзоры и инспекции,
менеджмент/обзоры
заказчиков, а также стадии?
Да
Да
Нет
Нет
Нет
Нет
Да
Нет
Да
Да
Да
Нет
Да
Нет Да
Да
Да
Нет
Да
Нет
Да
Да
Нет
Да
Да
Коллектив пользователей. На начальных фазах проекта можно получить четкое
представление о коллективе пользователей (табл. 4.3) и его будущей взаимосвязи с
командой разработчиков на протяжении всего проекта. Такое представление
поможет вам при выборе подходящей модели, поскольку некоторые модели требуют
усиленного участия пользователей в процессе разработки и изучения проекта.
Тип проекта и риски. И наконец, уточним, что собой представляют тип проекта и
риски (таблица 4.4), которые были рассмотрены нами как элементы, определение
которых осуществляется на фазе планирования. В некоторых моделях предусмотрен
менеджмент рисков высокой степени, в то время как в других он не предусмотрен
вообще. Выбор модели, которая делает возможным менеджмент рисков, не означает,
что вам не нужно составлять план действий, направленный на минимизацию
выявленных рисков. Такая модель просто обеспечивает схему, в рамках которой можно
обсудить и выполнить данный план действий.
Таблица 4.3. Выбор модели жизненного цикла на основе характеристик
коллектива пользователей
Коллектив
пользователей
Каскад- V-образ- Прототи- Спираль- RAD Инкре-
ная ная пирование ная ментная
Будет ли присутствие пользо- Да
вателей ограничено в
жизненном цикле?
Будут ли пользователи знако- Нет
мы с определением системы?
Будут ли пользователи озна- Нет
комлены с проблемами
предметной области?
Да
Нет
Да
Нет Да
Нет
Нет
Да
Да
Да
Нет
Нет
Да
Да
Да

172 Глава 4
Окончание табл. 4.3
Коллектив Каскад- V-образ- Прототи- Спираль- RAD Инкре-
пользователей ная ная пирование иая ментная
Будут ли пользователи вовле- Нет Нет Да Нет Да Нет
чены во все фазы жизненного
цикла?
Будет ли заказчик отслежи- Нет Нет Да Да Нет Нет
вать ход выполнения проекта?
Таблица 4.4. Выбор модели жизненного цикла на основе характеристик типа
проектов и рисков
Тип проекта и риски Каскад- V-образ- Прототи- Спираль- RAD Инкре-
ная ная пирование ная ментная
Будет ли проект идентифици- Нет
ровать новое направление
продукта для организации?
Будет ли проект иметь тип
системной интеграции?
Будет ли проект являться
расширением существующей
системы?
Будет ли финансирование Да Да Да Нет Да Нет
проекта стабильным на всем
протяжении жизненного
цикла?
Ожидается ли длительная Да Да Нет Да Нет Да
эксплуатация продукта в
организации?
Должна ли быть высокая сте- Нет
пень надежности?
Будет ли система изменяться, Нет
возможно, с применением
непредвиденных методов, на
этапе сопровождения?
Является ли график ограни- Нет
ценным?
Нет
Нет
Нет
Нет
Да
Да
Да
Да
Нет
Да
Да
Нет
Нет
Да
Да
Да
Да
Да
Да
Нет
Нет
Да
Да
Да
Нет
Нет
Да
Да
Являются ли "прозрачными" Да
интерфейсные модули?
Доступны ли повторное ис- Нет
пользуемые компоненты?
Являются ли достаточными Нет
ресурсы (время, деньги,
инструменты, персонал)?
Нет
Да
Нет
Нет
Да
Нет
Да
Да
Да
Нет
Да
Да
Да
Нет
Да
Нет
Да
Да
Нет
Нет

Выбор жизненного цикла разработки ПО 173
Подгонка модели жизненного цикла
разработки ПО
Выбор подходящей модели — это только первая стадия применения модели
жизненного цикла в процессе определенного проекта. Следующая стадия заключается в
ее подгонке в соответствии с потребностями этого проекта. Это означает, что
выбранные реальные фазы и действия должны помочь руководителю проекта соотнести
проект с выбранной моделью.
Согласно модели SEI СММ, не существует каких-либо четких предписаний на сей
счет: "Руководящие принципы и критерии для адаптации стандартного процесса
разработки ПО данной организации к выбранным проектам получают путем разработки
и последующего утверждения", а также "определенный процесс разработки ПО в
рамах данного проекта является адаптированной версией стандартного процесса
разработки ПО для данной организации".
Жизненные циклы, их фазы, а также соответствующие действия, приведенные
в этой главе, можно использовать в качестве отправной точки при определении
тех циклов, фаз и действий, которые требуются в данный момент времени. После
завершения подгонки модель приобретает большую степень значимости для
команды разработчиков и коллектива пользователей. Ее можно использовать как
опорную точку на собраниях, посвященных обсуждению состояния процесса
разработки, демонстрациях, на обсуждениях оценки рисков, а также при доставке
конечного продукта.
А что будет в том случае, если при выполнении проекта происходят какие-либо
изменения, которые заставляют команду прийти к мысли, что другая модель была бы
более действенной? Можно ли изменить модель в процессе выполнения проекта?
Ответ на этот вопрос почти всегда положительный, но это следует сделать с
обязательным учетом возможных последствий таких изменений для проекта. В крайнем случае,
лучше изменить модель, чем пытаться использовать ту, которая не подходит в
достаточной степени для соответствия потребностям проекта.
Стадии процесса выбора жизненного цикла разработки ПО и его последующей
подгонки можно определить следующим образом.
1. Ознакомьтесь с различными моделями.
2. Просмотрите и проанализируйте возможные виды работ: разработка,
модернизация, сопровождение и т.д.
3. Выберите самый подходящий жизненный цикл, используя для этого матрицы
критериев: высокая степень риска, пользовательский интерфейс, высокая
надежность, время доставки на рынок/выпуска продукта, приоритеты пользователя,
уточнение требований, ожидаемый срок эксплуатации системы, технология,
размер и сложность, возможный параллелизм, а также интерфейсы для
существующих и новых систем.
4. Проанализируйте, насколько выбранный жизненный цикл соответствует
стандартам вашей организации, ваших заказчиков или типа проекта — ISO, IEEE и т.д.
5. Сформулируйте набор фаз и действий, образующих каждую фазу.
6. Определите внутренние и внешние производимые продукты.
7. Определите шаблоны и внутреннее содержимое поставляемых продуктов.

'4 I лава 4
^Резервное' етшрование':■••■■
на случай вйвусной атайч:
управления.
й^сяниемеотнадйскё.
(Восстаноелениефайлов
Управление памятью
«WA
jBbinycKVxxjcx
1'ш: •/. / 9. Выпуск продукта в компании по разработке ПО с применением
комбинированных миделей
Рис. 4.20. Цикл разработки ПО, в котором применяются комбинированные модели

Выбор жизненного цикла разработки ПО 175
8. Определите действия по обзору, инспектированию, верификации и аттестации, а
также стадии проекта.
9. Выполните оценку эффективности схемы жизненного цикла и проведите ее
модернизацию там, где это необходимо.
Часто применяемый метод подгонки жизненных циклов заключается в
комбинировании моделей. Два примера подобной подгонки изображены на рис. 4.19 и 4.20.
Резюме
Существует множество различных моделей или представлений жизненного цикла
разработки ПО. Все они представляют собой логически построенную
последовательность действий, начиная с определения потребности и заканчивая производством
ПО. Каждая модель представляет собой процесс, который структурно состоит из
этапов, направленных на обеспечение целостности соответствующих субкомпонентных
действий. Каждая фаза снижает степень риска при выполнении проекта, что
достигается благодаря применению критериев входа и выхода для определения дальнейшего
хода действий. По завершении каждой фазы получают внутренние или
результативные внешние действия.
Жизненные циклы разработки ПО иногда называют методиками менеджмента
жизненных циклов. Эти методики охватывают все стандарты и процедуры, оказывающие
влияние на планирование, сбор требований и анализ, разработку проекта,
конструирование и внедрение программной системы. С целью обеспечения эффективности
произвольного жизненного цикла его потребуется аккуратно выбрать и зачастую настроить
(подогнать и разработать) в соответствии с задачами и целями определенного проекта.
Вместо того чтобы начать разработку "с нуля", в некоторых популярных,
обобщенных моделях обеспечиваются готовые начальные схемы. Каждая модель имеет
присущие ей преимущества и недостатки, определяющие ее применение для
определенных типов проектов.
Модель, выбранная для какого-либо проекта, должна обеспечивать потребности
организации, соответствовать типу выполняемых работ, а также навыкам и
инструментальным средствам, которые имеются у специалистов-практиков.
Убедившись в эффективности использования моделей жизненного цикла в рамках
процесса, вы можете помочь вашей организации достичь гибкости при выполнении
проекта. В каждом проекте, выполняемом организацией, можно применить отдельную
модель жизненного цикла, которая подвергается настройке. Однако интеграция
моделей жизненного цикла с "каркасом" процесса — это уже другая стадия в ходе достижения
более высокого уровня завершенности процесса разработки ПО. Организация должна
осознать то, что разрабатываемые программы должны обладать постоянными
характеристиками. В то же время реализация этого процесса должна быть гибкой, что
обеспечивается с помощью настраиваемых моделей жизненного цикла разработки ПО.
Контрольные вопросы
Для каждой из перечисленных ниже четырех групп проблем, выберите
подходящую модель жизненного цикла разработки ПО и опишите ее преимущества.
1. Корпорация переписывает код программы Accounts Payable для того, чтобы
перенести ее со старого группового мэйнфрейма в систему, подключенную к

176 Глава 4
Internet. Функциональные возможности остаются прежними. Рабочее задание
требует изменения исходных качеств системы. Для новой среды будут изменены
только входные и выходные подсистемы. Поскольку данная система относится к
области финансов, в рамках действий по разработке особое внимание будет
уделено ее тестированию и верификации. В графике предусмотрено, что на
выполнение проекта уйдет пять месяцев, и над ним будут работать два человека. Какой,
на ваш взгляд, самый приемлемый принцип построения жизненного цикла? В чем
заключаются преимущества такого принципа для данного проекта?
2. Корпорация по разработке электронных компонентов недавно приняла решение
вложить средства в проектирование "карманных" компьютеров (Personal digital
assistants, PDA), no образу и подобию карманных компьютеров Palm Pilot. В этом
случае предполагается применение сотовых модемов. Компания имеет
значительный опыт в выпуске серий продуктов, аналогичных этому, и считает, что,
продавая его по более низкой цене, достигнет успеха на рынке. Таким образом,
организация хотела разработать рабочую модель, которая будет представлена на
международной специализированной выставке по прошествию трех месяцев.
Каков наиболее подходящий принцип построения жизненного цикла? В чем
заключается преимущества такого принципа для данного проекта?
3. Корпорация недавно завершила трехлетний процесс разработки глобальной
системы менеджмента конфигурации. Теперь она готова перейти на следующую
фазу, на которой приблизительно каждые три месяца будет выпускаться новый
вариант программного продукта. В каждый выпуск будет включено в среднем 12
новых свойств и соответствующее количество безошибочных вариантов. Над
каждым выпуском будут совместно работать команды, состоящие из 1-3
инженеров и находящиеся в Индии, России и Соединенных Штатах. Время, отведенное
на разработку новых свойств, — от 1 до 5 месяцев. Для некоторых свойств может
возникнуть необходимость в выпуске нескольких вариантов вплоть до их полной
реализации. Что представляет собой, на ваш взгляд, самый подходящий принцип
построения жизненного цикла? В чем заключается преимущества такого
принципа для данного проекта?
4. Компания образовала новый отдел малого бизнеса, предназначенный для
разработки специализированной беспроводно-протокольной операционной системы.
С целью создания базы для нового предприятия из ключевых сфер деятельности
компании будет переведено приблизительно 12 человек. Извне будет нанято
около 23 дополнительных специалистов, большинство из которых— инженеры.
В корпорации уже принято решение, что совместно с языком Java будут
использоваться объектно-ориентированные средства и методы. Ни один из участников
проекта не располагает какими-либо предварительными знаниями относительно
этих методов, но все они пройдут десятидневное обучение, приступив к работе
над проектом. Более того, партнерконсорциум данной организации недавно
выпустил новую платформу разработки. В графике предусмотрено освоение новой
платформы. Основной провайдер беспроводной связи испытывает существенные
финансовые затруднения из-за понижения спроса на рынке и уволил около 35%
своих работников. Что представляет собой самый подходящий принцип
построения жизненного цикла в этом случае? В чем заключается преимущества такого
принципа для данного проекта?

Выбор жизненного цикла разработки ПО 177
Практическое занятие
Вице-президент отдела маркетинга только что одобрил выпуск
многофункционального набора CASE-технологий, разработанной и продаваемой вашей недавно
созданной дочерней компанией. Ниже приведены самые важные характерные черты
этого набора функциональных возможностей.
Программа xTRemeObjectMaker делает возможным синхронный круговой
инжиниринг, благодаря которому разработанные модели фактически используются
разработчиками и продолжают отвечать актуальным требованиям на протяжении всего
процесса выполнения проекта. Это средство даже позволяет восстановить исходный
ход с любых компиляторов, совместимых с классом языков Java и Swing. Оно также
обеспечивает возможность синхронной круговой разработки EJB на основе любого
исходного кода.
Программа xTRemeObjectMaker способствует выполнению более результативного
и эффективного процесса разработки, включая автоматическое генерирование
образцов .моделирования, проектных образцов, рефакторингов и EJB. Она также
позволяет командам разработчиков точно установить вид процесса построения
программы, позволяя при этом осуществлять обязательный или дополнительный контроль на
уровне проекта и на уровне разработчика.
Программа xTRemeObjectMaker поддерживает истинно командную разработку,
обеспечиваемую благодаря соблюдению синхронизации моделей, кода и
документации. Сюда включена ведущая многопользовательская многомашинная система
управления версиями, работающая в Internet. Также автоматически поддерживается
совместная работа с большинством ведущих систем управления версиями в
инструментальном комплексе Windows.
Программа xTRemeObjectMaker автоматически генерирует серии документов на
языке XML. соответствующих фактическим требованиям, включая многокадровый
HTML-документ Javadoc2, многомашинные отчеты в формате RTF, а также
документы, включающие описание государственного и корпоративного стандарта. Здесь в
качестве языка подготовки сценариев используется язык xmljava.
Программа xTRemeObjectMaker поддерживает возможность отслеживания
настраиваемых требований, что позволяет команде отслеживать данные о требованиях
для любых элементов модели, используя при этом любые методы сбора требований в
любой клиентской предметной области.
Программа xTRemeObjectMaker предоставляет обстоятельное визуальное
обеспечение для UML-диаграмм, обеспечивая при этом значительно более объемлющее
обеспечение, чем какой-либо другой продукт моделирования.
Программу xTRemeObjectMaker можно применять даже в самых больших
проектах. Он поддается масштабированию, как и любая файловая система управления
версиями. Она включает в себя проектное и подпроектное обеспечение для проектов, в
которых задействованы сотни или тысячи классов.
Отличительным признаком xTRemeObjectMaker является многоуровневый
открытый объектно-ориентированный программный интерфейс API-приложения.
Фактически большая часть особенностей xTRemeObjectMaker на практике реализуется
при использовании конфигурационных файлов и базового интерфейса API, доступ к
которому разрешен всем пользователям на графическом уровне. Это позволяет
разрабатывать усовершенствованные сценарии, необходимые для генерирования
метрических показателей, выполнения аудита контроля за качеством, генерирования по-

178 Глава 4
следовательных диаграмм из исходного кода и самосинхронизации со сторонними
инструментальными интерфейсами.
Программа xTRemeObjectMaker совместима с ведущими инструментальными
средствами. Вызовите любую программу редактирования в среде
xTRemeObjectMaker. Установите и запустите любое другое средство разработки, включая отладочную
программу. Вызовите компилятор, после чего произойдет следующее:
xTRemeObjectMaker перехватит и отобразит сообщения об ошибке. Теперь щелкните два раза
мышью, и XTRemeObjectMaker отобразит место появления ошибки. В состав среды
xTRemeObjectMaker входят все средства Sun JDK.
Программа xTRemeObjectMaker полностью поддерживает языки XML, DTD и
DDL. Являясь прикладной программой, написанной на языке Java,
xTRemeObjectMaker выполняется в операционных системах NT, 98/95 и Linux.
Возникает естественный вопрос: располагая такими свойствами, зачем тратить
попусту время на определение жизненного цикла? Вице-президент отдела маркетинга
возложил ответственность на вашего директора за то, что до сих не разрабатываются
приложения с применением этого инструментального средства прототипирования.
Вы, как менеджер проекта, должны найти ответ на этот вопрос до начала
завтрашнего заседания сотрудников.
Литература
Boehm Barry. "A Spiral Model of Software Development and Enhancement". IEEE Computer,
21E):61-72,1988.
Cantor Murray R. Object-Oriented Project Management with UML, 1-е издание, NY: John Wiley &: Sons,
Inc.. 1998.
Министерство военно-воздушных сил. Центр обеспечения программных технологий. "Guidelines
(ш Successful Acquisition and Management of Software Intensive Systems". Версия 2.0, июнь, 1996.
Deutsch Michael S., and Ronald R. Willis. Software Quality Engineering: A Total Technical and Management
Approach, 1-е издание. Englewood Cliffs, штат NJ: Prentice Hall PTR/Sun Microsystems Press, 1988.
Graham Ian. Migrating to Object Technology, 1-е издание. Reading, штат MA: Addison-Wesley, 1995.
IEEE 1074-1997. "IEEE Standard for Developing Software Life Cycle Processes". NY: The Institute of
Electiical and Electronics Engineers, 1998.
Martin Jarnes. Rapid Application Development, 1-е издание. NY: Macmillan, 1991.
McConnell Steve. Rapid Development: Taming Wild Software Schedules, 1-е издание. Redffibnd, WA:
Microsoft Press, 1996.
Pressman Roger S. "Understanding Software Engineering Practices: Required at SE1 Level 2 Process
Maiurity". Software Engineering Training Series, Software Engineering Process Group, 1993.
Pressman Roger S. Software Engineering: A Practitioner's Approach, 5-е издание. Бостон, штат MA: McGraw-
Hill, 2001.
Royce W.W. "Managing the Development of Large Software Systems: Concepts and Techniques".
Proceedings W£SCON,LoeAlarnitcs,CA,1970.
www. software. org/pub/darpa/erd/erdpv010004.html. DeSantis, Richard, John Blyskal, Assad
Moini, and MarkTappjnSlX397(B7CMCVersk«01.TO.0iHerrricn,VASofiwarePro^^
Дополнительные сведения в Internet
stsc.hill3f.mil/crosst3lk/1995/jan/comparis.asp. Abstract: "A Comparison of
Software Development Methodologies. Reed Sorensen, Software Technology Support Center". Цель и
предмет: В этой статье рассматриваются и сравниваются методики разработки ПО. Эта информация

Выбор жизненного цикла разработки ПО 179
поможет вам узнать, какие методики наиболее приемлемы для использования в различных
ситуациях. Центр обеспечения программных технологий военно-воздушных сил США (USAF), "Guidelines
for Successful Acquisition and Management of Software-Intensive Systems". CrossTalk, The Journal of Defense
Software Engineering
stsc.MlMf.mil/crosstalk/1996/aug/isoiBC.asp. Abstract: "ISO/IEC 12207 Software
Lifecycle Processes". Lewis Gray. Ada PROS, Inc. В этой статье описывается стандарт ISO/IEC 12207. В
ней показано, как с помощью этого стандарта можно решить некоторые из проблем, связанных со
стандартом DOD-STD-2167A и стандартом MIL-STD-498. Центр обеспечения программных
технологий (STSC) военно-воздушных сил США (USAF), "Guidelines for Successful Acquisition and
Management of Software-Intensive Systems", CrossTalk, The Journal ofDefense Software Engineering.
www. software. огд/pub. darpa/erd/erdpvOl 0004. html.
www.stsc.hill.af.mil/. Центр обеспечения программных технологий (STSC) военно-
воздушных сил США (USAF) "Guidelines for Successful Acquisition and Management of Software-
Intensive Systems", Cross Talk, The Journal of Defense Software Engineering, Версия 2.0,1996.

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

Управление процессами предметной области 181
сматриваются наиболее общие жизненные циклы разработки ПО, а также описываются
критерии выбора для каждого из них. Последняя глава раздела, посвященного
инициализации программного проекта, содержит описание методик отбора команды
разработчиков. В этой главе разрабатывается проект, имеющий отношение к предметной
области, в которой он будет играть основную роль. Благодаря этому менеджер проекта
получает возможность разрабатывать ПО, удовлетворяющее требованиям заказчиков.
При реализации менеджмента процессами предметной области необходим прежде
всего проект разработки ПО внутри организации. На рис. 5.1 показано, каким
образом связаны корпорация, программный продукт и жизненные циклы разработки ПО.
В ходе осуществления деловых корпоративных действий производятся многие
программные продукты. Эти продукты производятся на различных фазах жизненного
цикла в каждый конкретный период времени. Жизненный цикл разработки
программного продукта начинается после того, как было завершено определение
потребностей, а затем началась разработка концепции проекта. В каждой прибыльной
организации в процессе разработки находятся множество программных продуктов, а
также вполне контролируемое количество проектов. Каждому программному
продукту соответствует один или больше одновременно выполняющихся проектов, что
способствует формированию завершенного набора компонентов программных
продуктов. Для каждого из проектов определяются даты начала и окончания. В цикле
разработки программного продукта начало проекта определяется после оценки
возможности его выполнения, а выполнение проекта осуществляется на этапе
получения программного продукта. Начало проекта определяется инициализацией, при
этом учитываются потребности, возникающие на этапе создания программного
продукта. Завершение проекта определяется на этапе поставок, когда начинают
эксплуатироваться поставляемые продукты, полученные в ходе работы над проектом.
Вообще говоря, компьютерные системы представляют собой нечто большее, чем
обычное ПО. Создание качественных программ требует учета аппаратного
обеспечения, трудозатрат персонала, выполнения обработки данных, составления
документации, а также выполнения соответствующих процедур. Все это должно учитываться на
той либо иной стадии жизненного цикла разработки.
Корпоративный деловой жизненный цикл
Планирование
политики
Идентификация
потребностей
' >
Концепция
проекта
Осуществление
Продукт / Вывод из
в обслуживании / эксплуатации
\
\
Жизненный цикл программного продукта
Выполнимость
Приобретение
_ / Вывод из
Эксплуатация|эксплуатации
Жизненный цикл проекта
Инициализация
Разработка
Внедрение
Поставка
Рис. 5.1. Взаимосвязи жизненного цикла разработки ПО
Менеджер проекта должен быть способен к определению критериев выбора
проекта. Как правило, количество возможных проектов превышает объем ресурсов,
необходимых для выполнения этих проектов. Одной из ключевых тем, рассматривав-

182 Глава 5
мых в данной главе, является определение этих критериев и их включение в
структуру модели, используемую в процессе принятия решений.
Выбор проекта осуществляется с учетом возможности возврата инвестиций и
эффективности производства, т.е. получения прибыли. Подобный подход,
определяющийся прежде всего финансовым аспектом является универсальным и подходит
практически для любого предприятия.
В данной главе будет произведен обзор основных показателей, имеющих
отношение к модели финансового анализа DuPoint. Подробные сведения по этому вопросу
можно найти в приложении С.
Стадии жизненного цикла разработки
продукта
Управление процессами предметной области начинается на фазе исследования
концепции, как показано на рис. 5.2. Как только будет определена концепция
проекта, процессы предметной области реализуют формирование концепции в целевой
операционной среде. Завершение производства программного продукта требует от
менеджера проекта понимания предметной области заказчика, в которой будет
использоваться ПО.
Связь главы 5 с 34 компетенциями
При управлении процессами предметной области необходимы следующие навыки
менеджмента проектов.
Методики разработки продукта
1. Оценка альтернативных процессов — оценка различных подходов.
2. Понимание действий по разработке продукта — изучение цикла разработки ПО.
Навыки менеджмента проектов
3. Отслеживание процессов — мониторинг совместимости проектной команды.
Навыки менеджмента персонала
4. Проведение эффективных встреч — планирование и проведение эффективных
встреч.
Учебные цели главы 5
После изучения материала главы читатель должен уметь выполнять следующее:
■ объяснять процессы предметной области, которые должны быть отнесены к фазе
исследования концепции для каждого проекта;
■ понимать отличительные особенности шести классов предметных областей
продукта;
■ устанавливать соответствие между различными предметными областями
программного продукта и критическими компонентами программного продукта;
■ формировать портфель проектов организации, а также классифицировать
проекты согласно их экономической целесообразности.

Управление процессами предметной области 183
Исследование
концепции
•
Формулирование

потребности
Исследование
системы
• Спецификация'
интерфейса
системы
Требования
• Спецификация
требований
к ПО
Основной жизненный
цикл ПО
Модель процессов поддержки
Основная модель жизненного цикла системы
проекта
■ Описание

разработки ПО
Внедрение
Идентификация
циклов SLC
• План

тации/верификации ПО
Выбор модели
Установка
' Модель цикла SLC
Установка
соответствия
между задачами
и циклами SLC
с помощью IEEE 1074
Управление процессами
предметной области
■Отчет об

тестации/верификации
ПО
Эксплуатация
и поддержка
1
Пользовательская
документация
Сопровождение
■ Жизненный цикл SW
Распределение
ресурсов
' Документация''
по
сопровождению
Вывод из
эксплуатации
■ Бюджет
■ Архивный
отчет
Рис. 5.2. Управление процессами предметной области, происходящими на этапе
исследования концепции
Определение процессов предметной области
Процессы предметной области представляют собой взаимосвязанные действия,
которые являются специфичными для организации, в которой был разработан
рассматриваемый программный проект. Первым шагом на этом пути является
определение предметной области, для которой в конечном итоге, будет разрабатываться
программный проект, т.е. на этапе произвольного анализа предметной области
критически важной является точка зрения конечного пользователя. И она должна быть
обязательно учтена при оценке различных возможностей программы. Если
отсутствует "реальный" заказчик, нам следует ориентироваться на "голос заказчика".
Качество программного проекта определяется тем, насколько хорошо ПО
решает специфические проблемы, связанные с предметной областью. Исходя из
этого при поставке качественного ПО менеджер проекта должен уметь определять
предметную область, при использовании в которой ПО будет разрешать специфи-

184 Глава 5
ческие потребности. При разработке программного продукта выделяются шесть
классов предметных областей:
1. потребительский;
2. деловой;
3. индустриальный;
4. режим реального времени;
5. продукт с минимальной задержкой;
6. научный.
Отдельные пользователи приобретают программные продукты потребительского
класса для личного применения. Подобного рода продукты могут применяться дома,
по время путешествий либо па работе. Ключевым моментом в данном случае является
то, что потребительский рынок является массовым и обычно ориентируется на
покупателя, чувствительного к ценам. Примерами таких потребительских продуктов
могут служить мобильные телефоны, автомобили, телевизионное оборудование,
персональные компьютеры, а также персональные цифровые помощники.
Большинство же программных продуктов нацелены на предметную область,
связанную с деловым классом. Здесь ключевой задачей является организация поставки
деловым заказчикам экономичного программного продукта, который способен
увеличить норму прибыли в бизнесе. Программные продукты этого класса обычно
дороже по сравнению с программами потребительского класса, а также обязательно
включают сопровождение, обслуживание и услуги по выполнению установки.
Примерами программных продуктов подобного типа являются инструментальные средства
баз данных, такие как Oracle, программы планирования корпоративных ресурсов
(PeopleSoft), наборы инструментальных средств по разработке (WebSpere и Visual-
Age), а также операционные системы (Solaris).
Индустриальные продукты образуют специфичный подкласс деловых программных
продуктов. Подобные программные инструменты приобретаются для удовлетворения
специфических потребностей, например, автоматизации машин, автоматизации и
интеграции деятельности фабрик, а также в качестве управляющего встроенного ПО.
Эти программы имеют специальное назначения и обычно используются в отдельной
индустриальной отрасли, например, в автомобилестроении, пищевой
промышленности либо производстве полупроводников. Примерами подобных программных
продуктов могут служить ПО автоматизации деятельности фабрик от компании Factory-
Works, встроенные системы разработки от компании Wind River, а также
инструментальные средства моделирования процессов (программный продукт разработки
фирмы Hewlett Packard)
Программы из класса режима реального времени используются с целью управления
процессами, которые имеют определенный и ограниченный во времени бюджет.
Системы реального времени применяются при сборе данных, имеющих отношение к
событиям, длящимся менее одной микросекунды. Программы реального времени
могут управлять медицинскими встроенными устройствами, которые применяются,
например, миротворцами в "горячих точках" планеты. Информация, которая поступает
от датчиков в этом случае, может быть обработана за время, соответствующее
промежутку между "двумя ударами сердца". Эти продукты могут также использоваться в
качестве интерфейса, связывающего наборы аналоговых данных (например, голос либо

Управление процессами предметной области 185
музыка) и результаты их преобразования в цифровые данные, которые могут быть
сохранены на винчестере либо записываемом диске CD-ROM. Все ПО реального
времени создается специально для целевого аппаратного обеспечения, совместно с
которым оно будет применяться в дальнейшем.
ПО из класса продуктов с минимальной задержкой, должно разрабатываться с учетом
ограниченного запаса времени, выделяемого на его выполнение. Примером
подобного ПО является программа для ATM-компьютера, а также выполняющая
верификацию кредитных карточек при выполнении заказов через Internet. Большая часть
программных продуктов из этого класса являются частью деловых либо индустриальных
программных продуктов.
Научные программные продукты имитируют действия, происходящие в реальном
мире, с помощью математических формул. При этом создаются математические
модели, имитирующие объекты реального мира. Например, на компьютере могут
моделироваться некоторые из летных характеристик самолета. Могут имитироваться
моря, реки и горы. Вообще говоря, моделированию и имитации может подвергаться
практически любой объект с известными характеристиками. Результатом имитации
является огромное количество вычислений, для выполнения которых может
потребоваться вычислительная мощь суперкомпьютеров. По мере совершенствования
персональных компьютеров все большее количество лабораторных экспериментов
может преобразовываться в компьютерные модели, которые в интерактивном режиме
просматриваются студентами. При этом исключаются затраты и риск, с которыми
связано проведение реальных экспериментов. К этому классу можно отнести
программный продукт Matlib, используемый при разработке больших математических
формул, Analytica (разработка крупномасштабных деловых моделей), а также Expert
Choice (разработка широкомасштабных систем принятия решений). Научные
программы обычно представляют собой наборы инструментальных средств
специального назначения, применяемые для решения различных задач.
Четыре класса систем разработки программ представляют методы, с помощью
которых может быть создан и поставлен программный продукт (с точки зрения
разработчика). Этим четырем классам соответствуют различные планы и жизненные
циклы по разработке ПО. Несмотря на то, что любой процесс разработки программного
продукта является итеративным, в реальном деловом мире в качестве основы
используется существующий портфель программных продуктов. Во время концептуальной
стадии менеджер проекта работает над концепцией программного продукта, а также
выбирает предварительный жизненный цикл разработки. Результаты более ранней
работы оказывают влияние на один или более указанных ниже системных классов
программного продукта:
1. новый программный продукт;
2. реинжиниринг существующего программного продукта;
3. интеграция компонентов;
4. "героическое" сопровождение.
Разработка нового программного продукта начинается с определения требований.
Затем производится продвижение согласно циклу'разработки ПО вплоть до момента
его поставки заказчику. При этом могут использоваться некоторые
инструментальные средства разработки, а также возможные объектные библиотеки (при
необходимости). В этом случае создавался поистине новый программный продукт, в котором

186 Глава 5
использовались преимущества новой технологии (Internet), а также нового набора
инструментальных средств программирования (Java). Также открываются новые
ниши рынка, поскольку принимаются новые постановления государства, например, в
области телекоммуникаций либо касающиеся отмены жесткого регулирования
банковской деятельности.
Реинжиниринг существующего программного продукта проще, чем разработка новых
программ. Для подобного рода продуктов изначально используется либо устаревшая
технология программирования, либо устаревшее аппаратное обеспечение. Примером
программы подобного рода может служить система сбора данных (реализованная на
базе DOS), которая была переработана для использования в среде Linux. Процесс
использования доступных программных продуктов (commercial-ofF-the-shell, COTS) с
последующей их интеграцией в программный продукт именуется интеграцией компонентов. В
качестве примера программы этого типа может служить сконструированный на базе
доступного встроенного инструментального средства разработки баз данных,
инструмента генерирования сценариев, а также графического интерфейса пользователя (GUI)
генератор, позволяющий создавать новый программный продукт, используемый для
интеграции промышленного оборудования в глобальную производственную систему.
Этап "героического"сопровождения начинается в том случае, если компания пытается
"втиснуть" последний "выигрышный" бит в существующий программный продукт,
который бы подвергнут переработке. Компании по производству ПО проявляют
большое внимание вопросам менеджмента и своевременного выпуска новых версий
программ, реализующих на практике дополнительные возможности внутри
существующего портфеля программных продуктов. Если разрабатывается совершенно новый
программный продукт либо подвергается коренной переделке старый продукт, всегда
существует риск уменьшения существующего уровня продаж, вместо привлечения
новых покупателей. Своевременные решения могут реализовываться по причине
задержки выпуска новых программных продуктов. Они могут представлять собой
версии старых программных продуктов, на которые в результате осуществления
"героических усилий" была "надета новая одежда". Например, обратимся к "старой
доброй" DOS: вместо переделки всей системы интерфейс командной строки был
просто заменен псевдографическим интерфейсом. Подобная методика в программной
индустрии известна под названием "та же собака, но новый ошейник".
Первая матрица, разрабатываемая менеджером проекта, включает
идентификацию типа предметной области программного продукта (рис. 5.3). Этот тип
предметной области находится на пересечении шести классов предметной области
программного продукта и классов типа программ. При этом ПО может быть определено
таким образом, что будет указываться в нескольких ячейках рассматриваемой
матрицы. Например, предположим, что разрабатывается новый программный продукт,
использующий возможности Web, который будет применяться для регистрации личных
DVD-дисков в торговом клубе, где зарабатываются очки для займа (либо
выплачивается небольшой гонорар в случае, если количество очков будет недостаточным). Этот
продукт будет "жить" стараниями заказчика, а классы предметных областей
своевременного программного продукта в данном случае представляют собой как новый
программный продукт, так и результат интеграции компонентов. И хотя концепция про-
1-р:тты относится к числу новых, г* также может быть разра&отано новое /ТО, Доступны
многие разработанные ранее библиотеки компонентов. В матрице, представленной
на рисунке, соответствующая ячейка помечена "крестиком".

Управление процессами предметной области 187
В качестве другого примера может служить расширение возможностей
существующего программного продукта, встроенного в производственный процесс, для
включения информации прошедших этапов процесса, а также определения
оптимального процесса, используемого при производстве программного продукта. При
этом используются данные относительно производственной прибыли в прошлом,
а также заказы клиентов. В этом случае можно сразу же сказать, что речь идет о
переработке программного продукта, но при этом будет также разрабатываться
новое ПО. Разрабатываемый продукт может затрагивать четыре класса
предметных областей: деловой, индустриальный, режим реального времени, а также
научный. Причина использования делового класса заключается в том, что в данном
случае выполняется оценка хронологической информации, касающейся оценки
производственной прибыли. Причина использования индустриального класса и класса
режима реального времени состоит в том, что речь идет об автоматизированном
оборудовании, установленном на фабрике. Наличие научного класса объясняется
тем, что используются алгоритмы оптимизации, необходимые для определения
лучшего индивидуального потока производства продукта на рассматриваемой
фабрике. Сказанное представлено на примере матрицы в виде буквы 'О' в
соответствующих ячейках матрицы.
1. Идентификация типа
предметной области продукта
Разработка нового
аппаратного/программного продукта
Реинжиниринг существующего
продукта
Интеграция компонентов
Героическое сопровождение
I
II
%
Рис. 5.3. Шаг 1 —идентификация типа предметной области
программного продукта
Третий этап определения предметной области процесса заключается в
назначении классов компонентов продукта. Обзор этого набора классов также производился
с точки зрения конечного пользователя. Класс насчитывает всего шесть
составляющих элементов, а ключевой вопрос в данном случае звучит следующим образом:
"Поставку каких компонентов должен ожидать заказчик?" В обязанности менеджера
по разработке ПО входит получение ответа на вопрос относительно ожиданий
конечного пользователя в области разработки продукта. Всего же существует шесть
классов компонентов продукта:

188 Глава 5
1. ПО;
2. аппаратное обеспечение;
3. человеческий фактор;
4. база данных;
5. документация;
6. процедуры.
Если в ходе осуществления проекта разрабатывается "чистый" программный
продукт, конечный пользователь вправе ожидать получить набор установочных
носителей ПО либо ключ доступа к удаленному узлу, позволяющий загрузить программный
продукт. Именно этим способом большинство потребителей приобретают ПО —
полученные элементы представляют собой носитель данных либо цифровой файл.
Многие программы готовы к сдаче "под ключ", причем разработанное ПО
интегрировано в состав аппаратного обеспечения. Так, при покупке мобильного телефона
непроизвольно приобретается сопровождающее ПО. Хотя и программы являются
критическим системным компонентом, потребитель приобретает аппаратное обеспечение.
"Человеческий фактор" является критической частью многих программных
продуктов. Корпоративные программные системы, используемые при осуществлении
финансового менеджмента, контроля над работой предприятия, а также при
разработке продукта, предполагают оказание консультационных услуг, чтобы быть
"приобретенными" наряду с ПО, предназначенными для облегчения установки
программ, проведения интеграции, а также адаптации к условиям специфической среды.
Несмотря на то, что продукты баз данных самым очевидным образом принадлежат к
IIO, они выделены в отдельный класс в соответствии с ожиданиями, сопровождающими
приобретение этого класса сложных программ. Программный продукт базы данных
обычно приобретается в виде отдельного набора инструментов общего назначения,
используемого в качестве дополнения к другим информационным системам. Многие
"программные" продукты поставляются в виде внедренного пакета базы данных,
входящего в состав продукта. Для заказчика в этой ситуации важно то, что он может не
только приобрести "новое" ПО, но также получить доступ к продукту базы данных.
Практически всегда неотъемлемой частью поставляемого продукта является
документация. В некоторых случаях она может прилагаться в виде книг и руководств,
которые приобретаются в комплекте с готовой программой. При загрузке из Internet
цифровые файлы могут включать файл "readme", а также, по возможности, полный
комплект документации для данной копии программного обеспечения. При получении ПО
из некоторых источников, таких как SourceForge (www.SouceForgo.com), может
отсутствовать какая-либо другая документация, отличная от исходного кода программ.
Процедуры либо деловые правила представляют собой финальный класс
компонентов. В случае, когда заказчик приобретает системы и программное обеспечение,
используемое для поддержки принятия решений, контроля оборудования, а также
интеграции компонентов. При этом заказчику важно представлять готовые модули
какой-либо процедуры. Обычно при заказной разработке привлекаются собственные
силы либо консультанты, приглашенные из компании по разработке программного
обеспечения. Эта область является "весьма серой", поэтому важно, чтобы менеджер
проекта понимал назначение всех сборочных узлов проекта, причем еще на ранней
стадии жизненного цикла разработки ПО. Особенно важно обращать внимание на те
компоненты, которые могут вызвать неудовольствие пользователя.

Управление процессами предметной области 189
Теперь, когда был определен третий набор классов предметной области,
менеджер проекта может заносить сведения, как минимум, в две матрицы. После
заполнения следующей матрицы возможна идентификация критических компонентов
продукта, как показано на рис. 5.4. Данная матрица представляет собой таблицу, в
которой устанавливается соответствие между классами компонента продукта с классами
систем продукта. В этой матрице поддерживается информация о промежуточных
компонентах определенного продукта, которая видоизменяется в зависимости от
того, разрабатывается ли новое ПО, выполняется ли переработка существующих
программ, реализуется ли интеграция компонентов продукта, либо выполняется
"героическое" сопровождение наследственного продукта в составе портфеля
компании. Помните о том, что Web-пример обозначается литерой 'X1, а интеграция в
составе фабрики — литерой 'О'.
2. Идентификация критических
компонентов продукта
Разработка нового
аппаратного/программного продукта
Реинжиниринг существующего
продукта
Интеграция компонентов
Героическое сопровождение
о
X
0
0
X
Аппаратное
обеспечение
Люди
0
о
База данных
0
0
1
X
0
0
X
Процедуры
О
о
Рис. 5.4. Шаг 2—идентификация критических компонентов продукта
Например, вернемся к нашему программному продукту, основанному на
использовании Web, который предназначен для регистрации вашей личной фильмотеки,
размещенной на DVD-ROM. Этот продукт определяется в качестве нового продукта и
интеграции компонента. В роли критических компонентов данного продукта выступают
ПО и документация. Этот продукт основан на использовании Web и выполняется в
окне броузера, запущенного на выполнение на оборудовании заказчика. При этом
заказчик)' не доступна база данных, персонал разработчиков либо код процедур. Для
него доступна лишь документация в виде инструкций на Web-страницах.
Другим примером продукта является расширение возможностей существующего
программного продукта, причем в этом случае происходит переработка существующего
продукта и разработка некоторого нового ПО. Основываясь на прогнозе относительно
объема продаж разработанного продукта, заказчик может видеть все классы
компонентов, за исключением аппаратного обеспечения. Он может ожидать поставку ПО, а
также то, что инженер по эксплуатации выполнит установку и тестирование пригодности
на предприятии заказчика. Заказчик также может заказать разработку базы данных

190 Глава 5
с целью поддержки состояния продукта, относящегося к классу реального времени, а
также информацию о затратах и процедуры, предназначенные для реализации
алгоритмов оптимизации. Документация будет иметь значение для инженеров компании,
выполняющих установку ПО, а также заказчиков после того, как продукт будет принят.
Третья матрица, создаваемая менеджером проекта, предназначена для
определения предметной области, которая связана с предметными областями продукта для
производимых компонентов. Эта матрица представлена на рис. 5.5 в виде таблицы, в
которой классы компонентов продукта сопоставляются с классами предметной
области продукта. Эта матрица поддерживает сведения относительно промежуточных
компонентов определенного продукта, основываясь на которых можно установить
продукты, относящиеся к следующим предметным областям: деловой,
индустриальной, режима реального времени, продукта с минимальной задержкой либо научной.
А теперь снова обратимся к нашим примерам: программный продукт, основанный на
Web, предназначенный для регистрации в торговом клубе персональных фильмов на
DVD-ROM, что позволит "оживить" их для заказчиков. В данном случае мы имеем дело с
классом предметной области продукта с минимальной задержкой. При этом в качестве
поставляемых продуктов выступают ПО и документация. Второй пример представляет
собой расширение возможностей существующего продукта, т.е. интеграцию в
производство. При этом затрагиваются четыре класса предметной области продукта: деловой,
индустриальный, режима реального времени и научный. В качестве поставляемых
компонентов выступают ПО, персонал, база данных, документация и процедуры.
В главе 4 производится описание наиболее часто применяемых жизненных
циклов разработки ПО, а также приводятся критерии выбора для каждого из них. При
выполнении сравнения жизненных циклов производства продукта и компании в
целом, предполагается, что жизненный цикл разработки ПО включен в состав фазы
получения для жизненного цикла продукта. Все это иллюстрируется на рис. 5.5.
3. Связь предметных областей
продукта с компонентами
Потребитель
Бизнес
Индустрия
Режим реального времени
Режим минимальной задержки
Наука
о
X
0
0
0
X
0
Аппаратное
обеспечение
Люди
0
о
0
0
База данных
0
0
0
0
Документация
X
0
о
0
X
0
Процедуры
0
0
о.
0
Рис. 5.5. Шаг 3 —связь предметных областей продукта с компонентами

Управление процессами предметной области 191
Менеджер проекта должен иметь представление относительно взаимосвязей в
собственной организации, занимающейся разработкой ПО, используя жизненные
циклы разработки продукта. Типичный жизненный цикл разработки продукта
начинается с его разработки либо приобретения. Этап разработки продукта представлен
на рис. 5.6. На этом этапе менеджер проекта работает совместно с менеджером
программного продукта, разрабатывая план производства программного продукта.
Именно на этом этапе осуществляется производство. Производятся инвестиции в
инфраструктуру, обеспечивающую производство программного продукта, а также
создаются первые программы. После завершения производственного этапа
программная часть продукта выходит из-под контроля менеджера программного проекта,
исключая те случаи, когда необходимо устранить ошибки.
Рис 5.6. Жизненный цикл разработки ПО
На рис. 5.7 изображен жизненный цикл разработки продукта в целом, причем по
оси абсцисс представлены месяцы, а по оси ординат—сумма инвестиций (в тыс. долл.).
Левая часть графика, а также та часть, которая находится ниже нулевой линии,

192 Глава 5
представляет собой результаты оценки размера инвестиций для данного
продукта. Часть графика, находящаяся выше нулевой линии, представляет собой
результаты оценки дохода, который может принести данный продукт. Подобная
информация обычно предоставляется отделом маркетинга и представляет собой
критическую часть процесса возврата инвестиций, реализуемого с помощью
данного продукта.
И наконец, на рис. 5.8 в графическом виде представлена взаимосвязь между
жизненными циклами разработки и продукта. Эта взаимосвязь должна
учитываться менеджером проекта, участвующим в процессе разработки продукта. В
мире продуктов жизненный цикл продукта определяет принятие решений и
выполнение инвестиций. Для менеджеров продуктов, планирующих портфели
продуктов, наиболее важной в жизненном цикле разработки ПО является часть,
связанная с инвестированием.
300
250
200
150
100
50
0
-50
-100
-150
-200
Начальная производственная стадия
■f
Разработка
Рост рынка
Зрелость рынка
Уход продукта
с рынка
22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67
Месяцы
Рис. 5.7. Жизненный цикл разработки ПО
Модели выбора проектов
Процесс выбора проектов является ключевым деловым процессом. К тому же
он жизненно важен для поддержки текущего "экономического здоровья"
организации. В этом процессе участвуют менеджеры проектов, менеджеры линий
продуктов, руководители подразделений, а также все участники совместного дела,
которые принадлежат либо не принадлежат к коммерческой организации.
Определение нужного количества участников совместного дела, вовлеченных в
определение и выбор проекта, является критичным для успешного осуществления
разработки проекта.

Управление процессами предметной области 193
Начальная производственная стадия
Рис. 5.8. Жизненные циклы разработки и эволюции программного продукта
Акционер Менеджмент Заказчики
Рис. 5.9. Карта организаторов совместного
дела для мастного предприятия
В состав коммерческой организации входят служащие и служба менеджмента.
Большая часть структур, связанных с организаторами совместного дела, находится
вне организации. Организаторы совместного дела непосредственно заинтересованы
в финансовом успехе организации. Естественно, что они хотели бы, чтобы
выбранные проекты обеспечивали адекватный возврат вложенных средств. Заказчики
заинтересованы в том, чтобы версии реальных продуктов удовлетворяли их потребности
при минимальных затратах. Заказчики не готовы воспринимать идеи относительно
изменения программных средств, исходящие от компетентных поставщиков. Это
связано с тем, что объем внутреннего переключения "затрат", связанных с
изменениями, является чрезвычайно большим.
Поставщики организации являются организаторами совместного дела в том смысле,
что они продолжают поддерживать команды разработчиков, создавших лучшие
программные либо аппаратные продукты. Такие компании, как Microsoft, Sun и Oracle,

194 Глава 5
разрабатывают обширные программы для своих партнеров по разработке, а затем
работают с ними "рука об руку", продуцируя специфичные индустриальные продукты. Причем
в этом случае применяются их собственные внутренние инструменты разработки.
Правительство тоже является организатором совместного дела, принимающим
участие в принятии решений по потребительским продуктам. Причем иногда его
активность превышает все мыслимые пределы. Правительственное регулирование
затрагивает не только стратегии, связанные с продуктом, но также и относится к самим
работникам. Причем в последнем случае регулируется весьма широкий диапазон
вопросов, например, обеспечение безопасности рабочих мест, иммиграционное
законодательство, регламентирование работы с опасными материалами и т.д. Многие
программные продукты проходят через длительный процесс получения одобрений
от правительственных агентств, поскольку они будут применяться в медицинских
приборах, обеспечивать безопасность летательных аппаратов, а также обеспечивать
мониторинг опасных материалов.
И наконец, конкуренты выступают в роли своего рода "организаторов
совместного дела" при выработке критериев выбора продукта. Хотя они и не имеют "права
голоса", решения, выработанные в пределах одного и того же рынка, влияют на
решения, принятые при разработке новых продуктов. Ошибки конкурентов могут
открыть дорогу на рынок новому продукту. Весьма качественный продукт наравне с
группой верных клиентов может служить в качестве модели для организации,
которая будет выпускать похожий продукт для другого сегмента рынка. Конкуренция
также оказывает влияние на работников, изменяя объем их трудозатрат с целью
отбора лучших специалистов.
Рассматриваемые менеджеры проектов в общедоступном секторе обладают
подобной картой организаторов совместного дела, которая может использоваться в
работе. Эта взаимосвязь иллюстрируется на рис. 5.10.
Граждане "менеджмент Граждане
(избиратели) (заказчики)
/ Правительственная \
( организация Поставщики
N. Служащие у/
Рис. 5.10. Карта
правительственных организаторов совместного дела
Внутренняя структура коммерческих организаций является весьма сходной. А
внешние организаторы совместного дела довольно сильно отличаются друг от друга.
Природа же правительственных организаций такова, что они подвергаются огромному
политическому давлению. Все поставщики обладают похожими позициями в качестве
организаторов совместного дела, но для каждого из них существуют различные входные
барьеры и регулирующие отношения, которые потребуется преодолеть для
выполнения ими своих обязанностей. Многие поставщики не работают с правительственными
группами разработчиков, поскольку в этом случае приходится проделывать огромный
объем "бумажной" работы, а также возникает высокий риск, связанный с завершением
объединения проектов, относящихся к правительственному и частному секторам.

Управление процессами предметной области 195
В приведенной карте организаторов совместного дела конкуренция играет весьма
важную роль. Правительственные агентства озабочены проблемами, связанными с
конкуренцией со стороны либо "приватизированных" учреждений, таких, например, как
почтовое ведомство США. Также разрабатываются законы, поощряющие конкуренцию
со стороны ранее регулируемых областей индустрии, таких как банковское дело либо
телекоммуникации. Менеджер проекта, работающий в правительственной
организации, особое внимание должен уделять грядущим изменениям в регулировании и
трудозатратам. Как и в частном секторе индустрии, конкуренция обеспечивает привлечение
лучших работников. Многие компании рассматривают общественный сектор в качестве
своего рода "питомника", где взращиваются лучшие технические кадры.
После отметки на карте организаторов совместного дела на уровне
организации, специфичных для данного проекта, начинает выполняться следующий
процесс, который заключается в определении критериев выбора проекта. При
осуществлении процесса выбора производится оценка отдельных проектов либо групп
проектов, а затем выбираются те из них, реализация которых обеспечивает
достижение целей организации. В данном практическом руководстве не
рассматривается, каким образом устанавливаются цели и задачи организации. При рассмотрении
процесса предметной области, присущего этапу выбора проекта, предполагается,
что менеджер проекта и команда сотрудников, выполняющих работу по выбору
проектов, правильно понимают текущие цели коммерческой либо
правительственной организации. Если подобные цели до сих не сформулированы, процесс должен
быть прерван до тех пор, пока они не будут определены.
Процесс выбора проекта должен основываться на четко сформированной
стратегии, как правило, он осуществляется стараниями более чем одного отдела организатора
совместного дела. Процесс выбора проекта на практике реализуется благодаря усилиям
междисциплинарной команды. Использование подобной команды диктуется тем, что
требуется достаточное количество информации, общей для всех проектов и областей
продукта. Благодаря этим сведениям становится возможным принятие четких решений,
связанных с процессом выбора проектов. На процесс выбора проектов большое
влияние оказывает возможный риск (риск на этапе разработки и риск при осуществлении
продажи). То есть потребуется ответить на следующие вопросы: "Может ли быть
разработан продукт?" и "Может ли быть продан разработанный продукт?"
А для принятия решения по поводу выбора проектов потребуется ответить на
целый ряд следующих вопросов.
1. Какие организаторы совместного дела вовлечены в процесс принятия решения
по поводу выбора проекта?
2. Какова степень ознакомления членов команды с технологией, применяемой при
изготовлении продукта?
3. Насколько Хорошо члены команды осведомленных относительно рынка данного
продукта?
4. Какова степень сложности технологии, применяемой для создания продукта?
5. Насколько сложен продукт для объяснений конечному пользователю?
6. Каков опыт организации в разработке подобных типов продуктов?
7. Насколько велики предполагаемые трудозатраты, необходимые для разработки
продукта?

196 Глава 5
8. Каким образом определяется жизненный цикл проекта?
9. Каким образом определяется жизненный цикл продукта?
10. Какова величина риска на этапе разработки продукта?
11. Возможный риск при разработке данного продукта?
12. Насколько высок приоритет данного проекта?
13. Является ли проект своего рода оперативной необходимостью, (поддержка
существующих систем организации)?
14. Служит ли проект поддержания необходимого уровня конкуренции?
15. Как соотносится данный проект с текущими проектами?
Ответы на эти вопросы образуют основу модели выбора проекта организации.
Применяемый при этом типичный метод требует от команды, реализующей выбор
проекта, просмотр документа определения требований, созданного на этапе
исследования концепции, а также во время формирования ответов на приведенные выше
вопросы. Как только достигается требуемый консенсус, выполнение проекта перейдет
на следующий этап, когда должны быть назначен менеджер проекта и определен
собственник организации. Также должен быть разработан предварительный план
менеджмента программного проекта и установлена среда разработки проекта.
Менеджмент проектов
Всем проектам присуща определенная начальная и конечная фаза. Их
определение основывается на создаваемых сборочных узлах. Портфель проектов представляет
собой группу проектов, относительно которых реализуется спонсорство и/или
менеджмент со стороны организации. Группировка проектов производится в силу
следующего ряда причин:
■ принадлежность к одному и тому же семейству продуктов;
■ устранение дефицита ресурсов;
■ взаимная независимость между сборочными узлами проекта и промежуточными
компонентами, проявляющимися на этапе разработки;
■ наличие нескольких противоречащих друг другу целей организации;
■ критерии выбора являются количественными либо качественными, причем при
их определении учитываются специфические цели организации;
■ влияние политических интересов.
При выборе проектов могут применяться различные модели. Эти модели должны
быть связаны со стратегией корпорации, в отличие от простой максимизации дохода
либо продвижения единственного продукта. Благодаря группировке проектов в виде
портфелей процесс разработки ориентируется на преобразование из хаотического в
управляемое состояние с помощью стратегической концентрации на продукте.
Портфель проекта определяет стратегический процесс предметной области
внутри организации. Этот процесс весьма специфичен в для различных организаций.
В этом случае абсолютно необходим исполнительный менеджмент, определение
направления, фокуса, а также распределение бюджета. Необходима регулярная
корректировка модели портфеля проектов для гарантирования того, что адаптированная
стратегия соответствует текущей деловой и экономической среде.

Управление процессами предметной области 197
В моделях портфелей проектов учитываются относительные значения проектов, а
также взаимодействия между ресурсами. Эти модели могут быть специальным образом
приспособлены для более оперативного отклика в ответ на условия рынка (портфели,
управляемые рынком). При включении проекта в портфель можно использовать
простое правило — исключать любой проект, норма прибыли которого меньше 15%.
Модели портфеля проектов могут использовать широкое определение проекта, а также
включать большое число необязательных проектов лишь для выполнения сравнения.
При выборе этого типа модели портфеля используется двухточечное сравнение
атрибутов проекта с помощью таких методов, как аналитический иерархический процесс.
Важно правильно понимать суть трех классов моделей портфеля проектов. Первая
из них представляет собой чистую модель экономической прибыли, в которой
финансовые измерения применяются для определения нормы прибыли, чистой
приведенной стоимости, маргинальной стоимости капитала, прибыли на инвестированный
капитал, величины активов и инвестированного капитала, а также средневзвешенной
стоимости капитала (Weighted average cost of capital, WACC). На рис. 5.11
демонстрируется простейший случай применения этой модели. На протяжении какого-то
периода времени, строка, отслеживающая стоимость развертывания активов,
возрастает и устанавливается в соответствии с показателем WACC. Проекты, показатель
нормы прибыли которых превышает уровни для перемещающейся линии WACC,
обеспечивают получение прибыли, превышающей значение WACC. Если же данный
показатель меньше, чем показатель WACC, рекомендуется завершить проект. Эта
модель может применяться при отслеживании трендов, а также для составления
прогноза относительно будущих затрат, понесенных при развертывании активов. В
приложении С приводятся подробные сведения относительно всех финансовых
измерений, используемых в экономической модели выбора проекта.
Стоимость
развертывания активов
^> = Линия КОИ проекта
Время
Рис. 5.11. Выбор проекта в модели экономической прибыли
В экономической модели включение либо исключение проекта из портфеля
основывается на том, каким образом выполняется относительный "барьерный рейтинг".
В качестве этого рейтинга может применяться любой из показателей нормы
прибыли, применяемый при выполнении оценки. В примере, приведенном на рисунке,
1 Saaty Thomas L. "Multicriteria Decision Making." The Analytic Hierarchy Process: Planning Priority
Setting, Resource Allocation. Volume 1, AHP Series, extended edition. NY: McGraw-Hill, 1990.

198 Глава 5
применяется показатель WACC. Причем этот показатель вычисляется для каждого
проекта, а затем отображается на графике. Поскольку показатель WACC представляет
собой процентное соотношение, потребуется нарисовать другую линию,
определяющую стоимость развернутых активов. В роли подобной линии, построенной на базе
WACC, выступает линия, соответствующая коэффициенту возврата инвестиций
(KOH)(Return of investment, ROI). Проект, попадающий в область, которая находится
ниже линии ROI, может быть прекращен в любой момент времени. На рис. 5.11
показано, что проекты 2, 3 и 5 могут быть прекращены, поскольку попадают в область,
находящуюся ниже линии ROI. Проект 3 может быть оценен, поскольку он остается
выше точки, равной стоимости развернутых активов.
Модели "затраты-прибыль" представляют собой второй класс моделей оценок
портфеля. Используя методики анализа "затраты-прибыль", эти модели применяются
при сравнении альтернативных проектов, когда некоторые преимущества
практически неощутимы (как для внутренних, так и для общедоступных проектов). Для
каждого проекта определяются относительные преимущества, которые затем умножаются
на величину затрат/относительных затрат. Затем происходит распределение
проектов в соответствии с рейтингом "прибыль-затраты", когда лучшими считаются
большие показатели рейтинга.
Модели исследования рынка представляют собой третий класс моделей оценок
портфеля. Они применяются исключительно при разработке новых продуктов.
Неадекватный анализ рынка является основной причиной неудач при разработке
продуктов. Ниже перечисляются некоторые методики, применяемые при исследовании
рынка: выделенные группы, обзор рынка, панели потребителя и тестовый маркетинг.
Как только принято решение относительно модели портфеля проектов, следует
определить метод учета результатов, связанных с ней. При реализации техники
взвешенного измерения определяется для каждого процесса измерения определяются
свои параметры, а команда, выполняющая выбор портфеля проектов, учитывает
результаты измерений для всех проектов. Затем вычисляется среднее значение суммы
взвешенных результатов измерений для каждого проекта и происходит
ранжирование проектов в соответствии с вычисленными результатами. Матрицы портфеля
проектов применяются для отображения данных по решениям, принятым в рамках
проекта, используя два либо три возможные степени риска, величину проекта,
затраты, а также другие факторы.
Наравне со взвешенным измерением превосходно работает модель
количественной оценки Delphi. При этом доступны преимущества экспертных решений,
используемые при аттестации уникальной модели портфеля проектов организации.
Сведения, полученные в ходе проведения экспертизы уполномоченными специалистами,
способствует взаимодействию между членами группы, изолированными друг от друга.
Благодаря этому предотвращается возможность доминирования в дискуссии
влиятельных членов группы. Эксперты представляют собой отдельную группу, а общение
с ними осуществляется с помощью анкетных листов, в которых изложены мнения
экспертов. Анкетные листы распространяются на анонимной основе среди всех
членов группы. После каждого раунда опроса информация обобщается и повторно
распространяется на анонимной основе среди всех членов группы. Благодаря
использованию подобной стратегии повторного опроса максимизируются преимущества,
связанные с принятием решений в группе, а также ограничивается влияние некоторых
негативных факторов.

Управление процессами предметной области 199
Квалифицированный маркетинг предполагает комбинирование в
оптимизированных моделях методик выбора, оценки, аттестации и презентации. В ходе
выполнения оптимизации учитываются ограничения ресурсов и взаимозависимость многих
факторов. Результатами оптимизации являются максимизация отдачи при
достижении специфических целей, а также подготовка оптимального продукта и графика
ггроекта. Все это укладывается в схему выбора портфеля, при реализации которой
процесс имеет следующие характеристики:
■ простота (обоснованность шагов);
■ гибкость (пользователи могут выбирать свои любимые модели);
■ повторяемость (различные аналитики могут "приближаться" к одному и тому же
результату);
■ документированность (описываются методы принятия решений);
■ расширяемость (ограничения среды будут изменяться).
Финансовые аспекты
И наконец, последний процесс предметной области, который следует осознать
менеджеру проекта, — это учет финансовых аспектов проекта. Многие из методик,
включенные в экономические модели выбора, уже рассматривались ранее, а также
будут рассматриваться в приложении С. Наиболее широко применяемые методики
показаны на рис. 5.12.
CrpyiovDaCOGS
Торг
звые издержки
Административные затраты
Наличные средства
Olt
Факторы стаб
1адвишириь
Реестры
ильности рынка
Машины и обору/:
Другое
Земля
Здания
ование
Продажи
*
\
\
4
Общие
затраты
Чистый доход
1
Оборотные
фонды
+
*
Основные
активы
А
Т
Продажи
1
Величина
чистой прибыли
*
х ••
Т
А
1
Сумма баланса
*
Оборот
балансовой суммы
Структура КОИ
Рис. 5.12. Финансовая модель DuPoint
В общем случае каждый процесс выбора проекта либо решение относительно
критерия анализа портфеля проектов, оказывающие влияние на цены продукта,
стоимость единицы продукта, объем либо эффективность, будет определять величину
прибыли или коэффициент оборота. И любое решение, оказывающее влияние на
величину и вид долга, а также на величину собственных средств, будет оказывать
влияние на финансовую структуру в той же степени, как это происходит с величиной

200 Глава 5
стоимости. Финансовые аналитики предметной области и фининспекторы во многих
организациях применяют подобную методику анализа для принятия решений
относительно финансирования проектов.
Несомненно, что для менеджеров проектов и специалистов по маркетингу
продукта весьма важным является правильное понимание основных финансовых
концепций, без чего была бы невозможной квалифицированная помощь заказчикам,
которых тоже можно отнести к организаторам совместного дела, и успешная
реализация выполняемых проектов и разрабатываемых продуктов.
Резюме
Процессы предметной области представляют собой взаимосвязанные действия,
имеющие свою специфику при использовании в организации, в которой был
разработан программный проект. Оценка качества программного проекта основывается на
том, насколько хорошо ПО решает проблемы, связанные с предметной областью. Для
заказчиков программ актуальна точка зрения, связанная с их деловой предметной
областью. Для специалистов же в области информатики и инженеров-программистов
актуальна другая точка зрения. Ставя во главу угла задачу создания качественного ПО,
менеджер проекта должен иметь адекватное представление относительно
предметной области, специфические потребности которой удовлетворяет ПО.
Процессы предметной области являются общими для всех организаций, в которых
существуют определенные критерии для моделей выбора проектов, анализа портфеля
проектов, а также реализуется взаимодействие между основными финансовыми
коэффициентами, применяемыми при анализе проектов. Все общие действия, реализующие
менеджмент процессов в предметной области, рассматривались в данной главе.
При управлении процессами предметной области требуется выделение проекта
разработки ПО внутри организации. На рис. 5.1 показано, каким образом связаны
жизненные циклы корпорации, продукта и проекта. В ходе выполнения
корпоративного делового цикла производится множество продуктов. Эти продукты имеют
отношение к различным фазам цикла в один и тот же момент времени. Жизненный цикл
продукта начинается после того, как была идентифицирована потребность и начала
реализовываться концепция проекта. В экономически стабильной организации
одновременно могут производиться несколько продуктов, а также может осуществляться
разработка нескольких проектов. Каждому продукту может соответствовать один или
большее количество проектов, выполняемых одновременно с целью формирования
семейства продуктов.
Менеджер проекта должен уметь определять критерии, применяемые при выборе
проектов. Как правило, количество проектов превышает объем ресурсов, требуемых
для выполнения этих проектов. Одной из ключевых тем, рассматриваемых в главе,
явилось определение этих критериев, а затем их объединение в виде модельной
структуры, применяемой в ходе принятия решений. Способность к анализу портфеля
проектов и выбору "лучшего" из них, исходя из всей доступной информации,
является весьма важным навыком, которым должны владеть все менеджеры проектов. В
ходе менеджмента проектов все они рассматриваются с точки зрения срока возврата
инвестиций, который, в свою очередь, основан на эффективности нормы прибыли
внутри организации. Подобный финансовый взгляд на процесс выбора проектов
является актуальным практически для всех организаций. Управление проектами в этом
случае происходит с помощью универсального средства оценки, т.е. с помощью денег.

Управление процессами предметной области 201
Контрольные вопросы
1. Вы занимаете должность менеджера проектов в новой компании, занимающейся
разработкой программных инструментальных средств. В данное время вы заняты
разработкой своего первого продукта. Каким образом в этом случае может помочь
менеджмент выбора проектов?
2. Используя матрицы категоризации предметной области, определите предметную
область для каждого из следующих продуктов:
a) расширение системы паролей вашей компании;
b) новая навигационная система, предназначенная для последней модели
частного самолета Цессна, снабженного одним двигателем;
c) дополнительный модуль СГП (GPS) для операционной системы Palm,
устанавливаемой на новый Palm Pilot;
d) новый код, предназначенный для управления автоматической коробкой
передач в автомобиле, Ford Explorer.
3. Каким образом может применяться модель DuPoint в правительственной
организации?
4. Каким образом вы будете планировать менеджмент проектов в случае, если
вы, например, являетесь менеджером информационных ресурсов в офисе
Главного прокурора штата?
Практическое занятие
Несмотря на возражения со стороны менеджера отдела маркетинга, ваш босс
принял план 1074 для моделирования жизненного цикла. При этом проблемой,
является то, что ваш CASE-инструмент остается элементом строки бонус-плана,
составленного управляющим вашей деловой единицы. В этой ситуации можно
воспользоваться нужным жизненным циклом, но при этом придется применять корпоративный
CASE-инструмент для всех процессов поддержки. Каким образом вы будете изменять
план проекта с целью использования инструмента xTRemeObjectMaker? Влияет ли
заключительный поставляемый продукт на план СРМ? Что можно сказать о затратах,
если вы намереваетесь установить прототип и предложить работу над проектом за
определенную цену? На данный момент таблица затрат еще не подготовлена для
xTRemeObjectMaker, но затраты в данном случае сопоставимы с затратами системной
лицензии на разработку одного узла Oracle.
Дополнительные сведения в Internet
quote. yahoo. com/. Web-узел Yahoo!, содержащий финансовые данные, имеющие отношение ко
всем типам корпораций.
www. investoxguide.com/EDGAR.htm. Поисковый механизм, использующий информацию типа
EDGAR и создающий индексы в реальном режиме времени, облегчающие выборку.
www.sb.gov.bc.ca/smallbus/workshop/sample.html. На этом Web-узле содержатся
образцы бизнес-планов.

Отбор команды
разработчиков проекта
Отбор участников команды разработчиков проекта происходит на ранних стадиях
жизненного цикла разработки ПО. Селекция членов команды, формирование
коллектива разработчиков, а также способ организации технической поддержки
оказывают немалое влияние на все остальные действия жизненного цикла разработки ПО.
В главе изложены основные принципы формирования команды разработчиков,
приведены советы относительно того, как наилучшим образом использовать
индивидуальные особенности разработчиков и общий потенциал команды для достижения
положительного максимального эффекта в процессе совместной деятельности.
Зачастую участники команды разработчиков демонстрируют самые разные
поведенческие характеристики, присущие тем или иным типам личности. Некоторые из них
являются продуктивными, другие выглядят нефункциональными, а некоторые внезапно
проявляющиеся личностные характеристики могут оказать критическое воздействие на
процесс достижения целей проекта. Если руководитель команды выявляет наличие
каких-либо конфликтов между ее членами, в его власти прибегнуть к увольнению и нанять
новых разработчиков проекта. Однако в нашем мире за все приходится платить: любое
изменение состава группы потребует повторного прохождения стадии формирования
рабочей команды прежде, чем команда сможет делать что-либо стоящее.
Личностные качества команды определяются с помощью гласных и негласных
правил и постоянно изменяющихся взаимосвязей. Изменение этих компонентов
происходит по мере того, как появляются новые члены команды либо уходят старые.
Изменения также могут происходить по мере того, как сменяются различные фазы жизненного
цикла. Обычно доминантная личность (либо две) в составе команды определяется
непосредственно после ее формирования, а динамические характеристики рабочей
группы будут практически постоянно изменяться тем или иным образом. По мере эволюции
проекта (от начального до заключительного этапа— идеального сотрудничества), в
обязанности лидера команды входит распознание признаков дисфункциональности. В этом
случае его действия должны быть направлены на то, чтобы предотвращать
нежелательные трансформации. Эта задача является весьма непростой в связи с тем, что

Отбор команды разработчиков проекта 203
человеческая психология является весьма сложной, превышающей по степени
сложности многие объекты научных исследований и технологические приемы. Но если на
подобные вопросы не обращать внимания, негативные личностные характеристики могут
внести хаос в процесс выполнения проекта, а иногда привести к тому, что отдельные
участники проекта не будут способны к дальнейшему выполнению своих функций.
В главе 29 будут описаны аспекты взаимодействия между участниками проекта, а
предметом рассмотрения главы 25 является отслеживание процесса эволюции
команды. Практическое применение этих навыков облегчается благодаря корректному
отбору членов команды, а также правильному формированию команды в начале
жизненного цикла разработки проекта. Для лучшего применения навыков лидерства по
отношению к членам команды, сначала требуется исследовать уникальные свойства
отдельных личностей, динамику команды разработчиков проекта и, наконец,
специфические навыки лидерства.
Стадии жизненного цикла разработки
продукта
Материал этой главы имеет отношение к ранним стадиям проекта, связанным с
началом выполнения работы. Однако состав разработчиков проекта постоянно
изменяется, особенно в случае больших проектов. Выбор и формирование команды
разработчиков проекта происходит на всем протяжении жизненного цикла, поэтому эти действия
можно связать с каждой фазой выполняемого проекта. Но первичное формирование
команды разработчиков проекта реализуется в самом начале работы, как показано на
рис. 6.1. Подобные действия формируют основу, необходимую для наилучшего
понимания особенностей характера отдельных личностей, а также определения личностных
характеристик команды, которые представляют собой нечто большее, чем просто
совокупность личностных признаков отдельных членов команды.
Связь главы 6 с 34 компетенциями
Отбор команды разработчиков проекта затрагивает десять компетенций.
Методики разработки продукта
1. Управление субподрядчиками— планирование, управление и осуществление
контроля над деятельностью субподрядных организаций.
2. Понимание действий по разработке продукта— изучение особенностей цикла
разработки ПО.
Навыки менеджмента проектов
3. Оценка стоимости — оценка стоимости завершения проекта.
4. Оценка трудозатрат — оценка трудозатрат, требуемых для завершения проекта.
5. Менеджмент рисков — идентификация, определение воздействия и устранение
рисков.
Навыки менеджмента персонала
6. Взаимодействие и общение — взаимодействие с разработчиками, высшим
руководством и другими командами.

204 Глава 6
7. Лидерство— обучение проектных команд с целью получения оптимальных
результатов.
8. Набор персонала — набор персонала и собеседование с членами команды.
9. Отбор команды — отбор высококомпетентных команд.
10. Создание команды— формирование, руководство и поддержка эффективной
команды.
Исследование
концепции
■Формули-"
рование

потребности
Исследование
системы
• Спецификация'
интерфейса
системы
Требования
• Спецификация;'
требований
к ПО
Разработка
проекта
Идентификация
циклов SLC
1 Описание

разработки ПО
• Циклы SLC
Внедрение
Выбор
модели
• План

тации/верификации ПО
• Модель SLC
Установка
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
Выбор модели
жизненного цикла
разработки ПО
•Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
■SLC
Распределение
ресурсов
'
Пользовательская
документация
Сопровождение
Бюджет
' Документация
по
сопровождению
_>
Здесь происходит отбор участников
команды разработчиков проекта
Вывод из
эксплуатации
• Архивный
отчет
Рис. 6.1. Отбор команды разработчиков проекта, происходящий в начале жизненного цикла
разработки ПО
Учебные цели главы 6
После изучения материала главы читатель должен уметь выполнять следующее:
объяснять важность отбора разработчиков проекта, имеющих различные черты
характера, с целью формирования команды разработчиков программного проекта;

Отбор команды разработчиков проекта 205
■ описывать модели различных свойств характера;
■ обсуждать индивидуальные стили работы, а также то, каким образом они
воздействуют на ход выполнения проекта;
■ описывать фазы командной разработки;
■ описывать способы реализации общения;
■ описывать централизованное и нецентрализованное документирование проекта, а
также эффекты, проявляющиеся при организации взаимодействия между
разработчиками проекта;
■ обсуждать стили лидерства, а также то, каким образом они сказываются на команде.
Отбор команды разработчиков проекта
Специалисты из объединенной специальной комиссии IEEE-CS/ASM, входящей
в организацию по обеспечению этики программирования и профессиональной
практики (Software Engineering Ethics and Professional Practices, SEEPP),
разработали этический кодекс программистов. Этот документ включает восемь основных
принципов.
1. Общественные интересы—действия программистов должны соответствовать
общественным интересам.
2. Клиент и работодатель — программисты должны поступать таким образом,
чтобы как можно лучше выполнять требования клиента и работодателя, но при этом
соблюдать общественные интересы.
3. Продукт— программисты должны быть уверены в том, что создаваемые ими
программные продукты и связанные с ними модификации соответствуют
профессиональным наивысшим стандартам.
4. Критицизм—инженеры-программисты должны придерживаться целостности и
независимости своих суждений, формируя здоровый профессиональный
критицизм мышления.
5. Менеджмент— менеджеры и лидеры, управляющие группами по разработке ПО,
обязаны придерживаться этических норм в процессе разработки и
сопровождения программ.
6. Профессионализм— программисты обязаны быть честными и поддерживать
репутацию профессионалов, не забывая о соблюдении общественных интересов.
7. Коллегиальность— программисты обязаны быть честными и поддерживать
своих коллег.
8. Самосовершенствование — программистам следует постоянно повышать свою
квалификацию, что способствует их профессиональному росту, а также
формирует этический подход к профессиональной деятельности.
Рассмотрим подробнее принципы 7 и 8. Следует иметь в виду, что в силу своего
положения менеджерам проектов приходится быть "кураторами" своего персонала.
В дополнение к тому, что требуется знать о наших собственных действиях, отметим,
что необходимо поощрять команду за добросовестное соблюдение этических
принципов в отношениях между собой и с другими людьми.

206 Глава 6
Принцип 7 — коллегиальность
Программисты обязаны быть честными и поддерживать своих коллег. В
частности, они обязаны учитывать следующие требования.
7.01. Стимулировать коллег относительно того, что следует жестко придерживаться
кода;
7.02. Помогать коллегам в их профессиональной деятельности;
7.03. Полностью кредитовать работу других членов команды и воздерживаться от
получения непомерно большого кредита;
7.04. Рассматривать работу других членов команды объективно, беспристрастно, а
также пользоваться при этом всей необходимой документацией;
7.05. Беспристрастно воспринимать мнения, соображения и жалобы со стороны
коллег;
7.06. Помогать коллегам в изучении современных методик работы, включая
рассмотрение политик и процедур, обеспечивающих защиту паролей, файлов, другой
конфиденциальной информации, а также обеспечивающих оценку степени
безопасности;
7.07. Не препятствовать карьерному росту коллег; однако, интересы
работодателя и клиентов либо общественные интересы могут вынуждать инженеров-
программистов к "здоровой" конкуренции по отношению к своим коллегам;
7.08. В ситуациях, когда собственной компетенции недостаточно, учитывать мнения
других профессионалов, компетентных в данных областях
Принцип 8 — самосовершенствование
Программисты обязаны учиться на протяжении всей своей сознательной жизни,
постоянно повышая профессиональный уровень. Практика этой профессии требует
соблюдения определенных этических норм и понятий. В частности, необходимо
придерживаться следующего.
8.01. Совершенствовать свои познания при выполнении анализа, разработке
спецификации, разработке проекта, программировании, сопровождении и
тестировании ПО и связанных с ним документов, а также приобретать навыки,
необходимые для осуществления процесса разработки программ;
8.02. Улучшать свои способности, обеспечивающие создание надежного,
безопасного и полезного качественного ПО за приемлемое время;
8.03. Совершенствоваться в области создания точной, информативной и написанной
в хорошем стиле документации;
8.04. Быть максимально компетентным в вопросах создания рабочего ПО и
связанных с ним документов, а также лучше изучить среду разработки;
8.05. Изучать соответствующие стандарты и правовые нормы, связанные с
разработкой ПО и относящейся к нему документации;
8.06. Постоянно совершенствовать познания в области разработки программного
кода, его интерпретации и созданных на его основе приложений;

Отбор команды разработчиков проекта 207
8.07. Ни в коем случае не давать некорректные объяснения кому бы то ни было в силу
каких-то предубеждений;
8.08. Не оказывать влияния на других исполнителей, вследствие чего могут быть
допущены ошибки в разрабатываемом программном коде;
8.09. Помнить о том, что ошибки, допущенные в программном коде, несовместимы
со званием программиста-профессионала.
Руководитель, как минимум, должен иметь представление об одной модели,
применяемой для всесторонней оценки всех свойств характера команды и ее членов.
Благодаря этому возможна оценка "степени здоровья" взаимосвязей между командами
разработчиков. Если же руководитель получит представление о нескольких моделях,
это будет способствовать выработке интуитивного мышления. Помимо того, что
менеджеры должны быть ознакомлены с основными вопросами технологии управления
проектами, они обязаны владеть навыками выбора, формирования, мотивации и
руководства постоянно усложняющимися командами разработчиков проекта.
Большинство программных проектов являются настолько сложными, что не могут быть
выполнены силами одного разработчика; решать задачи, выдвигаемые современной
технологией, могут лишь команды разработчиков. Как отмечал Фред Брукс (Fred
Brooks) в статье "No Silver Bullet" ("Забудьте о серебряной пуле"), вышедшей в
1987 году, не существует единого инструмента, который может помочь решить все
современные проблемы в области разработки ПО.
С целью достижения успеха в реализации проектов, программ и просто бизнеса,
персонал современных компаний должен быть настроен на выполнение работы,
сочетающей структурирование и гибкость, диктат и делегирование, умение говорить и
слушать. Конечно, все это является своего рода "надстройкой" над "базисом",
обеспечивающим глубокое понимание предметной области.
Институт программного инжиниринга (Software Engineering Institute, SEI)
предложил модель оценки зрелости функциональных возможностей персонала (People
Capability Maturity Model, P-CMM). В рамках этой модели производится адаптация
схемы оценки зрелости в соответствии с моделью оценки зрелости функциональных
возможностей ПО (Capability Maturity Model, CMM), используемой для управления и
развития рабочих ресурсов организации. В качестве мотивации применения модели
Р-СММ выступает потребность в радикальном улучшении возможностей организации
по привлечению, развитию, мотивации, организации и удерживанию талантливых
специалистов, без которых невозможно развитие возможностей по разработке ПО.
При разработке модели Р-СММ преследовалась цель предоставить организациям-
разработчикам возможность интеграции и интенсификации усилий по разработке
наравне с программами по улучшению процесса создания ПО, управляемого с
помощью модели SW-SMM. Модель Р-СММ также может применяться в любой организации
в качестве руководства, обеспечивающего усовершенствование методик, связанных с
персоналом, и трудозатратами, понесенными при разработке программ. В разработке
модели Р-СММ принимали участие Билл Куртис (Bill Curtis), Вильям Хефли (William
Е. Hefley) и Салли Миллер (Sally Miller).
Эксперты, в число которых входит Билл Куртис, утверждают, что среди других
основных компонентов, определяющих успех проекта, наиболее изменчивыми
являются навыки персонала, формирующего команду разработчиков проекта. Задача
менеджера проекта заключается вовсе не в том, чтобы увольнять членов команды в
полном составе и нанимать новых участников при разработке тех или иных проектов, а в

208 Глава 6
том, чтобы "выжать" максимум производительности из работников, независимо от
того, работают ли они давно либо только что были наняты.
В данной главе исследуются методы и подходы, облегчающие для менеджера
проекта задачу изучения персональных качеств разработчиков, обеспечивающих
выполнение ими своих производственных функций. Здесь также содержатся основные
указания относительно выбора, структурирования, мотивации и поддержки
деятельности разработчиков.
Совокупность отдельных частей образует
единое целое
Индивидуальность, присущую проекту, образуют отдельные индивидуумы,
которые, в свою очередь, обладают сложными личными качествами. Согласно
утверждению Тайби Келера (Taibi Kahler), наблюдение за людьми подобно рассматриванию
голограммы. Любая голограмма состоит из сотен тысяч независимых изображений,
каждое из которых полностью отображает объект, но каждый раз слегка изменяется
угол обозрения этого объекта. Благодаря комбинированию этих "картинок"
получается трехмерное изображение. Во время просмотра изображения в целом зритель
получает "всю картину". Когда мы воспринимаем отдельного человека, мы "получаем
всю картину" личности в целом, образуемой отдельными единицами поведенческой
деятельности, связанных с помощью последовательностей либо шаблонов.
Некоторые шаблоны являются естественными, "здравыми" и конструктивными. Другие
шаблоны соответствуют негативным чертам характера, проявляемым человеком в раз-
1
личных затруднительных ситуациях .
По мере того, как в организации реализуются методологии по управлению
проектами, должно уделяться внимание не только техническим аспектам, таким как
реестры проектов и инструменты календарного планирования, но и реальным творцам
успеха в любом бизнесе— людям, обладающим разносторонним профессиональным
опытом. Руководитель проекта должен не ограничиваться знаниями
методологических процессов и инструментов, он обязан обладать навыками работы с людьми,
уметь распознавать "отдельные элементы целой голографической картинки",
идентифицировать "здоровые" и "нездоровые" поведенческие шаблоны.
Многие менеджеры проектов заняли эту должность, будучи техническими
экспертами в какой-либо одной предметной области. Ключевым навыком, который часто
отсутствует или плохо развит у технических руководителей, является способность к
распознанию многообразия личностных свойств, присущих участникам команды
разработчиков проекта, а также способности оптимизировать действия этих свойств с
целью достижения максимальной производительности. Команда образуется из
независимых "картинок", каждая из которых присуща отдельному человеку. Большую
помощь менеджеру проекту могут оказать модели, позаимствованные из прикладной
психологии. Каждый из нас в глубинах своей личности таит нечто "темное и
загадочное". Теория менеджмента предлагает несколько моделей личностных свойств,
объясняющих то, каким образом могут контролироваться неконструктивные черты
команды разработчиков.
Kahler Taibi and Hedges Capers. "The Miniscript." Transactional Analysis Journal, 4(l):27-42,1974.

Отбор команды разработчиков проекта 209
Индивидуальные типы личностей
А теперь приступим к рассмотрению нескольких индивидуальных типов
личностей, которые были определены на основе теории "психологических типов",
созданной Карлом Юнгом. Будут рассмотрены следующие наиболее часто применяемые
модели: индикатор типов Майерса-Бриггса (Myers-Briggs Type Indicator, MBTI), модель
фундаментальных межличностных отношений ориентации-поведения (Fundamental
Interpersonal Relations Orientation-Behavior, FIRO-B), модель сортировки
темпераментов Кирси (Keirsey Temperament Sorter), модель межпроцессного взаимодействия
Келера (Kahler Process Communication Model) и инвентарный перечень шаблонов
рабочих стилей (WorkStyle Patterns Inventory), разработанный компанией McFletcher
Corporation. Было разработано более 150 подобных моделей, но наиболее часто
используются именно упомянутые выше модели.
Индикатор Майерса-Бриггса
Индикатор типов личности Майерса-Бриггса является наиболее популярным и
широко применяемым на протяжении последних 40 лет. За это время данный
показатель был успешно применен для оценки личностных качеств людей во многих
странах мира, причем постоянно ведется работа по его совершенствованию. Метод MBTI
применяется для идентификации четырех биполярных видов поведения,
осуществляя оценку самостоятельно отображаемых установок для каждого из них. При этом
допускаются 16 различных описаний персональных свойств личности,
идентифицируемых с помощью 4-буквенных кодов (ISTJ).
Многие сведения, касающиеся метода MBTI, можно найти в Internet. В
частности, там можно найти сокращенную версию инструментария, предназначенного
для проведения тестирования, а также различные обсуждения, имеющие
отношение к модели лидерства. Что касается технических дисциплин, то можно с полной
ответственностью сказать о том, что многие типы личности (около 60%) попадают
в диапазон, определенный типами ISTJ. Особенности региональной либо
национальной культуры могут привести к изменению контекста, выражающего тип, как
описано в следующем разделе.
Таблица 6.1. Индикатор типа Майерса-Бриггса (MBTI)
Типы MBTI Характеристики
Introvert (интроверт) Источник и направление передачи энергии
(I, E) I: В направлении от внутренней концентрации (энергия поступает
Extrovert (экстраверт) от ДРУГИХ людей>
Е: Со стороны внешнего контакта ("включается" в энергию других
людей)
Sensing (ощущение) Предпочитаемый метод получения информации
(S, N) S: Предпочитает эмпирические, сенсорные данные
Intuitive (интуитивный) N: Предпочитает смысловые шаблоны и абстракции
Thinking (мышление) Методы обработки информации
(Т, F) Т: Принимает решения в соответствии с их безличной логикой
Feeling (чувства) F: Принимает решения в соответствии с их персональными
значениями

210 Глава 6
Окончание табл. 6.1
Типы MBTI Характеристики
Judging (Суждение) Способы "оживления" обрабатываемой информации:
(J, P) J: Организовывает все жизненные события и акты в строгом соот-
Perceiving (Восприятие) ветствии с планами
Р: Импровизация и поиск различных альтернатив
Модель FIRO-B
Другим инструментом, требующим выполнения сертификации с целью
администрирования, является модель фундаментальных межличностных отношений
ориентации-поведения (Fundamental Interpersonal Relations Orientation-Behavior,
FIRO-B). Эта модель реализуется в виде своеобразной анкеты, обеспечивающей
многовариантный выбор. При использовании этой модели, разработанной
Вильямом Шутцем (William С. Schutz), производится эффективное измерение
межличностных взаимосвязей, причем данные, полученные от десяти тысяч
индивидуумов, нормализуются таким образом, что они распределяются среди 15 видов
занятий . В процессе применения модели производится измерение трех
фундаментальных аспектов, имеющих отношение к межличностных взаимосвязям,
причем за очень короткий период времени. Большинство инструментальных
средств, применяемых в процессе тестирования, предусматривают получение
ответов на множество вопросов, поэтому краткость FIRO-B позволяет облегчить
"утомительные тесты".
Согласно Шутцу, все люди в большей либо меньшей степени испытывают
потребность в трех вещах. А именно, в привлечении, контроле и привязанности.
Привлечение представляет собой своего рода внутренний "двигатель", который
обеспечивает "установление и поддержку удовлетворительных отношений с людьми,
которые уважительно относятся к вопросам взаимодействия и ассоциации". При
описании этой потребности применяются предлоги "в" или "из". Человек может
нуждаться в привлечении со стороны других людей либо может сам привлекать
посторонних людей. Контроль представляет собой "потребность в достижении и
поддержке удовлетворительных отношений с людьми, уважающими контроль и силу.
Эта потребность может осуществляться на верхнем либо нижнем уровнях. Как и
привлечение, контроль действует в двух направлениях, но существует большая
потребность в получении либо предоставлении силовых качеств, которые обычно не
принадлежат одному и тому же человеку. Третья потребность, включенная в
рассматриваемую триаду, — "нужда в установлении и поддержке удовлетворительной
взаимосвязи с другими людьми, отдающими дань уважения любви и
привязанности". Эта потребность может характеризоваться эпитетами "близко" или "далеко".
Как показано в табл. 6.2, в модели FIRO-B шесть внутренних потребностей
представляют собой желания уравновешенного индивидуума.
www. seJbymiJJstnith. com. Selby MillSmith, Chartered Occupational Psychologists, FIRO-B
Instrument.
Slintz William. The Interpersonal Underworld. Paolo Alto. CA: Science and Behavior Books, 1996.
Впервые опубликовано в 1958 под названием FIRO: A Three Dimensional Theory of Interpersonal
Behavior, NY: Holt, Rinehart и Winston.

Отбор команды разработчиков проекта 211
Таблица 6.2. Модель
Направление
Ожидание от других
Передача другим
FIRO-B
Привлечение
Одобрение
Интерес
Контроль
Управление
Лидерство
Привязанность
Близость
Симпатия
Согласно заявлению Шутца, основные потребности человека определяются его
родителями либо опекунами в детстве, а затем эти потребности не изменяются на
протяжении всей жизни.
Применение принципа FIRO-B при выяснении совместимости команд проясняет
вопрос о том, какие люди будут продуктивно сотрудничать, а какие — конфликтовать.
В некоторых случаях желательно включение в команду работников, обладающих
подобными чертами характера (два человека являются совместимыми, если они
испытывают легкое чувство симпатии). В других случаях лучшим решением будет
совмещение комплиментарных черт характера (но это решение может быть
неработоспособным, если два человека из одной и той же команды испытывают высокую
потребность в контроле, имея при этом различные цели). Принцип Шутца о
взаимодействии в группе заключается в том, что каждая из трех потребностей становится
заметной в различных "точках" жизненного цикла группы:
В данном случае справедлива типичная последовательность: привлечение —>
контроль -> привязанность. Во время первых встреч участники команды пытаются
определить, на какой стадии жизненного цикла они находятся, а также количество
денежных средств, инвестированных в группу. В данном случае идет речь о фазе
привлечения. После того как были разрешены вопросы, связанные с первичным описанием
личности, происходит переключение на вопросы управления. Каковы основные
правила организации управления? Кто хочет быть лидером? Каковы пределы
распределяемой ответственности? Как только эта "борьба интересов" будет завершена,
осуществляется переход в фазу привязанности, где во главу утла ставится позитивное
влечение, образование пар, ревность и враждебность. Эта последовательность
повторяется в группах, которые продолжают выполнять совместную деятельность .
В дальнейшем эта последовательность будет рассмотрена подробнее (после
того, как будет рассмотрена популярная модель поведения, ведущего к
формированию команды).
Модель сортировки темпераментов Кирси
Тесно связана с MBTI модель сортировки темпераментов Кирси (Keirsey
Temperament Sorter). Она представлена ее автором Дэвидом Кирси (David Keirsey) в книге
"Please Understand Me" (пожалуйста, поймите меня) . Этот инструмент доступен в
Internet, он не требует профессионального администрирования, а также обеспечивает
тестирование личности на четырех языках (испанский, португальский, немецкий и
норвежский) . Модель Кирси идентифицирует четыре типа темперамента, которые
вместе с вариантами показаны в табл. 6.3.
4 См. примечание 3
Keirsey David and Marilyn Bates. Please Understand Me, An Essay on Temperament Styles.
Amherst, NY: Prometheus Books, 1984.
www. keirsey. com. Keirsey Temperament Sorter.

212 Глава 6
Таблица 6.3. Модель сортировки темпераментов Кирси
Тип Кирсн
Характеристики
Кураторы (Guardians, SJs)
Руководители (Supervisors, ESTJ)
Инспекторы (Inspectors, ISTJ)
Провайдеры (Providers, ESFJ)
Защитники (Protectors, ISFJ)
Ремесленники (Artisans, SPs)
Промоутеры (ESTP, Promoters)
Техники (ISTP, Crafters)
Исполнители (ESFP, Performers)
Компоновщики (Composers, ISFP)
Идеалисты (Idealists, NFs)
Учителя (Teachers, ENFJ)
Советники (Counselors, INFJ)
Чемпионы (Champions, ENFP)
Знахари (Healers, INFP)
Рационалы (Rationals, NTs)
Полевые маршалы (Field Marshals, ENTJ)
Вдохновители (Masterminds, INTJ)
Изобретатели (Inventors, ENTP)
Архитекторы (Architects, INTP)
Конкретны в общении
Склонны с сотрудничеству при достижении
целей; могут быть идеальными снабженцами
Конкретны в общении
Утилитарны при достижении целей
Могут идеально подходить прн тактическом
варьировании
Абстрактны в общении
Склонны с сотрудничеству при достижении
целей; могут идеально подходить для
дипломатической деятельности
Абстрактны в общении
Утилитарны при достижении целей
Могут идеально подходить в случае
необходимости проведения стратегического анализа
Модель межпроцессного взаимодействия Келера
Модель межпроцессного взаимодействия Келера (Kahler Process Communication
Model, PCM) представляет собой описание, состоящее из шести частей и основанное на
транзакционном анализе. Причем в процессе использования этой модели производится
анализ личностных качеств путем наблюдений за тем, каким образом одни транзакции
поддерживаются со стороны других транзакций (своего рода "минисценарии").
Администрирование и интерпретация результатов применения модели производится силами
формально обученных профессионалов, которые позволят вам лучше понимать
мотивацию и взаимодействие между членами команды. Более чем полмиллиона человек в 20
различных странах были протестированы с помощью модели РСМ. Например, она
применялась в NASA при оценке профессиональных качеств кандидатов в астронавты .
Шесть типов личности, идентифицированных в модели РСМ, представлены в
табл. 6.4.
Таблица 6.4. Модель межпроцессного взаимодействия Келера (РСМ)
Тип РСМ
Характеристики
Мечтатель Мечтательный, задумчивый, спокойный, самоуглубленный, зависимый;
мотивация к действию диктуется вещами и людьми
Трудоголик Логический, ответственный, организованный, обладающий чувством времени;
мотивация зависит от логики и 'конкретных предметов
См. сноску 1.

Отбор команды разработчиков проекта 213
Окончание табл. 6.4
Тип РСМ Характеристики
Реактор Теплый, чувствительный, сострадательный, сопереживающий;
ведущую роль играют ощущения и эмоции
Мятежник Спонтанный, творческий, игривый, экспрессивный, энергичный;
реагирует с проявлением симпатий и антипатий
Прессовщик Преданный, внимательный, совестливый;
производит оценки на основании мнений
Промоутер Адаптируемый, убедительный, очаровательный, находчивый;
ориентирован на действия
Ключевым свойством этой модели является то, что она учитывает изменение
характеристик личности человека на протяжении его жизни. Учет подобного "сдвига
по фазе" весьма важен для руководителя команды, поскольку можно верно
интерпретировать, например, трансформации типа "доктор Джекил — мистер Хайд". Модель
РСМ может быть эффективно применена обученным профессионалом при условии
серьезных трудозатрат с его стороны на этапе обучения .
К моделям свойств личности, не основанным на теории Юнга, относятся эннеа-
граммы" и нейро-лингвистическое программирование (Neuro-Linguistic
Programming, NLPI1.
Эннеаграммы
Эннеаграмма — это модель, условно состоящая из девяти частей, и
обеспечивающая своего рода "прорыв" при установке обратной связи и стратегии, позволяющей
управлять загрузкой отдельных исполнителей. Девять частей модели связаны между
собой, как показано на рис. 6.2.
Эннеаграммная модель связана с типами MBTI, как показано в табл. 6.5 .
Применение моделей
При корректном использовании любой из перечисленных выше моделей
можно добиться порой весьма неожиданных результатов, но с их помощью легче
объяснить, почему отдельные люди в одних случаях могут, а в других не могут
работать вместе.
Для менеджера проекта весьма важно обладать определенными знаниями,
позволяющими распознать личностные шаблоны и предвидеть характер взаимодействия
" Согласно личному опыту авторов, Роберта Т. Фатрелла и Линды И. Шафер, которые
читали в компании "Моторола" в 1998 году учебный курс под названием "Program Management
Methodology".
Baron Renee и Elizabeth Wagele. The Enneagram made easy: Discover the 9 Types of People. San
Francisco, CA: Harper Collins Press, 1994.
"' Palmer Helen. The Enneagram: Understanding Yourself and the Others in Vour Life. San
Francisco, CA: Harper, 1991.
www.pLirehlp.com/whatshlp.htm. Richard Bandler. What Is NLP? The First Institute of
Neuro-Linguistic Programming and Design Human Engineering, 1996.
См. сноску 10.

214 Глава 6
между ними. В упомянутых моделях, как правило, характеристикам личности
соответствуют те или иные шаблоны поведения, с помощью которых описываются ха-
/ ч IS, M, 15,16,17, 18 „
рактеристики (карту) личности отдельного человека . Весьма важно
понимать, что в данном случае речь идет о картах, "указывающих путь к той либо иной
местности, но не о карте самой местности". Эти модели, при условии их
осторожного применения опытными профессионалами, будут весьма полезными. Каждому
руководителю необходимо всесторонне изучить хотя бы одну подобную модель,
чтобы иметь возможность работать с личностными характеристиками отдельных
людей и команды в целом.
Миротворец
Оценщик (Т^-^Х^ГГ) Взыскательный
Авантюрист Qjfy l\A^ Помощник
Сомневающийся (б^Д l/дз) Прилежный ученик
Наблюдатель (б) \4J Романтик
Рис. 6.2. Эннеаграмма
Культурные влияния
Культурные шаблоны представляют собой "другую сторону медали"
индивидуальных и командных характеристик личности. Хорошо известно многообразие культур,
присущее многим современным компаниям, причем команды разработчиков
проектов в глобальном масштабе становятся все более похожими друг на друга. Различные
культуры оказывают влияние на выражение индивидуальных характеристик личности
путем формирования каркаса, "внутри которого" действуют различные типы
характеристик личности. Например, Соединенным Штатам присуща явная экстравертная
культура, в отличие от, например, интравертной культуры Англии и Японии. А
немецкие участники проекта обычно хорошо подготовлены к совещаниям И четко
придерживаются повестки дня (поведение MTBI SJ), в то время как латиноамериканские
участники проекта лучше импровизируют и свободнее ориентируются при
обсуждении неожиданно возникших вопросов (поведение NP). Также латиноамериканцы легко
выражают свои мысли (Е), а скандинавы вступают в дискуссию только в том случае, если
Bowditch James L. и Anthony F. Buono. A Primer of Organizational Behavior, 5-е издание. NY:
John Wiley & Sons, 2001.
I Iergenhahn B.R. An Introduction to Theories of Personality. Enj^ewood Cliffs, NJ: Prentice Hall, 1990.
Hirsh Sandra и Jean Kummerow. LIFETypes. NY: Warner Books, Inc., 1989.
'" Maples M.F. и С. Sieber "Gestalt Theory". Counseling and Psychotherapy: Theories and Interventions,
D. Capuzzi и D. Gross, ред. Boston, MA: Merril-Macmillan, 1998.
'' Rothwcll J.D. In Mixed Company. Small Group Communication, 4-е издание. Fort Worth, TX:
f larcourt College Publishers, 2001.
'" Tuckman Bruce W. "Developmental Sequence in Small Groups". Psychological Bulletin, 63:384-
ЗД9, 1965.

Отбор команды разработчиков проекта 215
они с чем-то в корне не согласны (I) . В странах Азии большое значение придается
взаимоотношениям между членами группы (NF), а в США и Европе, например,
большее значение имеют деньги и выполняемые человеком функции (ST). Некоторые
американки старшего возраста, особенно родившиеся на Юге либо Юго-Западе США,
опасаются возрастной дискриминации при найме на работу (в США отсутствует
традиция "уважения к старости", которая имеет место в Японии), и в силу этого
испытывают затруднения при участии в дискуссиях, связанных с финансовыми вопросами.
Американские бизнесмены часто сразу же "берут быка за рога", в то время как
представители Европы, Азии и Латинской Америки сначала предпочитают наладить
отношения, построенные на взаимном доверии.
Таблица 6.5. Эннеаграмные типы и типы MBTI
Эннеаграммные типы Типы MBTI
Взыскательный Рассуждающий
Помощник Экстраверт, ощущение
Прилежный ученик Экстраверт, сенситивность, суждение
Романтик Интуитивный, ощущение, восприятие
Наблюдатель Интроверт, мышление
Сомневающийся Интроверт
Авантюрист Экстраверт, интуитивный
Оценщик Экстраверт, интуитивный, мышление, восприятие
Миротворец Интуитивный, восприятие
С целью лучшего понимания культурных шаблонов менеджерам проектов следует
пройти короткие курсы, повышающие уровень знаний в области культуры. Если в
вашем ведении находится многонациональная команда разработчиков проекта, ее
члены должны общаться на общем деловом языке, скорее всего, английском (точнее,
американском варианте английского языка). Наилучшим способом формирования
отношений доверия в команде является разработка некоего краткого словаря,
составленного на языке, на котором говорит большинство членов команды (благодаря
этому вы сможете продемонстрировать, что приложили все усилия, несмотря на свою
неопытность). Для этого рекомендуется освоить азы иностранного языка, на котором
говорят некоторые члены команды. При этом вы не только изучите основы языка, но
и переймете некоторые культурные шаблоны той или иной страны. Благодаря тому,
что язык сложным образом переплетается с культурой страны, вы сможете лучше
понять мотивы и действия тех или иных членов команды.
Личная мотивация
Согласно Келеру (Kahler), понимание психологических потребностей индивида,
основанных на "домашней базе" (рождение), в дополнение к жизненной фазе, в
которой находится данный индивид (среда), способствует осознанию мотивов поведения
Chevrier Sylvia, согласно отчету Larraine Segil в статье "Global Work Teams: A Cultural
Perspective". PM Network, март 1999 г.

216 Глава 6
данного индивида, как отдельной личности, так и в составе команды
разработчиков. В табл. 6.6 приведены описания мотиваций для ранее описанной структуры
характеристик.
Таблица 6.6. Мотивации РСМ
Тип РСМ Мотивации РСМ
Мечтатель Уединенность и направленность.
Временное одиночество для созерцания и творчества
Трудоголик Понимание сути работы: награды, премии, "похлопывание по плечу".
Структурированное время и план
Реактор Приятная среда (рабочие места и персонал).
Комфорт и релаксация
Мятежник Частое взаимодействие с другими сотрудниками.
Персональные контакты и веселье
Прессовщик Осознание достижений благодаря строгой приверженности цели
Промоутер Допущение риска.
Высокий объем финансирования
Каналы, с помощью которых осуществляется взаимодействие, являются столь же
важными, как и восприятие каждого типа. Например, трудоголик, согласно
классификации РСМ, скорее просто располагает "несколькими фактами", чем является
высокообразованным специалистом.
Учитывая показатели личной мотивации, менеджер/руководитель команды также
может исследовать, каким образом можно избежать неприятностей, и какого рода
поведение вызывает "головную боль" и приводит к серьезному снижению
производительности (см. табл. 6.7).
С целью осознания персональной мотивации, характеризующей трудовую
деятельность членов команды, требуется исследование "индивидуальных
побудительных причин". Что для них играет ведущую роль: экспертное представление,
расширение возможностей карьерного роста, финансовые премии, саморазрушение или
что-либо еще?
Некоторые теории, связанные с мотивацией и рассматриваемые в литературе по
менеджменту, обеспечивают поддержку "дорожных карт", согласно которым
менеджеры выполняют свои задачи. Некоторые из наиболее часто применяемых теорий
кратко описаны в табл. 6.8 .
Современный менеджер проекта должен иметь представление об основных
моделях, применяемых для управления мотивацией отдельных людей и организаций.
Многие сведения относительно моделей поведения на уровне организации можно
найти в литературе по менеджменту общего характера, поскольку эта информация
входит в состав любой программы МВА. В частности, обратите внимание на
соответствующие ссылки .
Bowditch James L. и Anthony F. Buono. A Primer of Organizational Behavior. 5-е издание. NY:
John Wiley & Sons, 2001.
Hersey Paul, Kenneth Blanchard и Dewey Johnson. Management of Organizational Behavior:
Utilizing Human Resources, 7-е издание. Upper Saddle River, NJ: Prentice Hall, 1996.

Отбор команды разработчиков проекта 217
Таблица 6.7. Типы поведения, связанные с лидерством
Тип РСМ Менеджеры должны избегать
подобного поведения
Либо они должны предвидеть
следующие реакции
Мечтатель Стиль невмешательства,
сверхраздражение среды
Трудоголик Чересчур личный подход;
прекращение выполнения проектов
без видимой причины
Реактор Автократический стиль;
указание на ошибки
Мятежник Ограничение временных рамок;
"проповедование"
Прессовщик Автократический стиль;
"игра мускулами";
повторное определение
Промоутер Безликий стиль;
конфронтация
Отступление;
Незавершенные задачи
Критицизм по отношению к другим;
неудовлетворенность в силу разных
причин: справедливость, деньги,
порядок и т.д.
Сверхадаптация к другим участникам;
самосомнение;
критицизм
Негативизм;
жалобы;
порицание
"Крестовые походы";
словесные атаки;
справедливость
Аргументы;
"драма отрицания";
нарушение правил
Таблица 6.8. Модели индивидуальной мотивации
Модель мотивации
Краткое описание
Автор
Теория ожиданий
Модель установки пути к
цели (Path-Goal Model)
Теория определения
целей (Goal-Setting Theory)
Эффект Хауторна
(Hawthorne Effect)
Анализ методом силового
поля (Force Field Analysis)
Взаимосвязь между производительностью и
трудозатратами. Люди работают за
ожидаемое вознаграждение
"Уточнение" пути к достижению цели,
воспринимаемой исполнителями. Причем
исполнители действительно хотят работать
ради достижения цели
Растут обязательства в случае установки
исполнителями их собственных целей
Простое действие по измерению, которое
влияет на исход социального эксперимента.
В процессе наблюдения выясняется, что
люди поступают именно так, как и ожидают
наблюдающие эксперты
"Статус кво", поддерживаемый
противодействующими силами
Агенты изменений обязаны
идентифицировать эти силы и изменять их для реализации
любого длительного организационного
изменения
Виктор Врум
(Victor Vroom)
Роберт Хаус
(Robert House)
Эдвин Лок (Edwin
Locke)
Элтон Майо (Elton
Mayo)
Курт Левин (Kurt
Lewin)

I
i-
218 Глава 6
Окончание табл. 6.8
Модель мотивации
Краткое описание
Автор
Теория X и теория Y
(Theory X and Theory Y)
Теория Z (Theory Z)
Теория
мотиватора/ гигиены
Иерархия потребностей
"Предрасполагающее" поведение по отношению
к людям
X: люди по своей сути ленивы и должны
принуждаться к работе силой
Y: люди являются самоуправляемыми и
творческими в случае достаточно хорошей
мотивации
Фактически речь идет об организации типа
Z: комбинация лучших достижений
американской и японской теории менеджмента,
когда основной целью является ориентация
на человека
Мотиватор: рабочий элемент,
удовлетворяющий нужды исполнителя.
Гигиена: факторы, которые должны иметь
место при любой мотивации
Людям присуща иерархия потребностей:
■ физиологические (пища);
■ безопасность (защита, убежище);
■ любовные (социальная принадлежность);
■ самооценка (эго);
■ самореализация (выполнение)
Дуглас Мак-Грегор
(Douglas McGregor)
Уильям Оуши
(William Ouchi)
Фредерик Херцберг
(Frederick Herzberg)
Абрахам Маслоу
(Abraham Maslow)
Факторы, обеспечивающие
совместную работу
Очевидной, но часто недооцениваемой по степени важности является задача
подбора хорошей команды (по возможности) и подготовка участников проекта. Большое
количество проектов было "провалено" именно по причине плохо подобранной
команды разработчиков. В большинстве случаев руководители проектов не могут
выбирать членов команд, а работают с уже имеющимся персоналом. Несмотря на
это, подготовка менеджера проекта, позволяющая ему понимать индивидуальные
характеристики личности и динамику команды, является ключевой для
формирования успешной рабочей группы.
Привлечение в группу и обучение навыкам
Очевидно, что намного проще начинать проект с "положительной" спаянной
командой, показатели работы которой даже могут ухудшиться в дальнейшем, чем
начинать с командой, неспособной функционировать. В любом случае лучше отбирать
членов команды по признаку их совместимости и взаимного дополнения
характеристик личности, чем в соответствии с их проявленными навыками в определенной
области. На первый взгляд это утверждение противоречит распространенному мнению,

Отбор команды разработчиков проекта 219
но оно имеет смысл благодаря предположению, что проще обучить персонал новым
техническим навыкам (которые зачастую быстро изменяются), чем изменить их
личностные характеристики. В любом случае большинство людей получает удовольствие
в процессе учебы. Потребность в обучении не должна быть формальной. Общая
способность к быстрому обучению и адаптации к быстро изменяющейся информации
является более ценной, чем большой опыт в одной либо двух областях, особенно, если
предположить наличие базовой компетентности в основных технологиях.
Естественно, когда личные качества сотрудника не подходят для выполнения данной
задачи, начинает проявляться воздействие стресса и негативные характеристики.
Реестр шаблонов рабочих стилей Мак-Флетчера
Полезным инструментом, позволяющим объяснить особенности поведения,
является Реестр гиаблонов рабочего стиля (WorkStyle Patterns Inventory, WSPI),
разработанный корпорацией McFletcher Corporation. Назначение оценки в этом случае
заключается в идентификации того, каким образом человек предпочитает рабочий подход по
сравнению с подходом, который требует определенной позиции либо текущего назначения.
Причем администрирование процесса оценивания осуществляется с помощью
посредника, сертифицированного компанией McFletcher. Анализ расхождений между
предпочитаемым и фактическим рабочим стилем того или иного человека может
привести к возникновению стресса различной степени, который проявляется
различными способами.
Организационный стресс может проявляться в виде непонимания рабочих
ожиданий, низкого качества продукта, проблем с поддержкой пользователей,
нарушенных сроков сдачи или больших сроков оборота. Организационный стресс может
возникать в том случае, когда необходимы дополнительные действия специфического
рода помимо тех, к которым вы расположены.
В соответствии с реестром, работник соответствует одной из категорий,
перечисленных в табл. 6.9.
Таблица 6.9. Модель реестра рабочих стилей Мак-Флетчера
Категория Фокус Типы
Работник Задача Специалист
Мастер
Техник
Работник
Опытный работник
Независимый работник
Руководитель Проект Куратор
Руководитель
Менеджер Организация Адаптер
Синтетик
Новатор
Претендент
Менеджер
Промоутер
Оценщик
Менеджер проекта

220 Глава 6
Показатели, соответствующие реестру (анкете), отображаются на графике в виде
разницы между фактической и предпочитаемой позициями, как показано в примере на рис. 6.3.
Пример графика на рис. 6.3 отображает показатели для руководителя команды,
который предпочитает рабочий стиль независимого работника, а фактическая позиция
рабочего стиля соответствует руководителю. Он предпочитает работать независимо,
управляя ходом выполнения своей собственной работы. Фактически занимаемая им
позиция требует координирования рабочих усилий вместе с другими работниками. Также
возможно, что руководитель команды предпочитает работу, которая больше связана с
применением компьютера, в то время, как его позиция требует выполнения действий
но координированию, обучению и календарному планированию в гораздо большей
степени, чем он склонен это делать . Подобная ситуация типична для многих технических
специалистов, поднявшихся до позиции лидера. Такому руководителю команды следует
подумать относительно дополнительного обучения либо даже смены места работы.
48
44
40
36
32
28
24
20
16
12
Работник Руководитель Менеджер
(задача) (проект) (организация)
„
Фактические данные
48
44
40
36
32
28
24
20
16
12
Рис. 6.3. Пример реестра рабочих стилей Мак-Флетчера
Рабочие стили для каждого члена команды могут быть представлены на сводной
диаграмме, причем одновременно производится, проверка "комплиментарной смеси"
рабочих стилей (выявление конфликта либо возможного дисбаланса). Например,
если кто-либо хочет повторно спроектировать систему по уходу за больными, вполне
иозможно, что не останется ни одного человека, призванного руководить процессом
ухода за больными.
"Брешь" в системе навыков
Повторим, что способность руководителя быстро оценивать личностные
характеристики того или иного человека будет вполне удовлетворительной до тех пор, пока
он не будет иметь дело с листом бумаги, на котором перечислены основные
достоинства специалиста, т.е. с документом, называемым резюме. Фактически резюме
довольно часто дает неправдивую информацию.
"" McFletcher Corporation. WorkStyle Patterns Inventory. Scottsdale, AZ, 1993.

Отбор команды разработчиков проекта 221
Билл Куртис (Bill Curtis), бихевиорист и соавтор модели возможностей для ПО
(Capability Model for Software), в начале 80-х годов прошлого века занимался
программированием и вел специальный учебный курс. Предметом этого курса был вопрос о
том, каким образом навыки программистов могут воздействовать на технический
график выполняемого проекта. Он разработал программу на языке Fortran,
содержащую ошибки, а затем сделал выборку по времени, требуемому программистам для
нахождения всех ошибок . Все участники испытаний были программистами на языке
Fortran, работающими в коммерческих фирмах. Результаты были ошеломляющими.
Производительность участников теста варьировалась как 20 к 1. Таким образом,
худший программист осуществлял поиск ошибок в 20 раз медленнее, чем лучший
представитель этого славного племени. Подобный тип расхождения оказывает
большее влияние на проект, чем любой последующий метод либо процесс. Только
представьте себе на минуту, что составляется план, в график которого заложено
подобное расхождение!
Согласно исследованиям Куртиса, основанным на результатах тестов, всегда
наблюдается небольшая корреляция между навыками и образованием, опытом,
квалификацией индивида (заявленными в его резюме). Подобные факты говорят о том, что
для менеджера проекта большое значение имеет способность к пониманию "тонких"
различий между характеристиками личностей. Менеджеры/руководители, знакомые
с теорией мотивации, смогут лучше распознавать различные типы личностей. В
случае необходимости менеджеры также могут использовать профессиональные
инструментальные средства, позволяющие определять различные типы личностей. В
результате они смогут глубже осознавать потребности команды. К таким средствам
можно отнести, например, инструмент Alignment Products and Processes,
предлагаемый упомянутой ранее McFletcher Corporation.
Динамика развития группы
В обязанности руководителя входит определение того, каким образом правильно
сформированная команда может в дальнейшем обеспечить успех проекта. Одной из
хорошо известных моделей развития команды является пятистадийная модель,
приведенная на рис. 6.10.
Таблица 6.10. Модель развития команды
Стадия Описание
Формирование Участники команды выясняют следующее:
предстоящие задачи, стиль приемлемого руководства, а также возможные
виды межличностных и рабочих взаимосвязей
Характерные особенности:
вежливость, беспорядок, внимательность и общность
Шторм Члены группы начинают сопротивляться групповому влиянию. Возникает
конфликт конкурирующих подходов при достижении целей группы
Характерные особенности:
напряженность, критицизм и конфронтация
Curtis Bill. Personal communication, 1993.

222 Глава 6
Окончание табл. 6.10
Стадия Описание
Нормирование Достигается устойчивость благодаря преодолению влияния группы:
устанавливаются правила и стандарты, создаются связи внутри группы, а также
схематически определяются ее стандарты и ожидания
Характерные особенности:
кооперация, сотрудничество, связь и приверженность определенным взглядам
Выполнение Группа вполне "созрела" для начала выполнения задач. Устанавливаются
(функциониро- межличностные отношения, статусы членов группы, а также распределе-
вание) ние задач
Характерные особенности:
вызов, творчество, групповое сознание
Завершение Группа выполнила свое предназначение либо распалась
Характерные особенности:
компромисс, общение, достижение консенсуса и завершение работы
Данная модель демонстрирует процесс выбора группой своего оперативного
, 21. 25
профиля
Описанный выше эволюционный цикл развития присущ каждой команде
разработчиков, причем всякий раз, когда принимается новый работник либо кто-нибудь
увольняется, принятые в команды нормы должны быть повторно пересмотрены с учетом
новой ситуации. Отметим, что последовательность эволюционных стадий не имеет
особого значения. Команды могут "мигрировать" между стадиями шторма и нормирования
множество раз до того, как перейдут к стадии выполнения. Иногда подобная эволюция
некорректно интерпретируется как трансформация типа "доктор Джекил — мистер
Хайд". В обязанности руководителя входит распознание состояния команды в любой
момент времени и выполнение действий, которые будут способствовать переходу
команды на стадию выполнения за кратчайший промежуток времени. Причем для
каждого типа личности применяются корректные технические приемы.
Распознание признаков разрушения команды
Разрушение команды является результатом неправильной групповой динамики в
организационной среде, когда команда постоянно находится на стадии шторма. В
результате члены команды возвращаются к "истокам" своих личностных качеств,
которые часто носят деструктивный характер. Де Марко (DeMarco) и Листер (Lister)
посвятили рассмотрению этого вопроса целую главу "Teamicide" в своей книге People-
ware. В этой главе рассматриваются проблемы задержки формирования команды и
разрушения социологической основы проекта. Здесь же были перечислены причины
разрушения команды, относящиеся к факторам среды. Руководитель проекта обязан
распознавать эти факторы во избежание нарушения командной работы . Эти
факторы имеют следующие признаки: оборонительный менеджмент, бюрократия, физиче-
См. сноску 16.
' См. сноску 18.
' DeMarco Tom and Timothy Lister. Peopleware: Productive Projects and Teams. NY: Dorset House, 1987.

Отбор команды разработчиков проекта 223
ское разделение, фрагментация времени персонала, снижение качества
программного продукта, "мягкие" сроки окончания работы и контроль образовавшихся клик.
Руководитель технического проекта должен уметь вовремя распознавать
подобные проблемы и предпринимать соответствующие меры. В этом случае весьма
полезными станут некоторые советы от Де Марко и Листера.
■ Оборонительный менеджмент— необходимо позволять персоналу
предпринимать свои собственные решения, даже если они иногда являются ошибочными.
Предоставление свободы совершения ошибок является одним из признаков доверия.
■ Бюрократия— не допускайте превращения разработчиков в бюрократов.
Доверяйте выбору команды и выражайте уверенность в силах этой команды.
■ Физическое разделение — находясь вместе, сотрудники неизбежно
взаимодействуют друг с другом. Если они работают в одной и той же команде, у них
проявляется тенденция одновременного перехода в "режим молчания". Благодаря этому
ничто не мешает процессу размышления.
■ Фрагментация времени— ограничивайте количество проектов, а также число
задействованных в них людей. Иногда возможны большие потери в
"передаточном механизме" при переходе от одной командной культуры к другой.
■ Снижение качества производимого продукта— самолюбие разработчика будет
уязвлено в случае, когда от него требуется создавать продукт более низкого
качества, чем тот, на создание которого он способен. Не позволяйте, чтобы "дешевые"
продукты становились "низкокачественными". Помните о профессиональной
чести и достоинстве.
■ "Мягкие" сроки окончания работы — "жесткие" сроки окончания работы иногда
диктуются необходимостью и даже могут служить своего рода "приятным"
вызовом для команды. Однако "жесткие" сроки не эквивалентны "мягким" срокам и это
следует учитывать.
■ Контроль клик— менеджерам не всегда доводится работать в "спаянных"
командах. Поэтому приходится выполнять равное распределение обязанностей
посредством назначения ролей. Даже учитывая этот фактор, не следует забывать об
обеспечении условий совместной деятельности команды. В "спаянных" командах
деятельность членов команды приносит им удовольствие, а в процессе их
взаимодействия друг с другом производится энергия.
Создание каркаса—необходимое условие
совместной работы
Члены команды могут петь в хоре, но не могут говорить одновременно. Это
утверждение стало фундаментальным в теории музыки. При осуществлении управления
проектами аналогичную роль играет каркас, образуемый с помощью компетенций,
относящихся к подобной деятельности.
Руководитель проекта должен уметь получать информацию относительно
коллективных личностных характеристик команды, выбирать подходящую инфраструктуру,
а также поддерживать заданный ритм в течение всего времени выполнения проекта.
Эта деятельность должна быть частью групповой нормы. Следуя этой методологии,

224 Глава 6
разрабатывается групповое правило, охватывающее культурные и личностные
особенности. Это правило выступает в роли своего рода фундамента, обеспечивающего
повторное формирование группы в случае ее попадания на стадию шторма, и играет
роль своеобразного "клея".
Взаимодействие и количество участников команды
Многие из причин, могущих привести к развалу команды, находятся под контролем
руководителя проекта. Количество участников команды связано с размером проекта
(табл. 6.11). В случае несоответствия этих двух параметров может произойти нарушение
деятельности команды. Следствием этого может явиться легендарный феномен
"человеко-месяца", описанный в классическом труде Фреда Брукса (Fred Brooks) The
Mytjical Man-Month ', увидевшим свет в 1975 году. Обратите внимание, что такой
показатель, как человеко-месяц обычно равен 40 рабочим часам. Как правило, он
распределяется на период времени, который больше либо меньше календарного месяца.
Таблица 6.11. Соотношение между размерами проекта и количеством
участников команды
Размер проекта
Малый
Средний
Большой
Человеко-месяцы Календарные месяцы
Менее 6 Менее 3
6-48 3-9
Менее 48 Более 9
Количество участников
команды
Более 3
3-15
Более 15
Почему же то, что срабатывает в условиях небольшой команды, выполняющей
малый проект, не может применяться при выполнении средних и больших
проектов? Ответ на этот вопрос будет получен в дальнейшем, а пока примите к сведению,
что характеристики личностных качеств команды в первую очередь зависят от
количества ее участников. Две наиболее важные из этих характеристик —
взаимодействие и дисперсия.
Взаимодействие в команде
Взаимодействие между членами команды является определяющим условием при
выполнении задач проекта. Во избежание распада команды менеджеры и рядовые ее
участники должны использовать наиболее приемлемые каналы общения, чтобы стала
возможной передача достоверной информации. Наиболее употребительные каналы
общения, характерные для модели РСМ Келера, приведены в табл. 6.12.
Другие аспекты общения, находящиеся под контролем руководителя проекта,
связанные с бюрократией и подавлением клик. Из-за бюрократии резко возрастают
накладные расходы на поддержание каналов общения. Кликами называются "закрытые"
группы людей, образующие эксклюзивные подгруппы внутри команды. Клики
вызывают информационную изоляцию.
По мере увеличения количества членов команды быстро растет количество
каналов двустороннего общения. Их количество может быть оценено с помощью
"' Brooks Fredrick P. The Mythical Man-Month: Essays on Software Engineering, юбилейное издание
(первое издание датируется 1975 годом). Reading, MA: Addison-Wesley, 1995.

Отбор команды разработчиков проекта 225
формулы (п(п-1))/2. Здесь п обозначает количество членов команды, быстрый рост
которого проиллюстрирован на рис. 6.4.
Таблица 6.12. Наиболее употребительные каналы общения
ТипРСМ Наиболее употребительные Примеры
каналы общения
Мечтатель Непосредственный
Трудоголик Информативный
Реактор Обучающий
Мятежник Эмоциональный
Прессовщик Информативный
Промоутер Непосредственный
Разрешает работу во внерабочее время:
"Поработай над этим дома."
Прояснение вопросов: поддержка фактов и
данных
Вербальные "штрихи": "Я рад сообщить вам,
что здесь еще нужно поработать."
Игривый стиль общения: "О, это
великолепная идея!"
Вопрос относительно мнения: "Что вы об
этом думаете?"
Фокусирование на восхищении и действии:
"Идем делать это!"
Недостаточный контроль над перечисленными выше факторами может привести
к увеличению накладных расходов и появлению ошибок и непонимания (особенно,
когда члены команды говорят на разных языках).
Например, количество каналов для реализации общения в рамках проектов
различного размера, рассматриваемых ранее, может расти очень быстро (табл. 6.13).
Для большей наглядности здесь представлены очень большие проекты, когда
число участников превышает 50 человек (в данном случае мы имеем дело с
разработкой ПО).
100
Количество участников
команды разработчиков проекта
Рис. 6.4. Рост количества каналов общения
По мере роста количества участников команды проявляется тенденция к
формированию клик, которые обычно сосредотачиваются вокруг географических
центров. Причина этого феномена может заключаться в том, что руководитель обязан

226 Глава 6
поддерживать ограничивающий каркас, в пределах которого будет действовать
команда. Даже такие простые вещи, как формирование и поддержка общего для
команды словаря, требуют чрезмерного вмешательства руководителя. Руководитель
проекта обязан следить за тем, чтобы текущий уровень общения был достаточным.
Таблица 6.13. Примеры каналов общения
Размер Количество калеи- Типичное число уча- Максимальное количе-
проекта дарпых месяцев стников разработки ство двусторонних ка-
проекта (п) налов общения
Малый Менее 3 Менее 3 1
Средний 3-9 3-15 3-105
Большой Более 9 Более 15 Сотни
Очень большой Более одного Года Более 50 Тысячи
(программа)
Наличие различных личностных характеристик предполагает, чтобы в команде
разработчиков балы образованы: структура, ритуал и направление (аналогично, РСМ:
мечтатели, промоутеры; MBTI: SPs; Кирси: кураторы SJs). Причем эти ключевые
фигуры будут требовать большего, чем независимые работники либо мятежники,
входящие в состав группы. Модель зрелости возможностей персонала (People Capability
Maturity Model, P-CMM), предложенная Институтом программного инжиниринга
(Software Engineering Institute, SEI) представляет собой начальный каркас, который
руководитель проекта должен адаптировать таким образом, чтобы осуществлялись
только те процедуры, которые соответствуют параметрам команды и проекта.
Благодаря этому минимизируются ошибки, возникающие в ходе реализации общения.
Полезным инструментом, предлагаемым в рамках модели Р-СММ, является
матрица функциональной ответственности (Functional Responsibility Matrix),
показанная на рис. 6.5.
Матрица
распределения
обязанностей
Содержание
1 1 1
Исполнитель
Роль
Рис. 6.5. Матрица функциональной ответственности

Отбор команды разработчиков проекта 227
С помощью матрицы функциональной ответственности четко определяются
обязанности членов команды по выполнению различных проектных задач. Во всех
моделях, описывающих личностные характеристики, рассматривается понятие
"нарушения границ ответственности". Это связано с тем, что люди, по своей природе,
"привязаны к определенной территории". "Территориальные вопросы" являются основной
причиной дисгармонии в команде, поскольку во многих моделях они затрагивают
глубоко скрытые черты характера.
Руководитель также обязан собирать и представлять соответствующую
информацию, он должен уметь найти способ руководства, совместимый с личностными
качествами отдельного индивида и команды в целом. Именно в этом случае жизненно
важным является понимание динамики группы и типов личности. Команды с
большим количеством бюрократов и клик являются самыми уязвимыми среди команд, у
которых преобладают мятежные настроения.
Дисперсия команд
Несомненно, руководство командой разработчиков проекта будет затруднено в
случае географической удаленности членов команды друг от друга. Большие
расстояния и различные часовые пояса не могут не сказываться на динамике взаимодействия
внутри команды.
Вопросы, связанные с географией
Общение и дисперсия представляют собой ограничивающие реальности,
характерные для любой рабочей команды, распределенной в большой по объему
физической области. Причем в этом случае члены команды не имеют возможности общаться
друг с другом в "интерактивном" режиме. Современные телекоммуникационные
технологии, такие как конференции, видеоконференции и электронная почта,
облегчают общение на расстоянии, но все же не являются полноценной заменой
интерактивного общения. Однако менеджер проекта обязан "создавать среду" команды,
используя все возможные средства.
По возможности, организуйте хотя бы одно "интерактивное" совещание членов
команды разработчиков в начале и в конце работы над проектом. На начальном
совещании будут выбраны стиль и форма будущих межличностных взаимодействий,
связанные со средней частью жизненного цикла разработки проекта. Это критично
для начальных стадий работы, когда постепенно определяются требования,
выдвигаемые в ходе осуществления проекта. Последнее совещание обеспечивает
необходимое завершение работы над проектом, благодаря чему минимизируется
персональный эмоциональный "багаж", перемещаемый на следующий проект, здесь же
определяются важные расширенные действия, обеспечивающие коллекционирование
постпроектных метрических показателей.
Учет местного времени
Также важно учитывать наличие местного времени. Как правило, команды
выполняют асинхронные (выполняемые в одиночестве и не координируемые с
другими членами команды) и синхронные (выполняемые в одном месте и в одно
время)задачи.
Если члены команды удалены друг от друга, потребуется выбрать взаимно
согласованные время и место для выполнения синхронных задач. Как правило, выбирается

228 Глава 6
местоположение и временная зона руководителя проекта, хотя весьма полезным
является ротация этих параметров в объеме всей инфраструктуры проекта. Если
выбирается местоположение других участников проекта, расширяется обмен
культурными традициями, распределяются тяготы путешествий и временных неудобств, а
каждый участник проекта достигает более глубокого уровня понимания командных
личностных характеристик.
Структура и ритуал
Структура и ритуал представляют собой движущую силу проекта. Это — своего рода
каркас, внутри которого реализуются и закрепляются личностные качества команды.
Если подобного каркаса не будет, подобно лесному пожару начнет распространяться
некорректная интерпретация и смятение.
Формирование жесткого каркаса
Одной из наиболее важных задач, выполняемых руководителем проекта,
является выбор офиса проекта, который будет использоваться в качестве "хаба",
содержащего информацию о проекте. Это то место, где могут находиться
проектные документы, соответствующие модели Р-СММ, наряду с рабочими
документами команды. Офис проекта представляет собой скорее некоторую концепцию, а
не реальное физическое местоположение. Наиболее распространенным, но не
самым лучшим вариантом, является децентрализованный офис проекта.
Формирование подобного офиса означает, что документы и инструментальные средства
будут распределены в различных географически удаленных друг от друга местах,
где они будут находиться под контролем различных участников команды
разработчиков. Подобная организация труда обычно характеризуется большим
объемом пересылаемых по электронной почте файлов и документов, а также тем, что
не все члены команды разработчиков применяют общие программные и
аппаратные платформы. Это приводит к возникновению проблем, связанных с
вопросами территориального менеджмента и конфигурации. Пример
децентрализованного офиса проекта представлен на рис. 6.6.
Централизованный офис проекта является воплощением концепции общности и
локализации. В этом случае может рассматриваться одно географическое
местоположение, находящееся под контролем одного члена команды. В качестве подобного
офиса может выступать физическое помещение, например, проектная лаборатория,
конференц-зал либо офис. Также роль подобного офиса может выполнять
виртуальное пространство, находящееся на удаленной системе. На рис. 6.7 иллюстрируется
концепция централизованного офиса проекта.
Для любого офиса проекта требуются, как минимум, техническое и рабочее
задание для участников команды разработчиков. Также необходим график выполнения
рабочих задач, хотя уровень его детализации зависит от размера и области действия
проекта. Неплохим инструментом, обеспечивающим поддержку централизации в
случае средних и больших команд разработчиков, является матрица функциональных
требований. Этот инструмент может также применяться в том случае, если в
небольшой команде разработчиков имеют место серьезные проблемы личного характера
(территориальные вопросы).

Отбор команды разработчиков проекта 229
Проектные документы,
поддерживаемые локально
Проектные документы,
поддерживаемые в централизованном порядке
Члены команды разработчиков, находящиеся
в четырех различных местоположениях
Рис. 6.6. Децентрализованный офис
проекта
Члены команды разработчиков, находящиеся
в четырех различных местоположениях
Рис. 6.7. Централизованный офис проекта
Практика ритуалов
Наша жизнь подчинена небольшим ритуалам, которые осваиваются нами с
детства. Примерами подобных ритуалов могут служить сон и прием пищи, определенные
нормы поведения дома и на работе, различные социальные контакты. Благодаря
этому создается своего рода "зона комфорта", позволяющая нам справляться с
неопределенными ситуациями, подстерегающими нас каждый день. Согласно Абрахаму Маслоу
(Abraham Maslow), если не контролировать основные моменты жизнедеятельности,
любому из нас будет значительно труднее реализовать полный потенциал и
обеспечить решение имеющихся проблем .
Для команд разработчиков проекта это означает необходимость создания графика
регулярных обменов (синхронная часть проектов) и наличие "свободного" времени
(неструктурированная часть работы, предназначенная для выполнения отдельных
задач). Руководитель обязан определять шаблон подобного типа и организовывать с
его помощью общение в команде на самых ранних стадиях проекта. Также должны
быть определены ежедневные ожидаемые результаты для каждого отдельного
исполнителя проекта; в противном случае команда может расколоться.
Работайте с людьми, а не с бумагами
Размер каркаса, "монтируемого" для конкретного проекта, находится в
компетенции руководителя команды. Слишком тесный каркас буде служить серьезным
ограничителем, тогда как свободный каркас приводит к тому, что поведение членов команды
выходит из-под контроля. Оптимальным решением является использование опыта
практикующих профессионалов в области разработки проектов.
Обеспечение всеобъемлющего решения
Для достижения всестороннего решения какой-либо проблемы требуется нечто
большее, чем просто современная технология и процессы. Согласно утверждению
См. ссылку 19.

230 Глава 6
Фреда Брукса (Fred Brooks), высказанного в книге "No Silver Bullet" , не существует
единого подхода либо инструмента, призванного решить все проблемы. Даже
реализация модели Р-СММ должна рассматриваться в качестве своего рода каркаса, на
основе которого производится преобразование констант личностных качеств команды.
Этот каркас должен рассматриваться совместно с оценкой личностных качеств
индивидов и команды и наравне с суждением руководителя.
Управление творческой деятельностью
Одними из наиболее часто критикуемых недостатков готовых каркасов называют
бюрократию и "подавление" творчества. Чрезмерное ограничение всегда вредно.
Однако при отсутствии хорошо продуманного каркаса затрудняется работа ведущих
команд проекта и ограничиваются возможности для творчества. Это как раз та
ситуация, когда руководитель должен иметь четкое представление о том, как удержать
ситуацию под контролем.
Творчество "расцветает буйным цветом" в среде, которая является безопасной и
изолированной от воздействия внешних факторов. Согласно наблюдениям, дети,
занимающиеся в гимнастическом зале, где игровое поле ничем не ограничено, проявляют
гораздо меньший интерес к исследованию "представленной им территории". Они
просто "прилипают" к центру игрового поля, опасаясь нарушить неопределенные границы.
Если же эти границы четко обозначены с помощью маркера или ограждения, дети
ощущают себя свободнее и исследуют буквально каждый дюйм огражденной территории.
Аналогичный феномен наблюдается в том случае, когда профессионалы приступают к
выполнению работ, относящихся к проекту. При наличии явных и хорошо
определенных границ обеспечивается большая свобода для творчества. Основная идея
заключается в том, что руководитель проекта корректно определяет личностные характеристики
участников проекта и в "нужном месте" устанавливает границы, которые будут не
слишком тесными и в то же время не слишком свободными.
Когда следует руководить, а когда—управлять
В чем проявляется различие между руководством и менеджментом в аспекте
организации работы с командами разработчиков проекта?
Вопросы, относящиеся к менеджменту (управлению), касаются следования
политик и процедур, и организации правильных действий, связанных с проектом.
Менеджмент проявляется также в том случае, когда речь идет о выполнении и
одобрении проекта или о практической реализации модели Р-СММ.
Руководство же проявляется в том, что открывается некое "волшебное видение",
которому следуют участники команды разработчиков проекта. Оно также выражается в
том, что определяется правильный порядок выполнения действий и "разжигается
костер", поддерживать который должны остальные участники проекта. Руководство также
требуется для стимулирования процесса достижения цели проекта, разработки устава
команды и поддержки общения между ее членами. Все эти концепции отображены на
рис. 6.8. Идеальным вариантом является совпадение целей проекта и его руководителя.
При рассмотрении вопросов руководства и менеджмента весьма полезной может
быть модель ситуативного руководства (Situational Leadership Model), разработанная
Brooks Fredrick P. "No Silver Bullet: Essence and Accidents of Software Engineering." IEEE
Computer, 20D):10-19, 1987.

Отбор команды разработчиков проекта 231
Херси (Hersey) и Бланчардом (Blanchard) . В рамках этой модели тип руководства,
примененный в данный период времени, приводит к смещению спектра в
зависимости от четырех стилей руководства, принимая во внимание зрелость исполнителя
(см. табл. 6.14). Эта модель приводится на рис. 6.9.
Каждый из этих стилей представляет собой комбинацию поведения в процессе
решения задач (затрагивает выполнение работы, демонстрируется на оси у) и поведения
при установке взаимосвязей (имеет отношение к поддержке последователей, которые
должны выполнять работу, т.е. исполнителей, показано на оси х). Форма кривой
предполагает типичное "путешествие" стилей с учетом индивидуальных ситуаций — от S1 к
S4 (перемещение "справа налево"). Все это подобно "путешествию", которое
предпринимает команда в модели "формирования-шторма-нормирования", описанной ранее.
На рис. 6.10 отображается роль руководителя для каждого из четырех стилей.
Руководитель сообщает исполнителям не только то, что им следует делать, также
говорит о методе, применяемом для выполнения соответствующих действий. Роль
руководителя становится менее агрессивной в процессе убеждения до тех пор, пока он
остается наблюдателем в рамках делегированных ему полномочий.
В любом случае характер действий руководителя определяется степенью
готовности исполнителей на данный момент времени. Готовность исполнителей
определяется наличием желания выполнять задачу и возможностью реально ее выполнить (т.е.
знаниями о способах выполнения задачи), как показано на рис. 6.11.
Руководители
Установка направления
Делать вещи правильно
Менеджеры
Следовать процессу
Делать правильные вещи
Рис. 6.8. Руководство и менеджмент
Таблица 6.14. Поведение, присущее ситуативному руководству
Готовность
исполнителя
Стиль Поведение руководителя
руководителя
Разговор
В строгой форме указывается направление деятельности
(что и как делать), причем проявляется небольшое
внимание к чувствам исполнителей
Указания смягчены, высокая степень восприимчивости к
чувствам исполнителей
Демонстрирует сильную "озабоченность" чувствами
исполнителей, а также присоединяется к ним для оказания
помощи при выполнении задачи
Предоставление Просто передает задачу на выполнение и наблюдает за хо-
полномочий дом работы издалека
Убеждение
Участие
Не хочет.
Не знает
Не хочет.
Знает
Хочет.
Не знает
Хочет.
Знает
См. сноску 21.

Н Стиль руководителя
L Щ. Поведение ^ Н
в рамках задачи
Рис. 6.9. Модель ситуативного руководства
Стиль руководителя
•-/
УЧАС^Н
%ш
Jmf
АРМИРОВАНИЕ
*'
МЩЕНИЕ
V
=4^
РАЗГбЩН
Рис. 6.10. Роль руководителя при
ситуативном руководстве
Готовность исполнителя
Хочет
М4
Может
Хочет
МЗ
Не может
Не хочет
М2
Может
Не хочет
М1
Не может
Рис. 6.11. Готовность исполнителя при
ситуативном руководстве

Отбор команды разработчиков проекта 233
Если исполнители не могут и не хотят выполнять задачу, их степень готовности
(зрелости) соответствует Ml, и руководителю в этой ситуации приходится
адаптировать стиль менеджмента (S1). Например, этот подход считается традиционным для
сержантов армии США.
Если, согласно оценкам руководителя, исполнители хотят выполнять задачу, но
обладают недостаточным уровнем компетентности (возможно, по причине
недостатка некоторых знаний либо навыков), руководитель будет адаптировать стиль
руководства S3 (участие). Девиз этого стиля: "Покажи мне, как сделать это...". Причем
руководитель вместе с исполнителями принимает участие в выполнении задачи.
Если исполнители хотя и могут выполнять задачу (М4), руководитель должен
адаптировать стиль делегирования полномочий (S4). Такой подход характерен для
менеджера исследовательской лаборатории. При этом руководитель должен лишь
предоставить задачу исполнителям, и они сами могут выполнить ее, нуждаясь лишь в
незначительном руководстве.
Стиль S4, применяемый руководителем, можно назвать простейшим, однако он не
позволяет "расслабляться". Если команда будет испытывать трудности при
выполнении задачи, руководитель обязан вникнуть в суть проблемы, оценить ситуацию и
принять соответствующее решение.
Сущность ситуативного руководства заключается в умении оценить личностные
характеристики команды в целом и отдельных ее членов. Это является одним из
непременных условий на пути к достижению максимальной производительности команды.
Резюме
В главе обсуждаются различные модели оценки личностных характеристик
команды в целом и отдельных ее членов— индикатор типа Майерса-Бриггса (Myers-
Briggs Type Indicator, MBTI), модель фундаментальных межличностных отношений
ориентации-поведения (Fundamental Interpersonal Relations Orientation-Behavior,
FIRO-B), модель сортировки темпераментов Кирси (Keirsey Temperament Sorter),
модель межпроцессного взаимодействия Келера (Kahler Process Communication Model,
PCM), метод эннеаграмм и инвентарный перечень шаблонов WorkStyle (WorkStyle
Patterns Inventory, WSPI), разработанный компанией McFletcher Corporation.
Руководитель проекта обязан иметь глубокое представление хотя бы об одной из
перечисленных выше моделей, что позволит ему производить оценки личностных
свойств исполнителей, а также их взаимосвязей с другими членами команды.
Понимание нескольких моделей сделает руководителя проекта еще более проницательным.
Авторы книги призывают читателей всесторонне исследовать хотя бы одну из этих
моделей, возможно, даже с помощью профессиональных экспертов в этой области.
Были рассмотрены некоторые базовые составляющие процесса руководства
командой разработчиков проекта, включая личностные качества, культуру, мотивацию, а
также было показано, каким образом они могут влиять на групповую динамику
менеджмента проектов. Были идентифицированы некоторые модели личностной и командной
мотивации, описан процесс формирования команды, а также ее постепенная эволюция с
образованием рабочей группы. Также рассматривались действия, которые должен
выполнить руководитель проекта с целью минимизации потенциальной возможности
преобразования команды в "нечто нефункциональное". Исследовались вопросы
влияния размера проекта и количества участников команды, временных поясов и
расстояний между разработчиками на успешное выполнение проекта.

234 Глава 6
Обсуждалась важность наличия четкой структуры проекта для обеспечения
продуктивной деятельности участников разработки. Также указывалось на то, что
руководитель должен работать с людьми, а не с "бумагами".
Для выработки всеобъемлющего проектного решения руководитель должен
поддерживать соответствующую среду общения. Централизованный офис проекта
представляется наилучшим способом предоставления удовлетворительных коммуникаций
среди географически удаленных друг от друга членов команды.
После определения личностных характеристик отдельных исполнителей и
группы в целом, руководитель проекта должен уметь различать действия по руководству и
по управлению проектом. В данном контексте рассказывалось об использовании
модели ситуативного руководства.
Использование описанных моделей, инструментальных средств и методик
позволит придать вашей команде разработчиков спокойный и управляемый характер.
Контрольные вопросы
1. С помощью какой из представленных характеристик определяется размерность
психологического типа?
- интеллект
- достижение
- предпочтение
- психопатология
2. Воспользуйтесь материалами о "стилях общения", приведенными в табл. 6.15, в
качестве руководства при подготовке презентации вашего текущего проекта,
предназначенной для обычной аудитории. Учитывая ваши предпочтения
четырехбуквенных типов, опишите в вашей речи два способа эффективного общения
с учетом каждого из противоположных типов предпочтений. Например, если вам
присущ тип I из пары экстраверсия/интраверсия (extroversion/introversion),
опишите, как вы относитесь к использованию типа Е.
Экстраверсия/интроверсия (E/I, Extroversion/Introversion)
Мой тип:
Мой подход к моей противоположности:
1.
2.
Сенситивность/интуиция (S/N, Sensing/Intuition)
Мой тип:
Мой подход к моей противоположности:
1.
2.
Мышление/ощущение (T/F, Thinking/Feeling)
Мой тип:
Мой подход к моей противоположности:
1.
2.

Отбор команды разработчиков проекта 235
Суждение/восприятие (J/P, Judgment/Perception)
Мой тип:
Мой подход к моей противоположности:
1.
2.
3. Каковы, по крайней мере, две причины необходимости создания в команде
современной рабочей среды? Назовите четыре стадии жизненного цикла разработки.
Таблица 6.15. Общение между различными типами личностей в ходе
выполнения проекта
Распознавание стилей общения
Е Вовлекает вас в изучение проекта, желает первым вступать с вами в дискуссии
I Раздумывает по поводу проекта перед тем, как приступить к его обсуждению, хочет
сначала получить информацию о нем
S Поддерживает беседу на основании фактов, образов и реального опыта
N Описывает, каким образом проект связан с объектами реального мира либо улучшает
их качества
Т Точность, логика и исследования являются более значимыми, чем личные взаимосвязи
F Личное отношение, забота о человеческих реакциях; личные взаимосвязи значат
больше, чем проект
J Наибольшее значение придает целям, приоритетам и графикам
Р Ощущает себя счастливым при расширении возможностей; реалистическая адаптация
Общение с различными типами личностей по поводу проекта
Е (экстраверсия)
I(интроверсия)
S (сенситивиость) N (интуиция)
Требуется хорошая
словесная
презентация
Пытается вовлечь вас
в изучение проекта;
позволяет задавать
вопросы,
прерываться либо вступать
в диалог
Может принимать
решения быстро и
в словесной форме;
производит
наблюдения и не склонен
к"переоценке"
Большинство
вопросов решается за один
раз; не углубляется
в детали
Требует для
просмотра хорошо
составленное
предложение
Требуется время для
отображения
деталей либо следствий
проекта
Обычно не
принимает быстрых
решений, если только
вы не обсудили их
преждевременно
Начинает с
фактов, строит
"большую картину"
Использует
простые и
практичные примеры
Акцентирует
внимание на
реализации и
следующих этапах
Рассматривает
системы в
качестве
совокупности
фактов/проектов
Остается на
стадии "где и как"
Начиная с
"большой картины",
дополняет ее
фактами
Объединяет
факты и идеи
Комментирует
незамеченные
последствия и буду-
щие разработки
Обсуждает проект
как часть системы
Имеет творческие
идеи, обладает
энтузиазмом
Допускает
корректировки на
последней стадии

236 Глава 6
Окончание табл. 6.15
Общение с различными типами личностей по поводу проекта
Е (экстраверсия)
I (интроверсия)
S (сеиситивиость) N (интуиция)
Не думайте о том, что
Е вспомнит о вас на
следующей неделе;
напоминайте о себе
телефонными
звонками, почтовыми
сообщениями,
обновлениями
существующих программ. Этим
самым вы
удовлетворите потребности Е
в разнообразии,
контактах и действиях
Желание сделать что-
либо сейчас ради
удовлетворения
внешних нужд либо
устранения кризиса
То. что вы говорите,
имеет большее
значение, чем то, как вы
это говорите
Не отступайте от
логики, будьте
исследователем
Будьте сдержанным,
консервативным,
деловым
Подчеркивается
достоверность,
надежность и важность
статистических данных
Избегает обобщений,
повторения,
нелогичности
Не следует
беспокоить его
телефонными звонками,
литературой или
обновлениями
существующих
программ; поговорите
с ним заранее о
следующем
запланированном контакте
Даже в кризисной
ситуации
необходимо найти время все
сделать правильно
после тщательного
обдумывания;
никакой спешки
Тон вашего
разговора имеет большее
значение, чем
смысл сказанных
слов
Подчеркивается
преимущество
Используйте
визуальный контакт,
улыбайтесь, будьте
дружелюбным и
находите личный
подход
Поддерживайте
обслуживание либо
проект с
использованием
рекомендаций, полученных из
первых рук, либо
персональной
обратной связи
Высказывает
подлинный интерес по
отношению к
клиенту как к личности
Подстраивает
проект к
имеющимся
прецедентам
Никаких
сюрпризов!
Подбирает
графики,
приоритеты, критерии и
цели для
определенного клиента.
Будьте
организованными!
Предоставьте
обратную связь,
благодаря чему J
"остается
отслеживать" текущие
цели
Концентрируется
на расширении
возможностей по
адаптации
Дипломатическое
напоминание Р
о том, что
решение должно быть
принято в рамках
определенных
временных
ограничений
Оставляет время
для развлечений
Источник: Dr. Richard Grant, instructor for The University of Texas at Austin, Software Quality
Institute, Software Project Management Certification Program.

Отбор команды разработчиков проекта 237
Практическое занятие
В вашей компании была проведена реорганизация всех маркетинговых групп
таким образом, что они свелись к отчетным структурам. Ваш босс, директор по
управлению проектами, был перемещен в линейную организацию, находящуюся во
Флориде. В то же самое время мисс Пайтель, директор отдела маркетинга в AsiaPac, стала
менеджером отдела маркетинга в компании по разработке ПО в городе Бангалор
(BSD, Bangalore Software Development). Выполняя новые обязанности в BSD и
испытывая необходимость в том, чтобы декларировать свой доход, она собирается всю
работу по CRM перенести в Бангалор. Единственный руководитель, остающийся в
линейной маркетинговой организации, — это вы, менеджер проекта. Обратитесь в
BSD и укомплектуйте штат с целью выполнения незавершенного проекта CRM. Каким
образом эта ситуация скажется на ваших проектных планах?
Литература
Kummei owJean M., NancyJ. Barger and Linda К. Kirby. Worktypes. NY: Warner Books, 1997.
Kroeger Otto and Janet Theusen. Talk Type at Work. NY: Delacorte Press, 1992.
Tieger Paul D. and Barbara Barron-Tieger. Do What You Are: Discover the Perfect Career for You Through the
Secrets oj'Personality Type, 2-е издание. Boston, MA: Little, Brown, 1995.
Tieger Paul I), and Barbara Barron-Tieger. Nurture by Nature: Understand Your Child's Personality Type —
and Become a Better Parent, 1-е издание. Boston, MA: Little, Brown, 1997.
Дополнительные сведения в Internet
www. computer, огд/tab/swecc/. Объединенный Комитет IEEE-CS/ACM по этике разработки
ПО и профессиональной практике (Software Engineering Ethics and Professional Practices, SEEPP)
разработал этический кодекс для инженеров-программистов (Code of Ethics for Software Engineers).
www.huraanmetrics.com/jLingType.htni. Сокращенная версия инструмента тестирования
MBTI.
www. keirsey. com. Модель сортировки темпераментов Кирси, впервые представленная в книге
Дэвида Кирси Please Understand Me.

Определение цели
и области действия
программного проекта
В предыдущих главах процессы и жизненные циклы разработки подавались в
форме некоего "каркаса", обеспечивающего управление программными проектами.
А сейчас описывается начальная стадия формального процесса создания проекта.
В частности, здесь рассматривается, каким образом согласуются разработка продукта
и процессы определения уникального экземпляра проекта. Процесс выполнения
любого проекта делится на пять этапов, которые условно именуются почему, что, как, еы-
полшние, сделано. Эти этапы согласуются с пятью процессами проекта PMI®: начало,
планирование, выполнение, контроль и закрытие. При этом процесс завершения
проекта реализуется независимо от природы самого проекта. Ранее уже
рассматривалось, каким образом устанавливается соответствие между упомянутыми пятью
этапами и жизненными циклами проекта, бизнеса и продукта.
Будут рассмотрены действия, требуемые для определения цели и области действия
уникального программного проекта. Описывается метод S.M.A.R.T.,
предназначенный для заполнения целей и задач, а также методика "будет/не будет", позволяющая
конкретизировать цели и задачи проекта. Затем эти понятия преобразуются в
ключевое содержимое документов, определяющих проект. К числу этих документов
относятся: техническое задание (договор), рабочие планы и план менеджмента
программного проекта (Software project management plan, SPMP).
Стадии жизненного цикла разработки
продукта
Определим стадии основного жизненного цикла разработки ПО, на которых мы
находимся в настоящий момент времени. На первых трех этапах, представленных на
рис. 7.1, определяется цель и область действия проекта. В ходе исследования
концепции на высшем уровне формулирования потребности идентифицируется цель,
выдвигаемая при разработке системы. В процессе исследования системы и на этапах

Определение цели и области действия программного проекта 239
формирования требований область действия проекта уточняется до тех пор, пока не
станет понятной и легко управляемой.
^
\
\
Исследование
концепции
рование

потребности
.Л
\
Исследование
системы
.'
интерф
систем
Распределение
ресурсов
•
Бюджет
ейса
1 ,
1 1
1»
^
Требования
.'
• Cneunq икания'
требова
к ПО
НИИ
1
11
N
Разработка
проекта
,
i ■ иго сание '
1 раз
1 бОТ
Выбор модели
жизненного цикла
разработки ПО
i
i i
i i
i
i i
i i
■
i i
i i
i i
i i
i i
i i
i I
i i
Установка среды проекта
Методологии i
| Стандарты {
i Инструменты i
План менеджмента
| Проектная отчетность и испытательный план
l План менеджмента программного проекта

раки ПО
• Пл
Базовая модель жизненного цикла системы
^
Внедрение
тации/вери-
фикации ПО
J
,
>
<'
v
Установка
• Отчет об

тестации/верификации ПО
' ^
< i
N.
Эксплуатация
и поддержка
i
•
Пользовательская
документация
Инициализация
и планирование проекта
1
| Определение целей и области )
дейс
гвия
t
прог
ИМ).
(КОГО
1
прое
кта
■ ,
\
И ч
Сопровождение
1 • Документация'
по
сопровождению ,
1 (
L
.
Вывод из
эксплуатации
• Архивный
отчет !
Рис. 7.1. Местонахождение цели и области действия программного проекта в жизненном цикле
разработки ПО
Связь главы 7 с 34 компетенциями
В главе рассматриваются компетенции, приведенные на рис. 7.2. Определение
целей и области действия проекта напрямую связано с технологиями начальной оценки
и определения продукта, применяемыми при его разработке. Навыки по
менеджменту проекта связаны с процессами оценки и документирования. При этом
используются компетенции, относящиеся к управлению персоналом (лидерство, искусство
ведения переговоров, общение и взаимодействие).

240 Глава 7
Методики разработки продукта
1. Определение продукта— идентификация клиентской среды и требований,
выдвигаемых продуктов.
2. Выполнение начальной оценки— оценка степени трудности, рисков, затрат и
разработка графика.
Навыки менеджмента проектов
3. Создание структуры пооперационного перечня работ — разработка структуры
WBS для проекта.
4. Документирование планов— идентификация ключевых компонентов
разрабатываемого проекта.
5. Оценка стоимости — оценка затрат, понесенных на этапе завершения проекта.
6. Оценка трудозатрат — оценка трудозатрат, требуемых для завершения проекта.
Навыки менеджмента персонала
7. Взаимодействие и общение — взаимодействие с разработчиками, высшим
руководством и другими командами.
8. Лидерство — обучение команд разработчиков проекта с целью получения
оптимальных результатов.
9. Успешное ведение переговоров — разрешение конфликтов и успешное ведение
переговоров.
10. Эффективное представление— эффективное использование письменных и
устных навыков с целью презентации проекта.
Управление программными проектами
Продукт
1. Процессы оценивания
2. Знание стандартов процесса
3. Определение продукта
4. Оценка альтернативных
процессов
5. Управление требованиями
6. Управление субподрядчиками
7. Выполнение начальной оценки
8. Отбор методов и инструментов
9. Подгонка процессов
10. Контроль качества продукта
11. Понимание действий по
разработке продукта
Проект
12. Создание структуры
пооперационного перечня работ
13. Документирование планов
14. Оценка стоимости
15. Оценка трудозатрат
16. Менеджмент рисков
17. Контроль развития
18. Планирование
19. Отбор методов измерения
20. Отбор инструментов
менеджмента проектов
21. Отслеживание процессов
22. Отслеживание хода разработки
проекта
Персонал
23. Оценка производительности
24. Вопросы интеллектуальной
собственности
25. Проведение эффективных встреч
26. Взаимодействие и общение
27. Лидерство
28. Управление изменениями
29. Успешное ведение переговоров
30. Планирование карьерного роста
31. Эффективное представление
32. Набор персонала
33. Отбор команды
34. Создание команды
Рис. 7.2. Управление целями и областью действия программного проекта, связанных с 34
компетенциями

Определение цели и области действия программного проекта 241
Учебные цели главы 7
Основной темой главы является определение целей и области действия проекта с
тем, чтобы оценка хода его выполнения была в максимальной степени облегчена и
отсутствовали сомнения в реальности достижения целей проекта.
Ясное и четкое определение целей и области действия проекта возможно с
применением нескольких методик и инструментов. Среди них: методика "будет/не будет"
и контрольный список целей S.M.A.R.T.
После изучения материала главы читатель должен уметь выполнять следующее:
■ объяснять, почему планирование проекта является столь значимым;
■ описывать значение и содержимое технического задания проекта, а также плана
управления программными проектами;
■ создавать полезные формулировки для целей и перспектив;
■ объяснять методику, применяемую при ограничении области действия проекта;
■ описывать пять этапов выполнения любого проекта, а также объяснять, каким
образом они связаны с процессами делового продукта и разработкой ПО;
■ обосновывать, каким образом техническое задание проекта, рабочий план
(Statement of work, SOW), план управления программными проектами (Software
project management plan, SPMP) и спецификация требований по разработке ПО
(Software requirements specification, SRS) связаны между собой и с другими
документами.
Планирование проекта
Для чего же требуется планирование? Не правда ли, что планы постоянно
изменяются? Зачем тратить массу времени и нести трудозатраты на изложение
собственных мыслей на бумаге, если все может измениться "по мановению волшебной
палочки?" Почему бы просто не делать, что положено, преодолевая при этом всякие
неожиданности? Эти вопросы вполне логичны для нашего мира, изменяющегося со
скоростью, сравнимой с быстротой распространения Internet. Какая бы "дорожная
карта", состоящая из стадий жизненного цикла не выбиралась, всегда возможны
неоднозначные ситуации, и ваша команда разработчиков проекта может получить
конечные результаты, отличающиеся от запланированных целей.
Командующий силами англо-американского десанта на побережье Европы,
высадившегося на побережье Европы 6 июня 1944 года, генерал Дуайт Эйзенхауэр заявил:
"Планы ничего не значат. Но сам процесс планирования всеобъемлющ". Он имел в
виду, что хорошо продуманные и подробные планы являются крайне
недостоверными перед какими-либо роковыми обстоятельствами. Но при этом Дуайт осознавал,
что осознание сути проблемы на стадии обсуждения планов позволит команде
корректнее реагировать на новизну ситуации. Благодаря этому члены команды будут
лучше подготовлены к восприятию новых возможностей и смогут предотвращать
появление серьезных ошибок. Оптимальной ситуацию можно назвать в том случае,
когда подготовка соответствует возможностям.
Планирование проектов представляет собой процесс, который "укладывается в
каркас" выполняемого проекта. Сюда входит определение задач проекта, выбор
соответствующей стадии жизненного цикла, а также установка политик, процедур и процессов,

242 Глава 7
необходимых для достижения целей. Объем предварительной работы зависит от
степени организационной подготовки. Если ваша команда представляет собой "наспех
сколоченную" группу людей, потребуется дополнительное количество управляющих
структур. Если же костяк вашей команды образуют люди, которые достаточно долго
проработали вместе, потребуется всего лишь схема и простой контрольный список.
Как правило, команда разработчиков обладает достаточным "культурным
наследством", позволяющим в достаточной степени конкретизировать планы, используя
существующие структуры генерации отчетов, определения и рабочие продукты.
Старая шутка характеризует планирование словами "зарядил, выстрелил,
прицелился" либо "вы идете впереди и начинаете кодирование, в то время как я подымаюсь
вверх и выясняю, что они хотят". Также при работе над многими проектами можно
воспользоваться следующим ироническим "жизненным циклом" (см. примечание 7.1).
Авторы книги надеются, что вы не воспримете серьезно подобные рекомендации!
Примечание 7.1. Типичный жизненный цикл для организаций с низкой
степенью подготовки
Фаза 1-
Фаэа2-
ФаэаЗ-
Фаза 4-
Фаза 5 -
Фаза 6-
Фаза 7-
Фаэа8-
- начало работ над прс%к^»* 'г ^\^ТЩ^^^^^^'Щ '^?'-v3^**W*''M
-дикийэнтузиазм :;^ "-'-v^:У^^^^^^ШЩ^т< $Щ*Ж^Ь&%
-разочарование * ■' ' ' ■'^У^Ш^^Ш^^^^-
"хаос ■■■: '.^+^:щ*;яШ$${^^
-поисквиновника ••;?•''. ." V-"-'■V;r",,b^i-'-v?^i''>s'.'*iuV J'f'-ViwHv •
-избиениемладенцев . -. : , -.,,.; .' *'и/'h':-;ii;'.v?>>''4-■&%'■ '-'--Ч L-^.'У '&
- поощрение постороннгаГлнвд jjr \.Щ^Ш/^^^,^Ш^^Щф^^^ШШ^>Л
- определение потребносте| ; ^ ы^мЙ^М.^шШ'Л*>?*&I
Независимо от выбора жизненного цикла проекта, существует два различных
набора процессов:
■ процессы проекта: описывают, каким образом команда разработчиков проекта
будет определять и выполнять процессы разработки продукта (рис. 7.3 и 7.4);
■ процессы продукта: описывают, каким образом создается программный продукт
(рис. 7.1).
Почему
Обоснование
Коэффициент
КОИ
Что
Техническое
задание
(на проект)
Процесс SOW
Как
ПланБРМР
Модель
жизненного
цикла
Выполнение
Выполнение
жизненного
цикла
Сделано
Процесс РРА
Рис. 7.3. Схема процессов проекта

Определение цели и области действия программного проекта 243
Определение процессов продукта приводится в главах 3-5, а более подробному их
рассмотрению посвящены главы 19-24. Процессы проекта были определены в главе 3,
а более подробное их рассмотрение будет произведено при рассмотрении методов
создания конкретного экземпляра плана проекта.
Рис. 7.4. Карта интеграции процесса проекта
Этап "Почему?"
Для каждого проекта требуется подходящая причина завершения, и на этом этапе
гарантируется наличие, по крайней мере, одной такой причины. С помощью бизнес-
анализа, подходящего для данной организации, менеджер проекта может выполнять
анализ возможностей, подготовку обоснования коэффициента возврата инвестиций
для проекта (КОИ, ROI). Суть дела в данном случае речь идет о том, что проект имеет
большое стратегическое значение и должен быть завершен с целью выполнения
других проектов. Подготовка обоснования величины ROI осуществляется финансовыми
экспертами, которые могут определять показатели чистой приведенной стоимости
(Net present value, NRV), норму прибыли внутри страны (Internal rate of return, IRR),
окупаемость (Payback period, PBP), а также выполнить другие требуемые в этом случае
вычисления. Когда бы ни выполнялось обоснование, оно будет зафиксировано и
обычно становится частью технического задания проекта.
Этап "Что?"
Непосредственно после обоснования реализации программного проекта
определяются цель и область действия проекта. Техническое задание проекта представляет
собой рабочий план, в рамках которой реализуется проект. В этом документе
описываются разрабатываемые продукты, приведен схематический график высокого
уровня, производится начальная оценка требуемых ресурсов, а также рассчитывается
ожидаемый срок возврата инвестиций организации. Техническое задание выполняет
две основные функции.
1. Формально документируется существующий программный проект, а также
отделяется работа, выполняемая в рамках проекта, от текущих операций
(сопровождение и поддержка).

244 Глава 7
2. Обеспечивает получение одобрения со стороны менеджеров, а также передачу
ресурсов, необходимых для выполнения проекта.
Техническое задание может иметь форму юридического контракта в совокупности
с рабочим планом (Statement of work, SOW), регламентирующим выполнение работы
сторонними организациями, находящимися вне зоны непосредственного контроля
менеджера проекта. В этом случае детали определения раздела "как" остаются
субподрядчикам.
Этап "Как?"
Как только будет одобрено техническое задание, менеджер программного проекта
может воспользоваться другими навыками программного инжиниринга и управления
персоналом, требуемые при определении продукта, а также для управления
командой, которая разрабатывает и поставляет продукт. Этот этап представляет собой
"сердце" планирования программного проекта. Основной рабочий продукт данного
этана представляет собой план менеджмента программного проекта (Software project
management plan, SPMP). В плане SPMP объясняются (на уровне детализации,
соответствующем степени зрелости организации-исполнителя) порядок выполнения
стадий жизненного цикла. Они могут различаться для разных проектов даже в том
случае, если будет использован один и тот же основной жизненный цикл разработки ПО.
При этом формируется своего рода "дорожная карта" для команды разработчиков
проекта, в соответствии с которой разрабатываются поставляемые продукты в
соответствии с требованиями заказчиков. Как правило, при разработке больших проектов
либо проектов с большим сроком выполнения, применяется итеративное
планирование. Детализованное планирование выполняется только на следующем этапе
жизненного цикла проекта.
Этап "Выполнение"
Как только будет завершен и одобрен план SPMP (с помощью заказчика либо в
ходе осуществления менеджмента), выполняются следующие этапы жизненного цикла
разработки, выбранные для данного проекта. Даже если применяется спиральная
модель разработки проекта, план SPMP может сыграть роль "дорожной карты", которая
руководит действиями команды вплоть до завершения проекта. На этом этапе задей-
ствуется большая часть из 34 компетенций.
Этап "Сделано"
Наравне с хорошим менеджментом процесса потребуется выполнение этапа
оценки. Этот этан именуется анализом эффективности выполнения (Post-performance
analysis, PPA). В результате выполнения этого этапа генерируются соответствующие
отчеты. В ходе изучения этих уроков можно получить рекомендации относительно
выполняемого проекта либо улучшений производственной деятельности, полезных
при выполнении следующего подобного проекта.
Описанные пять этапов необходимы при выполнении каждого проекта
независимо от его масштаба и достигаемых результатов. Переменные, определяющие размер,
область действия, стоимость, график, степень сложности и риска, определяют
ограничения и объем документации на каждом этапе, а также используемые стадии
жизненного цикла. Даже если идет речь о небольшом проекте, таком как сборка детского
велосипеда в подарок, требуется обдумывание относительно выбора пяти стадий

Определение цели и области действия программного проекта 245
проекта. Хотя, конечно, проекты подобного уровня не нуждаются в тщательном
документировании.
Согласно данным Института менеджмента проектов (Project Management Institute,
PMI®), при выполнении каждого проекта необходимо предусмотреть пять фаз:
начало, планирование, выполнение, контроль и завершение.
На рис. 7.4 демонстрируется, что фаза начала процессов осуществляется во время
выполнения этапа почему. При этом включается достаточный объем информации из
этапа что, которая требуется для осуществления процессов планирования. Оставшаяся
часть этапа что и весь этап как. Попадает под влияние процессов планирования. Этап
выполнение включает процессы выполнения и контроля, а этап сделано описывает
процессы завершения.
Если обратить внимание на процессы создания продукта, изображенные на
рис. 7.1, процесс планирования проекта начинается с этапа исследования концепции.
В результате можно удостовериться в том, что достигается решение реальной
проблемы заказчика либо можно оценить величину понесенных трудозатрат. На этом
этапе получаем ответ на вопрос как.
В главах 16 и 17 подробно рассматривается разработка детализированных
требований.
Процесс планирования является итеративным и обычно повторяется во время
выполнения проекта по мере изменения условий либо получения новой информации.
Но если цели проекта были определены на достаточно раннем этапе, не следует их
изменять радикальным образом: в противном случае проект будет обречен на
"бесцельные блуждания" и досрочное завершение с последующим переопределением.
Если возникает конфликт между различными заданиями, придется назначить им
различные уровни приоритета. В противном случае выполнение проекта будет под
угрозой срыва.
Описываемый общий подход укладывается в схему, изображенную на рис. 7.5.
Определение цели
При выполнении каждого проекта определяется, как минимум, одна цель. Для
большинства проектов характерны несколько целей. Иногда эти цели именуются
заданиями проекта, либо используется собирательное название "миссия проекта".
В данном случае миссия проекта эквивалентна достижению целей и заданий проекта.
Независимо от того, используется или не используется соответствующее описание,
определение ясной и четкой миссии проекта является одним из простейших и
наиболее экономных действий, осуществляемых при разработке всего программного
проекта. "Размытая цель" чаще всего ведет к получению "неопределенных результатов".
Менеджмент программных проектов чаще всего связан с менеджментом ожиданий и
предсказанием рисков.
Менеджер программного проекта всегда имеет одну цель: завершение проект. Эта
цель является следствием следующего определения: проект является уникальной и
временной попыткой с определенными начальной и конечной датами, в ходе осуществления
которой выполняется одно или большее количество заданий. При этом учитываются
ограничения по затратам, трудозатратам, а также по достигаемому качеству.
Project Management Institute. A Guide to the Project Management Body of Knowledge. Sylva, NC: PMI
Publication Division, 1996.

246 Глава 7
Жизненный цикл проекта
уР Закрытие
[Выполнимость | Приобретение
Эксплуатация
Жизненный цикл проекта
Рис. 7.5. Взаимосвязь жизненных циклов проекта и продукта при разработке про-
граммного проекта
Зачастую то, что выглядит как обычная цель программного проекта, не может
одинаково трактоваться каждым заинтересованным лицом. Поэтому столь важно
зафиксировать цель проекта и интерпретировать ее для всех членов команды.
Предположим, что в рамках программного проекта создается эволюционная Web-система
ввода табличных данных, которая может рассматриваться как:
■ внутренний инструмент, позволяющий воплотить "в металле" трудозатраты по
разработке со стороны менеджера по проектированию ПО;
■ учебный пример, предназначенный для тренировки недавно принятых на работу
программистов;
■ требование, формулируемое генеральным менеджером для внешнего заказчика на
этапе, предшествующем запуску на выполнение нового программного проекта;
■ маркетинговый инструмент, предназначенный для демонстрации возможностей
программистов.
Каждый из этих аспектов предопределяет свой уровень надежности, простоты
эксплуатации и поддержки, адресуемой заключительному программному продукту. К
сожалению, многие менеджеры проектов в подобной ситуации просто говорят о том, что
целью проекта является "построение эволюционной системы ввода табличных
данных". В результате чего создаются условия для ложной интерпретации подобного
утверждения в будущем. С целью уточнения цели для всех исполнителей должны
утверждаться цель и задания, которые определены в том виде, как указано в примечании 7.2.
Подобное утверждение иногда называют "беседой в лифте". Это ясное, но сжатое
описание, которое, например, может излагаться генеральному менеджеру во время
неформальной беседы при подъеме на скоростном лифте (причем без
предварительного уведомления). Например, в этом утверждении может говориться о том, что
проект предназначен для внутреннего применения (влечет какие-либо внутренние
выгоды, но при этом отсутствует непосредственная прибыль). Также может утверждаться,

Определение цели и области действия программного проекта 247
что проект предусматривает успешное развертывание (а не просто разработку),
указывается, кто является заказчиком (отдел инжиниринга), а также устанавливается
временные рамки (перед началом следующего большого внешнего программного проекта).
Примечание 7.2. Пример описания цели
Важно определить общую цель проекта, выраженную в легко понимаемых и
воспроизводимых терминах. На любом совещании, посвященном обсуждению проекта,
каждый из членов команды разработчиков должен осознать цели производимой
работы. Благодаря этому достигается компактное определение проекта, которое может
служить вступлением для "беседы в лифте", когда каждый разработчик сможет
рассказать о целях проекта любому постороннему человеку.
Определение четко сформулированных заданий
В предыдущем примере в качестве заданий, связанных с достижением целей
проекта, упоминались некоторые характеристики, которые требуется уточнить.
Большинство заданий имеют отношение к вопросу что? Наилучшие из них также
отвечают на вопрос как? Ниже приводится соответствующий перечень:
■ концентрация на поставляемых продуктах, а не на процессах: в конечном счете,
заказчика заботит именно завершение разработки конечного продукта
(эволюционная система ввода табличных данных), а не процессы, необходимые для
получения конечного продукта (SPMP, SRS и т.д.);
■ способность к измерению и тестированию ($, %, коэффициент совместного
применения, даты): Любое задание должно выражаться в количественном виде,
поддаваться измерениям и тестированию, что обычно связано с достижением определенного
уровня качества (понятие "успех" влечет определенные критерии одобрения);
■ ориентированность на действия: цель провоцирует определенные действия (слова
построить и развернуть подразумевают наличие системы);
ш краткость: цель разрабатываемого проекта может быть процитирована и
объяснена за несколько секунд (за время подъема скоростного лифта);
■ реальность выполнения (в сфере имеющихся полномочий): цель должна быть
приемлемой и не направлена на решение проблем глобального характера
(учитывайте наличие аналогов разрабатываемого приложения);
■ общеизвестность: все разработчики должны быть ознакомлены с целями
проекта, и они должны быть изложены в техническом задании проекта (как можно
более кратко).
Процесс определения непрерывно эволюционирует, приводя к успешному началу
выполнения программного проекта .
Kerzner Harold. Project Management: A Systems Approach to Planning, Scheduling, and Controlling,
6-е издание. New York, NY: John Willey & Sons, 1998.

248 Глава 7
После определения заданий формируются легко оцениваемые подзадачи. При
этом должны отслеживаться затраты и производительность. Вместо применения
подхода "большого взрыва", когда устанавливается одно или несколько заданий,
хорошей практикой при выполнении проекта является определение множества
подзадач на всем протяжении выполняемого проекта. Множество небольших "стадий"
всегда лучше, чем одна большая "стадия", выполняемая в конце проекта. Каждый член
команды разработчиков должен иметь свои собственные задания и подзадания, к
достижению которых он будет стремиться. При определении четких заданий
весьма полезным является метод S.M.A.R.T. (сокращение от слов specific, measurable,
achievable, realistic и time-bound, т.е. специфичность, изменяемость, достижимость,
реалистичность и временные рамки, соответственно).
Для любого задания определяются специфичные результаты и производственные
цели. При этом возникают некоторые вопросы. Являются ли задания действительно
специфичными? Согласны ли вы и ваш спонсор/заказчик с результатами выполнения
каждого из заданий проекта? Являются ли задания измеряемыми? Что означает
термин "оправдание ожиданий" для вас и заказчиков при выполнении каждого из
заданий? Являются ли задания реалистичными и достижимыми? Обоснуйте ответы "да"
или "нет"? Какого рода поддержка потребуется при выполнении заданий? Являются
ли задания совместимыми? Соответствуют ли требования потребностям заказчиков?
Сопоставимы ли задания с ключевыми факторами успеха организации, бизнес-целями
и стратегиями? Связаны ли задания с жесткими временными рамками? Существуют ли
временные ограничения относительно выполнения задания?
Ниже приводится пример относительно краткосрочного задания, в ходе
выполнения которого реализуется часть проекта по усовершенствованию
крупномасштабных систем но обеспечению качества, развернутых в больших транснациональных
корпорациях. Обратите внимание, что данное задание является специфичным и
измеряемым, достижимым для среднего отдела по обеспечению корпоративного
качества. Также наличествуют признаки реалистичности и релевантности при
достижении долговременных целей отдела и корпорации, временных ограничений (в данном
случае указывается конечная дата, но не указывается длительность проекта).
Сравните два процесса по производству автоматизированных линий в двух
различных компаниях в соответствии со стандартом ISO 9000. Завершите проект к концу
третьего квартала с максимальным бюджетом в $30000.
Определение рабочей области
Частью плана SPMP, которая иногда оформляется в виде одного или нескольких
документов, является рабочая область проекта. Ее также называют рабочим планом
(Statement of work, SOW), иногда—утверждение, включающим описание требований
(Statement of requirements, SOR), хотя и последнее название может вступать в
противоречие со спецификацией требований к ПО (Software requirements specification,
SRS), которая и содержит детализированное описание требований. Документ SOW
содержит описание достаточного количества специфичных деталей и спецификаций
компонентов, которые "упакованы" таким образом, что могут передаваться
субподрядчику для дальнейшего выполнения. Он может быть встроенным, оформляться в
виде приложения плана SPMP либо реализовываться в виде полностью отдельного
документа в случае, когда требуется его отделение от основного документа, исходя из
соображений безопасности либо руководствуясь какими-либо другими причинами.

Определение цели и области действия программного проекта 249
Определение граничных условий
Довольно часто членам команды разработчиков проекта проще
идентифицировать, что должен включать данный программный проект, чем разобраться в том, что
он включать не должен. При формулировании цели и заданий проекта описывается,
что входит в заключительную часть области действия проекта. Конечно, довольно
трудно определить, чего не должен включать проект, но эта информация часто
является абсолютно необходимой при определении границ рабочей области проекта.
Затем осуществляется подготовка проекта документа SRS, в котором описываются
детали будущего проекта.
Установка четких границ между областью действия проекта и его заданиями
облегчается с помощью методики "будет/не будет". Эта методика является довольно
простой. При рассмотрении каждой цели либо задания команда может применять
технику "мозгового штурма". В этом случае определяется содержимое проекта, а
также формируются два специальных списка, предназначенные для разработчиков
(рис. 7.6).Затем метод "мозгового штурма" применяется для определения
содержимого обоих списков. После этого они могут применяться для создания перечня
предположений, касающихся проекта.
Проект НЕ будет...
Рис. 7.6. Методика "будет/не будет"
В следующем упражнении рассматриваются скрытые предположения,
высказанные членами команды разработчиков проекта относительно области действия
проекта либо его рабочих продуктов. Лучше рассмотреть предположения на ранних
стадиях проекта, а не после того, как будет выполнена значительная часть проекта, а потом
обнаружится непонимание сформулированных целей и заданий. Так,
воспользовавшись примером формулирования цели проекта (см. примечание 7.2), можно сказать
относительно проекта, что он
будет:
■ внутренним;
■ эволюционной системой ввода табличных данных;
■ основанным на использовании Web;
■ предназначен для отдела разработки программ;

250 Глава 7
■ развернут перед тем, как начнется следующий большой проект;
■ при этом были успешно применены существующие критерии развертывания
приложений;
■ выступать в роли учебного проекта с целью ознакомления команды разработчиков
с процессом менеджмента новых проектов;
не будет:
■ предназначаться для использования другими отделами либо пользователями;
■ полномасштабной системой учета труда;
■ предназначенным для обеспечения доступа к информации с помощью PDA либо
сотовых WAP-телефонов.
■ требуемым при организации взаимодействия с существующими программами
учета прибавочной стоимости, такими как MS Project;
■ находиться в режиме бета-тестирования во время начала разработки следующего
проекта;
■ применять услуги внешних субподрядчиков при разработке проекта.
Перечисленные характеристики позволяют четко определить границы рабочей
области проекта. Они легко преобразуются в предположения, которые могут
фиксироваться в техническом задании проекта либо в плане SPMP. С появлением
предположений в проект вносятся первые риски, поскольку при нарушении любого
предположения искажается рабочая область проекта.
Иногда рабочая область проекта является достаточно большой, что позволяет
разрабатывать свои собственные документы, вместо включения соответствующих
утверждений в техническое задание. Однако на ранней стадии жизненного цикла
рабочая область действия проекта представляет собой просто схематичную
позицию плана. Зачастую документы SOW/SOR/SRS подразделяются на более мелкие,
полностью описывающие задачи субподрядчиков с учетом общих требований. В этих
случаях документы SOW/SOR/SRS могут содержать неспецифические позиции,
относящиеся к плану управления проектами (например, протокол отчета о
состоянии, графики платежей либо юридические документы). Детали и шаблоны
конструкции SOW могут варьироваться в зависимости от специфики производства и
области действия, но в общем, случае они переносят спецификации продукта с целью
их встраивания в формат, позволяющий сделать разграничение относительно
других процессов проекта.
Техническое задание проекта
Техническое задание включает определение деловых потребностей, описание
продукта, а также основные предположения. Соответствующий пример приводится в
примечании 7.3.
Примечание 7.3. Определение технического задания

Определение цели и области действия программного проекта 251
Теперь, когда были определены индивидуальные задания проекта, осознана общая
рабочая область проекта и достигнуто согласование с другими членами команды,
наступило время подготовить техническое задание. Как правило, менеджер проекта
"схватывает" задания высокого уровня и информацию относительно рабочей области
проекта, а затем включает другую уместную информацию высокого уровня, которая
может быть одобрена спонсором либо заказчиком. Довольно часто техническое
задание проекта является единственным основным документом, требуемым при выборе
проекта в ходе процесса управления портфелем заказов организации. В ходе
выполнения этого процесса происходит сравнение проекта с другими проектами с
помощью критерия "затраты/прибыль". После выбора проекта происходит его
финансирование. Модели и методы выбора проектов не входят в число рассматриваемых в
книге тем. Для получения дополнительных сведений воспользуйтесь ссылками,
указанными в конце главы.
Содержимое технического задания проекта
Иногда техническое задание может именоваться по-другому, например, документ,
описывающий начало работ над проектом проекта (Project initiation document, PID),
базовая линия рабочей области, либо просто контракт (в случае привлечения
субподрядчиков). При его разработке могут применяться различные методы, такие как
составление описательных документов (самый распространенный метод), заполнение
стандартного бланка (бумажный либо реализованный с помощью программного
приложения) либо использование электронных таблиц (в случае большого количества
финансовой информации).
Техническое задание содержит ответы на вопросы почему и как, связанные с
процессами проекта, которые рассматривались в начале главы. Он может содержать
краткие утверждения (очень краткие— не включающее описание каждой фазы!), но
включающее следующую информацию:
■ задания — определяются желаемые результаты;
■ функции — большинство свойств и/или процессов;
■ производительность — обобщенные спецификации;
■ ограничения — связанные со средой разработки ограничения;
■ область действия — границы проекта;
■ затраты/прибыль — приблизительная оценка затрат.
Будьте готовы отвечать на вопросы, задаваемые неподготовленными
собеседниками: Какова причина осуществления проекта? Получить какую-либо возможность,
решить проблему, увеличить прибыль, уменьшить затраты либо решить сразу
несколько вопросов? Будьте уверены в том, что сможете получить ответы на типичные
"корреспондентские" вопросы: Кто? Что? Где? Почему? Зачем?.
Обычно техническое задание проекта представляет собой одно- трехстраничное
письмо, заметку либо электронный документ — этого вполне достаточно в целях
безопасного управления либо получения одобрения проекта со стороны заказчика.
Иногда техническое задание называется планом SPMP и использует соответствующую
схему (при этом в процесс выбора, осуществляемый на ранних стадиях, включаются
только необходимые разделы). Иногда техническое задание лучше оформить в виде
отдельного документа, а затем позднее подшить его в общую папку. Это связано с тем,

252 Глава 7
что исполнители, как правило, не любят работать с большими документами (такими
как планы SPMP, включающие множество дополнительных разделов, блоков
поправок и контроля изменений, спецификаций, приложений и т.д.)- Помните о том, что
техническое задание предназначено для сжатого представления проекта на высшем
уровне с целью получения одобрения на осуществление менеджмента и поддержки (а
также подписи). После подписания технического задания можно конкретизировать
оставшуюся часть процесса планирования проекта, поскольку вы получили право на
одобренное спонсорство (и финансирование) .
План управления программным
проектом (SPMP)
Этот документ является наиболее важным для разрабатываемого проекта. В нем
определяется, каким именно образом предполагается выполнить проект, а также
описывается производимая продукция. Следующим по значению является документ
SRS. План SPMP может содержать определяющую информацию о проекте,
описывающую следующие моменты:
■ техническое задание — элементы технического задания проекта, определяющие
сам проект (включая поставляемые продукты);
■ организация — определяется организация, выполняющая проект, а также порядок
его выполнения при производстве поставляемых продуктов;
■ процесс — детали управленческого и технического процессов, которые могут
применяться во время осуществления проекта;
■ пооперационный перечень работ— пооперационный перечень работ и детали
рабочего пакета;
■ график — календарный план, зависимости и ресурсы;
■ бюджет — бюджетные и определяющие оценки.
Все эти элементы являются взаимосвязанными, и через некоторое время после
начала выполнения плана SPMP выясняется, что различные элементы встречаются
одновременно. Обычно выполнение процесса начинается с включения элементов
из одобренного технического задания в план SPMP. Поскольку одобрение проекта
произошло вне стадии формулирования концепции, оно может выполняться на
стадии определения (что?) и планирования (как?), когда имеет место
детализированное планирование.
Основные элементы плана SPMP
Как правило, план SPMP создается на основе шаблона, пример которого
описывается в документе IEEE 1058, "Standard for Software Project Management Plans"
("Стандарт для планов управления программным проектом"). В этом плане
описываются процессы проекта, рассмотренные ранее в этой главе . План SPMP описывает,
Lewis James P. Project Planning, Scheduling, and Control: A Hands-On Guide to Bringing Projects in on
Time and on Budget, дополненное издание. Chicago, IL: Irwin, 1995.
1 IEEE. "IEEE 1058 Standard for Software Project Management Plans." IEEE Software Engineering
Standards Collation. New York, NY: Institute of Electrical and Electronics Engineers, 1993.

Определение цели и области действия программного проекта 253
каким образом команда разработчиков проекта может реализовать процессы
жизненного цикла разработки ПО для выбранного жизненного цикла.
Информация технического задания проекта интегрируется в соответствующих
разделах плана SPMP. Остальные документы включают описанные ниже разделы:
■ обзор проекта и описание поставляемых продуктов;
■ организация проекта;
■ управленческие процессы;
■ технические процессы;
■ рабочие пакеты, график и бюджет.
Детали, описывающие порядок идентификации и представления информации,
требуемой для завершения плана SPMP, рассматриваются в следующих главах книги.
Глубина и тщательность рассмотрения каждого раздела имеет значение для принятия
решения относительно типа и области действия проекта. После завершения и
утверждения плана SPMP появляется точка отсчета, позволяющая контролировать проект
во время его выполнения (этап сделать).
Взаимосвязь между плановыми
документами проекта
Как показано на рис. 7.7, информационный поток начинается с определения
цели, заданий и области действия высшего уровня для предлагаемого программного
проекта. Эти позиции обычно представлены в техническом задании проекта. В
случае с большими проектами, либо для тех из них, которые переданы на выполнение
субподрядчикам, к техническому заданию добавляется документ, содержащий
описание рабочей области действия проекта. В последнем документе детализируется
описание проекта.
Определить.
Цель
Задания
Область
действия
Поч
ему ? + Что?
Для этого
небольшого
документа...
►
Техническое
задание (на проект)
Может быть один
или более документа
Как?
Со включенными
документами, полученными
после одобрения
~►
В в...
Процесс SOW
План SPMP
Будет частью этого
документа....
►
Процесс SRS
Рис. 7.7. Взаимосвязь плановых документов

254 Глава 7
Резюме
В главе рассматриваются вопросы взаимосвязи процессов проекта и продукта.
Также описывается взаимосвязь с целью определения конкретного проекта. Пять
этапов любого проекта именуются почему, что, как, выполнение, сделано. Эти этапы
соответствуют пяти процессам проекта PMI®, именуемым начало, планирование,
выполнение, контроль и завершение. Рассматривалось, каким образом эти пять этапов
соответствуют жизненным циклам бизнеса, продукта и проекта.
В главе рассказывалось о том, каким образом определять цель и область действия
уникального программного проекта. Описывался метод S.M.A.R.T., обеспечивающий
завершенность цели и заданий, а также методика "будет/не будет", позволяющая
уточнить цели и задания проекта. Цель и область действия проекта образуют
ключевое содержимое важных документов, определяющих проект. К числу этих документов
относятся: техническое задание, рабочий план, определяющий область действия,
план управления программным проектом (SPMP).
Контрольные вопросы
1. Каковы цели учебного проекта?
2. Определите свойства S.M.A.R.T. для цели учебного проекта.
3. Какова область действия учебного проекта?
4. Объясните разницу между областью действия и целью проекта.
Практическое занятие
В вашем распоряжении имеется план РМР, одобренный менеджерами вашего
отдела. Мистер Лу, исполняющий роль непосредственного представителя
министерства CRM в вашей корпорации. Он хочет провести телеконференцию, в которой
примете участие вы и руководство проекта. Под его руководством была одобрена область
действия исходного прототипа, но при этом ожидается дополнительное
предложение относительно второго прототипа, который будет разработан через 60 дней после
первого прототипа. Это может быть расширением системы ARRS, включающим
города Пекин, Тяньцзинь, Шицзячжуан и Шанхай. Эти новости являются весьма
обнадеживающими для вашей службы корпоративного менеджмента, поскольку в вашем
распоряжении имеются большие производственные мощности в Тяньцзине.
Литература
Adams John R. The Principles of Project Management. Sylva, NC: PMI Publication Division, 1997.
Lewis James P. The Project Manager's Desk Reference: A Comprehensive Guide to Project Planning, Scheduling,
Evaluation, and Systems, 2-е издание. New York, NY: McGraw-Hill, 2000.
Дополнительные сведения в Internet
dictionary, com/. Dictionary.com, интерактивный английский словарь.
www.pmi.org/. Институт управления проектами (PMI®). Ведущая организация в США,
занимающаяся проблемами управления проектами. Она представляет собой сертификационную
организацию, подготавливающую профессионалов в области менеджмента проектов (РМР). Основанный

Определение цели и области действия программного проекта 255
в 1969 году, в настоящее время PMI® вырос в организацию, которая является образцом
профессионализма в деле осуществления менеджмента проектов. Насчитывая более 60000 членов, Институт
PMI представляет собой ведущую некоммерческую ассоциацию профессионалов в области
менеджмента проектов. Здесь утверждаются стандарты менеджмента проектов, а также проводятся
семинары, осуществляется поддержка обучающих программ и производится сертификация организаций,
желающих стать лидерами в области разработки и менеджмента проектов.
www.sei . cmu.edu/activities/str/indexes/glossary/. СловарьSEI.

Создание структуры
пооперационного
перечня работ
Итак, вы разработали техническое задание проекта и получили восторженные
отзывы. Для чего же нужно создавать структуру пооперационного перечня работ?
Неужели недостаточно опыта профессионала в области разработки ПО? Если у вас
возникают подобные вопросы, уместно будет напомнить о том, что структура
пооперационного перечня работ (Work breakdown structure, WBS) является "сердцем" плана
проекта. На основе этого документа проектируются другие компоненты проекта.
Структура WBS представляет собой инструмент, применяемый для документирования
всех рабочих операций, которые должны быть выполнены при разработке и поставке
ПО надлежащим образом. Хотя иногда может показаться, что информация,
поддерживаемая этой структурой, является избыточной по причине наличия других
документов, создаваемых в ходе осуществления программного проекта (область
применения работ, спецификация требований ПО, документы по разработке проекта и т.д.).
Однако это не так, поскольку структура WBS консолидирует информацию из
различных источников, организуя ее с применением единого формата, удобного при
планировании, оценивании и отслеживании.
Структура WBS образует своего рода каркас, на основе которого разрабатывается
график выполнения проекта. Благодаря этому можно переходить от действий верх-
пего уровня в рамках проекта (действия типа сделать) через ряд упрощенных и
сравнительно незначительных действий, предназначенных для создания поставляемых
продуктов проекта, до тех пор, пока не будут выбраны легко управляемые действия.
В результате выбора подобной модели действий каждый пользователь сможет
разобраться во взаимосвязях между задачами и действиями, воспользовавшись простыми
и "прозрачными" методами. Подобная структура позволяет убедиться в том, что
представлены все рабочие операции и ни один из этапов не был пропущен. При
использовании подобной структуры команде разработчиков проекта значительно проще
разделить весь рабочий процесс на ряд небольших, хорошо определенных задач и
действий. В частности, при наличии структуры WBS облегчается планирование в том числе
(календарное), и оценивание. Подобная структура представляет собой основу для

Создание структуры пооперационного перечня работ 257
осуществления мониторинга проекта, а также для создания хронологической
коллекции данных (на рис. 10.3 можно увидеть процесс построения структуры WBS,
представляющей собой часть большой картины, отображающей процесс оценки ПО.)
В результате созерцания подобной картины напрашивается логический вывод о
целесообразности замены утверждения "мы выполнили 90% от запланированного"
на утверждение "мы завершили 97 из 234 запланированных действий". При этом
приобретают значимость взвешенные задачи и действия, которые могут быть
связаны с оценкой затрат.
Стадии жизненного цикла
разработки продукта
На какой же из стадий основного жизненного цикла разработки ПО мы находимся
в настоящий момент времени? Как показано на рис. 8.1, в данном случае идет речь о
начале работы, фактически на этапе исследования предварительной концепции
проекта. В главе 7 уже рассматривались этапы планирования схемы выполняемого
проекта (почему, что и как) (как показано на рис. 8.2). На этапе почему необходимо
выбрать подходящую модель жизненного цикла разработки ПО. Также потребуется
осведомиться относительно уровня детализации рабочих процессов с целью
выполнения оценки рабочих операций. В результате, можно оценить коэффициент возврата
инвестиций (КОИ) для данного проекта. На этапе что разработанная структура WBS
применяется для составления прогноза ожидаемого выхода рабочего продукта при
выбранном жизненном цикле разработки ПО. На этапе как структура WBS
применяется для выполнения бюджетных и детализированных оценок выполняемой работы,
а также для разработки реального графика. При этом также определяется порядок
использования накопленных на данный момент знаний с целью выполнения оценки и
определения размеров разрабатываемого программного продукта (дополнительные
сведения по этим вопросам приводятся в главах 10 и 11), а также выполняются
необходимые подготовительные действия, в результате осуществления которых
составляется реальный рабочий график (главы 14 и 15).
Связь главы 8 с 34 компетенциями
Создание структуры пооперационного перечня работ (Work breakdown structure,
WBS) представляет собой одну из важнейших частей любого проекта, поскольку при
этом закладывается "фундамент" всей дальнейшей работы. После определения цели и
области действия проекта на высшем уровне и получения одобрения на выполнение
дальнейших действий начинается планирование и настройка выполняемых рабочих
операций в соответствии с выбранной моделью жизненного цикла. Этот процесс
непосредственно затрагивает компетенции определения продукта и подгонки процесса,
л также применяется для создания структуры WBS. Он косвенно связан с
документированием планов и оценок, а также использует такие навыки, связанные с
управлением персоналом, как взаимодействие и общение, лидерство, ведение переговоров,
а также осуществление многократных презентаций.

258 Глава 8
Исследование
концепции
•Формули-'1
рование

потребности
Исследование
системы
• Спецификация'
интерфейса
системы
Идентификация
циклов SLC
•SLCs
Выбор
модели
• Модель SLC
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
■SLC
Распределение
ресурсов
1 Бюджет
Требования
■ Спецификация
требований
к ПО
Разработка
проекта
' Описание

разработки ПО
Внедрение
План

тации/верификации ПО
Выбор модели
жизненного цикла
разработки ПО
Установка
■Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
'
Пользовательская
документация
Сопровождение
* Документация
по
сопровождению
Вывод из
эксплуатации
• Архивный
отчет
Рис. 8.1. Жизненный цикл разработки продукта
Методики разработки продукта
1. Определение продукта— идентификация клиентской среды и требований,
выдвигаемых к продукту.
2. Подгонка процессов — модификация стандартных процессов с целью
удовлетворения требований проекта.
Навыки менеджмента проектов
3. Создание сггруктуры пооперационного перечня работ— создание структуры
WBS для проекта.
4. Документирование планов — идентификация ключевых компонентов.
5. Оценка стоимости — определение стоимости работ по завершению проекта.
6. Оценка трудозатрат— определение трудозатрат, требуемых для завершения
проекта.

Создание структуры пооперационного перечня работ 259
Навыки менеджмента персонала
7. Взаимодействие и общение — взаимодействие с разработчиками, высшим
руководством и другими командами, задействованными в работах по проекту.
8. Лидерство — тренировка проектных команд с целью получения оптимальных
результатов.
9. Успешное ведение переговоров— разрешение конфликтов и успешное ведение
переговоров.
10. Эффективное представление — эффективное использование письменных и
устных навыков.
Структура
Почему ?
Коэффициент
КОИ
Что?
Техническое
задание
(на проект)
WBS
Как?
IbiaHSPMP
Выполнение
Жизненный
цикл
Сделано
Процесс РРА
Рис 8.2. Схема процессов проекта
Учебные цели главы 8
После изучения материала главы читатель должен уметь выполнять следующее:
■ описывать несколько различных архитектур WBS;
■ описывать основные подходы, применяемые при проектировании структур WBS;
■ мотивировать необходимость создания программной структуры WBS;
■ объяснять, каким образом программная структура WBS применяется при
осуществлении программного проекта;
■ определять сущность структуры WBS;
■ перечислять и описывать этапы, требуемые для построения программной
структуры WBS.
Определение структуры пооперационного
перечня работ
Структура WBS представляет собой иерархический перечень рабочих действий,
необходимых для завершения проекта. В этот перечень включаются управленческие,
административные, интегральные и программистские действия, с помощью которых:
■ выполняется разработка ПО;
■ происходит управление проектом;

260 Глава 8
■ обеспечивается поддержка для всех действий, выполняемых в ходе осуществления
проекта;
■ выполняются любые другие действия, требуемые для достижения целей проекта и
удовлетворения требований пользователей, например, создание документов,
разработка учебных программ, инструментальных средств разработки, закупки,
командировки и т.д.
Структура WBS представляет собой описание выполняемой работы, разбитой на
отдельные ключевые компоненты вплоть до самого нижнего уровня. Таким образом,
при разбиении проекта на отдельные управляемые части размер каждого компонента
может быть изменен (глава 10), а также возможна оценка трудозатрат, понесенных на
этапе разработки этого компонента (глава 11). При разработке программных
проектов подавляющая часть трудозатрат по разработке напрямую связана с размером и
сложностью программного продукта. На рис. 10.3 показано, каким образом
реализуются этапы что и как при выполнении программного проекта. На этой схеме
структура VVBS, ориентированная на разрабатываемые продукты, идентифицирует действия на
уровне применимости персоналом, обладающим необходимыми в данном случае
навыками (глава 6). Как только будет определено количество участников команды, а также
составлен перечень требуемых навыков, оценки трудозатрат (глава 10) могут
применяться наравне с составление графика с целью определения длительности выполнения
проекта, а также момента достижения определенных этапов проекта (глава 15).
Результирующий график выполнения проекта обычно отображается в виде диаграмм Ганта
(глава 15). В этот момент времени завершается этап планирования как, после чего могут
начинаться работы по выполнению проекта. В процессе выполнения каждое действие
из структуры WBS может отслеживаться в масштабе всего проекта.
Структура WBS, ориентированная на конечные продукты, отображает этапы
процесса разработки продукта, детализованные на уровне его компонентов. Эта
структура реализует управление планированием на этапах что и как, а также закладывает
основы отслеживания рабочих действий, величины затрат и хода выполнения графика
на этапе выполнение. При этом руководитель работ получает возможность взглянуть на
происходящее с "глобальной точки зрения". Подобная структура отображает
"содержание" работ, выполняемых в ходе осуществления проекта. Учитывая эти
обстоятельства, можно заключить, что данный инструмент является весьма ценным в
работе менеджеров проектов.
Ранее уже упоминалось о том, что тройные ограничения для проектов включают
область действия, график и затраты. Эти ограничения напрямую связаны с размером ПО,
сроком завершения работ и трудозатратами, связанными с распределением ресурсов.
1 (зпачалыю выполняется идентификация цели и области действия (глава 7). Затем
рассматриваются трудозатраты и рабочий график. Как упоминалось ранее, для
выполнения бюджетных и детализированных оценок работы, а также для разработки реального
графика требуется структура WBS, ориентированной на продукты. Потребность в ней
особенно ощущается при выполнении следующих трех действий в рамках проекта.
Оценка затрат
■ обеспечение оценки выполняемых действий;
■ обеспечение соответствия каждого элемента оценки рассматриваемому действию;
■ "пересчет" затрат на производство отдельных элементов в итоговые суммы затрат
на производство подэлементов, а также системы в целом.

Создание структуры пооперационного перечня работ 261
Счета затрат
■ обеспечивают распределение работ и "зарядку" соответствующих центров затрат
на основе специфических элементов структуры WBS;
■ позволяют детализировать фактические затраты.
Выполнение графика
■ обеспечивается отслеживание завершенных действий;
■ возможна оценка хода выполнения проекта.
Как показано на рис. 8.3, структура WBS может быть связана со счетами затрат
проекта, позволяющих выполнять контроль, а также со сметой затрат организации,
созданной с целью управления выполняемыми работами. Благодаря структуре WBS эти
объекты могут отображаться наравне со специфическими элементами, включенными в
рабочий график на завершающих этапах (глава 15). При разработке больших
программных проектов поддерживается базис, на основе которого можно оценить затраты
на создание каждого компонента финальной программной системы. Результаты
оценивания могут быть сохранены с целью их передачи экспертам в будущем (глава 11).
Структура пооперационного перечня работ может быть описана различными
способами. Пример обобщенной структуры WBS, представленной в виде дерева,
приводится на рис. 8.4. Представление в виде дерева является наиболее часто
используемым на этапах почему и что в схеме процесса проекта.
Структура
пооперационного
перечня работ
(сметы расходов)
Структура поопера
иконного
перечня работ
(сметы расходов)
организации
Рис. 8.3. Взаимосвязь между структурой WBS и организацией
контроля затрат
Источник: Struckenbruck, Linn С, ed. The Implementation of Project
Management: the Professional's Handbook. Reading, MA: Addison-Wesley, 1981
Еще одно представление структуры WBS, обычно отображаемое на этапе как,
имеет вид списка, разделенного отступами (рис. 8.5). Отступы определяют уровни
иерархии подобно тому, как это делают уровни в представлении дерева. Подобный тип
представления очень подходит для просмотра иерархической структуры работы в
случае, если процесс ее выполнения связан с множеством действий. Для большинства
пользователей формат структуры (применяемый в данном случае) представляется
вполне естественным. Большие списки с отступами могут легко просматриваться
I

262 Глава 8
с помощью простых электронных таблиц, позволяющих выполнять сортировку
разнообразными методами (код WBS, ответственность, начальная дата и т.д.) При
использовании большинства инструментов графиков управления проектами структура
WBS отображается в виде списка, разделенного отступами, и лишь некоторые из них
позволяют получать представление в виде дерева. Причина этого заключается в том,
что размер графического дерева довольно велик и, когда предполагается выполнение
множества действий, создается впечатление беспорядка. Однако функциональные
возможности, позволяющие получать представление в форме дерева, становятся
доступными при установке специальных подключаемых модулей (ссылки на
соответствующие Web-страницы приведены в конце этой главы).
Программа
С-компилятора
Программирование
С-компилятора
Создание
тестового
набора
Написание
документации
Создание
инсталляционной
программы
Управление
разработкой ПО
Пользовательский
интерфейс
Файловая
система
Синтаксический
анализатор
Генератор
кода
Система
времени
выполнения
Рис. 8.4. Пример структуры пооперационного перечня работ, отображенной в виде дерева
Источник: Courtesy of Dennis J. Frailey, Principal Fellow, Raytheon Company, Piano, TX.
1.0 Программное обеспечение для С-компилятора
1.1 Создание С-компилятора
1.1.1 Построение пользовательского интерфейса
1.1.2 Построение файловой системы
1.1.3 Построение лексического анализатора
1.1.4 Создание генератора кода
1.1.5 Создание системы времени выполнения
1.2 Построение тестовой оболочки для компилятора
1.2.1 Прочее
1.3 Написание документации
1.4 Создание установочного программного обеспечения
1.5 Управление всем вышеперечисленным
1.1 Создание С-компилятора
' 1.1.1 Построение пользовательского интерфейса
1.1.1.1 Анализ требований, выдвигаемых
для пользовательского интерфейса
1.1.1.2 Проектирование пользовательского
< интерфейса
1.1.1.3 Кодирование пользовательского интерфейса
1.1.1.4 Тестирование и интеграция
пользовательского интерфейса
^ 1.1.2 Прочее
Рис. 8.5. Пример структуры пооперационного перечня работ, представленной в виде списка
с отступами
Источник: Courtesy of Dennis J. Frailey, Principal Fellow, Raytheon Company, Piano, TX.

Создание структуры пооперационного перечня работ 263
Обратите внимание на схему нумерации из рис. 8.5, применяемую для пометки
элементов структуры WBS. Эта схема является весьма полезной и позволяет отличать такие
обобщенные действия как разработку проекта, кодирование и тестирование от многих
других программных компонентов. В рассматриваемом примере действие 1.1.1.3
применяется для разработки пользовательского интерфейса, а действие 1.4 применяется
для создания сценария программы установки. Благодаря наличию подобных
особенностей обеспечивается требуемая доля специфичности при пометке действий проекта.
Используемая в данном случае схема нумерации устраняет двусмысленность при
сопоставлении меток действиям проекта. Большая часть программ, применяемых для
составления графиков проектов, могут поддерживать автоматическую расстановку отступов и
структуру WBS либо структурную нумерацию. Также обратите внимание на то, что
подобная работа должна быть выполнена на различных уровнях структуры WBS.
Структура WBS может быть создана для двух наиболее общих представлений продукта.
■ Представление продукта указывает иерархические взаимосвязи среди элементов
продукта (подпрограммы, модули, подсистемы и т.д.). Однако не путайте эту
структуру с материальной ведомостью.
■ Представление проекта указывает на иерархические взаимосвязи среди рабочих
действий (элементы процесса). Часто распределяется среди организационных линий.
Оба набора элементов и действий следует учитывать при вычислении размера и
оценке создаваемого ПО (главы 10 и 11).
Как правило, для каждого различного жизненного цикла существует уникальный
пооперационный перечень работ, который может использоваться в самой организации.
Даже если в большинстве жизненных циклов разработки ПО применяются многие общие
действия, такие как декомпозиция системных требований, выполнение разработки
архитектуры, создание тестовых данных и управление проектом, порядок выполнения этих
действий для каждого жизненного цикла может быть совершенно различным. Некоторые
действия могут пропускаться в определенных ситуациях, например, при разработке
прототипов, либо в случае миниатюрных проектов. Во многих организациях создаются
структуры WBS с целью сравнения предварительно определенных жизненных циклов для
процессов и действий (на базе шаблона, определяемого с помощью стандарта IEEE 1074),
которые являются типовыми для определенных видов проектов. К подобным проектам
относится разработка новых системных Web-приложений, расширения возможностей
существующих систем либо специализированные базы данных. Во многих случаях
применяется классификация в соответствии с размером проекта: большой, средний либо малый.
Эта концепция иллюстрируется на рис. 3.10. Некоторые образцы перечней действий для
семи предопределенных жизненных циклов представлены в главе 9.
Методы создания структуры WBS
Структура WBS может создаваться с применением самых различных методов, но,
как правило, лучше всего ранжировать действия в соответствии с основными
рабочими и поставляемыми продуктами, разработанными в соответствии с требованиями
заказчиков. Здесь необходимо различать рабочие продукты (что-либо материальное,
производимое в ходе выполнения проекта, например, техническое задание,
документы SOW, SPMP, SRS, SRS, SDD, код, наборы тестов и т.д.), и поставляемые продукты
(рабочие продукты, модули исполняемого кода, документация и т.д.). Обратите
внимание на рис. 8.3, где иерархическое информационное "дерево" включает:

264 Глава 8
■ компилятор;
■ основные части компилятора;
■ этапы проектирования основных составляющих частей компилятора.
Первый из перечисленных объектов представляет собой поставляемый продукт,
второй — основные составляющие части рабочего продукта, применяемые
поставляемыми продуктами, третий — действия, которые могут применяться при создании
основных компонентов. Данная прогрессия демонстрирует, каким образом действия
в разветвлениях структуры WBS соотносятся с поставляемыми продуктами.
Организация структуры WBS вокруг поставляемых продуктов и выполняемых при их
производстве действий способствует тому, что необязательная работа, не будет
выполняться в ходе выполнения проекта.
Хотя организация структуры WBS вокруг рабочих и поставляемых продуктов
является неплохим способом, позволяющим избежать планирования дополнительной
работы в рамках проекта, возможен, также другой вариант. Иногда более удобным
является сегментирование работы путем ее организации на высшем уровне, а не на уровне
рабочих и поставляемых продуктов. При этом также оценивается степень контроля
проекта при условии наличия организаций, которые ответственны за разработку
компонентов заключительного рабочего продукта. В результате расширяются
возможности команды, и улучшается контроль над выполняемым программным
проектом. Дополнительные варианты приводятся на рис. 8.6. Они могут применяться в
качестве базисных элементов проекта. Могут также использоваться другие элементы,
например, поставляемые продукты, навыки, виды ответственности либо хронология.
В иллюстрируемых на рис. 8.6 методах предполагается, что имеет место
декомпозиция на системном уровне, а рассмотрению подвергаются элементы ПО. В этом случае
пооперационный перечень работ может включать аппаратное обеспечение, ПО, а
также деловые процессы.
Подхода Подход Б
Система
ПО
Продукты
Компоненты
Этапы процесса
Подход В Подход Г
Система
ПО
Этапы процесса
Продукты
Компоненты
Возможны также многие другие подходы
Рис. 8.6. Некоторые возможные варианты структуры пооперационного перечня работ
Источник: Courtesy of Dennis J. Frailey, Principal Fellow, Raytheon Company, Piano, TX.
Система
ПО
Организации
Продукты
Этапы процесса
Система
ПО
Продукты
Организации
Этапы процесса

Создание структуры пооперационного перечня работ 265
Структура WBS может создаваться в направлении "сверху-вниз" либо в
направлении "снизу-вверх", как показано на рис. 8.7. Подход "сверху-вниз" влечет за собой
последовательную декомпозицию. При использовании подхода "снизу-вверх"
применяется метод "мозгового штурма" и диаграммы связности. Обычно в начале
осуществления проекта на этапах что и как применяется подход "сверху-вниз".
Зачастую при определении структуры WBS используется представление в форме дерева,
поскольку в этом случае количество уровней будет ограниченным. Это
представление является весьма удобным при отображении документов, связанных с
техническим заданием проекта. В этом случае менеджеру проекта значительно проще
идентифицировать большие рабочие компоненты, которые будут выполняться в
дальнейшем, а также определить приближенный порядок разброса оценок выполняемой
работы (Order of magnitude, ROM). Подобные оценки обычно основываются на
широко распространенном "правиле большого пальца", заключающемся, например,
и экстраполяции, использующей сведения о предыдущих программных проектах
либо о размерах (большой, средний, малый) и типе прогнозируемого жизненного
цикла разработки ПО. Дополнительные сведения по детализированной оценке ПО
можно панти в главах 10 и 11.
"Сверху-вниз"
— Задача
— Задача
I
.Задачам
L 'ШтЩг
— Задача
Задача
Задача:
Задача'
■— Задача*}
- /Задача*
- 'Задача;
-/Задача ■■
- "Задача-;
- Задача
- *Зад4чаГ
- Задача
L.-.Задача'
'Задача
Задача
:3адаад"
—
Задача
Задача
Задача
Задача"
Задача*
Задача
"Снизу-вверх"
Рис. 8.7. Построение структуры WBS с применением подходов "сверху&низ" и "снизувверх"
Подход "сверху-вниз" часто применяется в том случае, когда работа была
выполнена преждевременно, а команда разработчиков проекта хорошо осознала этапы
выполняемого проекта. При использовании этого подхода разработка начинается с
самого верхнего элемента (обычно поставляемый программный продукт,
например, "завершенное ПО С-комнилятора"). Затем производится дальнейшая разбивка,
причем па каждом последующем уровне возрастает достигаемый уровень
детализации. Разбиение продолжается до тех пор, пока фрагменты работы не смогут быть
выполнены "одной единицей ресурса" за "относительно короткий период времени".
В качестве "одной единицы ресурса" может выступать один человек, одна секция.

266 Глава 8
один отдел либо другой элемент организационной структуры, который может
выполнять работу. "Относительно короткий период времени" может означать один
день, неделю, две недели, месяц либо другую единицу времени, обладающую
приемлемым уровнем детализации в масштабах области действия проекта, позволяющим
производить измерения во время выполнения проекта. Как правило, в
программных проектах происходит разбиение выполняемой работы до тех пор, пока она не
будет выполняться одним человеком либо группой за период времени, равный
одной либо двум неделям. При этом производится одна единица рабочего продукта.
В результате поддерживается равновесие, предотвращающее эффект "большого
взрыва" при управлении поставляемыми продуктами.
Подход "снизу-вверх" идеально подходит при разработке проектов новых типов,
когда команда разработчиков плохо ознакомлена с этапами, которые им предстоит
реализовать на практике. Применение этого подхода на практике обычно означает
использование методики "мозгового штурма" по отношению ко всему, что должно
выполняться в рамках проекта. Затем происходит группировка действий с
одинаковыми уровнями детализации (при этом выполняется приблизительная оценка объема
выполняемой работы). Также выполняется группирование всех действий до тех пор,
пока не будет достигнут элемент высшего уровня. Этот процесс именуется созданием
диаграмм связности.
При использовании каждого из этих подходов следует избегать чрезмерной
детализации, которая может привести к созданию чрезвычайно громоздких планов. Не
планируйте слишком много деталей. Например, если на разработку определенного
модуля кода отводится две недели, дальнейшее разбиение плана на детализированные
этапы, включающие идентификацию элементов данных, создание диаграмм потока
данных, а также обзор заказчиков являются излишними. В то же самое время
менеджер проекта полагается на инженерное образование разработчиков проекта.
Распространенной ошибкой в этой ситуации является продуцирование чрезмерного
количества деталей на начальных этапах планирования. Как только будет выполнено
описание, достаточное для четкого инструктирования участников разработки, а также
реализована приемлемая оценка общего объема трудозатрат, необходимо
остановиться. Сначала нужно распределить (делегировать) действие, позднее потребуется
завершить планирование.
Воспользуйтесь услугами команд и подгрупп для выполнения работы по частям.
Распределите работу таким образом, чтобы организационные единицы в целом несли
ответственность за выполнение действий на нижнем уровне структуры WBS. Также во
избежание затруднений в организации и управлении, попытайтесь ограничить
глубину дерева либо списка с отступами таким образом, чтобы эти объекты были хоть в
какой-то степени управляемыми. Слишком большое количество подуровней
структуры приводит к путанице. Старайтесь придерживаться принципов максимальной
простоты, оставляя при этом возможность выражения структуры и иерархии работы в
рамках проекта. В главах 10 и 11 будет показано, каким образом можно использовать
известные сведения о желаемом программном продукте с целью добавления
дополнительных уровней разбиения в структуру WBS, ориентированную на продукты, по мере
того, как становится доступной дополнительная информация. Известная под
названием "прогрессивное развитие характеристик", описанная выше методика является
своего рода "краеугольным камнем" для большинства программных проектов.

Создание структуры пооперационного перечня работ 267
Определение стадий проекта
Стадии проекта заслуживают специального упоминания. Стадия представляет
собой значимое событие проекта, обычно связанное с основным рабочим
продуктом либо поставляемым продуктом. Эти события служат своего рода "путевыми
знаками" на пути к завершению проекта. Причем в состав каждого проекта должно
входить достаточное количество стадий, равномерно распределенных в графике,
благодаря чему может легко измеряться прогресс в направлении достижения
конечной цели. Если количество стадий невелико, мы будем иметь дело с так
называемым проектом "большого взрыва", когда никто толком не будет знать срок
завершения проекта, для которого составлен график. Однако слишком большое
количество стадий может привести к чрезмерному замедлению темпов выполнения
проекта. Стадии имеют нулевую длительность, поскольку просто отмечают момент
времени, в который завершается некий важный этап проекта. Стадии могут
определять завершение одного либо большего количества действий. Также они могут
определяться для рабочего или поставляемого продукта или для определенной
группы из указанных выше объектов. С целью индикации времени завершения
лучше всего использовать определенные возможности языка, например, "готово" либо
"завершено". Для примера с С-компилятором на рис. 8.5 стадия для элемента 1.0
может иметь вид "разработка ПО С-компилятора завершена".
Фазы не эквиваленты стадиям, а представляют собой наборы взаимосвязанных
действий по разработке продукта. Стадии могут применяться для отметки времени
завершения фазы, как показано на рис. 8.7.
Проектирование рабочих пакетов
В основном вся работа выполняется на нижнем уровне структуры WBS. Здесь
находятся "листья", формирующие дерево, или действия, которым соответствуют
наибольшие по величине отступы (при использовании списков с отступами). Этот
уровень именуется рабочим пакетом, который, как правило, является результатом
производства рабочего продукта. Все рабочие пакеты проекта отличаются друг от друга.
В пакете обычно описывается вся необходимая информация, необходимая для
выполнения специалистом данного вида работы. На уровне программных проектов
рабочие пакеты обычно соответствуют наименьшим идентифицируемым объектам либо
модулям, которые создаются в рамках поставляемой системы. Рабочий пакет может
содержать следующую информацию:
■ описание ожидаемого рабочего продукта—производимые элементы ПО;
■ требования к персоналу — какого рода специалисты и в каком количестве
требуются для выполнения данного действия;
■ имена ответственных лиц— персональная ответственность за ход выполняемых
работ;
■ указанная в графике дата начала и завершения выполнения какого-либо действия;
■ выделенный бюджет (деньги, часы либо другие единицы измерения) — оценка
трудозатрат при выполнении действия;
■ критерии приемки работы —уровень дефектов либо другой вид оценки
достигаемого уровня качества.

268 Глава 8
Если персонал разработчиков проекта уже знаком с упомянутыми выше
моментами, что является общепринятой практикой в организациях, где группа инженеров-
программистов работают "бок-о-бок" изо дня в день, создание формального рабочего
пакета вовсе не будет обязательным, поскольку каждый уже ознакомлен со всеми
задачами, выполнение которых крайне необходимо для завершения действия. Однако,
если организовывается новая группа сотрудников, которые никогда не работали
вместе ранее, потребуется больший уровень контроля. Усиленный контроль также
требуется в случае отсутствия общепринятой практики создания предварительных схем
программных проектов. В этом случае регистрация информации о рабочих пакетах
является весьма полезной, поскольку в этом случае назначение этих пакетов
становится очевидным. Регистрация подобной информации может происходить также в
том случае, если рабочий пакет проекта определяет область действия работы в
рамках целого подпроекта, который подвергается дальнейшему разбиению на большее
количество действий, управляемых подобно проекту, но с приложением больших
усилий. Подпроект от самостоятельного проекта отличается тем, что не существовать
самостоятельно, вне контекста большего проекта. Поставляемый рабочий продукт
подпроекта может представлять собой автономную часть ПО, используемую в
контексте, лежащем вне области действия текущего проекта. Хорошим примером
программного подпроекта является проект по созданию пользовательских программных
утилит. В большинстве инструментов календарного планирования, обеспечивающих
управление проектами, таких как Microsoft Project, помечать сведения о каждом
выполняемом действии.
Создание структуры WBS при разработке ПО
Структура WBS является ключевым рабочим продуктом, необходимым при
выполнении оценок в рамках программного проекта. Во многих проектах наибольший вред
наносит не плохая оценка чего-либо, а то, что оценка вообще не выполняется. При
подготовке к процессу оценки размеров выполняемой работы (главы 10 и 11)
следуйте указаниям, изложенным в данной главе. Ранее уже упоминалось о том, что при
построении структуры WBS применяются два подхода, "сверху-вниз" и "снизу-вверх".
При планировании любого проекта следуйте простому правилу: если элемент
является слишком сложным для управления, он представляет собой перечень более простых
элементов. Ниже приводятся пять этапов, применяемых при конструировании
структуры WBS для программного проекта.
1. Идентифицируйте работу, связанную с разработкой программного продукта
(отделите ее от работы, связанной с аппаратным обеспечением, и от рабочих
процессов).
2. Найдите структуру WBS для произвольной системы высшего уровня (отделите ПО
от других систем и компонентов).
3. Определите программную архитектуру WBS (идентифицируйте все части и
действия, требуемые при ее разработке).
4. Наполните содержимым программную архитектуру WBS (идентифицируйте все
части и действия, требуемые при ее проектировании).
5. Определите категории затрат, связанных с ПО (подготовка к действиям по
оцениванию).

Создание структуры пооперационного перечня работ 269
Действия, связанные с разработкой ПО
Просмотрите всю доступную документацию (по крайней мере, ту, которая
доступна на момент выполнения данного проекта) и составьте полный перечень всех
элементов, влияющих на понесенные затраты. На этом этапе доступными должны быть
следующие исходные документы.
документ SOW (обычно наилучший документ, требуемые для начала работы);
спецификации, концепция деятельности;
любые документы, определяющие требования;
документы по разработке проекта;
стандарты (внутренние и внешние);
результаты переговоров с заказчиками;
проверочные критерии либо ожидания.
Итоговый перечень должен включать позиции что и где для каждого элемента, как
показано на рис. 8.8. Благодаря этому ничего не будет упущено.
Документ
Процесс SOW
Процесс SOW
Контракт
Документы по
спецификации
требований
Заказчик
Параграф
1.3.4
2.3.3
7.13.2.а
3.4
6/5/99 Mtg.
Описание
Разработка ПО компилятора
Командировки с целью обзора разработки проекта
Следование стандарту ISO 5432f
Использование сжатия данных
Кодирование всего ПО на C++
Рис. 8.8. Перечень элементов, оказывающих влияние на разработку ПО
Источник: Courtesy of Dennis J. Frailey, Principal Fellow, Raytheon Company, Piano, TX.
Поиск структуры WBS для произвольной системы
высшего уровня
Определите, существует ли структура WBS для произвольной системы высшего
уровня (проект либо программа высшего уровня), а также установите, приемлемо ли
это ПО в данном случае. Для этого во многих организациях применяется структура
WBS, имеющая стандартную архитектуру. Многие менеджеры системных проектов
устанавливают структуру WBS, применимую к разбитому на более мелкие части ПО.
На рис. 8.9. показаны два возможных разбиения. При этом важно определение
момента, при наступлении которого ПО будет сопоставимо с действиями высшего
уровня, поскольку это может оказать влияние на то, каким образом структурируются и
выполняются части программного проекта. Например, менеджер системного проекта
может иметь специфический подход к порядку расположения элементов структуры
WBS, к количеству уровней просмотра, к тому, каким образом следует соотносить
определенные виды затрат и т.д.

270 Глава 8
Подход, проиллюстрированный в левой части рис. 8.9, представляет ПО,
используемое в качестве внедренного элемента на базе аппаратного обеспечения в рамках
системного проекта. В правой части рисунка демонстрируется ПО, выступающее в
качестве отдельного, но эквивалентного элемента по отношению к аппаратному
обеспечению. В этом случае наблюдается тенденция к изоляции планирования ПО от
остальной части системы, в результате чего появляются несовместимые
интерпретации требований.
Внедренный
Отдельный, но эквивалентный
Радар
Антенна Генератор
Система
mn^nn
Электрическая! [Механическая! ., „. ,
часть часть Управление
Рис. 8.9. Пример структуры WBS высшего уровня, демонстрирующего место размещения ПО
Источник: Courtesy of Dennis J. Frailey, Principal Fellow, Raytheon Company, Piano, TX.
Определение программной архитектуры WBS
На этом этапе требуется определить логическую структуру (архитектуру) для
программных частей структуры WBS. Как описывалось ранее и показывалось на рис. 8.6,
существует множество различных программных архитектур WBS. В распоряжении
многих организаций оказываются стандартные программные архитектуры WBS,
благодаря чему можно убедиться в совместимости и лучше отслеживать затраты. Для
различных программных продуктов и разных жизненных циклов разработки ПО
требуются разные структуры WBS. На рис. 8.10 представлены возможные программные
архитектуры, применяющие подходы А и В (рис. 8.6).
Использование подхода А
Использование подхода В
Требования

Проектирование
^
Текстовый
процессор

Кодирование
^\
База
данных
^

Пользовательский
интерфейс
Реда
Электронная
таблица
\_.
ктор
Формаггер

Тестирование
Рис. 8.10. Пример архитектур WBSdjuinO, проиллюстрированного на рис. 8.6
Источник: Courtesy of Dennis J. Frailey, Principal Fellow, Raytheon Company, Piano, TX.

Создание структуры пооперационного перечня работ 271
Указание сведений для программной архитектуры WBS
Заполните выбранную структуру WBS действиями, в ходе внедрения которых
выполняется работа, идентифицированная в доступной документации (SOW, или другие
документы, указанные на этапе 1). Созданная на основе данных из рис. 8.8 и 8.10,
матрица перекрестных ссылок на рис. 8.11 отображает стандартные элементы структуры
WBS для ПО (в правой части рисунка). В левой части рисунка находятся
соответствующие исходные документы, номера параграфов, а также описания, связанные с
созданием элементов структуры WBS в правой части рисунка. При этом снижается
вероятность пропуска каких-либо элементов в структуре WBS. Если один параграф
SOW отображается в нескольких элементах структуры WBS (либо наоборот), можно
создать несколько различных записей в матрице перекрестных ссылок. В данном
случае структура WBS может выступать в роли элемента отслеживания требований либо
она может быть дополнена. Иногда стандартная структура WBS является более
детализированной, чем исходные документы. В подобных случаях отслеживание
всегда следует выполнять на наивысшем уровне во избежание появления чрезмерного
количества деталей.
Определение категорий затрат для ПО
Определите категорию оценки затрат для каждого элемента в структуре WBS. Этот
последний этап не является необходимым для каждого проекта, однако он является
важным для тех проектов, где отслеживаются затраты на уровне единиц в структуре
WBS (рис. 8.3). Если этот этап не будет выполнен в данный момент времени, его
придется выполнить позднее, во время осуществления процесса оценки затрат. В
некоторых проектах с целью упрощения применяется лишь одна категория затрат.
Обычно при оценке учитываются только время, затрачиваемое на разработку. В более
сложных проектах требуется большее количество категорий в силу того, что
возникает потребность в различных единицах. Категория оценки затрат определяет, каким
образом будут оцениваться затраты для каждого элемента (рис. 8.12). Например,
капитальное оборудование, обычно оценивается в деньгах, в то время, как
трудозатраты оцениваются в часах, неделях либо месяцах, в течение которых выполняется
работа (эти результаты могут быть легко преобразованы таким образом, что будут
выражаться в денежном эквиваленте). Элементы накладных расходов, например, при
выполнении управления проектами, контроля изменений, а также менеджмента
конфигурации могут оцениваться с помощью пропорциональных добавлений в базовые
оценки трудозатрат на разработку ПО (процентные соотношения).
Пять этапов построения структуры WBS
Некоторые элементы из этапа 1 могут быть пропорционально распределены
среди многих элементов структуры WBS. Примером применения подобной
методики является потребность в использовании конкретного стандарта либо языка
программирования в рамках выполняемого проекта. Отдельные элементы из этапа 1 не
выглядят универсальными, поскольку некоторые элементы их стандартной
структуры WBS на уровне организации не могут быть явно указаны в исходных
документах для данного проекта. Примерами подобных элементов являются обучение,
управление проектом, удовлетворение нужд, а также внедрение инструментов,
используемых при разработке.

272 Глава 8
Информация
об источнике
Требование
Процесс SOW 1.1.1 Разработка С-компилятора
Процесс SPEC 2.0
Процесс SPEC 2.1
PROCSTD3.4
PROCSTD3.5
Разработка компилятора
Пользовательский интерфейс для ПК
Анализ требований
Проектирование
Процесс SPEC 2.2 Файловая система
Процесс SPEC 3.0 Тестирование в среде компании
Процесс SOW 2.3.4 Поддержка руководства пользователя
Элемент программной
структуры WBS
1.0 ПО С-компилятора
1.1 Создание С-компилятора
1.1.1 Создание пользовательского интерфейса
1.1.1.1 Анализ требований для пользовательского
интерфейса
1.1.1.2 Проектирование пользовательского интерфейса
1.1.2 Создание файловой системы
1.2 Создание тестовой оболочки
1.3 Документация
Рис. 8.11. Пример матрицы перекрестных ссылок для ПО из рис. 8.6
Источник: Courtesy of Dennis J. Frailey, Principal Fellow, Raytheon Company, Piano, TX.
Документ Параграф Номер пункта WBS Описание
Процесс 1.3.4
SOW
1.1.2.2
Категория
Разработка ПО компилятора ПО
Процесс 2.3.3
SOW
1.7.1
Командировки с целью Фактические денежные затраты!
обзора разработок проектов
Рис. 8.12. Пример категорий затрат
Источник: Courtesy of Dennis J. Frailey, Principal Fellow, Raytheon Company, Piano, TX.
Описанные функции поддержки проекта обычно отображаются в виде отдельной
ветви дерева структуры WBS. После того как была создана и проверена структура
WBS, наравне с сопровождающими и поддерживающими элементами, такими как
матрица перекрестных ссылок, она может служить в качестве каркаса для всех
действий, которые будут выполняться в программном проекте.
Резюме
В главе была определена структура пооперационного перечня работ (Work
breakdown structure, WBS), а также была продемонстрирована ее важность для
проекта в целом. Было рассмотрено конструирование каркаса для любого
программного проекта на основе структуры WBS, ориентированной на продукты.
Также обсуждались подходы "сверху-вниз" и "снизу-вверх", реализуемые при
построении структуры WBS.
Благодаря изучению структуры WBS вы лучше подготовитесь к восприятию
материала главы 9, где изучается заполнение структуры WBS соответствующими задачами,
а также глав 10 и 11, где изучается оценивание размеров программных продуктов, а
также трудозатрат, необходимых для их создания.

Создание структуры пооперационного перечня работ 273
Контрольные вопросы
1. Где в структуре WBS могут быть представлены стадии? Почему?
2. Каково значение структуры WBS, ориентированной на продукты, для менеджера
программного проекта?
Практическое занятие
Предположим, вы знаете должность менеджера проектов CRM ARRS. Мистер Лу
пожаловал к вам с весьма приятными новостями. Его новый ассистент, доктор Чжоу,
имеющий титул первого РМР, сертифицированного согласно требованиям PMI в
материковой части Китая, отправляется в 90-дневную командировку в Бангалорский центр
разработки (Индия). Его функции будет временно выполнять производственный
менеджер вашей корпорации в Тянцзине. Он хочет разработать детализированный
шаблон управления программным проектом в соответствии с условиями,
сформулированными CRM. Причем этот проект будет использован для автоматизации работы маяка.
Что необходимо сделать для сверки существующего плана проекта с новыми
требованиями? Каким образом можно скорректировать структуру WBS прототипа жизненного
цикла для ее приспособления к полномасштабному проекту разработки ПО.
Литература
Archibald Russell D. Managing High-Technology Programs and Projects, 2-е издание. NY: John Wiley &
Sons, 1992.
Brown Karen A., and Nancy Lea Hyer. "Mind Mapping as a WBS Development Tool." PMI 2001
Seminar and Symposium, Nashville, TN, 2001.
Cleland, David 1. Project Management: Strategic Design and Implementation, 2-е издание. NY: McGraw-
Hill, 1991.
Goldratt, Eliyahu M., and Jeff Cox. The Goal: A Process of Ongoing Improvement, 2-е издание. Aldershot,
Hampshire. England: Gower, 1993.
Kerzner Harold. Project Management: A Systems Approach to Planning, Scheduling and Controlling, 6-е
издание. NY: John Wiley & Sons, 1998.
King David. Project Management Made Simple: A Guide to Successful Management of Computer Systems Projects.
Englewood Cliffs, NJ: Yourdon Press, 1992.
Lavold, Gary D. "Developing Using the Work Breakdown Structure." Project Management Handbook,
2-е издание., David I. Cleland and William R. King, редакция. NY: Van Nostrand Reinhold, 1998.
Lewis James P. Project Planning, Scheduling and Control: A Hands-On Guide to Bringing Projects in on Time and
on Budget, повторное издание. Chicago, IL: Irwin, 1995.
Lewis James P. Mastering Project Management: Applying Advanced Concepts of Systems Thinking, Control and
Evaluation, Resource Allocation. NY: McGraw-Hill, 1998.
Lewis James P. Team-Based Project Management. NY: American Management Association, 1998.
Lewis, James P. The Project Manager's Desk Reference: A Comprehensive Guide to Project Planning, Scheduling,
Evaluation, and Systems. NY: McGraw-Hill, 2000.
Paulk Mark C. The Capability Maturity Model- Guidelines for Improving the Software Process. Reading MA: Ad-
dison-Wcsley. Section 7.2, "Software Project Planning" and Section 7.3, "Software Project Tracking and
Oversight", 1994.
Pressman Roger S. Software Engineering: A Practitioner's Approach, 5-е издание. Boston, MA: McGraw-
Hill. 2001.
Warner Paul. "How to Use the Work Breakdown Structure." Field Guide to Project Management, David I.
Cleland, редакция. New York, NY: John Wiley & Sons, 1998.

274 Глава 8
Дополнительные сведения в Internet
varatek.com/howtowbsO.html. Разработка пооперационного перечня работ. "How to Create A
Project Work Breakdown Structure (WBS). " Varatek Software, Inc.
www. 4pm.com/artxcles/wbs.html. "Work Breakdown Structure: Important Project Design Issue
or Clerical Task?"
www.acg.osd.mil/pm/newpolicy/wbs/wbs.html. MIL-HDBK-881, "Work Breakdown Structures
(WBS) for Defense Material Items."
www. dir. state, tx. us/eod/ga/contents,htm. Штат Техас, Отдел информационных
ресурсов, указания по соблюдению внутреннего качества.
www.jsc.nasa.gov.bu2/PCEHHTML/pceh.htm. Учебник, содержащий описание методики
параметрической оценки затрат.
www.pmi.org/publictn/pmboktoc.htm. Руководство по управлению проектами в области
знаний PMI (PMBOK® Guide).

Идентификация задач
и действий
Как описывалось в главе 8, создание структуры пооперационного перечня работ
(Work breakdown structure, WBS), ориентированной на продукты, влечет за собой
декомпозицию полномасштабного действия (всего проекта) на ряд последовательных и
меньших действий (подход "сверху-вниз"). Этот процесс продолжается до тех пор,
пока не будут подробно описаны все детали предстоящей работы, что, в свою
очередь, позволит реализовать надлежащее управление этой работой. В качестве
альтернативы этой методики можно использовать метод "мозгового штурма" по отношению
ко всему, что должно выполняться в виде детализированных действий. Затем
происходит распределение действий до тех пор, пока не будет получен результат,
достаточный для представления и управления ходом выполнения работы (подход "снизу-
вверх"). В любом случае идентификация корректных действий представляет собой
дело первоочередной важности.
Тройные ограничения проекта (область действия, график, затраты) в большой
степени зависят от определения корректной области действия, поскольку с этим обычно
связаны график и затраты для выполняемого программного проекта. В главе 10
рассматривается, каким образом структура WBS, ориентированная на продукты, может
стать первичным детерминантом компонентов программных проектов, имеющих
отношение к области действия и затратам. Это аналогично тому, как размер продукта
представляет собой первичную доминанту трудозатрат, понесенных при разработке ПО
(либо любого интеллектуального продукта). В главе исследуются методы
идентификации задач и действий, используемых в практике инженеров-программистов для
продуцирования элементов структуры WBS, ориентированной на продукты. Также будет
рассмотрено, каким образом можно расположить элементы с целью достижения
наилучшего эффекта при использовании моделей жизненного цикла, описанных в главе 4.
Привязка к моделям жизненного цикла разработки ПО производится с помощью
наборов контрольных списков. Как только менеджер проекта примет решение
относительно выбора модели жизненного цикла, контрольные списки могут применяться
для идентификации задач и действий.

276 Глава 9
Стадии жизненного цикла
разработки продукта
На какой же из стадий основного жизненного цикла разработки ПО находимся мы
в настоящий момент времени? Как показано на рис. 9.1, мы все еще находимся в
начале жизненного цикла разработки ПО, глубоко "погрузившись в дебри" этапа что
планирования проекта, как показано на рис. 9.2.
Исследование
концепции
• Формули-''
рование

потребности
Исследование
системы
■ Спецификация
интерфейса
системы
Требования
■ Спецификация
требований
к ПО
Разработка
проекта
Идентификация
циклов SLC
1 Описание

разработки ПО
■SLCs
Внедрение
Выбор
модели
• План

тации/верификации ПО
• Модель SLC
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
Выбор модели
жизненного цикла
разработки ПО
Установка
■ Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
■SIX
Распределение
ресурсов
■
Пользовательская
документация
Сопровождение
■ Бюджет
' Документация
по
сопровождению
Вывод из
эксплуатации
• Архивный
отчет
Рис. 9.1. Жизненный цикл разработки программного продукта
Связь главы 9 с 34 компетенциями
Ключевая техника по разработке продукта, необходимая для идентификации
задач и действий, заключается в осведомленности относительно процессов,
происходящих при разработке ПО с применением различных жизненных циклов.
Жизненные циклы должны быть оценены и настроены в соответствии с индивидуальными

Идентификация задач и действий 277
потребностями каждого проекта. В качестве компетенций, необходимых при
идентификации задач и действий, выступает общее представление о действиях по
разработке ПО (программный инжиниринг), а также методика определения
программного продукта.
Навыки по управлению проектами являются органичным продолжением навыков,
необходимых для создания структуры WBS (документирование планов для имеющейся
структуры). Идентификация действий требует определенных навыков по управлению
персоналом, таких как лидерство, взаимодействие и общение, а также способность
презентовать идеи эффективным образом на протяжении всего процесса идентификации.
Методики разработки продукта
1. Процессы оценивания — определение критериев для обзора.
2. Определение продукта — идентификация клиентской среды и требований,
формулируемых по отношению к продукту.
3. Оценка альтернативных процессов — оценка различных подходов.
4. Подгонка процессов — модификация стандартных процессов с целью
соответствия требованиям проекта.
5. Понимание действий по разработке продукта — изучение цикла разработки ПО.
Навыки менеджмента проектов
6. Создание структуры пооперационного перечня работ — разработка структуры
WBS для проекта.
7. Документирование планов — идентификация ключевых компонентов.
8. Составление графика— разработка графика и ключевых стадий выполняемого
проекта.
Навыки менеджмента персонала
9. Взаимодействие и общение — взаимодействие с разработчиками, высшим
руководством и другими командами разработчиков.
10. Лидерство— обучение команд разработчиков проекта с целью получения
оптимальных результатов.
11. Эффективное представление— эффективное использование письменных и
устных навыков для представления проекта.
Почему ?
Коэффициент
КОИ
Что?
Техническое
задание
(на проект)
Идентификатор
задачи
Как?
ПланБРМР
Выполнение
Жизк
цикл
енный
Сделано
Рис 9.2. Схема процессов проекта
Процесс РРА

278 Глава 9
Учебные цели главы 9
После изучения материала главы читатель должен уметь выполнять следующее:
■ определять задачи и действия, описывать различия между ними, а также
объяснять, где они могут использоваться;
■ помечать действия;
■ перечислять несколько источников действий по разработке ПО;
■ демонстрировать способности по отображению действий на каждый из
жизненных циклов, рассмотренных в главе 4;
■ идентифицировать характеристики полезности и значимости действия для
структуры WBS;
■ перечислять, как минимум, три общих типа действий, найденных для каждого
программного проекта;
■ объяснять методы конструирования подогнанной структуры WBS;
■ находить, как минимум, пять областей применения одного и того же действия
среди пяти жизненных циклов, представленных в главе 4;
■ использовать контрольные списки, поддерживаемые с целью идентификации
задач и действий в различных моделях жизненного цикла разработки ПО.
Характеристики задач и действий
Насколько велика сложность идентификации деятельности, выполнение которой
требуется в рамках программного проекта? Эта задача носит общий характер, не так ли?
То, что выглядит как непосредственное назначение, может вызывать затруднения и
приводить к плохим результатам. В этом случае первым делом требуется определить
тины выполняемых задач и действий. Эти вопросы впервые рассматривались в главе 1, где
приводились некоторые из важных определений, относящихся к области управления
программными проектами. В документе РМВОК® приводятся следующие определения.
Действие — элемент работы, выполняемой в ходе осуществления проекта.
Обычно для действия характерна ожидаемая длительность и затраты, а также
прогнозируемые требования к ресурсам. Действия могут подразделяться на задачи.
Задача — обобщенный термин для работы, не включенной в структуру WBS, но
которая потенциально может быть подвергнута дальнейшей декомпозиции с
последующим назначением отдельных ответственных исполнителей. В данном случае
также речь идет о нижнем уровне трудозатрат, понесенных при выполнении проекта.
Это может означать то, что технически структура WBS состоит только из
действий, а эти действия определяют трудозатраты при выполнении задач. Трудозатраты
при выполнении задач связаны с предметной областью, известной профессионалам, а
также с тем, что именно планируется выполнить. Для инженеров-программистов
трудозатраты по выполнению задач могут быть связаны с разработкой проекта,
кодированием, компиляцией, отладкой и документированием, а также с набором
инструментов по разработке ПО. Здесь речь идет о таких вещах, которые опытный
программист-практик вполне способен предвидеть и готов выполнять в дальнейшем.
К характеристикам идентификации действий можно отнести метку, размер и
источник.

Идентификация задач и действий 279
Значимая метка
Многие разработчики рассматривают план SPMP как одну большую задачу,
относящуюся к этапу выполнение. Однако эта метка не является слишком информативной,
поскольку разработка ПО представляет собой нечто большее, чем обычный план
SPMP (причем разница весьма существенна). Итак, мы собираемся описывать работу
более точно и корректно. Наиболее общим требованием, выдвигаемым в этом случае,
является указание идентификатора действия таким образом, чтобы он вполне
определенным образом описывал выполняемую работу. Однако на практике многие
разработчики и менеджеры "скупы" на слова при составлении меток действий,
призванных описывать процессы. Вместо того чтобы присвоить действию метку типа
"создать С-компилятор", они ограничиваются словом "С-компилятор". В этом случае
проявляется некая доля неоднозначности. Возникают вопросы относительно того,
требуется ли разработать весь продукт либо ограничиться лишь какой-то его частью?
Требуется ли включать в состав разрабатываемого продукта тестовую оболочку и
документацию? Что же на самом деле означает термин "завершенный С-компилятор",
если рассматривать основной поставляемый продукт? Не следует использовать
структуру WBS, построенную лишь исключительно с применением имен существительных.
Используйте глаголы, поскольку они обозначают выполняемые рабочие действия.
Конечно, не стоит ударяться в другую крайность, используя слишком много слов в
метке действия, ибо структура WBS станет чересчур громоздкой. Лучше всего
составлять краткие метки, применяя, по возможности, простые предложения, состоящие из
существительных и глаголов. Язык, применяемый в этом случае, именуется
"командным языком" и используется, как правило, в ситуациях, где требуется быстро
и четко высказать определенную мысль.
Оптимальный размер действий
Итак, какой должна быть величина единицы работы? Слово "оптимальный" при
разработке программных проектов означает то, что следует обеспечить соответствие
масштабам и области действия текущего проекта. Вряд ли можно добавить что-либо
еще к этому определению. Как упоминалось в главе 8, действия являются частями
работы, которая может быть приемлемым образом выполнена с помощью "одной
единицы ресурса" за "относительно короткий промежуток времени". "Одна единица
ресурса" может обозначать любой приемлемый организационный сегмент, вплоть до
одного физического лица, а "относительно короткий период времени" может
означать любой период времени, на протяжении которого возможна адекватная оценка
достигаемых целей, а также различных промежуточных объектов силами командой
разработчиков проекта.
Сначала, руководствуясь вашим наилучшим предположением и "здравым
смыслом", сформулируйте общие руководящие принципы, с помощью которых
определяются размеры отдельных частей выполняемой работы. Затем, после уточнения
набора требований к разрабатываемому программному продукту (глава 16), производится
оценивание размера создаваемого ПО (глава 10). Благодаря этому определяется
необходимый объем трудозатрат (глава 11), а также более точно оценивается
количественный показатель происходящих действий.
Помните о том, что одной из характеристик проекта является "прогрессивное
развитие характеристик". Это означает, что не следует ожидать того, чтобы все
детали, упоминаемые в планах проекта, были сформулированы изначально, поскольку

280 Глава 9
они уточняются по мере выполнения работ (процесс уточнения реализуется в виде
краткосрочных планов). При этом, по мере уточнения деталей, крупномасштабные
действия разбиваются на более мелкие. Например, в начале осуществления проекта
действие может иметь название "разработка интерфейсов". По мере появления
дополнительных сведений относительно требований и особенностей конструкции
действие может быть разбито на поддействия "проектирование меню основных
функции" и "проектирование меню утилит". Опять же, разбиение работы следует
производить до тех нор, пока это будет практичным с точки зрения понимания самой
работы и управляемости реализаций проекта.
Источники
Откуда же можно получить перечень действий и задач, используемых при
выполнении программного проекта? Выбор источников зависит от того, существуют ли
проекты, предшествующие данному проекту. Если ни вы, ни ваша организация не
разрабатывали подобные проекты ранее, либо отсутствуют какие-либо другие
наметки, потребуется исследование детализованных рабочих этапов, необходимые для
выполнения проекта. Подход, заключающийся в исследовании действий по разработке
продукта с помощью "мозгового штурма", предпринимаемого участниками команды
разработчиков проекта и участников совместного дела, будет описан позднее. Если
< уществует проект, предшествующий данному проекту, выполните обзор
соответствующих ему действий, в результате чего будут формулироваться некоторые
руководящие указания, применяемые при идентификации действий. Даже в случае
отсутствия предшествующих проектов следует учитывать то, что профессиональные
организации, такие как SEI, ISO и IEEE, поддерживают источники, которые могут
применяться в действиях по разработке ПО. Модели Института SEI обсуждаются во
всех главах книги. Комитет ISO/IEC 12207 перечисляет 12 инженерных действий,
выполняющих реализацию процесса, которые подобны фазам в типичной модели
жизненного цикла разработки ПО:
1. анализ требований к системе;
2. разработка проекта системной архитектуры;
3. анализ требований к ПО;
4. разработка проекта программной архитектуры;
5. детализированная разработка программного проекта;
6. кодирование и тестирование ПО;
7. интеграция ПО;
8. проверка степени пригодности ПО;
9. системная интеграция;
10. тестирование степени пригодности системы;
11. установка ПО;
12. тестирование приемлемости ПО.
Институт IEEE опубликовал определения модели жизненного цикла,
представляющие описания 17 процессов и 65 действий (наиболее важные действия,
предпринимаемые в процессе разработки ПО). Эти действия будут рассмотрены в
следующем разделе.

Идентификация задач и действий 281
Идентификатор действия процесса
Фактически существует два метода, с помощью которых могут быть
идентифицированы задачи и действия, предпринимаемые в ходе выполнения проекта. В
частности, они могут представлять собой часть ранее существовавшей структуры WBS для
жизненного цикла разработки ПО либо определяться в качестве новых при
возникновении уникальной ситуации во время осуществления программного проекта. В
любом случае потребуется выполнять настройку. В дальнейшем будут рассмотрены оба
подхода, а также произведены исследования по поводу выбора и организации задач,
выполняемых в ходе программного проекта. Во-первых, будет рассмотрен порядок
применения источников в качестве руководства по идентификации действий для
данного программного проекта. Затем, в главе 14 будут рассмотрены методы
идентификации действий, выполняемых при отсутствии каких-либо источников.
Адаптация действий, выполняемых в жизненном
цикле разработки ПО, к общим ситуациям
В документе IEEE 1074 описывается набор из 17 процессов и 65 действий,
выполняемых в рамках программного проекта. Благодаря этому работа по созданию
программ может быть организована таким образом, что она будет соответствовать
основному циклу разработки ПО (рис. 4.1). Эти процессы и действия описаны в
табл. 9.1, которая представляет собой другой формат рис. 4.1, с добавлением ряда
действий. 34 компетенции, знакомые любому менеджеру программного проекта,
напрямую связаны с 65 действиями по разработке в ходе выполнения программного
проекта. Эти действия более подробно рассматриваются в остальных главах книги.
Действия по разработке (продукта) могут включать анализ, разработку проекта на
высоком и низком уровнях, кодирование, тестирование, а также другие задачи,
выполняемые на протяжении различных фаз жизненного цикла по разработке ПО.
Действия по управлению могут включать планирование проекта, отслеживание,
контроль, анализ рисков и т.д. Действия по поддержке могут включать документацию по
поставляемым продуктам, такую как руководство пользователя, операционные
справочники, сетевые коммуникации и т.д. Все упомянутые типы действий представляют
собой часть структуры WBS, ориентированной на продукты. Задачи по выполнению
менеджмента, администрирования и поддержки будут называться интегральными
задачами. В их число входит одна или больше задач (иногда все) по разработке
программного продукта. Другие интегральные задачи включают процедуры по менеджменту
конфигурации, технологию по обеспе.чению качества ПО, анализ и управление
рисками, инструменты и технологию разработки ПО, методы проведения обзоров
поставляемых продуктов, разрабатываемых в ходе осуществления процесса,
коллекционируемые и анализируемые метрические показатели, определение и
документирование стандартов (правила разработки поставляемых продуктов). Сюда также могут
быть включены любые другие действия, направленные на то, чтобы удовлетворить
требования заказчиков (разработка документов, учебных программ, проектирование
инструментов и выполнение закупок).
Перед каждым менеджером программного проекта возникает задача по установке
соответствия между действиями в табл. 9.1 и моделью жизненного цикла разработки
ПО с последующим их описанием (на достаточном уровне детализации) для
персонала организации. Каждое из представленных в таблице действий может подвергаться

282 Глава 9
дальнейшей разбивке с целью его применения командой разработчиков проекта.
Например, "план менеджмента конфигурации" может представлять собой все, что
требуется для проекта, выполняемого в организации, в которой реализуется сложный
менеджмент конфигурации (СМ) процессов и систем, а персонал обучен и может
корректно использовать данные процессы и системы. В этом случае единственным
необходимым действием является минимальное описание рабочего пакета, например,
"распределить поддержку СМ со стороны координатора отдела". При этом не требуется
составление отдельного документа по планированию менеджмента конфигурации ПО
(Software configuration management plan, SCMP). Вместо этого может использоваться
лишь один раздел в плане SPMP. Однако при образовании новых организаций это
действие может включать достаточно большой объем рабочих операций, включая
разработку проекта и выбор СМ-системы, приобретение, установку программы и обучение
персонала с целью поддержки набора инструментов по менеджменту конфигурации
ПО. При этом подразумевается разработка отдельного (и возможно очень
детализированного) плана SCMP. Область определения этих двух действий может быть весьма
различной, так же, как весьма различаются понесенные при этом трудозатраты.
Еще одно замечание по поводу действий из табл. 9.1 заключается в том, что все
они следуют за руководящим указанием, упомянутым ранее в связи с соответствующей
меткой действия.
Таблица 9.1. Процессы и действия, выполняемые в рамках жизненного цикла
разработки ПО (документ IEEE 1074)
Фаза разработки
Процессы жизненного Действия
цикла
Планирование
модели жизненного
цикла разработки
ПО
Управление
проектом
1. Установка соответствия
между циклом SLCM и
потребностями проекта
Начало выполнения
проекта
1. Идентификация "кандидатов" на
роль цикла SLCM
2. Выбор модели проекта
3.
Сопоставление действий и цикла
SLCM
4. Распределение ресурсов проекта
5. Установка среды проекта
6. Управление планом проекта
3. Отслеживание и контроль 7. Анализ рисков
проекта 8. Планирование непредвиденных
ситуаций
9. Управление проектом
10. Хранение записей
11. Реализация метода отчетов
по проблеме
4. Управление качеством ПО 12. Планирование управления
качеством ПО
13. Определение метрических
показателей
14. Управление качеством ПО
15. Идентификация потребностей по
улучшению качества

Идентификация задач и действий 283
Продолжение табл. 9.1
Фаза разработки Процессы жизненного Действия
цикла
Действия,
предшествующие
разработке проекта
Разработка
5. Исследование концепции
6. Системное распределение
7. Требования
Действия,
следующие за разработкой
ПО
8. Разработка проекта
9. Внедрение
10. Установка
11. Эксплуатация
и поддержка
16. Идентификация идей или
потребностей
17. Формулирование потенциальных
подходов
18. Проведение исследований по
осуществимости проекта
19. Планирование системных
переходов (при необходимости)
20. Уточнение и завершение идеи либо
потребности
21. Анализ функций
22. Разработка системной архитектуры
23. Декомпозиция системных
требований
24. Определение и разработка
требований к ПО
25. Определение требований к
интерфейсу
26. Назначение приоритетов и
интеграция требований к ПО
27. Разработка проекта архитектуры
28. Проектирование базы данных (при
необходимости)
29. Проектирование интерфейсов
30. Выбор либо разработка алгоритмов
(при необходимости)
31. Выполнение детализированной
разработки проекта
32. Создание тестовых данных
33. Разработка исходного кода
34. Генерирование объектного кода
35. Создание оперативной
документации
36. План интеграции
37. Выполнение интеграции
38. План установки ПО
39. План интеграции
40. Установка ПО
41. Приемка ПО в операционной среде
42. Системные операции
43. Обеспечение технической
поддержки и консультаций
44. Журнал запросов о поддержке

284 Глава 9
Окончание табл. 9-1
Фаза разработки
Процессы жизненного Действия
цикла
Интегральные
задачи
12. Сопровождение
13. Вывод из эксплуатации
14. Аттестация и
верификация
15. Менеджмент
конфигурации ПО
16. Разработка документации
17. Обучение
45. Повторное применение жизненного
цикла разработки ПО
46. Извещение пользователей
47. Осуществление одновременных
операций (при необходимости)
48. Вывод системы из эксплуатации
49. План аттестации и верификации
50. Выполнение задач по аттестации и
верификации
51. Сбор и анализ метрических данных
52. План проведения тестирования
53. Разработка требований по
тестированию
54. Выполнение тестирования
55. Планирование менеджмента
конфигурации
56. Идентификация конфигурации
57. Контроль конфигурации
58. Учет состояния
59. Планирование документации
60. Применение документации
61. Производство и распределение
документации
62. Планирование учебной программы
63. Разработка учебных материалов
64. Проверка учебной программы
65. Реализация учебной программы
Действия жизненного цикла по разработке ПО
Фактическая структура настраиваемого жизненного цикла разработки ПО
рассматривалось в главе 4. Сейчас же будут рассмотрены общие модели жизненного
цикла которые являются результатом различных перестановок действий,
представленных в табл. 9.1. Обратимся к действиям и соответствующим им описаниям для
следующих циклов разработки ПО, подробнее описанных в главе 4:
■ каскадная модель;
■ V-образная модель;
■ структурированная эволюционная модель быстрого прототипирования;
■ модель быстрой разработки приложений (RAD);
■ инкрементальная модель;
■ спиральная модель.

Идентификация задач и действий 285
Каждая из упомянутых моделей жизненного цикла разработки ПО включает
различный набор действий и задач, выполняемых при разработке основных
компонентов ПО. Действия интегральных процессов (менеджмент конфигурации,
верификация, составление документации) являются идентичными для каждой модели.
В табл. 9.2 приводится контрольный список, соответствующий общим задачам и
действиям. Этот список может применяться совместно с другими контрольными
списками жизненного цикла разработки ПО.
Таблица 9.2. Интегральные действия для всех моделей жизненного цикла
Интегральные действия — поддержка действий, происходящих на всем протяжении
жизненного цикла
отслеживание и контроль проекта
управление качеством ПО
аттестация и верификация
менеджмент конфигурации ПО
разработка документации
обучение
анализ рисков
планирование случайных событий
управление проектом
сохранение записей
внедрение метода отчета о проблемах
планирование управления качеством ПО
определение метрических показателей
планирование качества ПО
идентификация потребностей по улучшению
качества
план аттестации и верификации
выполнение задач по аттестации и верификации
сбор и анализ метрических данных
план менеджмента конфигурации
идентификация конфигурации
контроль конфигурации
учет состояния
документирование плана
внедрение документации
создание и распределение документации
планирование учебной программы
разработка учебных материалов
аттестация учебной программы
внедрение учебной программы
Вполне очевидно, что многие из упомянутых жизненных циклов разработки ПО
обязаны своим происхождением таким источникам, как IEEE 1074, и относятся к
разработке продукта и операциям текущей поддержки, включенных в разработку
проекта. Не забывайте о том, что действия по фактической разработке проекта завершаются

286 Глава 9
после окончания создания программных продуктов и начала текущей эксплуатации
и действий по сопровождению. Операции и действия по сопровождению (иногда
называемые "поддерживающими") обычно занимают больше времени в жизненном
цикле разработки типичного ПО и могут не учитываться при ссылке на программный
проект. Это согласуется с относительными размерами областей кривой затрат,
приведенными на рис. 9.3.
В большинстве организаций действия по сопровождению ПО представляют собой
нечто большее, чем кажется на первый взгляд. Существует, как минимум, три типа
действий по поддержке.
■ Коррекция (примерно 20%) — устранение дефектов для поставляемых продуктов
(ПО, руководства, обучение и т.д.).
■ Адаптация (примерно 20%) — компенсация воздействия со стороны
изменяющихся сред (изменения платформы, изменения правил и методов регулирования
(например, изменение налоговых ставок), а также учет официальных учетных
данных, связанных с изменениями в законах).
■ Совершенствование (примерно 60 %) — добавление новых возможностей либо
изменение свойств в соответствии с запросами пользователей.
Рабочие операции Работа в рамках проекта
Требования
Рис. 9.3. Типичное распределение денежных средств жизненного цикла
разработки ПО
Перечисленные типы действий по поддержке формирует две трети общего
объема затрат на разработку программного продукта, понесенных во время цикла его
разработки. Поскольку совершенствование начальных версий программных продуктов в
большинстве случаев маловероятно, некоторые корректирующие действия по
поддержке могут ожидаться на любой операционной фазе полного жизненного цикла
разработки ПО. Эти действия должны быть сопоставлены с бюджетом, выделенным

Идентификация задач и действий 287
на поддержку операций ведущей организацией. Действия по адаптации и
совершенствованию, возможно, могут трактоваться как отдельный проект по разработке ПО,
применяемый при подготовке основной версии программного продукта. Они
представляют собой типы действий по сопровождению, которые являются результатом
изменения среды и усилением роли проблемы знаний, связанной с оригинальным
проектом разработки ПО. Некоторые из рассматриваемых в дальнейшем моделей
жизненного цикла включают данные операции и действия по сопровождению
наравне с их описаниями, а некоторые не включают.
Другим важным моментом, о котором стоит упомянуть, является распределение
действий для структуры WBS. При его реализации даже в том случае, когда некоторые
модели выделены в качестве циклических, происходит их "выпрямление" с целью
представления в структуре WBS для проекта. Подобная циклическая итеративная
природа, при реализации которой используются конструкции в виде циклов,
объясняется тем, что некоторые действия должны повторяться. Например, спиральная
модель может рассматриваться в качестве прямой линии, если ее завитки будут
распрямлены, а сама она "разворачивается" на плоскости. Специалист по планированию
проектов должен обладать достаточным уровнем полномочий и опыта, чтобы
принять решение относительно планирования и включения в состав спирали того или
иного количества циклов.
Действия, выполняемые в каскадной модели
разработки ПО
Как указывалось в главе 4 и описывалось на рис. 4.9, каскадная модель
обеспечивает линейное распределение большинства действий, указанных в табл. 9.1.
Распределение производится по отдельным фазам с помощью процессов и действий,
показанных в табл. 9.3.
Таблица 9.3. Контрольный список потенциальных действий и задач,
характерных для каскадной модели
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
Исследование концепции — проверка требований на системном уровне с целью
определения их выполнимости
■ идентификация идей либо потребностей
■ формулирование потенциальных подходов
■ выполнение исследований выполнимости
■ планирование системного перехода (в случае необходимости)
■ уточнение и завершение идеи либо потребности
Процесс системного распределения—установка соответствия между функциями и
программным либо аппаратным обеспечением на основе общей системной архитектуры
■ анализ функций
■ разработка системной архитектуры
■ декомпозиция системных требований

288 Глава 9
Потенциальные действия
Продолжение табл. 9.3
Фаза жизненного цикла
Потенциальные задачи
Процесс определения требований — определение требований к ПО для получения
информации относительно области действия и функций системы, поведения, производительности и
применяемых интерфейсов
■ определение и разработка требований со стороны ПО
■ определение требований по разработке интерфейса
■ расстановка приоритетов и интеграция требований к ПО
Процесс разработки проекта — разработка и представление логически связной,
технической спецификации программной системы, включая структуры данных, программную
архитектуру, представления интерфейса, а также процедурные (алгоритмические) детали
■ разработка проекта архитектуры
■ проектирование базы данных (в случае необходимости)
■ проектирование интерфейсов
■ выбор либо разработка алгоритмов (в случае необходимости)
■ выполнение детализованной разработки проекта
Процесс внедрения —трансформация описания разработки программного проекта в
программный продукт, а также создание исходного кода, баз данных и документации независимо
от того, были ли эти программные продукты разработаны, приобретены либо имеют
смешанное происхождение
■ создание тестовых данных
■ создание исходного кода
■ генерирование объектного кода
■ создание оперативной документации
■ план интеграция
■ выполнение интеграции
Процесс установки — установка и проверка ПО в операционной среде, а также получение
формального одобрения ПО со стороны заказчиков
И план установки
■ распределение ПО
■ установка ПО
■ приемка ПО в операционной среде
Процесс эксплуатации и поддержки — включает пользовательские операции в системе и
действующую поддержку, в том числе техническую помощь, оказание консультаций
пользователям, фиксация их запросов с целью выполнения расширений и изменений, а также
обработка исправлений либо ошибок
■ выполнение операций в системе
■ обеспечение технической поддержки и проведение консультаций
■ поддержка журнала регистрации запросов пользователей

Идентификация задач и действий 289
Окончание табл. 9.3
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
Процесс сопровождения—анализ запросов с целью обнаружения программных ошибок,
сбоев, ошибок, расширений, а также изменений, генерируемых при осуществлении процесса
поддержки
■ повторное применение цикла разработки ПО (начало процесса разработки)
Процесс вывода из эксплуатации — прекращение активного применения используемой
системы путем завершения выполняемых ей операций, замена на новую систему либо
обновление с применением новой версии существующей системы
■ извещение пользователей
■ выполнение параллельных операций (в случае необходимости)
■ вывод системы из эксплуатации
Интегральные действия — см. табл. 9.2.
Действия, выполняемые в V-образной модели
разработки ПО
V-образная модель, описанная в главе 4 и показанная на рис. 4.10, определяет
линейное распределение большинства действий в табл. 9.1, как и в случае с каскадной
моделью. Контрольный список задач и действий V-образной модели показан в табл. 9.4.
Таблица 9.4. Контрольный список действий и задач для V-образной модели
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
Планирование проекта и требований — определение системных требований и методов
распределения ресурсов организации с целью удовлетворения требований
■ начало выполнения проекта ■ установка соответствия между действиями и
планом SLCM
■ распределение ресурсов проекта
■ настройка среды проекта
■ планирование управления проектом
■ исследование концепции ■ идентификация идей или потребностей
■ формулирование потенциальных подходов
■ исследование выполнимости
■ планирование системных переходов (при
необходимости)
■ уточнение и завершение идей либо потребностей
■ управление качеством ПО ■ планирование управления качеством ПО
■ определение метрических показателей

290 Глава 9
Продолжение табл. 9.4
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
Требования к продукту и анализ спецификаций—анализ и спецификация ожидаемого
внешнего поведения разрабатываемой программной системы
■ анализ системного распределения ■ анализ функций
■ разработка системной архитектуры
■ декомпозиция системных требований
■ идентификация требований к ПО ■ определение и разработка требований к ПО
■ определение требований к интерфейсу
■ установка приоритетов и интеграция требований
к ПО
Архитектура и разработка проекта иа высоком уровне — определение порядка применения
программных функций для разработки проекта
■ разработка проекта на высоком уровне
■ выполнение разработки проекта архитектурного
■ проектирование базы данных (при необходимости)
■ проектирование интерфейсов
Детализированная разработка проекта—определение и документирование алгоритмов для
каждого компонента, который был определен на фазе разработки архитектурного проекта
■ выбор и разработка алгоритмов (при необходимости)
■ выполнение детализированной разработки проекта
Кодирование—трансформация алгоритмов, определенных на фазе детализированной
разработки проекта, в готовое ПО
■ создание исходного кода
■ генерирование объектного кода
■ создание оперативной документации
Тестирование модуля — проверка каждого созданного модуля на предмет наличия ошибок
■ план тестирования
■ разработка тестовых требований
■ создание тестовых данных
■ выполнение тестов
Интеграция и тестирование—проверка предварительно протестированных модулей, в
результате которой нужно убедиться в том, что они будут вести себя так же, как и в случае
независимого тестирования
■ план интеграции
■ выполнение интеграции
■ план тестирования

Идентификация задач и действий 291
Потенциальные действия
Фаза жизненного цикла
Потенциальные задачи
Окончание табл. 9.4
■ разработка тестовых требований
■ создание тестовых данных
■ выполнение тестов
Системное тестирование—проверка на предмет того, будет ли программная система в
целом (полностью интегрированная), которая встроена в действительную аппаратную среду,
вести себя в соответствии со спецификацией программных требований
■ план тестирование плана
■ разработка тестовых требований
■ создание тестовых данных
■ выполнение тестов
Тестирование приемлемости—обеспечение возможности тестирования функциональных
свойств системы пользователями в соответствии с исходными требованиями. После
завершения тестирования ПО и соответствующее аппаратное обеспечение становятся
работоспособными. Затем следует этап сопровождения системы
■ план установки ПО
■ распределение ПО
■ установка ПО
■ план тестирования
■ разработка тестовых требований
■ создание тестовых данных
■ выполнение тестов
■ приемка ПО в операционной среде
Производство, эксплуатация и сопровождение—начало производства ПО, а также под- ■
держка возможности исправления и корректировок
■ выполнение операций в системе
■ техническая помощь и выполнение консультаций
■ поддержка журнала запросов о технической помощи
Интегральные действия—см. табл. 9.2
Действия, выполняемые в структурированной модели
эволюционного быстрого прототипирования
Структурированная модель эволюционного быстрого прототипирования,
описанная в главе 4 и отображенная на рис. 4.11, представляет собой результат циклической
перестановки большинства действий, описанных в табл. 9.1. При этом следует
учитывать, что эта модель применяется согласно линейному закону несколько раз, причем
каждый раз создаются все более устойчивые поставляемые продукты. В табл. 9.5

292 Глава 9
приводится одна из версий задач и действий, выполняемых в рамках
структурированной модели быстрого прототипирования.
Таблица 9.5. Контрольный список потенциальных действий и задач,
выполняемые в рамках модели быстрого прототипирования
Фаза жизненного цикла
Потенциальные действия
Потенциальные задачи
Совместное планирование проекта — пользователь и разработчик проекта совместно
разрабатывают предварительный план проекта, в котором "набрасываются" схематичные
графики и поставляемые продукты
начало выполнения проекта
установка соответствия между действиями и планом
SLCM
исследование концепции
■ распределение ресурсов проекта
■ установка среды проекта
■ планирование управления проектом
■ идентификация идей либо потребностей
■ формулирование потенциальных подходов
■ исследование выполнимости
■ планирование системных переходов
■ уточнение и завершение идей либо потребностей
Разработка "бумажного" прототипа — совместная работа пользователя и разработчика
проекта с целью разработки требований и спецификаций для критических частей воображаемого
ПО, умышленно создавая при этом незавершенную "бумажную" модель высокого уровня
Быстрый анализ — пользователь и разработчик проекта выполняют совместную разработку
на основе предварительно сформулированных требований
анализ структуры системы
идентификация
предварительных программных требований
анализ функций
разработка предварительной системной архитектуры
декомпозиция предварительных системных
требований
проведение предварительного собеседования с
пользователями
■ определение и разработка предварительных
требований к ПО
■ разработка предварительных требований к
создаваемому интерфейсу
■ расстановка приоритетов и интеграция требований
к ПО
Создание базы данных — совместная идентификация предварительных элементов базы
данных
■ выполнение предварительной разработки проекта архитектуры
■ проектирование предварительной базы данных

Идентификация задач и действий 293
Продолжение табл. 9.5
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
Проектирование пользовательского интерфейса—совместное определение порядка
взаимодействия ПО с пользователем
■ проектирование предварительных интерфейсов
Разработка алгоритмических функций
■ выбор либо разработка алгоритмов (только на бумаге)
Частичная спецификация требований—используется при создании начального прототипа
Создание программного прототипа системы—применение спецификации быстрого
анализа требований
Внедрение системы—разработка ПО на основе спецификаций и результатов измерений.
■ создание тестовых данных
■ создание исходного кода
■ генерирование объектного кода
■ план установки
■ установка ПО
Оценка системы—совместный обзор программного прототипа
Повторное производство программного прототипа—включение изменений, изученных на
этапе оценивания (при необходимости). Этап может повторяться несколько раз. Используйте
авторитетные суждения для планирования циклов обучения
Обновление спецификации требований—применяется для создания исправленного прототипа
Повторение быстрого анализа—пользователь и разработчик проекта выполняют
совместную повторную разработку на основе исправленных требований
■ анализ структуры системы
■ идентификация исправ- ■ проведение предварительного собеседования с пользова-
ленных требований к ПО телями
■ уточнение и дальнейшая разработка требований к ПО
■ определение исправленных требований к интерфейсу
■ расстановка приоритетов и интеграция требований к ПО
Коррекция базы данных—совместная идентификация скорректированных элементов базы
данных
■ разработка скорректированного проекта архитектуры
■ коррекция разработки проекта базы данных
Коррекция пользовательского интерфейса—совместное повторное определение порядка
взаимодействия интерфейса с пользователем
■ разработка предварительных интерфейсов
Коррекция алгоритмических функций
■ выбор либо разработка алгоритмов

294 Глава 9
Потенциальные действия
Фаза жизненного цикла
Потенциальные задачи
Продолжение табл. 9.5
Приемка функциональных свойств прототипа ПО — формальное одобрение со стороны
пользователя функциональных свойств прототипа
Наследование детализованной разработки проекта на втапе производства ПО
—наследование детализированной разработки проекта на основе принятого быстрого прототипа
■ уточнение алгоритмов
■ выполнение детализированной разработки проекта
■ создание документа, определяющего разработку проекта производственной системы
Внедрение производственной системы—трансформация описания разработки проекта
производственной системы в программный продукт. При этом создается исходный код, базы
данных и документация независимо от того, приобретается, производится/частично
производится продукт
Кодирование — преобразование детализованной разработки проекта в производственную
систему
■ создание исходного кода
■ генерирование объектного кода
■ создание оперативной документации
Интеграция—объединение программных компонентов
■ план интеграции
■ выполнение интеграции
Тестирование — проверка внедрения разработки производственного проекта
■ план тестирования
■ разработка тестовых требований
■ создание тестовых данных
■ выполнение тестов
Установка производственной системы —установка и проверка ПО в операционной среде,
выполнение необходимой настройки с целью формальной приемки ПО со стороны заказчика
■ план установки
■ распределение ПО
■ установка ПО
■ приемка ПО в производственной операционной среде
Процесс эксплуатации и поддержка—выполняются пользовательские операции в системе
и текущая поддержка, включая обеспечение технической поддержки, консультации с
пользователями, фиксация пользовательских запросов на расширения и изменения, а также
обработку исправлений либо ошибок
■ выполнение операций в системе
■ обеспечение технической помощи и выполнение консультаций
■ поддержка журнала запросов о помощи

Идентификация задач и действий 295
Потенциальные действия
Фаза жизненного цикла
Потенциальные задачи
Окончание табл. 9.5
Процесс сопровождения—анализ запросов с целью нахождения программных ошибок,
сбоев, недостатков, расширений, а также изменений, генерируемых в ходе осуществления
процесса сопровождения.
■ повторное применение цикла разработки ПО (начало нового проекта разработки ПО)
Процесс вывода из эксплуатации—прекращение активного использования существующей
системы либо путем завершения системных операций с помощью внедрения совершенно
новой системы, либо путем использования обновленной версии существующей системы.
■ извещение пользователя (пользователей)
■ выполнение параллельных операций
■ вывод системы из эксплуатации
Эксплуатация и сопровождение — перевод ПО в производственное состояние.
■ распространение ПО
■ установка ПО
■ приемка ПО в операционной среде
■ операции в системе
■ обеспечение технической помощи и консультации
■ поддержка журнала запросов о помощи
Интегральные действия — см. табл. 9.2.
Действия, выполняемые в модели быстрой разработки
приложений (RAD)
Модель RAD, описанная в главе 4 и приведенная на рис. 4.12, представляет собой
специальный случай линейной модели. Главной отличительной чертой этой модели
является то, что для нее присущ чрезвычайно короткий цикл разработки ПО, при
осуществлении которого используется конструкция, основанная на компонентах.
Основная область применения этой модели — разработка приложений
информационных систем, особенно в случае архитектуры клиент/сервер.
Действия, приведенные в табл. 9.1, по-прежнему могут применяться для
заполнения структуры WBS для модели RAD. Типичные задачи и действия модели RAD
указаны в табл. 9.6.
Действия, выполняемые в инкрементной модели
Инкрементная модель, описанная в главе 4 и представленная на рис. 4.13, представляет
собой еще одну линейную модель, в которой используются действия, описанные в
табл. 9.1. Фактически в качестве подобной модели может использоваться более ли менее
стандартный цикл разработки ПО, в процессе реализации которого используется одна из
прочих моделей (каскадная, V-образная. RAD, спиральная и т.д.) Однако в инкрементных
моделях завершенная система разрабатывается на ранних стадиях проекта, а затем

296 Глава 9
реализуется в виде версий дискретных компонентов, набор функциональных свойств
которых постоянно расширяется. Зачастую происходит перекрытие действий по
разработке каждого дискретного компонента. Количество создаваемых компонентов определяется
на ранних стадиях проекта. Задачи и действия в примере инкрементной модели
определяют создание трех компонентов для завершенной системы, как показано в табл. 9.7.
Таблица 9.6. Контрольный список потенциальных действий и задач,
выполняемые в рамках модели RAD
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
Планирование и активизация проекта
■ начало выполнения проекта ■ установка соответствия между действиями и
планом SLCM
■ распределение ресурсов проекта
■ установка среды проекта
■ планирование управления проектом
Фаза планирования требований
Исследование концепции—исследование требований на системном уровне с целью
определения выполнимости с применением подхода совместного планирования требований (Joint
requirements planning, JRP)
■ идентификация идей или потребностей
■ формулирование потенциальных подходов
■ проведение изучения выполнимости
■ планирование системного перехода
■ уточнение/завершение идеи и потребности
Процесс определения структуры системы—установка соответствия между функциями и
программным/аппаратным обеспечением на основе общей системной архитектуры и с
применением подхода совместного планирования требований (JRP)
■ анализ функций
■ разработка архитектуры системы
■ декомпозиция системных требований
Процесс определения требований — определение требований к ПО для информационной
области и функций системы, применяя подход совместного планирования требований (JRP)
■ определение и разработка требований к ПО
■ определение требований к интерфейсу
■ расстановка приоритетов и интеграция требований к ПО
Фаза описания пользователя
Процесс разработки проекта — разработка и представление логически
непротиворечивой технической спецификации программной системы, включая структуры данных,
программную архитектуру, представления интерфейса, а также процедурные
(алгоритмические) детали; в данном случае используется подход, применяемый при совместной
разработке приложений (Joint application design, JAD)

Идентификация задач и действий 297
Потенциальные действия
Фаза жизненного цикла
Потенциальные задачи
Окончание табл. 9.6
■ разработка проекта архитектуры
■ проектирование базы данных
■ проектирование интерфейсов
■ выбор либо разработка алгоритмов
■ фаза конструирования
Разработка проекта — разработка и представление логически непротиворечивой
технической спецификации программной системы, включая структуры данных, программную
архитектуру, представления интерфейса, а также процедурные (алгоритмические) детали,
созданные за ограниченный период времени
■ разработка проекта архитектуры
■ проектирование базы данных
■ проектирование интерфейсов
■ выбор либо разработка алгоритмов
■ выполнение детализированного дизайна
Процесс внедрения — преобразование описания разработки проекта ПО в программный
продукт, продуцирование исходного кода, баз данных и документации независимого от того,
были ли они произведены, закуплены либо частично произведены, а частично закуплены
■ генерирование тестовых данных
■ создание исходного кода
■ генерирование объектного кода
■ создание оперативной документации
■ планирование интеграции
■ выполнение интеграции
■ планирование тестирования
■ разработка тестовых требований
■ выполнение тестов
Фаза "расчистки"
Процесс установки —установка и проверка ПО в операционной среде, а также выполнение
формальной приемки со стороны заказчика
■ план установки
■ распространение ПО
■ инсталляция ПО
■ установка ПО в операционной среде
Интегральные действия — см. табл. 9.2.

298 Глава 9
Таблица 9.7. Контрольный список потенциальных действий и
выполняемых в рамках инкрементной модели
Потенциальные действия
Фаза жизненного цикла
Потенциальные задачи
задач,
Планирование и активизация проекта
■ начало выполнения проекта ■ установка соответствия между действиями и
планом SLCM
■ распределение ресурсов проекта
■ установка среды проекта
■ планирование управления проектом
Выполнимость системы
Исследование концепции — исследование требований на системном уровне с целью
определения ее выполнимости
■ идентификация идей либо потребностей
■ формулирование потенциальных подходов
■ изучение выполнимости
■ планирование системного перехода
■ уточнение и завершение идеи и потребности
Процесс определения структуры системы—установка соответствия между функциями и
программным/аппаратным обеспечением на основе общей системной архитектуры
■ анализ функций
■ разработка архитектуры системы
■ декомпозиция системных требований
Планы и требования, имеющие отношение к ПО
Процесс определения требований — определение требований к ПО для информационной
области, функций, поведения, производительности, а также интерфейсов системы
■ определение и разработка требований к ПО
■ определение требований к интерфейсу
■ расстановка приоритетов и интеграция требований к ПО
Процесс разработки проекта — разработка и представление логически
непротиворечивой технической спецификации программной системы, включая структуры данных,
программную архитектуру, представления интерфейса, а также некоторые процедурные
(алгоритмические) детали
■ проектирование базы данных
■ проектирование интерфейсов
■ выбор либо разработка алгоритмов
Разработка проекта продукта: 1-й этап
Процесс разработки проекта—разработка и представление логически непротиворечивой
технической спецификации программной системы, включая структуры данных, программную
архитектуру, представления интерфейса, а также процедурные (алгоритмические) детали

Идентификация задач и действий 299
Продолжение табл. 9.7
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
■ выбор либо разработка алгоритмов
■ выполнение детализованной разработки проекта
Процесс кодирования — преобразование описания разработки программного проекта в
программный продукт, продуцирование исходного кода и баз данных
■ генерирование тестовых данных
■ создание исходного кода
■ генерирование объектного кода
Процесс интеграции — комбинирование элементов с последующим созданием рабочего
компонента системы
■ план интеграции
■ выполнение интеграции
Процесс эксплуатации и поддержки — включает пользовательские операции в системе и
текущую поддержку, в том числе техническую помощь, консультации с пользователями,
регистрацию пользовательских запросов о расширении и изменениях, а также обработку
исправлений либо ошибок
Операционный процесс — использование системы в производстве
■ выполнение эксплуатации системы
■ предоставление технической помощи и проведение консультаций
■ поддержка журнала запросов о технической помощи
Процесс сопровождения — анализ запросов с целью выявления программных ошибок,
сбоев, недостатков, расширений и изменений, генерируемых в процессе сопровождения
■ повторное применение цикла разработки ПО (начало выполнения проекта)
Разработка проекта продукта: 2-й этап
Процесс разработки проекта—разработка и представление логически непротиворечивой
технической спецификации программной системы, включая структуры данных, программную
архитектуру, представления интерфейса, а также процедурные (алгоритмические) детали
■ выбор либо разработка алгоритмов
■ выполнение детализированной разработки проекта
Процесс кодирования—преобразование описания процесса разработки проекта ПО в
программный продукт, продуцирование исходного кода и баз данных
■ генерирование тестовых данных
■ создание исходного кода
■ генерирование объектного кода
Процесс интеграции — комбинирование элементов в составе рабочего компонента системы
■ план интеграции
■ выполнение интеграции

300 Глава 9
Потенциальные действия
Фаза жизненного цикла
Потенциальные задачи
Продолжение табл. 9.7
Процесс внедрения — преобразование программных компонентов в начальные версии
установленных программных продуктов, снабженных документацией. Производится
установка и проверка ПО в операционной среде, а также выполняется формальная приемка ПО
на 2-ом этапе
■ создание оперативной документации
■ планирование установки
■ распространение ПО
■ установка ПО
■ приемка ПО в операционной среде
Процесс эксплуатации сопровождения — вовлекает пользовательские операции в системе и
текущую поддержку, включая обеспечение технической помощи, консультации с
пользователями, фиксацию пользовательских запросов относительно расширений и изменений, а также
обработку исправлений либо ошибок
Процесс эксплуатации — использование системы в производственных целях
■ выполнение операций в системе
■ оказание технической помощи и консультаций
■ ведение журнала запросов о технической поддержке
Процесс сопровождения — анализ запросов с целью обнаружения программных ошибок,
сбоев, дефектов, расширений и изменений, сгенерированных в процессе поддержки
■ Повторное применение цикла разработки (инициализация цикла разработки)
Разработка проекта продукта: 3-й этап
Процесс разработки проекта — разработка и представление логически непротиворечивой
технической спецификации программной системы, включая структуры данных, программную
архитектуру, представления интерфейса, а также процедурные (алгоритмические) детали
■ выбор или разработка алгоритмов
■ выполнение детализированной разработки проекта
Процесс кодирования — преобразование описания программного дизайна в программный
продукт, продуцируя при этом исходный код и базы данных
■ создание тестовых данных
■ создание исходного кода
■ генерирование исходного кода
Процесс интеграции — комбинирование элементов в виде рабочего системного компонента
системы
■ план интеграции
■ выполнение интеграции

Идентификация задач и действий 301
Потенциальные действия
Фаза жизненного цикла
Потенциальные задачи
Окончание табл. 9.7
Процесс внедрения—преобразование программных компонентов в начальную версию
установленного программного продукта, сопровождаемого документацией. Установка и
проверка ПО в операционной среде, а также выполнение формальной приемки ПО заказчиком
на 3-м этапе
■ создание оперативной документации
■ план установки
■ распространение ПО
■ установка ПО
■ приемка ПО в операционной среде
Процесс эксплуатации и поддержки — вовлечение пользовательских операций в системе и
текущая поддержка, включая оказание технической помощи, проведение консультаций с
пользователями, фиксация запросов пользователей относительно расширений и изменений, а
также обработка исправлений либо ошибок
Процесс эксплуатации — использование системы в производстве
■ выполнение операций в системе
■ оказание технической помощи и консультаций
■ ведение журнала запросов о поддержке
Процесс сопровождения — анализ запросов с целью выявления ошибок, сбоев, дефектов,
расширений, а также изменений, сгенерированных в ходе процесса поддержки
■ повторное применение цикла разработки ПО (начало разработки проекта)
Процесс вывода из эксплуатации — прекращение активного использования существующей
системы либо путем отказа от выполнения соответствующих операций, заменяя систему на
совершенно новую, либо путем применения обновленной версии существующей системы
■ извещение пользователя (пользователей)
■ проведение параллельных операций
■ вывод системы из эксплуатации
Интегральные действия — см. табл. 9.2.
Действия, выполняемые в спиральной модели
разработки ПО
Как указывалось в главе 4, существует множество вариаций спиральной модели
жизненного цикла разработки ПО. Все они подобны модели быстрого прототипирования,
описанной ранее в главе. В качестве примера рассматривается спиральная модель,
описанная и показанная на рис. 4.14. Все спиральные модели представляют собой
циклическую перестановку большинства действий из табл. 9.1, но выполняемые по линейному
закону несколько раз, причем каждый раз производятся все более устойчивые
поставляемые продукты. В табл. 9.8 показана одна из версий задач и действий спиральной модели.

302 Глава 9
Показанный здесь перечень действий представляет собой схему жизненного цикла
для рассматриваемых общих моделей жизненного цикла. Каждая из моделей может
быть модифицирована с целью удовлетворения условий, характерных для
индивидуального проекта. Другие распределения либо перефразировки действий не только не
невозможны, но и вполне вероятны.
Если схема не была заранее составлена (что может быть справедливым лишь для
отдельных частей одного из рассматриваемых жизненных циклов разработки ПО),
для "изобретения" действий потребуется воспользоваться методом "мозгового
штурма". Соответствующая методика рассматривается в главе 14.
Таблица 9.8. Контрольный список потенциальных действий и задач,
выполняемые в рамках спиральной модели
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
Первый проход: цикл определения проекта
Определение целей, альтернатив и ограничений—определение требований и спецификаций для
критических частей воображаемой системы с точки зрения производительности,
функциональных свойств, способности к аккомодации изменений, программного/аппаратного
интерфейса, критических факторов успеха и т.д
Определение проекта — разработка предварительной цели и плана проекта, с помощью
которых приближенно описываются графики и поставляемые продукты
■ начало выполнения проекта ■ установка соответствия между действиями и
планом SLCM
■ распределение ресурсов проекта
■ установка среды проекта
■ управление планом проекта
■ исследование концепции ■ идентификация идей либо потребностей
■ формулирование потенциальных подходов
■ проведение исследований выполнимости
■ планирование системных переходов
■ детализация и заключительное уточнение идеи
или потребности
Оценка альтернатив, а также идентификация и устранение рисков—оценивание альтернатив,
связанных с целями и ограничениями; идентификация и устранение рисков
Разработка концептуального прототипа для выбранной части системы — определение
требований и спецификаций для потенциально наиболее опасных частей воображаемой
системы с целью выполнения оценивания и определения степени риска; разделение на
отдельные части в соответствии со степенями риска
Анализ проекта—разработка проекта на основе ранее определенных требований
■ анализ структуры системы ■ анализ функций
■ разработка предварительной системной
архитектуры

Идентификация задач и действий SOS
Продолжение табл. 9.8
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
■ декомпозиция предварительных системных
требований
■ идентификация предварительных ■ проведение предварительных собеседований
требований к ПО с пользователями
■ определение и разработка предварительных
требований к ПО
■ определение предварительных требований
к интерфейсу
■ расстановка приоритетов и интеграция
требований к ПО
Разработка продукта следующего уровня—создание прототипа с применением информации,
полученной на предыдущей фазе
■ создание частичной спецификации требований на системном уровне; включает
концепцию операций, которые будут использоваться для построения проекта
демонстрационного прототипа
Планирование следующей фазы—применение информации, относящейся к фазе разработки
продукта на следующем уровне, к планированию на следующем шаге фазы проекта
■ повторное планирование управления проектом
■ повторное формулирование потенциальных подходов
■ повторное планирование системного перехода
■ уточнений идей либо потребностей
■ проведение обзора концепций на системном уровне; приемка системной концепции
демонстрационного прототипа
Второй проход: цикл обзора требований
Определение целей, альтернатив и ограничений—определение требований и спецификаций для
критических частей воображаемой системы с точки зрения производительности,
функциональных свойств, способности к аккомодации изменений, программного/аппаратного
интерфейса, критических факторов успеха и т.д.
■ анализ функций на уровне системы/продукта
■ разработка системной архитектуры
■ декомпозиция системных требований
■ уточнение и разработка требований к ПО
■ определение требований к интерфейсу
■ расстановка приоритетов и интеграция программных требований на уровне
системы/продукта
Оценка альтернатив, а также идентификация и устранение рисков—оценивание альтернатив,
имеющих отношение к целям и ограничениям; идентификация и разрешение рисков

304 Глава 9
Продолжение табл. 9.8
Фаза жизненного цикла
Потенциальные действия
Потенциальные задачи
Разработка демонстрационного прототипа для выбранной части системы—уточнение
требований и спецификаций для потенциально наиболее опасных частей воображаемой
системы с целью выполнения оценки и определения степени риска; разделение на части в
соответствии со степенью риска
Изучение выполнимости — выполнение
имитаций и сравнительных тестов
Анализ проекта — проектирование на
основе предварительно сформулированных
требований
анализ рисков
планирование случайных факторов
анализ дальнейшей структуры системы
идентификация дальнейших требований к
программному продукту
Создание базы
данных—идентификация предварительных элементов базы
данных
Проектирование пользовательского
интерфейса — определение порядка
взаимодействия интерфейса с пользователем
Проектирование алгоритмических
функций
дальнейший анализ функций
дальнейшая разработка предварительной
архитектуры системы
дальнейшая декомпозиция
предварительных системных требований
дальнейшее проведение собеседований с
пользователями
дальнейшее определение и разработка
требований к ПО
дальнейшее определение требований к
интерфейсу
дальнейшая расстановка приоритетов и
интеграция системных требований
выполнение предварительной разработки
проекта архитектуры
предварительное проектирование базы
данных
предварительное проектирование
интерфейсов
выбор или разработка алгоритмов (только
"на бумаге")
Разработка продукта на следующем уровне—создание прототипа на базе информации,
полученной на предыдущей фазе
■ создание завершенной спецификации требований; включает детали, которые будут
использоваться для создания прототипа проекта, применяемого для оценки проекта

Идентификация задач и действий 305
Потенциальные действия
Продолжение табл. 9.8
Фаза жизненного цикла
Потенциальные задачи
Планирование следующей фазы—использование информации со следующего уровня шага фазы
продукта для выполнения перехода, запланированного на шаге следующей фазы проекта
■ повторное планирование управления проектом
■ повторное формулирование потенциальных подходов
■ повторное планирование системных переходов
■ уточнение идей либо потребностей
■ выполнение обзора требований; приемка проекта прототипа оценивания проекта
Третий проход — цикл обзора проекта
Определение целей, альтернатив и ограничений—определение требований и спецификаций для
критических частей воображаемой системы относительно производительности,
функциональных свойств, способности к аккомодации изменений, программного/аппаратного
интерфейса, критических факторов успеха и т.д.
■ анализ функций на уровне проекта
■ дальнейшая разработка системной архитектуры
■ дальнейшая декомпозиция системных требований
■ дальнейшее определение и разработка требований к ПО
■ дальнейшее определение требований к интерфейсу
■ расстановка приоритетов и интеграция требований на уровне проекта
Оценка альтернатив, а также идентификация и устранение рисков—оценка альтернатив,
имеющих отношение к целям и ограничениям; идентификация и устранение рисков
Разработка демонстрационного прототипа для выбранных частей системы —уточнение
требований и спецификаций для потенциально уязвимых частей воображаемой системы с
целью выполнения оценивания и определения степени риска; разделение на части по степеням
риска
■ Изучение выполнимости — выполнение
имитаций и сравнительных тестирований
■ Анализ проекта— разработка проекта на
основе принятых требований
■ анализ рисков
■ планирование случайных факторов
■ дальнейший анализ структуры системы ■ дальнейший анализ функций
■ дальнейшая разработка предварительной
системной архитектуры
■ дальнейшая декомпозиция
предварительных системных требований
■ дальнейшая идентификация требований ■ дальнейшее проведение интервью с поль-
к программному продукту зователями

306 Глава 9
Продолжение табл. 9.8
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
■ дальнейшее определение и разработка
программных требований
■ дальнейшее определение требований
к интерфейсу
■ дальнейшая расстановка приоритетов
■ Создание базы данных — идентификация ■ уточнение разработки проекта
элементов базы данных архитектуры
■ уточнение проекта базы данных
■ Проектирование пользовательского ин- ■ уточнение разработки проекта
терфейса — определение методов взаи- интерфейса
модействия ПО с пользователем
■ Разработка алгоритмических функций ■ уточнение алгоритмов
(только на "бумаге")
Разработка продукта следующего уровня—создание прототипа на основе информации,
полученной на предыдущей фазе
■ Производная детализованная разработка проекта ■ уточнение алгоритмов
ПО — детализированная разработка проекта ПО
является производной от принятых требований
■ выполнение детализованной
разработки проекта
■ генерирование документа
разработки системного проекта
(System design document, SDD)
Планирование следующей фазы — использование сведений, полученных на шаге фазы
продукта следующего уровня, для выполнения перехода, запланированного для шага следующей
фазы проекта
■ повторное планирование управления проектом
■ повторное формулирование потенциальных подходов
■ повторное планирование системного перехода
■ уточнение идей либо потребностей
■ выполнение обзора проекта; приемка оперативного проекта прототипа проекта
Четвертый проход: начальный цикл обзора возможностей продукта (Initial operational
capability, IOC)
Определение целей, альтернатив и ограничений—определение требований и спецификаций для
критических частей воображаемой системы с точки зрения производительности,
функциональных свойств, способности к аккомодации изменений, программного/аппаратного
интерфейса, критических факторов успеха и т.д.
■ анализ функций на уровне продукта
■ дальнейшая разработка системной архитектуры

Идентификация задач и действий 307
Продолжение табл. 9.8
Фаза жизненного цикла
Потенциальные действия
Потенциальные задачи
■ дальнейшая декомпозиция системных требований
■ дальнейшее уточнение и разработка программных требований
■ дальнейшее уточнение требований к интерфейсу
■ расстановка приоритетов и интеграция требований на операционном уровне
Оценка альтернатив, а также идентификация и устранение рисков— оценивание альтернатив,
относящихся к целям и ограничениям; идентификация и оценивание рисков
Разработка демонстрационного прототипа для выбранной части системы—уточнение
требований и спецификаций для потенциально уязвимых частей воображаемой системы с
целью выполнения вычислений и оценки рисков; разделение на отдельные части согласно
степени риска
■ Анализ проекта — проектирование на базе ■ анализ рисков
принятого проекта продукта
■ планирование случайностей
■ дальнейший анализ структуры системы
■ дальнейший анализ функций
■ уточнение разработки проекта
архитектуры
■ уточнение проекта базы данных
■ уточнение проекта интерфейса
Создание базы данных — идентификация
элементов базы данных
уточнение алгоритмов
(только на "бумаге")
■ Проектирование пользовательского
интерфейса— определение методов
взаимодействия ПО с пользователем
■ Проектирование алгоритмических
функций
Разработка продукта следующего уровня—создание прототипа на основе информации,
полученной на предыдущей фазе
Создание операционного прототипа — преобразования описания, содержащегося в
документе проекта ПО, в начальную операционную возможность (ЮС) программного продукта,
продуцируя при этом исходный код, базы данных и документацию независимо от того, были
ли они разработаны, приобретены, либо частично разработаны, а частично приобретены
■ Изучение выполнимости — выполнение
имитаций и сравнительных тестов производительности
■ Кодирование — преобразование детализованного
проекта в операционную систему
создание исходного кода
Интеграция — комбинирование программных
компонентов
генерирование объектного кода
создание оперативной
документации
план интеграции

308 Глава 9
Продолжение табл. 9.8
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
■ выполнение интеграции
■ Тестирование — проверка функционирующего ■ план тестирования
проекта
■ разработка тестовых требований
■ создание тестовых данных
■ выполнение тестов
■ Установка производственной системы—уста- ■ план установки
новка и проверка ПО в операционной среде,
выполнение необходимой настройки с целью
осуществления формальной приемки
функционирующего ПО со стороны заказчика
■ распространение ПО
■ установка ПО
Планирование следующей фазы — использование информации, полученной на этапе
следующего уровня продукта, с целью выполнения перехода к планированию (этап следующей
фазы проекта)
■ Оценка системы — обзор операционного прототипа
■ повторное планирование управления проектом
■ повторное формулирование потенциальных подходов
■ повторное планирование системного перехода
■ уточнение идеи либо потребности
■ выполнение обзора продукта; приемка операционного прототипа
Пятый проход: заключительный цикл обзора операционных возможностей продукта
(Final operational capability, FOC)
Определение целей, альтернатив и ограничений—определение требований и спецификаций для
критических частей воображаемой системы с точки зрения производительности,
функциональных свойств, способности к аккомодации изменений, программного/аппаратного
интерфейса, критических факторов успеха и т.д.
■ анализ функций на уровне FOC
■ дальнейшая разработка системной архитектуры
■ дальнейшая декомпозиция системных требований
■ дальнейшее определение и разработка требований к ПО
■ дальнейшее определение требований к интерфейсу
■ расстановка приоритетов и интеграция требований на заключительном операционном
уровне
Оценка альтернатив, а также идентификация и устранение рисков—оценка альтернатив,
имеющих отношение к целям и ограничениям; идентификация и устранение рисков

Идентификация задач и действий 309
Продолжение табл. 9.8
Фаза жизненного цикла
Потенциальные действия
Потенциальные задачи
Разработка заключительного проекта системы, обладающей операционными
возможностями (FOC) —уточнение операционного прототипа для указанной системы
■ Анализ проекта — разработка проекта на ос- ■ анализ рисков
нове принятого проекта продукта
Создание базы данных — идентификация
элементов базы данных
Проектирование пользовательского
интерфейса — определение порядка
взаимодействия ПО с пользователем
планирование случайных факторов
дальнейший анализ структуры системы
дальнейший анализ функций
дальнейшая разработка системной
архитектуры продукта
уточнение разработки проекта
архитектуры
уточнение проекта базы данных
уточнение проекта интерфейса
уточнение алгоритмов
■ Проектирование алгоритмических
функций
Разработка продукта на следующем уровне— создание прототипа на базе информации,
полученной на предыдущей фазе
Создание завершающих операционных возможностей системы (FOC) — преобразование
описания документа обновленного программного проекта в завершающие операционные
возможности (FOC) программного продукта, при этом создается исходный код, базы данных,
документация, а также проводится обучение независимо от того, были ли эти компоненты
разработаны, приобретены, либо частично разработаны, а частично приобретены
В Изучение выполнимости — выполнение
имитаций и сравнительного тестирования
■ Кодирование—преобразование детализованной ■ создание исходного кода
разработки проекта в операционную систему
■ генерирование объектного кода
■ создание оперативной
документации
■ план интеграции
Интеграция -
компонентов
- комбинирование программных
Тестирование — проверка завершающей
операционной возможности (FOC) для данного экземпляра
проекта
выполнение интеграции
план тестирования
разработка тестовых требований

310 Глава 9
Окончание табл. 9.8
Фаза жизненного цикла
Потенциальные действия Потенциальные задачи
■ создание тестовых данных
■ выполнение тестов
■ Установка производственной системы—уста- ■ план установки
новка и проверка ПО в операционной среде,
настройка (при необходимости) для осуществления
формальной приемки заказчиком
производственного ПО
Планирование следующей фазы—использование информации этапа следующего уровня
продукта для выполнения планирования перехода на этап следующей фазы проекта
■ Оценка системы — выполнение обзора ■ повторное планирование '
операционного прототипа
■ повторное формулирование потенциальных
подходов
■ повторное планирование системных
переходов
■ уточнение идеи либо потребности
■ выполнение обзора продукта (FOC);
приемка операционной системы
Эксплуатация и сопровождение — перемещение ПО в производственное состояние
■ распространение ПО
■ установка ПО
■ приемка ПО в операционной среде
■ выполнение операций в системе
■ оказание технической помощи и консультаций
■ ведение журнала запросов о помощи
Процесс вывода из эксплуатации — прекращение активного использования существующей
системы путем завершения выполняемых ею операций либо путем замены на новую систему,
либо с помощью использования обновленной версии
■ извещение пользователей
■ выполнение параллельных операций
■ вывод системы из эксплуатации
Интегральные действия — см. табл. 9.2.

Идентификация задач и действий 311
Резюме
В главе рассматривались характеристики задач и действий, образующих
структуру WBS для проекта. Были исследованы различия между задачами и действиями, а
также их связь со структурой WBS. Было показано, каким образом 65 действий,
имеющих отношение к 17 процессам, которые определены стандартом IEEE 1074,
могут выглядеть в качестве настраиваемых шаблонов жизненного цикла для
выполняемых действий. Также рассматривалась роль сопровождения в жизненном цикле
разработки ПО.
Контрольные вопросы
1. Объясните различия между задачей и действием, относящимся к проекту
разработки ПО. Приведите соответствующие примеры.
2. Идентифицируйте действия, отсутствующие в каждом из рассматриваемых
пооперационных перечнях работ.
3. Приведите пример действия "оптимального размера" из собственного опыта.
Практическое занятие
Доктор Чжоу тщательно просмотрел ваш план проекта. Он пришел к выводу, что
ваша структура WBS непротиворечива. Он предполагает, что, будучи менеджером
проекта, вы ознакомлены с определением задачи, приведенном в РМВОК. "Задача
представляет собой обобщенный термин для работы, которая не включена в
пооперационный перечень работ". Вы присоединили копию сети плана менеджмента
проекта, диаграммы Ганта, а также ресурсов, с помощью которых загружаются
диаграммы из программы Microsoft Project. Все эти диаграммы ссылаются на выполняемые
вами задачи. Доктор Чжоу, мистер Лу и мисс Пайтель хотят знать, почему вы
работаете с объектами, не включенными в структуру WBS, утверждая при этом, что
снижение риска при составлении графика является столь высоким. Пожалуйста,
объясните это с помощью презентации PowerPoint, представленной на утренней
конференции NetMeeting, проводимой в 7 часов утра.
Литература
Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 5-е издание.
Van Nostrand Reinhold, 1995.
Lewis James P. Project Planning, Scheduling, and Control: A Hands-On to Bringing Projects in on Time and on
Budget. McGraw-Hill, 1995.
Paulk Mark С. и др. The Capability Maturity Model- Guidelines for Improving the Software Process, Addison-
Wesley SE1 Series in Software Engineering. Section 7.2, Software Project Planning and Section 7.3, Software
Project Tracking and Oversight, 1994.
Pressman Roger S. Software Engineering: A Practicioner"s Approach, 5-е издание. McGraw-Hill.
Глава 5. "Software Project Planning," и глава 7, "Project Scheduling and Tracking", 2001.

312 Глава 9
Дополнительные сведения в Internet
stsc.hill.af.mil/crosstalk/1996/apr/project.asp. Линн Сатервайт (Lynn Satterth-
waite). "Управление проектами: некоторые уроки—апрель 1996 г." Центр поддержки ПО.
www.pmi . org/publish/pmboktoc.htm. А руководство Основы знаний в области управления
проектами Института PMI (PMBOOK Guide), глава 6.
www.pmi . org/standarts/wbspractice.htm. Синди Берг (Cindy Berg) и Ким Коленсо (Kim
Colenso). "Стандартный проект, иллюстрирующий разработку структуры пооперационного перечня
работ — структура WBS и действия." РМ Network, апрель, 2000 г.
www.worldbank.org/worldlinks/english/training/world/webproj/define/develop/
develop2.htm. Создание совместного Web-проекта, ссылки на учебные материалы для программы
по разработке ПО (WorLD).

Оценка размера
и возможности
повторного
использования ПО
В процессе выполнения работ в рамках проекта значительно упрощается
получение оценки возможного "размера" программной системы. Если подобные
попытки предпринимаются на начальном этапе жизненного цикла разработки ПО,
доступен для оперирования лишь небольшой объем сведений. Более ли менее
точно можно оценивать требования заказчиков высокого уровня. Аналогичная
ситуация складывается, если, основываясь лишь на идее проекта дома,
попытаться учесть все запросы застройщика. Архитектор вместе с клиентом должны
оценить расположение участка, а уточнения запросов и создание чертежей могут
вносить существенные изменения в план застройки. Когда разработка
программного проекта близится к завершению, с целью уточненного оценивания следует
учитывать некоторые дополнительные аспекты и спецификации. Конечно, не
следует откладывать процесс оценивания на последний этап работы. Общую
смету, время работы над проектом и объем необходимых трудозатрат необходимо
оценивать значительно раньше. Труднее всего выполнить оценивание в начале
проекта, когда еще не сформировались достаточно четкие представления о нем.
На базе этих оценок можно сделать общий вывод, стоит ли заниматься данным
проектом в дальнейшем, на каких условиях следует заключить контракт на его
выполнение. Оценивание следует производить в любом случае, даже если
возникают определенные неудобства.
При оценке стоимости проекта и количества времени, требуемого для его
выполнения, следует выполнить два основных этапа. Первый этап состоит в оценивании
размера проекта; на втором этапе представление об этих размерах наряду с
информацией о других факторах среды позволяет оценивать общий объем трудозатрат и,
соответственно, стоимость работ. Уточнение размеров создаваемого ПО предшествует
этапу кодирования, выполняемого с целью реализации требований на практике.
Путем выполнения оценивания можно спрогнозировать общий объем ресурсов,
который необходим для выполнения данного проекта. При этом учитываются затраты
времени, количество штатных единиц и бюджетные ограничения.

314 Глава 10
Второй этап рассматривается в главе 11. В главе 10 обсуждается первый этап
процесса оценивания. На данный момент времени мы займемся оценкой размеров
программного проекта. В качестве единиц измерения могут выступать самые различные
величины. Выбор этих единиц зависит от конкретного проекта и потребностей
вашей организации.
Размер ПО определяется в терминах строк кода (Lines of code, LOC),
функциональных точек и точек свойств. Также можно учитывать количество "жирных точек"
на диаграмме потока данных (Data flow diagram, DFD), оценивать количественные
характеристики спецификаций процесса/управления (PSPECS/CSPECS), количество
основных записей и/или взаимосвязей на диаграмме, отражающей взаимосвязь
сущностей (Entity relationship diagram, ERD). Иногда прибегают к сравнительному
подсчету количества упоминаний "должно" и "желательно" при изучении документа,
содержащего основные требования, учитывают число страниц пользовательской
документации, объекты и/или классы объектной модели, а также прибегают к другим
вариантам оценок. Не столь важно, что некоторые термины звучат немного
непривычно, поскольку при рассмотрении все же будут учитываться наиболее
распространенные определения. Вне зависимости от того, оценивается ли конечный продукт,
как в случае с применением показателя LOC, либо некоторая его абстракция или
модель, как это происходит с объектами классов, в данном случае оценке подвергается
то, чего еще нет в природе. Поэтому оценивание размеров представляет
значительные трудности.
Стадии жизненного цикла разработки
продукта
Оценивание размера и потенциала повторного использования ПО выполняется на
ранних стадиях планирования проекта. Если воспользоваться терминологией из
области обобщенной модели жизненного цикла, можно сказать, что планирование
осуществляется на этапах исследования концепций, системы и в фазе формирования
требований (рис. 10.1). Оценка размера и трудозатрат выполняется неоднократно во
время осуществления жизненного цикла, причем после каждого оценивания
повышается и уровень доверия к достигнутым результатам. Точность оценки значительно
повышается после формулирования начальных требований заказчиков, проведения
анализа, после завершения разработки проекта и т.д. В используемой в данном случае
модели процесса описываются фазы жизненного цикла (глава 4). Используемые фазы
могут служить в качестве индикаторов, с помощью которых устанавливается наличие
оценки и повторной оценки. Хороший менеджер проекта просто обязан взять себе за
правило оценивать (однократно и повторно) размеры ПО, используя результаты
оценивания в качестве выходных критериев для каждой фазы
Связь главы 10 с 34 компетенциями
Оценивание размера программного продукта, результат которого затем
применяется для оценивания трудозатрат и накладных расходов на этапе разработки проекта,
хорошо вписывается в набор компетенций проекта. Оценки размера ПО,
скорректированные с целью повторного применения, фиксируются в плане проекта. Таким
образом, связь с данной главой имеет третья компетенция проекта, называемая доку-

Оценка размера и возможности повторного использования ПО 315
ментированием планов. При оценке размера ПО используется метод измерения,
который поддерживается на всем протяжении эволюции проекта. И наконец, данные о
размере ПО являются исходными при составлении графика проекта.
Исследование
концепции
• Формули-''
рование

потребности
Исследование
системы
1 Спецификация
интерфейса
системы
Требования
1 Спецификация
требований
к ПО
Разработка
проекта
Идентификация
циклов SLC
■ Описание

разработки ПО
•SLCs
Внедрение
Выбор
модели
■ План

тации/верификации ПО
• Модель SLC
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
Выбор модели
жизненного цикла
разработки ПО
Установка
■ Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
•SLC
Распределение
ресурсов
1
Пользовательская
документация
Сопровождение
1 Бюджет
' Документация
по
сопровождению
Вывод из
эксплуатации
■ Архивный
отчет
Рис. 10.1. Оценка размера ПО и возможности повторного использования в начале жизненного
цикла разработки
Навыки менеджмента проектов
1. Создание структуры пооперационного перечня работ— задачи в рамках
выполнения проекта и производства продукта разбиваются на достаточно малые
составляющие элементы, размер которых будет затем оцениваться.
2. Документирование планов — разбитые на составляющие элементы задачи в рамках
выполнения проекта и производства продукта оцениваются с целью вычисления
величины, трудозатрат и накладных расходов. Результаты оценки используются при
составлении графика. Все упомянутые выше параметры отображаются в плане
управления программными проектами (SPMP); оценки рисков документируются
в виде отдельного плана рисков, выступающего в качестве части плана SPMP.

316 Глава 10
3. Оценка стоимости и трудозатрат, требуемых для завершения проекта —
благодаря оценке возможного размера ПО можно судить относительно размера
планируемых трудозатрат. Например, если размер разрабатываемого ПО оценивается
величиной в 500 LOC (единица оценки размера), а скорость программирования в
среднем равна 5 LOC/час (оценка производительности), то в этом случае
трудозатраты составят 100 часов. Если ваша небольшая команда состоит из двух
человек, которые могут распределять между собой рабочую нагрузку, трудозатраты
каждого из них составят по 50 часов. Оценка трудозатрат влечет за собой оценку
возможных накладных расходов. Если накладные расходы (стоимость) для
первого разработчика составят 65 долларов в час, а накладные расходы для другого
разработчика — 55 долларов в час, то накладные расходы при разработке всего ПО
составят 6000 долларов C250 + 2750).
4. Составление графика — на основе оценки трудозатрат можно составить график.
Если в рассматриваемом примере каждый разработчик затратил 25 часов на
производство в неделю и при этом он может работать в параллельном режиме (не
учитывая зависимости), то согласно оценкам, 500 единиц LOC продукта будет
поставлено в течение двух недель.
5. Выбор метрических показателей— на базе применяемых единиц измерения
формируется метрический показатель. Его достаточно выбрать лишь один раз
(в предыдущем примере LOC), а затем просто ссылаться на протяжении всей
оставшейся части главы.
Учебные цели главы 10
После изучения материала главы читатель должен уметь выполнять следующее:
■ объяснять, почему оценивание размера ПО является важной составляющей
частью технологии оценивания, используемой в жизненном цикле разработки ПО
(также читатель сможет осознать, каким образом при этом снижается степень
риска и повышается уровень зрелости организации);
■ описывать, каким образом структура пооперационного перечня работ (WBS)
может оказывать влияние на способность к выполнению оценки размера ПО;
■ перечислить несколько моделей, которые достаточно часто используются в
индустрии производства ПО при оценке размера программ;
■ объяснять смысл методов LOC, функциональных точек, точек свойств, блиц-
модели, а также методов оценивания размера ПО, позаимствованных в Delphi;
■ резюмировать преимущества и недостатки каждой из упомянутых моделей;
■ для каждой модели описывать ее применимость, степень точности, а также
величину накладных расходов;
■ объяснять степень влияния повторно используемых программных компонентов
при оценивании размера ПО.
Модель СММ SEI и процесс оценивания
Модель зрелости возможностей (СММ), разработанная Институтом
программного инжиниринга (SEI), впервые была упомянута в главе 4, где она применялась для

Оценка размера и возможности повторного использования ПО 317
поддержки описываемых действий. Планирование программных проектов
представляет собой ключевую область процессов, используемую для обеспечения зрелости
уровня 2 (повторяемый уровень). Оценка размеров программных продуктов и
проектов является элементом планирования проектов.
Назначение планирования программных проектов заключается в установке
приемлемых планов, применяемых при выполнении программного инжиниринга и управления
программным проектом. В ходе осуществления планирования программных проектов
производится выполнение оценок выполняемой в перспективе работы, установка
требуемых ограничений, а также определение непосредственного рабочего плана....
Планирование разработки ПО начинается с утвгрждения выполняемой работы, а также с
установки других ограничений и целей, которые определяют и связывают программный
проект (все они устанавливаются с помощью практических приемов, описанных в
ключевой области процесса управления требованиями). Процесс планирования разработки
ПО включает этапы, при выполнении которых производится оценка программных
рабочих продуктов, а также необходимых ресурсов, разрабатывается график,
идентифицируются и заносятся в актив риски при разработке ПО, а также торговые издержки.
Итерация по этим этапам может быть необходимой с целью установки плана
программного проекта (так называемого плана разработки ПО). Этот план
поддерживает основу для выполнения управления действиями в рамках программных проектов, а
также адресует имеющиеся ограничения функциональных возможностей заказчикам
программных проектов. Уровень этих ограничений зависит наличных ресурсов, "узких
мест " и возможностей программного проекта.
Цели модели SEI СММ уровня 2, ключевая область
процесса (КРА): планирование программного
проекта (РР)
Цель 1 — выполнение оценки ПО документировано с целью применения при
планировании и отслеживании программного проекта.
Возможность для выполнения, связана с КРА РР, цель 1
Способность 4 — менеджеры программных проектов, инженеры-программисты и
специалисты другого рода, вовлеченные в процесс планирования программных
проектов, обучаются процедурам планирования и оценивания ПО, применимым в их
зонах ответственности.
Выполненные действия
Действие 5 — идентифицируется либо определяется жизненный цикл разработки
ПО, который включает предопределенные стадии, имеющие управляемый размер.
Действие 8 — идентифицируются программные рабочие продукты, требуемые для
установки и поддержки контроля над осуществлением программного проекта.
Paulk Mark. С, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis. The Capability Maturity
Model: Guidelines for Improving the Software Process, 1st ed. Reading, MA: Addison-Wesley, 1994.

318 Глава 10
Действие 9 — оценивается размер программных рабочих продуктов (либо
изменения в размере программных рабочих продуктов), которые производятся согласно
документированной процедуре.
1. Оценивание размера выполняется для всех основных программных продуктов и
действий.
2. Программные рабочие продукты разбиваются на более мелкие компоненты
согласно уровню детализации, удовлетворяющему требованиям, выдвигаемые при
оценивании.
3. Применяются исторические данные (в случае их наличия).
4. Документированные гипотезы относительно результатов оценивания размеров.
5. Результаты оценивания размеров документированы, просмотрены и одобрены.
Проблемы и риски, связанные
с оцениванием размера ПО
В последующих разделах главы описываются причины, приводящие к появлению
нетрадиционных проблем у менеджеров и разработчиков ПО в процессе оценивания
выполняемых ими задач. Здесь также объясняется, почему процесс оценивания
является столь рискованным.
Проблемы, возникающие в процессе оценивания
Общеизвестно, что инженеры-программисты весьма плохо справляются с
проблемами оценивания. К этому выводу несложно прийти, если принять во внимание тот
факт, что около 15 % программных проектов не доводятся до завершения, а накладные
расходы при реализации программных проектов нередко составляют 100-200
процентов. Как правило, мы не являемся плохими исполнителями, хотя со стороны может
показаться обратное. Нас оправдывает то, что прогнозы по поводу достигаемой
производительности весьма далеки от совершенства. Существует множество причин, в силу
которых мы надеемся достичь невиданных результатов, поэтому корректное
оценивание превращается в весьма сложную задачу.
Несоответствие производительности изначально предполагаемым показателям,
может иметь две следующие причины: плохая работа или некорректная оценка. В мире
программного обеспечения можно получить множество свидетельств плохо
выполненной оценки, однако практически невозможно доказать, что персонал не трудился
усердно над разрешением проблемы либо не является в достаточной степени компетентным .
Конечно, Де Марко прав. Разработчиков часто критикуют за то, что они
безответственны и невнимательны к потребностям заказчика. Причем зачастую они не могут
"исправиться" в силу каких-то черт характера либо просто из-за обыкновенной лени.
На самом деле все эти утверждения весьма далеки от истины. Истина заключается в
том, что разработчиков зачастую нельзя призвать к ответственности за их деяния.
' DeMarco Tom (). Why Does Software Cost So Mucht And Other Puzzles of the Information Age. NY:
Dorset House, 1995.

Оценка размера и возможности повторного использования ПО 319
Этот вывод основывается на положении, которое Де Марко назвал менеджментом
ожиданий. И все начинается с оценки размеров ПО.
Конечно, оценивание не является простой задачей. И причин здесь немало:
■ проблема может быть недостаточно хорошо понята разработчиками и/или
заказчиками из-за того, что некоторые факты были упущены или искажены из-за
предвзятого отношения;
■ недостаток либо полное отсутствие исторических данных не позволяет создать
базу для оценок в будущем;
■ специалисты-оценщики могут потерпеть неудачу при попытке описания того,
насколько большой может быть система, еще до ее создания или даже еще до этапа
разработки проекта;
■ проектирующая организация не располагает стандартами, с помощью которых
можно выполнять процесс оценивания (либо в случае наличия стандартов их
никто не придерживается); в результате наблюдается недостаток совместимости при
осуществлении процесса оценивания;
■ согласно требованиям менеджеров и/или заказчиков, необходимо быстрое
оценивание, и в этой ситуации важно понимать, что возможно непосредственное
создание программного кода, минуя этапы анализа и разработки проектов;
■ менеджеры проектов полагают, что было бы неплохо фиксировать требования в
начале осуществления проекта, заказчики же считают, что не стоит тратить
драгоценное время на разработку спецификации требований;
■ при осуществлении менеджмента используются оценки с целью повышения
производительности или достижения мотивированных целей;
■ разработчики желают получать удовольствие от результатов менеджмента, а также
находиться с заказчиками на равных;
■ ошибки, как правило, будут скрытыми вместо того, чтобы оцениваться и
отображаться, в результате чего создается ложное впечатление о фактической
производительности;
■ возможности оценивания существенно зависят от субъектов, вовлеченных в
процесс внедрения;
■ предварительное оценивание и составление предписаний рассматриваются в
качестве целей исполнения; оценивание выполняется на подготовительном этапе,
т.е. еще до того, как завершится исследование понятий; между предполагаемыми и
реальными предписаниями возникают конфликты;
■ повторное оценивание кажется излишним;
■ для достижения желаемой четкости в функционировании других частей системы
(интерфейсов наследственной системы, аппаратного обеспечения и т.д.) может
потребоваться дополнительное ПО, что скажется на размерах программного
продукта; имеет место недостаточно четкое представление об ограничениях как на
уровне системы, так и иного рода;
■ менеджеры, аналитики, разработчики, тестеры и те, кто внедряет продукт, могут
бытовать самые разные представления о процессах оценивания и о возможностях
совершенствования рассматриваемого продукта.

320 Глава 10
Исходя из вышеизложенного, вызывает удивление тот факт, что довольно
сложный и нелегкий процесс прогнозирования размеров программного продукта можно
охарактеризовать с помощью проектных рисков.
Риски оценивания
Основополагающие принципы рисков, возникающих при управлении
программными продуктами, рассматриваются в главе 18. Большинство типичных рисков,
связанных с процессом создания программного продукта, возникают при оценивании
размера, трудозатрат, стоимости работ и графиков по их выполнению. Причем в
основе этих рисков лежат "проблемы, связанные с оцениванием". Ниже приводится
краткий обзор некоторых характерных рисков, а также небольшая подборка советов
по уменьшению их влияния на осуществление проекта.
Некоторые риски управления программными проектами,
связанные с оценкой его размера
Если оценки неполные или некорректные, возникает очевидная угроза потерять
заказчиков, а возможно, и утратить перспективы развития всего бизнеса. Столь же
серьезные последствия имеют и ошибки при определении стоимости работ (в случае,
если контракт заключается с указанием заранее оговоренной суммы). Слишком
оптимистичные оценки могут привести к существенным финансовым потерям (возможно,
даже в крупных размерах), а также к потере доверия со стороны клиентов.
Неверные оценки приводят к изменениям графика, к необходимости резко
сокращать временные рамки выполнения работ, что зачастую приводит к
существенным недоработкам в готовом проекте.
Возможности уменьшения степени риска, связанного
с оценкой размера ПО
Ниже перечислены способы уменьшения влияния рисков, связанных с оценкой
размера ПО. Многие из этих методов широко используются в практике
менеджмента проектов:
■ обратитесь к WBS, используйте самый малый уровень из возможных, применяйте
подход "разделяй и властвуй"; учитывайте то, что меньший размер компонентов
способствует облегчению задачи оценщика;
■ выполните обзор требований с учетом всех "отягчающих обстоятельств", включая
выполнение действий, поддержку и сопровождение;
■ если это возможно, различные предположения заменяйте информацией,
основанной на опыте по организации подобных работ. Этот подход можно
использовать и при отсутствии исторически конкретных данных. Самые невероятные
случаи можно исключить из рассмотрения;
■ необходимо поддерживать тесное сотрудничество с разработчиками других
системных компонентов (возможно, при выполнении работы в параллельном режиме),
причем желательно использовать единый понятийный аппарат;
■ через определенные интервалы необходимо изменять оценки, как показано на
рис. 10.2. Точность оценивания улучшается на протяжении всего жизненного
цикла разработки ПО;

Оценка размера и возможности повторного использования ПО 321
■ с целью повышения степени доверия к получаемым результатам используйте
несколько методов оценивания размера ПО;
■ повышайте уровень квалификации разработчиков, широко используя методику
оценивания размеров ПО.
Барри Боэм (Barry Boehm) и Каперс Джонс (Capers Jones) составили графические
диаграммы, на основе которых можно сделать вывод, что уже на ранних этапах
жизненного цикла можно успешно реализовывать оценку размера ПО. При этом
становится возможным рассматривать перспективы эволюции первоначальных решений,
принимаемых при работе над проектом. Если заказчики требуют приблизительных
оценок, им следует учитывать, что в этом случае невозможно достижение большой
степени точности. Обычно погрешность этого метода оценивания составляет 35% от
конечной реальной величины (которая может представлять размер/объем
затрачиваемых усилий/уровень выполнения графика работ/объем затрат). Этот метод чаще
приводит к получению заниженных оценок размера ПО. Данный феномен
проиллюстрирован на рис. 10.2.
8
X
б
Выполнимость План
и требования
Детализированные Утвержденное
спецификации, программное
дизайна обеспечение
Разработка Детализированный Разработка
проекта проект и тестирование
продукта
Рис. 10.2. Точность оценивания размера ПО
Начальный этап определения размеров
программного продукта: оценивание
начинается с планирования
Определение размеров программного продукта представляет собой и
прогнозирование структуры поставляемых продуктов (имеющих как внутреннюю, так и
внешнюю природу) с целью удовлетворения требований проекта. В процессе оценивания
также выполняется прогнозирование трудозатрат (ресурсов), необходимых для
проектирования поставляемых продуктов.
5 Boehm Barry. Software Engineering Economics. Engkewood Cliffs, NJ: Prentice Hall, 1981.

322 Глава 10
Действия по определению размеров и оценке ПО попадают в центральную
область последовательности задач по планированию программных проектов. Как
показано на рис. 10.3, задаче оценке размеров ПО предшествует определение цели и
области действия программного проекта, создание WBS, а также идентификация задач
и действий (главы 7-9). После задач по прогнозированию размеров ПО следуют
задачи по оценке длительности и стоимости разработки (глава 11), в процессе
выполнения которых происходит распределение ресурсов (глава 12), учет зависимостей
(глава 14), а также составление рабочего графика (глава 15).
Определение целей
и области действия
программного
проекта (глава 7)
Выбор жизненного
цикла разработки
ПО (глава 4)
Выбор
организационной
формы (глава 13)
с-
Начало процесса
отбора команды
разработчиков
проекта (глава 6)
Определение
проектных
рисков (глава 18)
С-
Создание структуры
пооперационного
перечня работ (сметы
расходов) (глава 8)
Идентификация
задач и действий
(глава 9)
Учет зависимостей
(глава 14)
<=■
Оценка размера
ПО, учет потенциала
повторного использования
(глава 10)
Оценка трудозатрат
(стоимость) и длительности
(график) (глава 11)
Распределение
ресурсов (глава 12)
Планирование
работы (глава 15)
Рис. 10.3. Большая картина оценки ПО
Разбиение проекта на отдельные задачи (WBS)
В главе 8 уже рассказывалось о том, что структура VVBS представляет собой описание
выполняемой работы, разбитой на ключевые элементы (задачи). Каждая задача может
быть управляемой, административной, интегральной либо поддающейся разработке.
Путем разбиения проекта на вышеупомянутые управляемые части производится
оценивание размера каждого элемента (задачи), и трудозатрат на его разработку.
Трудозатраты выражаются в человеко-часах, неделях, месяцах и т.д. При использовании WBS
задачи идентифицируются на уровне выполнимости с учетом наличия доступного
персонала, обладающего необходимыми навыками. После определения
необходимого количества персонала, а также установки требуемых навыков оценка трудозатрат
будет соотноситься с календарным планированием для определения длительности
выполнения проекта и его ключевых стадий. Результирующий график проекта обычно

Оценка размера и возможности повторного использования ПО 323
отображается в виде диаграмм Ганта. И напоследок стоит отметить, что каждая задача
определяется, оценивается и отслеживается на протяжении выполнения всего проекта.
Существует несколько представлений WBS. Представление продукта определяет
иерархические взаимосвязи между элементами продукта (процедуры, модули,
подсистемы и т.п.). Представление проекта указывает на иерархические взаимосвязи между
рабочими действиями (элементы процесса). При выполнении оценок и
измерительных операций для графиков-прогнозов потребуется учитывать оба набора элементов
и действий. Задачи по разработке (продукта) могут включать анализ,
высокоуровневое и низкоуровневое проектирование, кодирование, тестирование и т.д. Все
вышеперечисленное происходит на фазах жизненного цикла. Управленческие задачи
включают планирование проекта, отслеживание, контроль, анализ рисков и т.п.
Задачи поддержки могут включать документацию на поставляемые продукты,
например, руководства пользователя, операционные пособия, а также справочники,
описывающие выполнение сетевых коммуникаций. Задачи управленческие,
административные, а также задачи поддержки называются интегральными. При этом
рассматривается одна задача или больше, а иногда и все задачи по разработке ПО.
Другие интегральные задачи включают: процедуры управления конфигурацией, практику
обеспечения качества ПО, управление и анализ рисков, технику и инструменты
разработки ПО, методы проведения обзоров незавершенных поставляемых продуктов,
собираемые и анализируемые метрические показатели, определение и
документирование стандартов (правила, применимые для незавершенных поставляемых
продуктов), а также любые другие действия, необходимые для удовлетворения требований
заказчиков (например, создание документации, учебные программы, инструменты
разработки либо получения необходимых результатов).
Структура WBS обеспечивает выполнение планирования и отслеживания рабочих
действий, определение стоимости или графика путем предоставления инженеру либо
менеджеру глобальной точки зрения. Благодаря этому можно организовать и
иллюстрировать процесс выполнения работы. В результате идентифицируется вся
необходимая работа; распределение работы на небольшие по размеру, хорошо
определенные задачи; облегчение планирования, оценки и составления графика для проекта.
При этом поддерживается фундамент, необходимый для выполнения мониторинга
данных и сбора исторических данных; а также для идентификации договорных задач
и конструктивных узлов. Это позволит нам заменить высказывание "сделано на 90%"
на "мы выполнили 97 из 234 задач". "Утяжеленные" задачи приобретают значимость и
могут быть связаны с оценкой затрат.
При использовании структуры WBS в ваше распоряжение предоставляется
содержание, иерархический перечень рабочих действий, требуемых для завершения
проекта. В результате, WBS выступает в роли "неприметного" инструмента,
применяемого для определения размера и оценки действий процесса.
В главе 3 уже упоминалось о том, что каждый процесс включает входные данные,
преобразования и выходные данные. Следующие дополнительные вводы
применяются для измерения и оценки процесса (в то время как для выводов характерны
оцененный размер, трудозатраты, длительность [график], а также затраты):
■ план выполнения проекта или рабочий план (Statement of work, SOW);
■ начальная проектная документация;
■ перечень требований:
— ожидаемый уровень производительности;

324 Глава 10
— указанные для включения свойства;
— методы оценки результатов;
■ ограничения;
■ используемые процессы и стандарты:
— методы разработки ПО;
— правила, используемые в качестве руководства к действию, и применяемые
критерии оценки качества;
■ контракт на оказание услуг;
■ предыдущий опыт решения подобных задач;
■ хронологическая оценка и фактические данные, используемые в вашей организации;
■ применяемые языки программирования;
■ информация о повторно используемом ПО;
■ сведения о разработке проекта системы;
■ начальные концепции архитектуры ПО — основные компоненты;
■ назначение и область действия проекта, включая выполняемые задачи и
поставляемые продукты.
Конечно, маловероятно, чтобы большая часть из этих входных данных была
доступной в ходе процесса оценки, но в данном случае справедливым является принцип
"чем больше, тем лучше". Благодаря использованию возможностей WBS оценка
размера ПО превращается в серьезное мероприятие.
Оценка размера ПО в процессе разработки проекта
В процессе преобразования величин длины, объема, массы и площади из одной
метрической системы в другую напрашивается вывод, что выбор единиц измерения
и их наименований не является столь важным по сравнению с возможностью
использования общего понятийного языка. То же самое справедливо в случае с
оценками размеров ПО. Как только выбирается и фиксируется единица измерения, при
сравнении фактических данных требуется отслеживание оценок в течение
длительного периода времени с целью поддержки обратной связи, необходимой для
дальнейшего улучшения инструментальных измерительных средств. Ниже
приводятся примеры некоторых наиболее распространенных единиц измерения,
используемых при оценке размера ПО. Не беспокойтесь, если вы не знакомы со всеми
новыми терминами, — освоите в процессе чтения данной главы.
Примеры единиц измерения
Наше исследование различных единиц измерения, используемых при оценке
размеров ПО, будет посвящено рассмотрению некоторых наиболее часто
используемых из них:
■ количество строк кода (Lines Of Code, LOG);
■ функциональные точки;
■ точки свойств;
■ количество "пузырьков" на диаграмме потока данных (Data flow diagram, DFD);

Оценка размера и возможности повторного использования ПО 325
■ количество сущностей на диаграмме сущностей (Entity relationship diagram, ERD);
■ количество "квадратиков", соответствующих процессу/контролю (PSPEC/CSPEC)
на структурном графике;
■ количество различных элементов в составе управленческой спецификации;
■ объем документации;
■ количество объектов, атрибутов и служб на объектной диаграмме.
Можно привести множество академических доводов в пользу того или иного
метода измерения, но лучше всего руководствоваться критерием пригодности метода в
конкретной ситуации. Поэтому следует выбирать тот метод, который позволяет
получать непротиворечивые результаты измерений, а также помнить о том, что
хронологические данные являются "лучшими союзниками".
Количество строк кода
При использовании этих единиц измерения возникает масса вопросов. Каким
образом можно определить количество строк кода (Lines of code, LOC) до того, как они
фактически будут написаны либо просто спроектированы? Как показатель количества
строк кода может отражать величину трудозатрат, если не будет учитываться
сложность производимого продукта, способности/стиль программиста либо возможности
применяемого языка программирования? Каким образом разница в количестве строк
кода может быть трансформирована в объем эквивалентной работы? Эти и другие
подобные вопросы приводят к тому, что единицы измерения LOC получают "дурную
репутацию", хотя они по-прежнему остаются наиболее широко используемыми.
Взаимосвязь между LOC и затрачиваемыми усилиями не является линейной. Несмотря на
появление новых языков программирования, средняя производительность
программиста за последние двадцать лет осталась неизменной и составляет около 3000 строк
кода на одного программиста в год. Это говорит о том, что уменьшение времени,
затрачиваемого на цикл разработки, не может быть достигнуто за счет
значительного повышения производительности труда программистов. Причем это не зависит
от усовершенствований языка программирования, усилий со стороны менеджеров
либо от наличия/отсутствия сверхурочных работ. На самом деле огромное
значение имеет набор функциональных свойств и качество ПО, а не количество строк
программного кода.
Оценка показателя LOC с помощью экспертных заключений и восходящего суммирования
В настоящее время мы будем полагать, что наша структура WBS содержит
несколько уровней декомпозиции в иерархии продукта/проекта. Требования к иерархии
продуктов WBS могут быть разбиты на фактические компоненты программных
систем. Причем начало разбиения определяется уровнем обобщенных подсистем
(например, модуль Дебиторы или модуль Кредиторы в финансовых системах).
В дальнейшем разбиение может детализироваться, формируя очень точный либо
примитивный уровень абстракции (например, редактор, процедуры ввода/вывода
GET/PUT либо экранный дизайнер). Наиболее низкий уровень детализации, как
правило, редко формируется ко времени первоначальной оценки размера ПО
(обычно эти уровни детализации формируются на более поздних стадиях проекта).
Обычно несколько уровней абстракции могут определяться на весьма ранних стадиях
планирования проектов. Следует учитывать тот факт, что в максимальной степени
детализированная структура WBS может принести пользу на стадии точных
измерений, за которой следует стадия точных оценок.

326 Глава 10
Как только структура WBS будет разбита с учетом выделения самых нижних уровней,
может быть создан "статистический" показатель размера. При этом используются
процессы измерения и суммирования. Величина размера каждого компонента может быть
получена путем опроса экспертов, разрабатывавших подобные системы, либо путем
использования данных опроса потенциальных разработчиков подобных систем. В
результате становится возможной оценка размеров каждого блока на нижних уровнях
структуры WBS. После сложения результатов измерений полученный итог будет называться
оценкой размера "снизу-вверх". Улучшенная оценка может быть получена в том случае,
если каждый оценщик произведет оптимистическую, пессимистическую и
реалистическую оценку размеров. Затем формируется бета-распределение путем умножения
реалистической оценки размера на 4, добавления оптимистической и пессимистической
оценок с последующим делением результата на 6. Подобное взвешенное среднее значение
является удобным в условиях естественной неопределенности процесса оценивания.
Например, если данный оконный объект отображается в структуре WBS для системы,
поддерживающий код, который требуется для реализации процесса редактирования в
данном окне, может занимать от 200 до 400 строк кода, причем, скорее всего эта цифра
окажется более близкой к 200. Учитывая предложенные оценщиком пессимистические
и оптимистические сценарии, можно получить следующую итоговую оценку:
B00+B50х4)+400)/6 = 266 LOC
Количество тысяч строк исходного кода (KSLOC) является производным от общей
метрики, вводимой при оценках производительности. Обычно производительность
выражается в KSLOC/SM либо KLOC/SM (где SM - staff-month (человеко-часы)). Барри
Боэм (Barry Boehm), который является одним из наиболее титулованных
исследователей в этой области, на протяжении нескольких лет производил поиск наилучших
средств измерения продуктов с учетом корреляции трудозатрат и графика. Однако эти
поиски не увенчались успехом. Оценка LOG представляет собой универсальную
метрику, поскольку может применяться при создании любых программных продуктов.
Соображения по поводу оценок с помощью LOC
Подсчет строк существующего кода вручную является достаточно утомительным и
длительным занятием. В силу этого многие организации приобретают либо
разрабатывают автоматизированные LOC-счетчики. В этом случае могут возникать в
некоторой степени замысловатые вопросы относительно того, что же собой точно
представляет строка кода. Повторим, что, не имеет значения, каким образом определять
LOC в случае, если определение не является противоречивым. Приведенные ниже
рекомендации по выполнению необходимых подсчетов могут применяться на
протяжении многих лет, как для регистрации размера существующих программ, так и с
целью оценки размеров только разрабатываемых программ.
■ Убедитесь в том, что каждая учитываемая "строка исходного кода" содержит лишь
один оператор (если в одной строке содержатся два выполняемых оператора,
разделяемых точкой с запятой, то будут учитываться две строки; если же один
выполняемый оператор разбит на две "физические" строки, он будет учитываться как
один оператор). В языках программирования допускаются все опции
кодирования, но обычно проще определять в строке один выполняемый оператор,
обрабатываемый компилятором либо интерпретатором.
■ Учитывайте все имеющиеся выполняемые операторы— конечный пользователь
может не иметь возможности непосредственно использовать каждый оператор, но все
операторы должны поддерживаться данным продуктом (в том числе и утилитами).

Оценка размера и возможности повторного использования ПО 327
■ Определения данных учитывайте лишь один раз.
■ Не учитывайте строки, содержащие комментарии.
■ Не учитывайте отладочный код либо любой другой временный код (пробное ПО,
средства тестирования, инструменты разработки и прототипирования, а также
другие подобные средства).
■ Учитывайте каждую инициализацию, вызов либо включение (иногда называемое
директивой компилятора) макроса в качестве части исходного кода, в котором
осуществляется то либо иное действие (не учитывайте повторно используемые
операторы исходного кода).
■ Транслируйте количество строк исходного кода в эквивалентные строки языка
ассемблера, что даст вам возможность одновременно выполнять сравнительный
анализ для нескольких проектов.
Первый и второй столбцы из табл. 10.1 представляют метод трансляции SLOC,
применяемый в различных языках по отношению к среднему количеству строк SLOC
в базовом языке ассемблера. (Обратите внимание, что SLOC н LOC являются
взаимозаменяемыми.) Большинство менеджеров проектов предпочитают выполнять
трансляцию с языков программирования на базовый язык ассемблера по той простой причине,
что в этом случае операции сравнения во многих проектов могут производиться на
идентичной основе. Эти данные могут быть полезными также в случае трансляции
проекта с обычного языка программирования на язык преобразования. Например,
предположим, что операционная система, написанная на языке С и насчитьшающая 50000
строк LOC, будет преобразована в C++. Руководствуйтесь сведениями из табл. 10.1, где
базовый показатель SLOC языка С относительно языка ассемблера равен 2.5. Поэтому
операционная система, содержащая 50000 строк SLOC, написанных на С, будет
эквивалентной 125000 строкам в случае использования языка ассемблера E0,000 х 2.5). Если
же 125000 строк операционной системы на языке ассемблера были переписаны с учетом
использования языка C++, получим 125000/6, или 20,833 строк SLOC.
Оценка количества LOC по аналогии
Один из путей оценки размера программной системы, находящейся на стадии
проекта, заключается в сравнении ее функциональных свойств с уже существующими
аналогами. Представьте себе, что в вашем распоряжении имеется программный
компонент, модуль А, который будет преобразован в новую систему. Модуль А
оценивается показателем в 2345 LOC, и вы предполагаете, что новый модуль А будет более
эффективным (при сопровождении исходного модуля А вы продумали, каким образом
можно сделать код более компактным). Хотя при этом не следует забывать о том, что
в новый модуль будут добавлены некоторые дополнительные свойства. В результате
этого размер модуля А' оценивается с помощью показателя 3000 LOC.
Конечно данный метод не является самым точным, поскольку при написании
модуля А могли использоваться различные языки программирования, относящиеся к
разным областям приложений. Также могли применяться разнообразные алгоритмы,
имеющие различные уровень сложности, совместно с непроверенными
функциональными свойствами, а также с различной степенью моделирования реальности
(моделирование, эмуляция, реальное приложение).
Рассмотрим еще один пример: программа переходит с языка COBOL (не
используются технологии проектирования) на язык C++ (используется объектно-ориенти-

328 Глава 10
рованное проектирование). При этом размер программы уменьшается вследствие
лучшей проработки проекта, а набор функциональных свойств и качество
повышаются. Однако затраты на создание строки кода будут на Ю% выше. Неужели в данном
случае происходит падение производительности, как может показаться на первый
взгляд? Конечно, нет. На самом деле наблюдается рост производительности наравне с
улучшением набора функциональных свойств и обслуживания.
Таблица 10.1. Показатели SLOC при преобразовании кода с языка
программирования на язык Basic Assembler SLOC из расчета на одну
функциональную точку
Язык программирования Basic Assembler Средний показатель SLOC нэ расче-
SLOC (уровень) та на одну функциональную точку
Basic Assembler
Autocoder
Macro Assembler
С
Пакетные файлы DOS
Basic
Макросы LOTUS
ALGOL
COBOL
FORTRAN
JOVIAL
Смешанные языки
программирования (по умолчанию)
Pascal
COBOL (ANSI 85)
RPG
MODULA-2
PL/1
Параллельный Pascal
FORTRAN 95
BASIC (ANSI)
FORTH
LISP
PROLOG
LOGO
Расширенный общий LISP
RPG III
C++
1
1
1,5
2,5
2,5
3
3
3
3
3
3
3
3,5
3,5
4
4,5
4,5
4
4,5
5
5
5
5
5,5
5,75
5,75
6
320
320
213
128-150
128
107
107
105-106
105-107
105-106
105-107
105
91
91
80
80
80
80
71
64
64
64
64
58
56
56
53

Оценка размера и возможности повторного использования ПО 329
Продолжение табл. 10.1
Язык программирования
Basic Assembler Средний показатель SLOC нэ расче-
SLOC (уровень) та на одну функциональную точку
JAVA
УАСС
Ada 95
CICS
SIMULA
Языки баз данных
CLIPPER DB и dBase Ш
INFORMIX
ORACLEи SYBASE
Access
Dbase IV
FileMaker Pro
Языки поддержки принятия
решений
FOXPRO 2.5
APL
Статистические языки (SAS)
DELPHI
Стандартные объектно-
ориентированные языки
OBJECTTVE-C
Oracle Developer/2000
SMALLTALK
awk
EIFFEL
Shell-сценарии UNIX (PERL)
Стандартные языки 4-го
поколения DGL)
Application Builder
CORBA
Crystal Reports
Datatrieve
CLIPPER
Языки запросов баз данных
6
6
6,5
7
7
8
8
8
8
8,5
9
9
9
9,5
10
10
11
11
12
14
15
15
15
15
16
16
16
16
16
17
25
53
53
49
46
46
40
40
40
40
38
36
36
35
34
32
32
29
29
27
23
21
21
21
21
20
20
20
20
20
19
13-16
(Database Query Languages, SQL)

330 Глава 10
Окончание табл. 10.1
Язык программирования Basic Assembler Средний показатель SLOC нэ расче-
SLOC (уровень) та на одну функциональную точку
HTML 3.0 22 15
Information Engineering Facility 23 14
(IEF)/Information Engineering
Workbench (IEW)
EASYTRIEVE+ 25 13
SQL (ANSI) 25 13
Языки электронных таблиц 50 6
(EXCEL)
QUATTRO PRO 51 6
Языки создания пиктограмм 75 4
Преимущества при использовании LOC в качестве единиц измерения
Ниже перечислены преимущества, проявляющиеся при использовании строк кода
в качестве единиц измерения размеров ПО:
■ эти единицы измерения широко распространены и могут легко адаптироваться;
■ позволяют выполнять сопоставление методов измерения размеров и
производительности в различных группах разработчиков;
■ непосредственно связаны с конечным продуктом;
■ единицы LOC легко оцениваются еще до завершения проекта;
■ оценка размеров ПО производится на основе точки зрения разработчика —
физическая оценка созданного продукта (количество написанных строк кода);
■ действия по непрерывному улучшению базируются на оценочной технике —
спрогнозированный размер может быть легко сопоставлен с реальным размером в
ходе осуществления постпроектного анализа. (Насколько точной была оценка?
Что означает определенный процент? Что может быть изучено в рамках оценки
размера следующего проекта?).
Недостатки, связанные с применением метода LOC
При использовании показателя количества строк кода в качестве единиц
измерения проявляются следующие недостатки:
■ единицы измерения LOC затруднительны в применении при оценке размера ПО
на ранних стадиях жизненного цикла разработки;
■ исходные инструкции могут различаться в зависимости от типов языков
программирования, методов проектирования, стиля и способностей программиста;
■ применение методов оценки с помощью подсчета количества строк кода не
регламентируется промышленными стандартами (например, ISO);
■ разработка ПО может быть связана с большими затратами, которые прямо не
зависят от размеров программного кода — "фиксированные затраты", такие как
спецификации требований и пользовательские документы не включены в прямые
затраты на кодирование;

Оценка размера и возможности повторного использования ПО SS1
■ программисты могут быть незаслуженно премированы за достижение высоких
показателей LOC в случае, если служба менеджмента по ошибке посчитает это
признаком высокой продуктивности, но при этом будет отсутствовать
тщательно разработанный проект; исходный код не является самоцелью при создании
готового продукта — главную роль играют функциональные свойства и
показатели производительности;
■ при подсчете количества единиц LOC следует различать автоматический и
вручную созданный код — эта задача является более сложной, чем "простой
подсчет", который может быть выполнен на основе листинга, сгенерированного
компилятором, либо с помощью утилиты, выполняющей подсчет строк
программного кода;
■ показатели LOC не могут применяться при осуществлении нормализации в случае,
если применяемые платформы или языки являются различными;
■ единственный способ применения учета с помощью единиц измерения LOC по
отношению к разрабатываемому ПО заключается в использовании метода
аналогии на основе сравнения функциональных свойств у подобных программных
продуктов, либо в использовании мнений экспертов (однако, эти методы не относятся
к числу точных);
■ генераторы кода зачастую продуцируют чрезмерный объем кода, в результате чего
искажаются показатели LOC.
К сожалению, довольно часто производительность труда программистов
оценивается количеством производимых LOC. И если средняя производительность
программиста выросла с 200 LOC/месяц до 250 LOC/месяц, менеджер может прийти к
заключению относительно роста производительности. Это впечатление зачастую
является ложным, хотя в итоге будут поощряться те разработчики, которые
производят больше строк LOC из расчета на разработку проекта. Более правильным
будет награждать разработчиков не только за высокие показатели
производительности, а за качественный безошибочный код. При оценке качества может
применяться следующая формула:
количество дефектов/количество строк кода
Большая величина знаменателя будет свидетельствовать о высоком качестве кода.
Фаза кодирования в большинстве проектов обычно требует от 7% до 20% от общего
объема трудозатрат. И конечно, более важным является качество программного кода,
а не его объем.
Результатом подобных размышлений является осознание необходимости другой
единицы измерения. И в качестве такого метода может выступать метод
функциональных точек.
Использование функциональных точек
в качестве единиц измерения
Метод функциональных точек (Function point, FP) основывается на том, что
размер ПО лучше всего оценивать в терминах количества и сложности функций,
реализованных в данном программном коде, а не посредством количества строк кода.
Первая работа, посвященная использованию метода функциональных точек, увидела свет
в конце 70-х годов XX века. Автором этой работы был некий А.Дж. Альбрехт (A.J. А1-
brecht), представляющий фирму IBM. Его деятельность была связана с разработкой

332 Глава 10
систем, ориентированных на использование транзакций. Каперс Джонс (Capers
Jones) из фирмы Software Productivity Research, Inc расширил и обогатил идеи
Альбрехта, создав обширную и распространенную область знаний. В 1986 году была
сформирована некоммерческая группа, the International Function Point User Group
(IFPUG), в задачи которой входило распространение информации о методах
измерений и метрических показателях. В 1987 Британское правительство одобрило
использование модифицированного метода функциональных точек в качестве стандартного
метода измерения производительности. В 1994 году вышла в свет публикация, в
которой описывалась версия 4.0 IFPUG Standard Function Point Counting Practices Manual, a
также версия 1.0 IFPUG Standard Guidelines to Software Measurement.
При использовании метода функциональных точек измеряются категории
пользовательских бизнес-функций. При этом способ их определения является более методо-
логичным, чем в случае подсчета строк LOC. В этом случае уместно сравнить
программу с домом: площадь дома, выраженная в квадратных метрах, аналогична
применению единиц измерения LOC; количество спален и туалетных комнат в доме
аналогично применению в качестве единиц измерения функциональных точек. Ранее
применявшийся подход учитывал лишь размер ПО; нынешний подход учитывает
размер и функциональные свойства.
Метод функциональных точек позволяет выполнять следующие задачи:
■ оценивать категории пользовательских бизнес-функций;
■ разрешить проблему, связанную с попыткой применения единиц измерения LOC
на ранних стадиях жизненного цикла разработки;
■ определять количество и сложность входных и выходных данных, запросы к базе
данных, файлы либо структуры данных, а также внешние интерфейсы, связанные
с программной системой.
Ниже приводится краткий обзор процесса применения функциональных точек:
1. подсчитываются функции в каждой категории (перечень категории: вывод, ввод,
опросы, структуры данных и интерфейсы);
2. определяется сложность каждой функции — простая, средняя, сложная;
3. устанавливаются требования для каждой из категорий;
4. каждая функция умножается на соответствующий ей параметр, а затем
суммируется с целью получения общего количества функциональных точек;
5. производится преобразование функциональных точек в единицы измерения LOC
с помощью следующей формулы:
LOC = Функциональные точки х ADJ х множитель преобразования
Здесь аббревиатура ADJ обозначает настройку общих характеристик приложения.
Множитель преобразования основывается на статистических показателях для
приложения и языка программирования, представляя среднее количество строк кода,
применяемых для реализации простой функции. Какова же задача, выполняемая этим
параметром? Потребность в нем обосновывается тем, что большинство
автоматизированных инструментов, предназначенных для оценки трудозатрат, обычных затрат,
а также составления графика, нуждаются в использовании LOC в качестве входных
данных. А теперь опишем процесс использования метода функциональных точек
более детально.

Оценка размера и возможности повторного использования ПО 333
Соображения по поводу выполнения оценок с помощью метода функциональных точек
На рис. 10.4 продемонстрированы базовые шаги, выполняемые при оценке
размера с помощью метода функциональных точек; каждый из этих шагов в дальнейшем
будет описан подробнее. С каждым шагом продуцируется результат, используемый при
следующем шаге. В табл. 10.2 показаны процессы ввода, преобразования и вывода на
каждом шаге процесса учета с помощью метода функциональных точек.
Отображенный рабочий лист остается пустым и предназначен для использования в будущем.
Рис. 10.4. Базовые шаги анализа методом функциональных точек
Шаг 1. Подсчет функций в каждой категории
Общие указания
■ Учитывайте только функции, удовлетворяющие программным требованиям.
■ Учитывайте логические представления. Если в процессе ввода либо вывода
требуется другая обрабатывающая логика, каждое из подобных логических
представлений рассматривается как уникальная функциональная точка.
Оценка размера разрабатываемой системы непременно влечет за собой
выполнение исследования основных системных компонентов. При этом возникает множество
ноиросов. Каков объем выводимых данных? Насколько важны входные данные при
генерировании вывода? Каков объем хранимых данных?
Учитывайте количество элементов: вывод, ввод, опросы и файлы.
Предварительная архитектура обеспечивает основу для выполнения подобных действий. Некото-

334 Глава 10
рые предпочитают начинать с архитектуры в форме текстовых требований, однако
использование архитектуры в графической форме является весьма полезным.
Весовые множители, применяемые ко всем видимым внешним аспектам ПО,
представляют собой набор эмпирических констант, которые являются производными от данных
испытаний и ошибок.
Учет выводимых данных
В следующем перечне приводятся "советы", которые могут оказаться полезными
при подсчете выводимых данных.
■ Внешние выводы представляют собой данные, продуцируемые ПО с целью их
передачи за пределы системы.
■ Выводы представляют собой единицы деловой информации, которые
генерируются ПО и предназначены для конечного пользователя (ориентированы на
приложение).
■ В качестве примеров выводов могут служить экранные данные, отчетные данные,
сообщения об ошибках и т.д.
Таблица 10.2. Рабочий лист анализа по методу функциональных точек
Шаг 1. Подсчет количества функций в каждой категории
Шаг 2. Применение весовых множителей сложности
Простой Средний Сложный Функциональные точки
Количество выводов
Количество вводов
Количество опросов выводов
Количество опросов вводов
Количество файлов
Количество интерфейсов
Общее количество функциональных точек
Шаг 3. Применение факторов среды
Фактор среды Рейтинг @,1, 2, 3,4, 5)
Каналы передачи данных
Распределенные вычисления
Требования к производительности
Конфигурирование с ограничениями
Частота транзакций
Интерактивный запрос и/или запись
Эффективность на уровне конечного пользователя
Интерактивное обновление
Сложная обработка
_х5
_х4
_х5
_х4
_х10
_х7
_х7
_х6
_х7
_х6
_х15
_х10

Оценка размера и возможности повторного использования ПО 335
Окончание табл. 10.2
Повторное использование
Упрощение преобразования/установки
Упрощение операции
Используется на нескольких узлах
Потенциал изменения функции
Итого (N):
Шаг 4. Вычисление корректировочного множителя сложности (CAF)
CAF = 0,65 +@,01 xN) =
Шаг 5. Вычисление скорректированных функциональных точек (AFF)
AFP = ГР(исходное число) х CAF »
Шаг 6. Преобразование в строки LOC (дополнительно)
LOC = AFP x LOC/AFP
■ Учитывайте каждую уникальную единицу вывода, которая покидает область
приложения. Единица вывода будет уникальной в случае, если она имеет другой
формат и/или требует другой логики обработки.
■ Применяйте структурированные методы (глава 22) в случае, если вывод
представляет собой поток данных, сгенерированный ПО и предназначенный для
конечного пользователя. Количество выводимых данных, выходящих за пределы области
приложения, может быть легко подсчитано с помощью диаграммы
источников/приемников.
Каждый выводимый результат добавляется к одному из трех итоговых значений в
зависимости от сложности этого результата: итог для простых выводимых
результатов, итог для выводимых результатов средней сложности и итог для сложных
выводимых результатов. Такое разделение позволяет применить весовой множитель для
каждого из типов итога— сложный вывод требует больше усилий при создании по
сравнению со средним или простым выводом. Инструкции по определению уровня
сложности приведены в табл. 10.3.
Таблица 10.3. Весовые множители для вывода, применяемые при анализе
методом функциональных точек
От 1 до 5 элементов От 6 до 19 элементов 20 и более элемен-
данных данных тов данных
От 0 до 1 задейство- простой D) простой D) средний E)
ванного файла
От 2 до 3 задейство- простой D) средний E) сложный G)
ванных файлов
4 и более задейство- средний E) сложный G) сложный G)
ванных файлов

336 Глава 10
Подсчет вводов
При подсчете количества вводов учитывайте следующее.
■ Внешние вводы представляют собой данные, получаемые ПО из внешней для
системы области.
■ Вводы являются единицами деловой информации, вводимые пользователем при
использовании ПО с целью дальнейшей обработки или организации хранения.
■ Учитывайте каждую уникальную единицу ввода.
Как и в случае с выводами, вводы разделяются на простые, средние и сложные с
целью дальнейшего взвешивания. Инструкции по определению уровня сложности
приведены в табл. 10.4.
Таблица 10.4. Весовые множители для ввода, применяемые в анализе
функциональных точек
От 1 до 5 элементов От 6 до 19 элементов 20 и более элемен-
данных данных тов данных
От 0 до 1
задействованного файла
От 2 до 3
задействованных файлов
4 и более
задействованных файлов
простой D)
простой D)
средний E)
простой D)
средний E)
сложный G)
средний E)
сложный G)
сложный G)
Подсчет количества опросов (вывод/ввод)
При подсчете количества опросов имейте в виду следующее.
■ Внешние опросы представляют собой специфические команды или запросы,
которые выполняются ПО и генерируются извне. Любой интерактивный ввод
приводит к отклику со стороны ПО.
■ Опросы обеспечивают непосредственный доступ к базе данных, выполняющей
выборку указанных данных с помощью простых ключей в режиме реального
времени (требует немедленного отклика), но не выполняет функции обновления.
■ Учитывайте каждую уникальную единицу опроса. Опрос будет рассматриваться как
уникальный в одном из двух случаев:
— если его формат отличается от формата других порций ввода либо вывода;
— его формат совпадает с форматом ввода либо вывода, но требует логики
обработки, отличной от других опросов.
■ Опросы, относящиеся к различным порциям ввода и вывода, имеют различные
весовые множители сложности (это объясняется ниже).
■ Запросы не совпадают с опросами. Запросы обычно классифицируются в качестве
вводов либо выводов, поскольку они часто используют несколько ключей и
выполняют операции либо вычисления, применяя введенные данные.
Опросы разделяются на простые, средние и сложные. Инструкции по
определению уровня сложности приведены в табл. 10.5.

Оценка размера и возможности повторного использования ПО 337
Таблица 10.5. Весовые множители для опросов, применяемые в анализе
методом функциональных точек
Часть вывода (Примечание:
выберите большее значение — вывод
или ввод)
От 1 до 5
элементов данных
От 6 до 19 эле- 20 и более
элементов данных ментов данных
От 0 до 1 задействованного файла простой D)
От 2 до 3 задействованных файлов простой D)
4 и более задействованных файлов средний E)
простой D) средний E)
средний E) сложный G)
сложный G) сложный G)
Часть ввода (Примечание:
выберите большее значение — вывод
или ввод)
От 1 до 5
элементов данных
От 6 до 19 эле- 20 и более
элементов данных ментов данных
От 0 до 1 задействованного файла простой C)
От 2 до 3 задействованных файлов простой C)
4 и более задействованных файлов средний D)
простой C) средний D)
средний D) сложный F)
сложный F) сложный F)
Учет структур данных (файлы)
При подсчете структур данных (файлов) следует учитывать следующее:
■ внутренние файлы представляют собой логические файлы в составе программы;
■ структуры данных (ранее известные как "файлы") представляют собой первичную
логическую группу пользовательских данных, которые постоянно находятся
полностью внутри границ программной системы;
■ структуры данных доступны для пользователей с помощью ввода, вывода, опросов
либо интерфейсов.
Структуры данных делятся на простые, средние и сложные. Инструкции по
определению степени сложности приводятся в табл. 10.6.
Таблица 10.6. Весовые множители файлов в анализе методом
функциональных точек
Примечание: учитывайте логические От 1 до 9 От 20 до 50 51 и более
взаимосвязи, а не физические типы за- элементов элементов элементов
писей данных данных данных
1 логическая запись формат/взаимосвязь
От 2 до 5 логических записей типа
формат/взаимосвязь
6 и более логических записей типа
формат/взаимосвязь
простой G) простой G) средний A0)
простой G) средний A0) сложный A5)
средний A0) сложный A5) сложный A5)
Подсчет количества интерфейсов
При подсчете количества интерфейсов следует учитывать следующее:
внешние файлы представляют собой файлы, сгенерированные компьютером,
которые используются программой;

338 Глава 10
■ интерфейсы представляют собой данные (и систему управления), которые
хранятся за пределами программной системы при выполнении оценки;
■ структуры данных, разделяемые несколькими системами, учитываются в виде
интерфейсов и структур данных;
■ учитывайте каждый поток данных и управления в любом направлении в качестве
уникального интерфейса.
Интерфейсы делятся на простые, средние и сложные. Инструкции по
определению уровня сложности приведены в табл. 10.7.
Таблица 10.7. Весовые множители интерфейсов в анализе методом
функциональных точек
Примечание: учитывайте От 1 до 9 элемен- От 20 до 50 эле- 51 и более эле-
логические взаимосвязи, а не тов данных ментов данных меитов данных
физические типы записей
1 логическая запись фор- простой E) простой E) средний G)
мат/ взаимосвязь
От 2 до 5 логических записей простой G) средний G) сложный A0)
типа формат/взаимосвязь
6 и более логических записей средний G) сложный A0) сложный A0)
типа формат/взаимосвязь
Шаг 2. Применение весовых множителей сложности
■ Умножайте каждую величину определенного типа (простой, средний, сложный)
внутри каждой категории (вывод, ввод, опросы [вывод/ввод], структура данных
[файлы], интерфейсы) на соответствующий весовой множитель. Весовые
множители, приведенные в табл. 10.3-10.7 и отображенные в табл. 10.2, представляют собой
пробные временные интервалы, которые могут при необходимости изменяться.
■ В каждую категорию добавьте итоги. После этого результат выполнения шагов 1 и
2 будет выглядеть аналогично верхнему разделу табл. 10.10.
■ Обратите внимание, что итоговые результаты выражены количеством
"физических функциональных точек".
Шаг 3. Применение факторов среды
Скорректируйте общий итог по физическим функциональным точкам таким
образом, чтобы учитывать факторы среды, влияющие на процесс разработки ПО в целом.
Известно, что многие аспекты среды могут оказывать влияние на процесс разработки
программ. Некоторые из этих аспектов оказывают на проект положительное
влияние, другие же "качают весы" в отрицательном направлении; все они
рассматриваются с учетом их уникальности в применении к конкретному проекту.
В табл. 10.8 приводится детализованное определение каждого из 14 факторов
среды, либо оказывающих влияние множителей корректировки. Здесь же можно найти
инструкции по выбору веса фактора среды.
Ниже приводится краткое описание выполнение процесса взвешивания в среде.
Пиюльзуя материал табл. 10.8, оцените каждый фактор по шкале от 0 to 5 (в
данном случае 0 означает невозможность применения фактора). С целью получения
"эффекта присутствия" на одном из краев спектра оценивания, в табл. 10.9 приво-

Оценка размера и возможности повторного использования ПО 339
дятся примеры программных систем с высоким рейтингом — показатели рейтинга
от 4 до 5 на шкале.
Суммируйте рейтинги факторов (Fn) с целью вычисления итогового фактора
влияния среды (N).
N = sum (Fn)
Используйте рабочий лист анализа по методу функциональных точек из табл. 10.2
для записи значений. Обратитесь к табл. 10.10, чтобы увидеть, каким образом
выглядит шаг 3 на этапе занесения данных.
Таблица 10.8. Описание факторов среды при анализе методом
функциональных точек
Фактор среды
Рейтинг @,1, 2,3,4, 5)
Каналы передачи данных
Распределенные вычисления
Требования к производительности
Конфигурирование с ограничениями
Частота транзакций
Интерактивный запрос и/или запись
Эффективность на уровне конечного
пользователя
Интерактивное обновление
Сложная обработка
Повторное использование
Упрощение
преобразования/установки
Упрощение операции
Данные или контрольная информация, принимаемые
или получаемые через каналы передачи данных.
Интерактивные системы всегда испытывают некоторое
влияние со стороны каналов передачи данных
Приложение, использующее данные, которые
хранятся, обрабатываются и к которым обеспечивается
доступ в хранилище или системе обработки,
отличающихся от используемых в основной системе
Требования, одобренные пользователем, которые
были применены для получения высокой скорости
передачи данных либо малого времени отклика
Приложение, выполняемое с применением
интенсивно используемой, ограниченной или наполненной
конфигурации
Высокий сетевой трафик, перегруженность экранов
информацией и графикой, высокая частота
обновления экрана
Высокая степень интерактивности
Необходимо дополнительно учитывать человеческий
фактор
Динамическое обновление базы данных,
распределенные базы данных
Высокая степень безопасности, обработка со
множеством транзакций, сложные алгоритмы, логика,
управляемая прерываниями
Код, разработанный с целью повторного
использования, должен обладать высоким качеством
Процессы преобразования и установки требуют
наличия документов по планированию, которые были
протестированы
Эффективные, но простые процедуры запуска,
резервирования, восстановления при появлении ошибок, а
также завершения. Минимальное вмешательство со
стороны пользователя

340 Глава 10
Окончание табл. 10.8
Фактор среды
Рейтинг @,1,2,3,4,5)
Используется на нескольких узлах
Потенциал изменения функции
Учет различий в бизнес-функциях
Модульность, управляемость с помощью таблиц,
поддержка со стороны пользователей, возможности по
формированию запросов и т.д.
Шаг 4. Вычисление множителя корректировки сложности (САР)
Как упоминалось ранее в этой главе, Барри Боэм (Barry Boehm) постулировал, что
а ровспь неопределенности оценок является функцией фазы жизненного цикла.
Каперс Джонс (Capers Jones) поддерживает теорию эмпирических данных, согласно
которой максимальная степень влияния факторов среды на итоги анализа
функциональных точек может составлять +/- 35%. Причем рассматривается максимальная
< тепень влияния, поскольку анализ функциональных точек выполняется в начале
жизненного цикла. Как следствие, в этом случае существует максимальная
вероятность неточности измерений, как показано на рис. 10.2. С целью компенсации
подобной неопределенности в случае недостаточного уровня знаний множитель
корректировки сложности (CAF) будет применяться к итоговым значениям факторов среды.
Таблица 10.9. Факторы среды при анализе методом функциональных точек,
примеры высокопроизводительных систем
Фактор среды
Примеры высокопроизводительных систем
1. Сложные коммуникации
данных
2. Распределенная обработка
3. Цели, требующие достижения
максимальной
производительности
4. Интенсивно используемое
конфигурирование
5. Высокая частота транзакций
6. Интерактивный ввод данных
7. Проект, дружественный по
отношению к п< ■ дьзователю
Программа, предназначенная для международного
банка, которая выполняет денежные переводы из
финансовых учреждений, разбросанных по всему миру
Механизм поиска в Internet, при реализации которого
обработка выполняется несколькими десятками
компьютеров, работающими в параллельном режиме
Система контроля воздушного трафика,
поддерживающая точное и своевременное определение позиции
воздушного судна на основе показаний радиолокатора
Университетская система, реализующая одновременную
регистрацию нескольких сотен студентов, находящихся
в лаборатории
Банковская программа, выполняющая миллионы
транзакций за ночь с целью сведения баланса по всем книгам
на начало нового рабочего дня
Программа утверждения закладных, с помощью которой
клерки могут вводить данные в компьютерную систему в
интерактивном режиме, используя бумажные анкеты,
заполненные будущими домовладельцами.
Программное обеспечение для компьютеризованных
касс на станциях метро, оборудованных сенсорными
экранами, позволяющими покупать билеты с помощью
кредитных карточек

Оценка размера и возможности повторного использования ПО 341
Окончание табл. 10.9
Фактор среды
Примеры высокопроизводительных систем
8. Интерактивное обновление
данных
9. Комплексная обработка
10. Повторное использование
11. Облегченная установка.
12. Облегченное оперирование
13. Несколько узлов
14. Гибкость
Авиационная система, позволяющая агентам
туристических фирм заказывать авиарейсы и получать
информацию о наличии свободных мест. Это ПО должно
обеспечивать возможность блокировки и модификации
некоторых записей в базе данных с целью предотвращения
повторной продажи билетов на одни и те же места
Медицинское ПО, которое на основе различных
симптомов, выявленных у пациента, а также путем
обширного логического вывода позволяет устанавливать
предварительный диагноз
Рабочий процессор, который может быть
спроектирован таким образом, что его панели инструментов и меню
могут встраиваться в другие приложения, такие как
электронные таблицы или генератор отчетов
Приложение, выполняющее контроль оборудования, с
помощью которого даже неспециалист может
установить и настроить оборудование морской буровой вышки
Программа, предназначенная для анализа большого
количества хронологических финансовых записей,
которая должна оптимизировать обработку информации
таким образом, чтобы не вынуждать операторов
постоянно менять носители данных
ПО по поддержке платежных ведомостей для
транснациональной корпорации, которое должно учитывать
различные характеристики разнообразных стран,
включая различную валюту и правила определения налоговых
ставок
Программа финансового прогноза, которая может
формировать месячные, квартальные либо годовые
прогнозы, необходимые конкретному бизнес-менеджеру,
который может нуждаться в информации, разбитой по
географическим регионам и линиям продуктов
Источник: uww. ifpug. org.
CAP = 0.65 +@.01 xN)
где N является суммой взвешенных факторов среды.
Поскольку приходится иметь дело с 14 предполагаемыми факторами среды, каждый
из которых имеет вес, изменяющийся в диапазоне от 0 до 5, наименьшее значение для N
может быть 0 (ни один из 14 не применим); а наибольшее значение для N может быть 70
(каждый из 14 факторов имеет максимальный вес, равный 5). Исходя из этих граничных
условий, приходим к выводу, что минимум САР = 0.65 + @.01 х 0) = 0.65. Максимум САР =
0.65 + @.01 х 70) = 1.35. A.35 - 0.65 = 0.70) Ранняя оценка размеров и трудозатрат может
отклоняться при условии использования фактора на величину +/- 35%.
Шаг 4 проиллюстрирован в табл. 10.10.

342 Глава 10
В табл. 10.8 приводится предположение Джонса, касающееся факторов среды, но
вы можете определять собственные значения в случае, если будете ощущать, что
простой метод анализа функциональных точек является слишком обобщенным и
малопригодным для использования в данном случае. Однако лучше выбирать более
простые методы измерения, поскольку не стоит посвящать часть драгоценного времени
жизненного цикла разработки на изучение сложного метода измерения. Методы
измерения, как и другие качественные технологии программного инжиниринга,
должны ускорять нашу работу, а не замедлять ее.
Шаг 5. Вычисление скорректированных функциональных точек
Скорректированные функциональные точки (AFP) - физические функциональные
точки х САР
Шаг 5 рассматривается в табл. 10.10.
Шаг 6. Преобразование в строки LOC (дополнительно)
Метод функциональных точек обеспечивает способ предварительной оценки
размера потенциальных программ либо программных систем. При этом осуществляется
анализ будущих функциональных свойств с пользовательской точки зрения. Языки
программирования являются весьма различными с точки зрения их характеристик,
однако существует некое среднее количество выполняемых операторов, требуемых
для реализации одной функциональной точки. Преобразование функциональных
точек в строки LOC может потребоваться в силу следующих причин:
■ с целью измерения и сравнения производительности либо размера программ,
либо систем, которые были написаны на различных языках программирования;
■ с целью использования стандартных единиц измерения для осуществления ввода
данных в инструментальные средства оценки (глава 11);
■ для преобразования размера программы либо приложения, написанных на любом
языке программирования, в эквивалентный размер в случае приложения,
написанного на другом языке программирования.
Вплоть до завершения шагов 1-5 по отношению к данным может быть применено
достаточно точное преобразование, позволяющее перейти от функциональных точек к LOC.
Частичное преобразование "функциональные точки/язык" показано в табл. 10.10.
Здесь иллюстрируется преобразование функциональных точек в LOC (первый и третий
столбцы). В таблице перечислены далеко не все языковые преобразования, одобренные
11-TUG (этот перечень достаточно велик). Также следует отметить, что этот перечень
постоянно пополняется по мере разработки новых языков программирования.
I.OC = скорректированные функциональные точки х L0C на
скорректированную функциональную точку AFP х # L0C на AFP = L0C
Пример завершенного рабочего листа анализа функциональных точек приводится
птабл. 10.10.
Преимущества анализа методом функциональных точек
Ниже перечислены некоторые преимущества, проявляющиеся при использовании
функциональных точек в качестве единиц измерения ПО:
■ этот метод может применяться на ранних стадиях жизненного цикла разработки
программного обеспечения — размер ПО может определяться на фазе
выдвижения требований либо на фазе разработки проекта;
■ он не зависит от используемого языка программирования, технологии, а также
техники, исключая некоторые корректировки, выполняемые на заключительной стадии.

Оценка размера и возможности повторного использования ПО 343
Таблица 10.10. Пример рабочего листа анализа методом функциональных точек
Шаг 1. Подсчет количества функций в каждой категории
Шаг 2. Применение весовых множителей сложности
Простой Средний Средний Функциональные точки
Количество выводов 12x4-48 11x5-55 5x7-35 48 + 55+35-138
Количество вводов 8x3-24 9x4-36 6x6-36 24 + 36 + 36 = 96
Количество опросов 5 х 4 - 20 7 х 5 - 35 3 х 7 =21 20 + 35 + 21 = 76
Выводы
Количество опросов 5x3-15 8x4 = 32 4x6 = 24 15 + 32 + 24 = 71
Вводы
Количество файлов 12x7-84 3x10-30 2x15-30 84 + 30+30 = 144
Количество иитерфейсов 9 х 5 - 45 6 х 7 = 42 4 х 10 - 40 45 + 42 + 40 » 127
Итого (по функциональным точкам): 652
Шаг 3. Применение
Фактор среды
факторов среды
"физических"
' функциональных точки
Рейтинг @,1,2,
з,
4,
5)
Каналы передачи данных 5
Распределенные вычисления 5
Требования к производительности 3
Конфигурирование с ограничениями 0
Частота транзакций 5
Интерактивный запрос и/или запись 4
Эффективность на уровне конечного пользователя 5
Интерактивное обновление 4
Сложная обработка 2
Повторное использование 2
Упрощение преобразования/установки 3
Упрощение операции 4
Используется на нескольких узлах 5
Потенциал изменения функции 4
Итого (N): 51
Шаг 4. Вычисление корректировочного множителя сложности (CAF)
CAF = 0,65 + @,01 х N) = 0,65 + @,01 х 51) = 1,16
Шаг 5. Вычисление скорректированных функциональных точек (AFP)
AFP = FP (физические функциональные точки) х CAF = 652 х 1,16 = 756,32

344 Глава 10
Окончание табл. 10.10
Шаг 6. Преобразование в строки LOC (дополнительно)
Показатель LOC для языка С - AFP x LOC/AFP - 756.32 х 128 - 96,808.96 LOC
■ Метод функциональных точек обеспечивает надежную взаимосвязь с
затрачиваемыми усилиями (в случае, если вы сможете определить корректную функцию для
выполнения нужных измерений).
■ Создание дополнительных функциональных точек из расчета на час (неделю либо
месяц), является целью при достижении желательного уровня
производительности (в отличие от создания дополнительных строк LOC из расчета на час (неделю
либо месяц), что является не столь оправданным, пожалуй, даже парадоксальным).
■ Для пользователей эти единицы измерения могут быть более привычными.
При этом облегчается понимание степени влияния изменений
функциональных требований.
■ Может быть измерен уровень производительности проектов, написанных на
различных языках программирования.
■ Функциональные точки обеспечивают механизм, позволяющий выполнять
отслеживание и мониторинг "сползания" области видимости. Функциональные точки
могут учитываться часто и на ранних этапах — результаты подсчета
функциональных точек могут сравниваться в конце этапов формирования требований,
проведения анализа, разработки проекта, а также внедрения. Если количество
функциональных точек увеличивается при каждом подсчете, это означает, что проект
был лучше определен либо размер проекта был увеличен (это довольно опасно,
если только график и/или средства будут перераспределены).
■ Функциональные точки могут использоваться в системах, в которых реализован
графический пользовательский интерфейс (GUI), в клиент-серверных системах, а
также при объектно-ориентированной разработке.
■ Функциональные точки могут учитываться как пользователями высшего уровня
(клиентами или заказчиками), так и простыми техниками.
■ Учитываются факторы среды.
Так же, как и в случае с моделями определения размеров и оценивания, может
выполняться адаптация и калибровка. Могут учитываться способы применения весов, а
также факторы среды, которые в целом являются изменяемыми. Например, в
промышленности полупроводников в случае, когда физические модули тестируются с
применением ПО, компоненты устройств могут учитываться вместо вводов и выводов.
Недостатки анализа методом функциональных точек
Ниже перечислены недостатки метода функциональных точек.
■ Используются субъективные оценки, вследствие чего возможны судебные
разбирательства.
■ Получаемые результаты зависят от технологии, используемой для их реализации.
■ Многие модели затрат и трудозатрат зависят от показателя LOG, поэтому
приходится преобразовывать функциональные точки.

Оценка размера и возможности повторного использования ПО 345
■ Требуются дополнительные исследования данных на базе LOG, отличные от
исследований в случае данных, основанных на функциональных точках.
■ Этот метод лучше применять после создания спецификации дизайна.
■ Данный метод не очень хорошо подходит в случае с приложениями, не
относящимися к классу MIS-приложений (в этом случае используйте точки свойств).
Табл. 10.1 представляет другой пример, в котором существующая программа
может проверяться с целью подсчета количества функциональных точек. Например,
если в вашем распоряжении имеется приложение, состоящее из 500 строк SLOG на C++,
то исходя из этой таблицы, можно сделать вывод что в данном случае имеется 6 х 500
- 3000 функциональных точек. Данная техника, именуемая "обратным огнем", может
использоваться для создания приближенной оценки размеров целого набора
приложений. Этот набор может выступать в виде интенсивно используемой
хронологической базы данных, которая может применяться при оценке будущих проектов, а
также для моделей калибровки размеров и оценки.
Какое количество функциональных точек должно содержаться в системе, чтобы
она считалась очень большой? Некоторые крупномасштабные военные приложения
содержат примерно 400000 функциональных точек, полная система SAP/R3 — 300000
функциональных точек, Windows 98 включает примерно 100000 функциональных
точек, and MVS фирмы IBM тоже около 100000 функциональных точек. Фирма Software
Productivity Research, Inc., сгенерировала эти данные на основе своей базы данных,
включающей 8500 проектов из более чем 600 организаций.
Использование точек свойств в качестве единиц измерения
Метод точек свойств представляет собой расширение метода функциональных
точек, применяемого для измерений в приложениях различного типа, даже таких, как
встроенные системы и/или системы реального времени. В 1986 году компания Software
Productivity Research адаптировала метод анализа точек свойств в отношении
системного ПО. Чистые подсчеты по методу функциональных точек, выполненные по
отношению к ПО, которое не принадлежит классу MIS, могут давать неправильные результаты.
Это связано с тем, что приложения, как правило, неоднородны и могут иметь большую
степень алгоритмической сложности, но при этом обладать простыми внешними
вводами/выводами. Точка свойства представляет собой новую категорию функции,
которая может представлять сложные алгоритмы и управление (возбуждение/отклик).
Сложность алгоритма определяется в терминах количества "правил", необходимых для
выражения алгоритма. Точки свойств обычно применяются в следующих случаях:
■ ПО, функционирующее в режиме реального времени, например, системы ПРО;
■ системное ПО (например, операционные системы и компиляторы);
■ встроенное ПО, например, пакеты навигационных радаров или микропроцессоры
автомобильных подушек безопасности;
■ инженерные приложения, например, системы автоматизированного
проектирования (САПР), автоматизированного производства (АЛ), а также математическое ПО;
■ системы искусственного интеллекта (ИИ);
■ ПО, предназначенное для поддержки телекоммуникаций (например, системы
поддержки телефонных коммуникаций);
■ ПО, выполняющее функции контроля над процессами (например, управление
автоматизированными нефтеперегонными заводами).

346 Глава 10
Точки свойств, по сути, являются функциональными точками, но в отличие от
последних они лучше адаптированы к высокой сложности алгоритмов. В данном случае
под алгоритмом подразумевается связанный набор правил (выполняемых операторов),
требуемых для решения вычислительных проблем.
Инструкции по подсчету с помощью точек свойств
На рис. 10.5 демонстрируются базовые шаги, выполняемые при подсчете с помощью
точек свойств; каждый из этих шагов будет подробнее описан в дальнейшем. Рабочий
лист, применяемый при реализации метода точек свойств, приведен в табл. 10.11.
Шаг 1. Подсчет с помощью точек свойств
Этот шаг аналогичен шагу, выполняемому при подсчете функциональных точек, —
учитываются вводы, выводы, файлы (структуры данных), опросы и интерфейсы.
Заполненный рабочий лист (табл. 10.13), применяемый при методе точек свойств,
служит примером, иллюстрирующим каждый из семи упомянутых шагов.
Шаг 2. Продолжение подсчета с помощью точек свойств путем учета количества алгоритмов
Любой алгоритм представляет собой связанную вычислительную проблему,
которая включена в состав конкретной программы.
Значимые и исчисляемые алгоритмы могут разрешать определенные и в
принципе решаемые связанные проблемы, для которых существует одна точка входа и
одна точка выхода.
Разработчики, которые на этапе разработки проекта часто имеют дело со схемами
информационных потоков либо со структурными диаграммами, сравнивают
алгоритмы со спецификациями базового процесса либо модуля.
Шаг 3. Сложность взвешивания
Используйте "средние" веса вместо простых, средних либо сложных (обратите
внимание, что понятие "средний" для точек свойств отличается от "среднего" в
случае с функциональными точками) для вводов, выводов, файлов (структур данных),
опросов и интерфейсов. При взвешивании алгоритмов применяются простые,
средние и сложные множители.
Средний фактор сложности для "файлов" уменьшается с 10 до 7, что отражает
уменьшение значимости логических файлов по сравнению с ПО, предназначенным
для выполнения интенсивных вычислений.
По умолчанию весовой множитель для алгоритмов равен 3. Это значение может
варьироваться в диапазоне от 1 до 10. Алгоритмам, использующим базовые
арифметические операции и некоторые правила принятия решений, присваивается
значение 1. Алгоритмам, в состав которых включены сложные уравнения, матричные
операции и сложная логическая обработка, назначается значение 10. Значимые
алгоритмы, которые должны быть исчисляемыми, имеют следующие характеристики:
■ представлять решаемую, связанную и определенную проблему;
■ обладать свойством конечности;
■ быть точным и однозначным;
■ иметь ввод или начальное значение;
■ иметь вывод или продуцировать результат;
■ являться реализуемым — каждый шаг может выполняться на компьютере;
■ обеспечивать возможность представления с помощью одной из стандартных
программных конструкций: последовательность, конструкция if-then-else, do-
case, do-while и do-until.

Оценка размера и возможности повторного использования ПО 347
4t ^.Преобразование
J£^BBtWHAwtOC •
Рис. 10.5. Основные шаги анализа методом точек свойств
Таблица 10.11. Рабочий лист анализа методом точек свойств
Шаг 1. Подсчет количества точек свойств
Количество шюдон
Колнчес 1 во выводов
Количество файлов (структуры данных)
Количег гво опросов
Количество интерфейсов
Среднее значение
х4
х5
х7
х4
х7
Точки свойств

348 Глава 10
Окончание табл. 10.11
Шаг 2. Подсчет количества алгоритмов
Среднее значение Точки свойств
Количество алгоритмов xS
Итого по точкам свойств:
Шаг 3. Сложность взвешивания
Шаг 4. Оценка факторов среды
Шаг 5. Вычисление фактора корректировки сложности (CAF)
Логические значения (выбор одного из них)
1 !]имтые алгоритмы и вычисления — 1
Во чмпинство простых алгоритмов — 2
Алгоритмы средней сложности — 3
J kh'o торые сложные алгоритмы — 4
Многие сложные алгоритмы — 5
Значения данных (выбор одного из них)
J Ipot-тыс данные — ]
li !i лешие переменные, но простые взаимосвязи — 2
I Ь( колько полей, файлов и интерактивных взаимодействий — 3
< южные файловые структуры — 4
; >киъ сложные файлы и взаимосвязи между данными — 5
Итого по CAF:
Шаг 6
Умножение физического количества точек свойств
Физические FI' x CAF =
Шаг 7
I 1 >С -
Преобразование в
\ГР х LOC/AFP -
У
строки кода (дополнительно)
на
САГ:
Шаг 4. Оценка факторов среды
Нмссто 14 факторов среды (как в случае с анализом функциональных точек), в
данном случае используются лишь два фактора: сложность логики и сложность данных.
Диапазон значений варьируется от 1 до 5.
Логические значения
1. простые алгоритмы и вычисления;
2. большинство простых алгоритмов;

Оценка размера и возможности повторного использования ПО 349
3. алгоритмы средней сложности;
4. некоторые сложные алгоритмы;
5. многие сложные алгоритмы.
Значения данных
1. простые данные;
2. числовые переменные, но простые взаимосвязи;
3. несколько полей, файлов и интерактивных взаимодействий;
4. сложные файловые структуры;
5. очень сложные файлы и взаимосвязи между данными.
При суммировании факторов сложности логики и данных получаем значения,
находящиеся в диапазоне от 2 до 10.
Шаг 5. Вычисление фактора корректировки сложности
Воспользуйтесь табл. 10.12 для вычисления фактора корректировки сложности.
Таблица 10.12. Фактор корректировки сложности метода точек свойств
Сумма степеней сложности логики и данных Фактор корректировки сложности
2
3
4
5
6
7
8
9
10
0,6
0,7
0,8
0,9
1,0
1,1
1,2
1.3
1.4
Шаг 6. Результат умножения физического количества точек свойств на фактор корректировки
сложности
Шаг 7. Преобразование в количество строк кода с помощью таблицы преобразования
функциональных точек (дополнительно)
Таблица 10.13. Пример рабочего листа анализа точек свойств
Шаг 1. Подсчет количества точек свойств
Количество вводов
Количество выводов
Количество файлов (структуры данных)
Количество опросов
Количество интерфейсов
Среднее значение
12x4
15x5
22x7
17x4
8x7
Точки свойств
48
75
154
68
56

350 Глава 10
Окончание табл. 10.13
Шаг 2. Подсчет количества алгоритмов
Среднее значение Точки свойств
Количество алгоритмов 43 х 3
129
Итого по точкам свойств: 530 "физических" точек свойств
Шаг 3. Сложность взвешивания
Шаг 4. Оценка факторов среды
Шаг 5. Вычисление фактора корректировки сложности (CAF)
Логические значения (выбор одного из них)
Простые алгоритмы и вычисления — 1
Большинство простых алгоритмов — 2
Алгоритмы средней сложности — 3
—> Некоторые сложные алгоритмы — 4
Многие сложные алгоритмы — 5
Значения данных (выбор одного из них)
Простые данные — 1
Числовые переменные, но простые взаимосвязи — 2
-■. Несколько полей, файлов и интерактивных взаимодействий—3
Сложные файловые структуры — 4
Очень сложные файлы и взаимосвязи между данными — 5
Итого по CAF: 4 + 3 ■ 7 Фактор корректировки сложности
Шаг 6. Умножение физического количества точек свойств на CAF:
Физические FP x CAF » 530 х 7 » 3710 скорректированных точек свойств
Шаг 7. Преобразование в строки кода (дополнительно)
LOC для языка Java = AFP x LOC/AFP = 3710 х 53 = 196630 LOC
Преимущества анализа методом точек свойств
Анализ точек свойств обеспечивает те же самые преимущества, что и анализ
функциональных свойств. Причем при этом обеспечивается улучшенный подход к
использованию оценки размера алгоритмически насыщенных систем.
Недостатки анализа методом точек свойств
Основным недостатком анализа точек свойств является субъективный подход к
классификации алгоритмической сложности.

i
j
Оценка размера и возможности повторного использования ПО 351
Метод объектных точек
Подход с использование подсчета "объектных точек" для определения размера
ПО позаимствован из объектно-ориентированной технологии. При использовании
этого подхода оценка выполняется на более обобщенном уровне, чем в случае с
функциональными точками. В данном случае каждому уникальному классу или объекту
(экран, выводимый отчет и т.д.) назначается одна объектная точка. В остальном этот
метод подобен методу функциональных точек и точек свойств, лишь следует учесть,
что применяются различные факторы преобразования.
Блиц-модель
Оценка, выполняемая на каждой фазе проекта, будет более качественной в случае,
если доступен больший объем исходных данных. Влияние исходных знаний особенно
хорошо заметно на стадии анализа и проектирования, на которых обычно
формируются модели (глава 22). Здесь особенно хорошо заметно, что от количества
начальных данных зависит точность оценки размера ПО. Еще до того, как будет достигнута
текущая стадия проекта, могут оказаться весьма полезными некоторые модели
высокого уровня, созданные на фазе планирования. Эти модели могут применяться в
качестве быстрого и простого метода оценки размера ПО.
Концепция блиц-моделирования основана на банг-метрике, предложенной Томом
Де Марко (Tom DeMarco). В этом случае грубые оценки размера программного кода
определяются путем подсчета компонентных частей системы (элементов дизайна) и
дальнейшим умножением результата на множитель производительности (как
правило, этот множитель определяется на основе хронологических данных и определяет
количество строк процедурного кода, необходимых для реализации алгоритма).
Например, если данные высокого уровня в схеме последовательности операций
либо в объектных моделях генерируются в качестве части исследования концепции или
планирования, их компоненты могут быть просмотрены на предмет их размера.
Представьте себе, что 20 классов объектов и их характеристики получаются путем
наблюдения существующих систем и реализованы как средние величины в качестве
пяти процедурных программ из расчета на один класс. Также путем наблюдения за
существующими системами стало известно, что средний размер процедурной
программы (язык С) равен 75 LOC. Затем размер может быть быстро вычислен
следующим образом:
Количество процессов (классы объекта) х количество программ из расчета
на класс х размер средней программы - расчетный размер
20 классов объекта х 5 программ на класс х 75 строк L0C на программу =
7500 вычисленных L0C
Приведенные выше выкладки известны как "блиц", примененный по отношению к
документам, созданным на ранних стадиях. Компоненты любой модели ("пузырьки"
процесса, потоки данных, репозитории данных, сущности, взаимосвязи, объекты,
атрибуты, службы и т.д.) могут умножаться на множитель, который вычисляется как
результат выполнения предыдущих проектов. А теперь рассмотрим другие примеры.
Если известно, что каждый "пузырек" процесса на уровне 0 DFD приблизительно
соответствует четырем фактическим программам на языке SQL, а также известно, что
средний размер программ в библиотеке SQL равен 350 строкам LOC, поэтому
простое умножение будет достаточным для подсчета начального размера. Известно, что в
данном случае существует семь основных "пузырьков" процесса:

352 Глава 10
■л!ичество процессов ("пузырьки" DFD) х количество программ на
"пузырек" х размер средней программы = вычисленный размер
".' "пузырьков" х 4 программы на "пузырек" х 350 строк LOC на программу
; 9Н00 вычисленных строк LOC
Если глобальная модель высокого уровня продуцируется на этапе определения
времени выполнения, а на основе исторического опыта известно, что каждая служба
соответствует двум программам на языке C++, а стандарты компании ограничивают
каждый размер служебного пакета величиной в 100 строк LOC и менее, приведенная
ниже формула обеспечивает хорошую начальную базу для оценивания размера
систем, выраженного в количестве строк LOC:
'lumber of services x 2 х 100
В данном случае ключевой является фраза "на базе исторического опыта". База
данных, содержащая данные за достаточно долгий период времени, является весьма
важной в деле повышения точности оценки. При этом база данных должна содержать
запись, соответствующую фактическому размеру каждого программного компонента.
Объем трудозатрат, понесенных на создание компонента данного размера, также
должен отслеживаться. По мере роста количества точек данных, улучшается степень
соответствия среднего количества строк LOC из расчета на программу со средним
обьемом трудозатрат, понесенных при создании компонента. Как только станут
известными размеры фактических компонентов и величины объемов соответствующих
усилий, затраченных на этапе разработки, становится известной также средняя
"производительность" (размер/трудозатраты).
Согласно предложениям Де Марко, при использовании банг-метрики системы,
использующие множество функций (в том числе и системы реального времени),
должны оцениваться отдельно от систем, обрабатывающих большие объемы данных. При
оценке функционально богатых систем в качестве базисных значений используется
количество неделимых функциональных примитивов, как определено с помощью
схемы информационных потоков. Системы, обрабатывающие большое количество
данных, в качестве базисных значений используют количество объектов в модели
данных, глобальных на системном уровне. При этом также применяются весовые
множители (Weighting factor, WF).
Ниже приводится пример функционально богатой системы: множитель WF
(среднее количество модулей, требуемых для завершения функции) равен трем,
количество процессов плюс спецификации контроля (функции) равно восьми, а средний
размер одной функции равен 78 LOC. Затем воспользуемся следующей формулой:
WF х (количество процессов и спецификаций контроля) х среднее
количества LOC для данного модуля = LOC
3 модуля, требуемые для функции х 8 функций х 78 L0C = 1,872 LOC
Чем же все это отличается от анализа методом функциональных точек,
представленного на фазе определения области осуществимости? Менеджер проекта может
выбрать выполнение анализа точек свойств во время фазы определения области
выполнения, когда существуют только модели высокого уровня, такие как DFD уровня
содержимого. Затем полученная оценка улучшается на фазе планирования, когда доступен
больший объем знаний о проекте и дополнительная документация, например DFD
уровня О наравне с DFD уровня 1 для некоторых из основных подсистем. Любые из этих
моделей могут применяться на протяжении любой фазы. Если они применяются
последовательно, повышается ожидаемая точность измерений и получения оценок.

Оценка размера и возможности повторного использования ПО 353
Преимущества блиц-модели
Ниже перечислены некоторые из преимуществ, обеспечиваемые методом блиц-
модели.
■ Облегчается использование структурных систем (схемы информационных
потоков, диаграммы взаимосвязи сущностей) совместно с объектно-ориентированными
классами, службами и т.д.
■ Повышается степень точности при использовании хронологических данных.
■ Действия по непрерывному улучшению используются при реализации техники
оценки. Оцененный размер может быть легко сопоставлен с фактическим
размером при выполнении постпроектного анализа. (Насколько точной была оценка?
Каков процент возможного отклонения? Что потребуется освоить при оценке
размера следующего проекта?)
Недостатки блиц-модели
Ниже перечислены недостатки блиц-модели.
■ Требуется использование методологии дизайна.
■ Оценка не может начинаться до завершения разработки дизайна.
■ Требуются хронологические данные.
■ Не могут оцениваться факторы среды.
Метод оценивания Wideband Delphi
Еще одним популярным и простым методом, применяемым при оценке размера
ПО и величины трудозатрат, является сбалансированный подход, разработанный
группой Wideband Delphi. Техника Delphi изначально была разработана в Rand
Corporation; само название позаимствовано из греческой мифологии (знаменитый
Оракул в Дельфийском храме). Этот метод был успешно использован в корпорации Rand
с целью прогнозирования развития большинства технологий в мире.
Этот метод основывается на использовании опыта многих экспертов с целью
выполнения оценки, которая отражает всю сумму их знаний.
В среде разработчиков ПО исходный подход Delphi был модифицирован.
"Чистый" подход используется при сборе изолированных мнений экспертов,
обратной связи, в ходе реализации которой отсылаются анонимные итоговые результаты,
а также при выполнении итераций до тех пор, пока не будет достигнут консенсус (без
проведения групповых дискуссий).
Инструкции по достижению консенсуса согласно модели группы
Wideband Delphi
Поскольку реализация подхода Delphi требует очень больших затрат времени,
разработанная концепция Wideband Delphi предназначалась для ускорения этого
процесса. Улучшенный подход использует групповые дискуссии.
Шаги по достижению консенсуса согласно модели Wideband Delphi
Достижение консенсуса в рамках модели Wideband Delphi требует реализации
шести основных шагов:
1. представление проблемы и ответной формы на рассмотрение экспертов;

354 Глава 10
2. проведение групповой дискуссии;
3. анонимный сбор мнений экспертов;
4. обратная связь по сводке результатов с каждым экспертом;
5. поддержка других групповых дискуссий;
6. выполнение итераций (при необходимости) до тех пор, пока не будет достигнут
консенсус.
Основное отличие между "чистым" методом Delphi и Wideband Delphi
заключается в том, что в последнем случае проводятся групповые дискуссии. Сводка по
результатам, достигнутым на шаге 4, представлена на рис. 10.6.
Название проекта: _ _
Дата:
Оценка диапазона размеров из предыдущего периода оценки
Ваша Средняя
оценка оценка
5,500 L0C 8,000 LOC
5,000 6,000 7,000 8,000 9,000 10,000 11,000 12,000
Пожалуйста, укажите вашу оценку
для следующего периода либо состояние,
которое является причиной остающейся предыдущей оценки
Рис. 10.6. Сводная форма результатов оценки размеров ПО по методу Delphi
Ниже представлен другой взгляд на процесс Wideband Delphi.
Опросите нескольких экспертов (обычно их число варьируется от трех до пяти).
Включите их опыт во все области "риска"— область приложения, язык
программирования, алгоритмы, целевое аппаратное обеспечение, операционные
системы и т.д.
Организуйте встречи с экспертами для обсуждения вопросов и объяснения
деталей функционирования ПО. Подготовьте спецификации, другие исходные
документы, структуру WBS и т.д. Позвольте им дополнить все это собственной
информацией и вопросами. Пусть каждый из них сделает свои замечания.
Попросите каждого эксперта выполнить свою оценку, включающую
минимальный, ожидаемый и максимальный рейтинг. Разрешите им оставаться
независимыми и анонимными.
Запишите анонимные оценки в виде графа.
Встретьтесь с каждым экспертом и позвольте ему высказать в дискуссии мнение
относительно его оценки, допущениях и причинах выполнения подобной оценки.
Найдите консенсус по поводу допущений. Это отразится на элементах действия,
выполняемых с целью получения фактических данных.
Если возможно, выполните оценку достижения консенсуса.

Оценка размера и возможности повторного использования ПО 355
■ Если консенсус не был достигнут, прервитесь до тех пор, пока не сможете
получить доступ к дополнительным данным; затем повторите.
■ Прекратите повторение в случае, если достигнете консенсуса, либо на
протяжении двух последовательных циклов не будет внесено больших изменений, а также
не будет появляться значительный объем свободных дополнительных данных
(с которыми можно будет согласиться либо нет). В итоге будет достигнут консенсус
при оценке ожидаемого значения. Также при выполнении оценки должен
учитываться максимальный и минимальный объем возможной конфиденциальности.
Преимущества модели Wideband Delphi
Ниже перечислены преимущества модели Wideband Delphi:
■ простая и недорогая реализация на практике;
■ экспертиза проводится несколькими специалистами в своей области;
■ все участники обсуждения повышают свою квалификацию в области
рассматриваемого ПО;
■ не требуются хронологические данные, хотя они могут применяться в случае их
доступности;
■ используется на высшем уровне и при выполнении детализированной оценки;
■ результаты будут более точными и менее "опасными", чем в случае использования
оценки по методу LOC;
■ обеспечивается поддержка глобальной точки зрения на проект со стороны членов
команды.
Недостатки модели Wideband Delphi
Ниже перечислены недостатки модели Wideband Delphi:
■ затруднительная повторяемость различными группами экспертов;
■ существует вероятность достижения консенсуса для некорректной оценки.
Поскольку вы "все выкупили", вы не сможете быть достаточно критичными в случае,
если фактические данные будут выглядеть некорректными;
■ вас может посетить ложное чувство самоуверенности;
■ иногда вы не сможете достичь консенсуса;
■ все эксперты могут работать в одном и том же направлении.
Влияние эффектов повторного
использования на размер ПО
Многие программы происходят от предыдущих версий этих же программ. В
результате может быть достигнута экономия средств и/или времени, а также возрасти
уровень качества. Однако при повторном использовании могут расходоваться
дополнительные средства и время, а уровень качества будет низким.
Повторному использованию подлежат: код, тестовый код, тестовые условия,
тестовые процедуры, документация, дизайн, спецификации дизайна, спецификации
требований и т.д.

356 Глава 10
Терминология повторного использования
■ Новый код — это код, разработанный для нового приложения, который не
включает большие порции ранее написанного кода.
■ Модифицируемый код— это код, разработанный для предыдущих приложений,
который становился пригодным для использования в новым приложениях после
внесения умеренного объема изменений.
■ Повторно используемый код — это код, разработанный для предыдущих
приложений, который будет пригодным для новых приложений без внесения каких-либо
изменений.
■ Наследственный код — это код, разработанный для предыдущих приложений,
использование которого ожидается новым приложением.
Почему же код считается "модифицируемым" в случае, если он будет подвергаться
лишь незначительным изменениям? Код, повторно используемый, в полном объеме,
имеет идентичную документацию, идентичные тестовые процедуры и код, но лишь
одну копию с целью поддержки библиотеки менеджмента конфигурирования. Даже
если изменяется единственная строка комментария, две копии кода, тестовый код,
документация и прочее должны поддерживаться в библиотеке управления
конфигурированием. Если изменяется лишь одна строка исполняемого кода, подвергается
изменению тестовый код и документация.
При использовании наследственного кода имейте в виду, что он может быть
снабжен документацией плохого качества, могут отсутствовать тестовый код либо
процедуры. Для этого кода может отсутствовать тщательно проработанный проект, и он
может не отвечать стандартам качества.
Первый этап при оценке систем, которые могут повторно использовать код,
заключается в отделении нового кода от модифицируемого и повторно используемого
кода. Это необходимо по той причине, что модифицируемый и повторно
используемый код практически никогда не может быть использован непосредственно, — для
выполнения интеграции этого кода требуются некоторые изменения, в результате
чего возрастает размер кода и объем трудозатрат, требуемых для реализации
подобных изменений. Соответствующий пример приводится в табл. 10.14.
Таблица 10.14. Разделение новых, модифицируемых и повторно
используемых строк кода
Элемент LOC для нового LOC для модифи- LOC для повторно Итого по
кода цируемого кода используемого кода LOC
Компонент 1 1233 0 0 1233
Компонент 2 0 988 0 988
Компонент 3 0 0 781 781
Компонент 4 560 245 0 805
Компонент 5 345 549 420 1314
Итого 2138 1782 1201 5121
А теперь возникает вопрос о том, как можно узнать, в какой степени компонент
может быть модифицируемым или повторно используемым? Обратимся к компонен-

Оценка размера и возможности повторного использования ПО 357
там 4 и 5 в табл. 10.15. Правило "большого пальца" говорит о необходимости
проверки наименьшего уровня, известного для единицы либо модуля (обычно около 100
строк LOG). Если единица в целом не была изменена, она может "повторно
использоваться". Если единица была изменена (пусть даже речь идет об одном комментарии
или выполняемом операторе), она является "модифицируемой". Если более чем 50%
кода единицы было изменено, рассматривайте ее как "новую". Кроме того, как только
модифицируемый код был идентифицирован, его можно разбить на категории,
представляющие тип модификации. Широко используемый подход заключается в том,
чтобы отделять модификации, предназначенные для корректировки дефектов, от
модификаций, направленных на добавление расширений. Как видно, табл. 10.14 и
10.15 весьма похожи за исключением одного выполненного разделения.
Таблица 10.15. Различные типы модифицируемого кода
Элемент LOC для Модифициров Модифициро- LOC для no-
нового ано для устра- вано с целью до- вторно исполь-
кода нения ошибок бавлеяия рас- зуемого кода
ширений
Компонент I
Компонент 2
Компонент 3
Компонент 4
Компонент 5
Общее
количество
произведенных LOC
1233
0
0
560
345
2138
0
988
0
0
302
1782
0
0
0
245
247
1782
0
0
781
0
420
1201
1233
988
781
805
1314
5121
После завершения оценки общего объема разработанного программного кода
повторно используемый код будет преобразован в "эквивалентный" новый код. В ходе
процесса преобразования ставится цель минимизировать объем трудозатрат при
внедрении повторно используемого или модифицируемого кода по сравнению с
внедрением нового программного кода. Обычно определяется множитель преобразования с
целью отражения количества трудозатрат, сэкономленных при повторном
использовании кода. Предполагая наличие хронологического выравнивания множителей
преобразования, можно заключить, что в этом случае выполняется простая калькуляция.
Возвращаясь к примеру из табл. 10.16, можно применить множители повторного
использования, свидетельствующие о том, что при внедрении повторно используемого
ПО экономится примерно 70% трудозатрат по сравнению с внедрением нового ПО.
При использовании модифицируемых программ экономия составляет примерно 40%.
Это говорит о том, что объем трудозатрат, требуемых при написании 5121 строк
повторно используемого, модифицируемого и нового кода эквивалентен объему
трудозатрат в случае написания 3567 строк нового кода.
Множители повторного использования вычисляются на основании опыта.
Множители, равные 30% (трудозатраты на создание повторно используемого кода) и 60%
(трудозатраты на создание модифицируемого кода) наблюдаются в сотнях проектов.
Однако в данном случае речь идет о средних значениях и возможный диапазон будет
Итого
noLOC

358 Глава 10
шире. Наилучшим индикатором достигаемого размера и понесенных трудозатрат в
вашей организации являются фактические данные, полученные в ней, —
отслеживайте оценки и фактические данные в хронологической базе данных.
Типичные множители повторного использования приведены в табл. 10.17.
Таблица 10.16. Применение множителей повторного использования
Элемент
Итого
Множитель
Результат
LOC для нового LOC для модифи-
кода цируемого кода
1238 1782
100% 60%
2138 1069
LOC для повторно
используемого кода
1201
30%
360
Таблица 10.17. Типичные множители повторного использования
Итого
noLOC
5121
3567
Степень простоты использования Повторно используемый Модифицируемый
Простой
Средний
Сложный
10%
30%
40%
25%
60%
75%
Будьте особенно внимательны при повторном
использовании кода
Можно достичь большей точности при повторном использовании кода, если более
внимательно присмотреться к процессу и повторно использовать характеристики.
Возвращаясь к нашему примеру, заметим, что первый шаг заключается в проверке
процесса и в определении процента от общего количества трудозатрат, понесенных
на каждом шаге разработки нового кода.
Предположим, нам известно о том, что данная организация тратит 18% своего
времени на разработку требований, 25% времени — на дизайн, 25% времени — на
кодирование и тестирование, а 32% времени — на выполнение интеграции (в данном
примере рассматриваются лишь четыре фазы жизненного цикла).
Как показано в табл. 10.18, на разработку нового кода уходит максимальное
количество трудозатрат. В случае применения повторно используемого и
модифицируемого кода трудозатраты будут меньшими.
Отметим, что, вместо обычных 100%, модифицируемый код требует лишь 20%
трудозатрат на этапе формулировки требований, а повторно используемый код —
лишь 10% трудозатрат.
Вместо 100% трудозатрат на этапе разработки проекта, модифицируемое ПО
требует 40% трудозатрат, а повторно используемое ПО вообще не нуждается в
разработке проекта @%). Показатель 40% появляется по той причине, что потребуется
разработать план тестирования модифицируемого ПО, а также вполне возможно, что
придется специальным образом переработать часть ПО. Таким образом отчетливо
просматривается важность повторного использования.
Вместо 100% трудозатрат на этапе кодирования и тестирования единицы,
необходимых при разработке новых программ, модифицируемое ПО требует лишь 70%

Оценка размера и возможности повторного использования ПО 359
трудозатрат, а повторно используемое ПО является полностью "свободным" от
трудозатрат. При использовании "чистого", повторно используемого ПО данный
показатель равен нулю. Если будет изменена лишь одна строка кода, все ПО будет
считаться модифицируемым.
Трудозатраты по интеграции кода не будут сильно уменьшены даже в случае
применения модифицируемого или повторно используемого кода. Даже в случае
чистого повторно используемого кода трудозатраты по интеграции часто
составляют 50%-100%.
На каждой фазе процесса эффект от повторного использования кода может
определяться после того, как установлено процентное значение для каждой повторно
используемой категории. В табл. 10.18 демонстрируется, что включение повторно
используемого либо модифицируемого кода в любом случае может привести к экономии
размера, трудозатрат, времени по графику или затрат денежных средств.
Таблица 10.18. Применение метода точной оценки в повторно используемом
или модифицируемом коде
Шаг процесса Требования Дизайн Код Интеграци
я
Процент 18% 25% 25% 32%
Произведено Эквивалент
2138 Новый 100% 100% 100% 100% 2138
1782 Модифицируе- 20% 40% 70% 100% 1124
мый
1201 Повторно ис- 10% 0% 0% 100% 406
пользуемый
5121 3668
Оценка трудозатрат
После того, как размер программного продукта был оценен, можно перейти к
оценке трудозатрат, понесенных на производстве этого продукта. Эти вопросы
подробно обсуждаются в следующей главе.
Резюме
Измерение размера, оценка и составление графика сложным образом
переплетаются в процессе планирования проекта. На самом деле довольно сложно создать
реальный график (учитывающий обязанности исполнителей, зависимости, перекрытие
действий, а также дату поставки продукта) без информации об объеме трудозатрат,
требуемых для выполнения каждой задачи (например, определения нагрузки
сотрудников на месяц). Достаточно трудно оценить объем трудозатрат, необходимых для
выполнения задачи, без информации относительно ее "размера". Таким образом,
измерение предшествует оценке, а оценка, в свою очередь, предшествует составлению
графика. Каждое из этих важных действий проекта может быть выполнено с
помощью множества различных методик. Способность к выполнению оценки является
весьма важной для зрелой организации, выполняющей разработку ПО.

360 Глава 10
Плохие оценки влекут проблемы и увеличивают степень риска. Негативные
последствия могут быть в значительной степени смягчены при использовании стандартных
методов оценки. В начале работы с любыми методами следует получить хорошее пред-
с гавление о пооперационной разбивке проекта, как в случае со структурой WBS.
При выполнении операции определения размеров используются пять весьма
полезных и широко известных технологий, каждая из которых создана на базе
структуры WBS:
■ подсчет строк кода (LOC) в качестве единиц оценки размера;
■ подсчет функциональных точек в качестве единиц оценки размера;
■ подсчет точек свойств в качестве единиц оценки размера;
■ применение блиц-модели (также известной под именем банг-метрики Де Марко и
оценивания "снизу-вверх");
■ применение модели Wideband Delphi.
Повторное использование существующих компонентов не всегда возможно в
полном объеме. Существует так называемая плата за интеграцию: особенности
существующих компонентов может не допускать обеспечение качества и возможность
повторного использования. Выход состоит в использовании набора весовых
множителей, произведенных на основе эмпирических правил, с целью их применения при
оценке процесса повторного использования.
Индустрия ПО часто возвращается к использованию метрики LOC, единицы
измерения, хорошо знакомой практикам в области разработки ПО. Они находят ее
комфортной и простой в применении. Какая бы технология не использовалась,
оценка размера продукта является весьма важной, поскольку она является составной
частью одной наиболее важной задачи проекта: установка реальных ожиданий.
Нереальные ожидания, основанные на неточных оценках, представляют собой одну из
наиболее частых причин сбоев ПО. Зачастую причина кроется не в недостаточной
производительности команды проекта, а в неточном предвидении уровня этой
производительности. Точное оценивание обеспечивает улучшенный контроль над
проектом и является жизненно важным в деле проектного менеджмента; неточное
оценивание приводит к возникновению паники "в последние минуты", что ведет к
появлению дефектов.
Для обеспечения точного оценивания в первую очередь следует иметь
представление относительно размера продуцируемого ПО. Эта величина должна определяться
па ранних стадиях цикла разработки и выражаться в единицах, которые являются
простыми в процессе наблюдения и при осуществлении коммуникаций.
Контрольный список оценивания может включать следующие аспекты:
■ Ставилась ли при основании фирмы цель выполнения оценки размера ПО?
■ Были ли обучены заказчики, менеджеры и разработчики основам измерений и
получения оценки?
■ Были ли корректно применены хронологические данные?
■ Применялись ли корректно модели?
■ Был ли адаптирован метод оценки к процессу разработки?
■ Были ли выполнены приемлемые допущения относительно факторов продукта и
процесса, оказывающих влияние на производительность?

Оценка размера и возможности повторного использования ПО 361
■ Применялись ли реальные стратегии, способствующие достижению
агрессивных целей?
■ Использовался ли альтернативный метод оценивания в целях сравнения?
■ Были ли применены несколько методов? (В большинстве случаев достаточно
одного метода. Если оба метода не подходят, могут быть утеряны важные факты.)
■ Были ли задействованы все используемые функции? (Многие из функций легко
пропустить или недооценить, например, контроль, включение электропитания,
сбой электропитания, диагностика, операционные системы и т.д.)
■ Удалось ли вам избежать выполнения той работы, в которой вы плохо
разбираетесь? При оценке размера ПО важно помнить о следующем:
— хронология является вашим "союзником";
— используйте несколько методов с целью их изучения и снижения степени риска;
— учитывайте возможность повторного использования.
Авторы книги выражают особую благодарность Ричарду Фарлею (Richard Fairley),
разработавшему и прочитавшему множество великолепных курсов по выполнению
измерений и оценке ПО.
Контрольные вопросы
1. Объясните, почему единицы измерения LOC используются либо не используются
в вашей организации.
2. Выберите текущий, будущий либо прошлый проект в вашей организации и
опишите, будет ли метод функциональных точек либо точек свойств наиболее
применяемым методом для оценки размера системы.
3. Перечислите фазы жизненного цикла, используемые в вашей организации, а также
определите процент трудозатрат для каждой фазы (в среднем). Если в данном
случае не будет использоваться стандартный жизненный цикл, перечислите фазы
жизненного цикла, которые (согласно ожиданиям) будут образовывать хороший
стандарт; затем примените процентную характеристику трудозатрат для каждой фазы.
Практическое занятие
Мисс Пайтель, ваш менеджер по маркетингу в регионе AsiaPac, презентовала
документ ARRS Market Requirements Document (MRD), предназначенный для комитета
управления продуктивностью корпорации. Корпорация задалась целью превратить
"инвестиции в область разработки ПО в продаваемые продукты". Поэтому каждый
менеджер по маркетингу должен создать предварительный MRD для ПО,
разрабатываемого в его области ответственности. Причем BSD был установлен в качестве SEI уровня 5
для организации, а также адаптирован процесс менеджмента ПО, управляемый
измерениями (Measurement-Driven Software Management, MDSM) для деловой модели
повторного использования ПО (Software Reuse Business Model, SRBM).
BSD MDSM включает следующие атрибуты.
■ Измерение и менеджмент. Анализ влияния повторного использования должен
быть отмечен в качестве аспекта общих метрических показателей программы,
зависящий от данной программы. Программа, реализующая систематическое изме-

362 Глава 10
рение, реализует плановые систематические трудозатраты, в результате чего на
регулярной основе оценивается процесс и продукты, созданные на протяжении
жизненного цикла.
■ Повторное использование и управление областью. Менеджер программного
проекта имеет перспективу в рамках нескольких проектов, а также несет общую
ответственность за управление производством семейства подобных проектов в
составе области. Часть этой функции обеспечивает управление повторным
использованием среди всех членов этого семейства. Программный менеджер принимает
решения по инвестициям, основываясь на оценке возможности повторного
использования, примененной к нескольким программам (текущим либо ожидаемым)
в области.
■ Повторное использование и программный менеджмент. Менеджер программного
проекта обладает перспективой в рамках одной программы. Более того, он должен
выдать предупреждение относительно потенциальных возможностей
ресурсосберегающего повторного использования в пределах области действия программы.
■ Типичные вопросы, связанные с затратами в процессе повторного использования
кода. В зависимости от анализа затрат в процессе повторного использования,
некоторые типичные вопросы могут звучать следующим образом:
— Каким образом можно уменьшить затраты на производство новой системы,
если придерживаться имеющегося процентного распределения для повторного
использования в производимых продуктах?
— Что такое избежание затрат при среднем процентном соотношении
повторного использования в семействе подобных систем?
— Какое количество систем в конкретной области должны реализовать
ожидаемые преимущества повторного использования, учитывая данные инвестиции, с
целью окупаемости повторного использования?
— Каковы ожидаемые затраты при разработке каждой системы семейства, исходя
из данной конкретной стратегии инвестиций при повторном использовании?
— Какие именно инвестиции возвращаются при использовании текущей
стратегии инвестиций для повторного использования?
Основной аспект, который логически выводится из данной презентации,
заключается в ответе на эти стандартные вопросы для ARRS. К сожалению, мисс Пайтель
находится в командировке в Австралии до конца этой недели. Поскольку она знает
вас. как менеджера программных проектов, изучавшего SEI СММ и работающего с
BSD, она разрешает вам ответить на вопросы почтой, направив ее членам производ-
стненного совета корпоративного рынка. Следующее собрание членов совета
состоится во вторник в Чикаго в 15.30.
Литература
Albrecht Allan J. "Measuring Application Development Productivity". Proceedings of the IBM Application
Development Symposium, October 1979. Monterey, CA. pp. 83-92.
Albrecht AllanJ., and John E. Gaffney, Jr. "Software Function, Source Lines of Code, and Development
Effort Prediction: A Software Science Validation". IEEE Transactions on Softiuare Engineering, SE-9F) :639-648.
NY: The Institute of Electrical and Electronics Engineers, 1993.

Оценка размера и возможности повторного использования ПО 363
DeMarco Tom, and Barry W. Boehm. Controlling Software Projects: Management, Measurement, and Estimates.
Englewood Cliffs, NJ: Prentice Hall PTR/Sun Microsystems Press. 1998.
Florae William A., and Anita D. Carleton. Measuring the Software Process. Reading, MA: Addison-Wesley,
1999.
Garmus David, and David Herron. Function Point Analysis: Measurement Practices for Successful Software
Projects. Boston, MA: Addison-Wesley, 2001.
Jones Capers. Programming Productivity. NY: McGraw-Hill, 1986.
Jones Capers. Applied Software Measurement: Assuring Productivity and Quality, 2nd ed. NV: McGraw-
Hill, 1997.
Kemerer Chris F. "An Empirical Validation of Software Cost Estimation Models'*. Communications of the
ACM, 30E):416-429. NY: Association for Computing Machinery, 1987.
Stutzke Richard D. Software Estimation: Projects, Products, Processes. Reading, MA: Addison-Wesley, 2001.
Von Mayrhauser, Anneliese. Software Engineering: Methods and Management Boston, MA: Academic
Press, 1990.
www.ifpug.org. International Function Point Users Group. Function Points as Asset Reporting to
Management, 1990.
www.ifpug.org. International Function Point Users Group. Function Point Counting Practices Manual,
Release 4.0. IFPUG Standards, 1994.
www.ifpug.org. International Function Point Users Group. Guidelines to Software measurement,
Release 1.0. IFPUG Standards, 1994.
Дополнительные сведения в Internet
kapis.www.wkap.nl/kapis/CGI-BlN/WORLD/journalhome.htm71382-3256. Виктор Р. Бази-
ли (Victor R. Basili), главный редактор Уоррен Гариссон (Warren Harrison), ассоциативный редактор.
Эмпирический программный инжиниринг.
ifpug.org. Web-узел Международной организации пользователей метода функциональных
точек (International Function Point User's Group, IFPUG).
ourworld.compuserve.com/homepages/softcomp/fpfaq.htm. "Часто задаваемые вопросы
(и ответы), связанные с анализом методом функциональных точек". Copyright 1996-1997 by Software
Composition Technologies, Inc.
www.dacs.dtic.mil/databases/url/key.hts?keycode=4:7sislowerlevel=l. Оценка
затрат: Анализ методом функциональных точек. Центр данных и анализа ПО (Data & Analysis Center for
Software, DACS) является информационно-аналитическим центром Министерства обороны США
(Department of Defense, DoD).
www.qpmg.com/fp-intro.htm. Роджер Хеллен, "An Introduction to Function Points", Q/P
Management Group, Inc.
www.sciam.com/1998/1298issue/1298jones.htmltfurther. Каперс Джонс (Capers Jones),
"Sizing Up Software: Unlike oil. steel or paper, software is an intangible commodity".
www. softwaremetrics. com/Articles/de fault .htm. Longstreet Consulting, Inc.
www.spr. com/index. htm. Компания Software Productivity Research, Inc.
www.spr.com/2ibrary/0funcmet.htni. Каперс Джонс (Capers Jones), президент компании
Software Productivity Research, Inc. "Что такое метод функциональных точек?"
www.stsc.hill .af.mil/crosstalk/. Оценка размера ПО: проблемы и исследования.
www.stsc.hill.af.mil/CrossTalk/1995/nov/Living.asp. Лаврентий Бернштейн и
Александр Любашевский (Lawrence Bernstein and Alex Lubashevsky), AT&T, "Живем с методом
функциональных точек".

Оценка длительности
и стоимости
разработки ПО
В главе 10 описывались методы, используемые при оценке размера программного
проекта. Обычно этот показатель выражается в тысячах строк программного кода
(KSLOC или KLOC). После определения размера ПО, следует оценить некоторые
другие параметры, представляющие интерес для всех участников выполняемого
проекта. Большинство заказчиков и инвесторов не слишком интересуются размером
программного кода. Гораздо больше их привлекает способ производства этого кода, а
также величина накладных расходов. Как только менеджер проекта сможет реально
планировать и распределять трудозатраты, необходимые для производства того или
иного программного продукта, он займется набором персонала, обучением,
ротацией, а также другими вопросами, связанными с управлением персоналом. В главе также
затрагиваются вопросы по выполнению оценки размера ПО путем использования
таких единиц измерения, как KLOC, объектные точки, функциональные точки, точки
свойств и т.д.
Стадии жизненного цикла
разработки продукта
Оценка трудозатрат, длительности и стоимости разработки ПО выполняется на
ранних стадиях планирования проекта, непосредственно после оценки размера
программ. Используя термины обобщенной модели жизненного цикла, можно сказать,
что планирование выполняется на фазах исследования концепции, изучения
системы, а также на фазе формирования требований (рис. 11.1). Оценка размера ПО
и трудозатрат, связанных с его разработкой, может происходить множество раз на
протяжении всего жизненного цикла (после формулирования начальных
требований, анализа, стадии разработки проекта и т.д.). При этом в каждом новом случае
повышается степень достоверности оценки. Наша модель процесса описывает фазы
жизненного цикла, указывая на случаи выполнения оценки и повторной оценки.
Хорошей практикой для менеджеров проекта должно стать выполнение оценки либо

Оценка длительности и стоимости разработки ПО 365
повторной оценки размера, используемой в качестве выходного критерия на каждой
фазе жизненного цикла.
Обратите внимание, что приведенный здесь жизненный цикл не представляет
собой единую картину. Здесь приведены лишь некоторые действия и фазы, которые
связаны с процессом измерения и оценки полученных результатов.
Исследование
концепции
• Формули-'L
рование

потребности
Исследование
системы
1 Спецификация'
интерфейса
системы
Требования
Идентификация
циклов SLC
• Спецификация
требований
кПО
Выбор
модели
• Модель SLCj
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
Базовая модель жизненного цикле
разработки системы
Разработка
проекта
' Описание

разработки ПО
Выбор модели
жизненного цикла;
разработки ПО
■ Жизненный цикл SW
Распределение
ресурсов
■ Бюджет
Внедрение
• План

тации/верификации ПО
Установка
■ Отчет об

тестации/верификации ПО
Оценка размера, i
повторного применения, •
трудозатрат, графика и затрат
Установка среды проекта |
• Методологии
' Стандарты
' Инструменты
Эксплуатация
и поддержка
'
Пользовательская
документация
Инициализация
и планирование проекта
План управления проектом
Проектная отчетность и испытательный план
} ' План вывода из эксплуатации
I ' План менеджмента программного проекта
План подЬержки [ 1
I
Сопровождение
• Документация
по
сопровождению
Вывод из
эксплуатации
■ Архивный
отчет
Рис. 11.1. Начальные оценки трудозатрат на разработку ПО и определение графика
(длительности выполнения) на ранних стадиях жизненного цикла разработки ПО
Связь главы 11 с 34 компетенциями
Оценка трудозатрат и разработка графика напрямую связаны с компетенциями
проекта (рис. 11.2). Результаты оценивания регистрируются в плане проекта; таким
образом, в данном случае начинает сказываться третья компетенция проекта,
называемая документированием планов. Оценки также представляют собой метрические
показатели, которые должны поддерживаться по мере разработки проекта.

366 Глава 11
Методики разработки продукта
1. Оценка альтернативных процессов— выполнение оценки с применением, как
минимум, двух технологий.
2. Отбор методов и инструментов — доступно множество методов и инструментов,
предназначенных для поддержки процессов, в ручном и автоматическом режимах.
3. Подгонка процессов — все модели оценивания должны быть отобраны с целью
отражения среды организации.
Навыки менеджмента проектов
4. Документирование планов— разбиение задач по разработке проекта и
программного продукта в соответствии с их размерами, необходимыми затратами,
и графиком проекта. Все эти моменты представлены в плане управления
программным проектом (Software Project Management Plan, SPMP). Риски,
возникающие при оценивании, документированы в виде отдельного плана рисков
либо представлены в виде части плана SPMP.
Оценка трудозатрат и затрат— прогнозирование размера ПО приводит к
прогнозированию ожидаемых трудозатрат.
1. Составление графика— сведения о трудозатратах необходимы для разработки
графика выполняемых работ.
2. Выбор метрических показателей — единицы измерения образуют метрические
показатели; единожды выбранные (размер, затраты по временным периодам,
показатели графика), они могут без особых проблем применяться на протяжении
всего проекта; также единицы измерения могут быть полезными при сравнении
оценок с фактическими результатами.
ПО
Продукт
1. Процессы оценивания
2. Знание стандартов процесса
3. Определение продукта
4. Оценка альтернативных
процессов
5. Управление требованиями
6. Управление субподрядчиками
7. Выполнение начальной оценки
8. Отбор методов и
инструментов
9. Подгонка процессов
10. Отслеживание качества
продукта
11. Понимание действий по
разработке продукта
Проект
Проект
12. Создание структуры
пооперационного перечня работ
13. Документирование планов
14. Оценка стоимости
15. Оценка трудозатрат
16. Менеджмент рисков
17. Отслеживание процесса разработки
18. Составление графика
19. Выбор метрических показателей
20. Отбор инструментов менеджмента
проектов
21. Отслеживание процессов
22. Отслеживание хода разработки
проекта
Менеджмент
Персонал
23. Оценка производительности
24. Вопросы интеллектуальной
собственности
25. Организация эффективных
встреч
26. Взаимодействие и общение
27. Лидерство
28. Управление изменениями
29. Успешное ведение переговоров
30. Планирование карьерного роста
31. Эффективное представление
32. Набор персонала
33. Отбор команды
34. Создание команды
Рис. 11.2. Оценивание и 34 компетенции

Оценка длительности и стоимости разработки ПО 367
Навыки менеджмента персонала
Довольно затруднительно составить отдельный перечень компетенций,
связанных с персоналом, поскольку большинство из них требуется при выполнении
практически любого действия в ходе разработки ПО. В ходе осуществления оценки
трудозатрат и формирования графика особенно полезными являются следующие навыки по
управлению персоналом:
1. вопросы интеллектуальной собственности;
2. организация эффективных встреч;
3. взаимодействие и общение;
4. лидерство;
5. управление изменениями;
6. успешное проведение переговоров;
7. эффективное представление.
Учебные цели главы 11
После изучения материала главы читатель должен уметь выполнять следующее:
■ перечислять основные этапы оценивания размеров ПО, определить длительность
разработки и всех необходимые для этого затраты;
■ применять на практике две модели, повсеместно используемые в индустрии ПО
для оценки трудозатрат и составления графика;
■ различать регрессионные, математические и эмпирические модели оценивания;
■ объяснять базовые концепции, заложенные в основу модели СОСОМО;
■ объяснять базовые концепции, на основе которых построена модель
оценивания SLIM;
■ хорошо знать преимущества и недостатки каждой из моделей;
■ уметь практически применять любую из моделей оценивания в процессе
разработки ПО.
Модель СММ Института SEI
и процесс оценивания
Модель зрелости возможностей (СММ), разработанная Институтом программного
инжиниринга (SEI), используется для описания упомянутых в данной главе действий.
Планирование программных проектов является ключевой областью процесса (КРА) для
уровня зрелости 2, который является повторяемым. Модель КРА на уровне 2 составляет
основу процессов зрелости, которые имеют место на последующих уровнях. Заметим,
что планирование проектов является жизненно важным при поддержке программного
инжиниринга, измерений, а также действий по непрерывному улучшению,
выполняемых на уровнях: 3 (определенный), 4 (управляемый) и 5 (оптимизация).
1 Paulk, Mark С, Charles V. Weber, Bill Curtis и Mary Beth Chrissis. The Capability Maturity
ModeLGuMelines for Improving the Software Process, 1-я редакция, Reading, MA: Addison-Wesley, SEI
Series in Software Engineering, 1994.

368 Глава 11
Необходимость оценивания ПО определяется целью (цель 1), указанной в
планировании проекта КРА. Цели, необходимые способности и действия, связанные с
планированием проекта, перечислены ниже.
Цели модели SEI СММ уровня 2, ключевая
область процесса (КРА): планирование
программного проекта (РР)
Цель 1. Оценки ПО документированы для применения в планировании и
отслеживании программных проектов.
Возможность выполнения, связанная с КРА РР и целью 1
Возможность 4. Менеджеры программных проектов, программисты и другой
персонал, вовлеченный в процесс планирования программных проектов, получают
подготовку по методам оценки ПО и процедурам планирования.
Выполненные действия
Действие 10. Оценки необходимых затрат по внедрению программных проектов
производятся в соответствии с документированной процедурой.
Данная процедура обычно определяет следующие аспекты.
1. Оценивание всех затрат по программным проектам связано с оценками размера
разработанных программных продуктов (либо с оценками необходимых изменений).
2. Данные о производительности (хронологические и/или текущие) применяются
для оценок в случае доступности этих данных; происхождение и обоснование
подобных данных документированы.
■ Данные о производительности и затратах берутся из организационных проектов.
■ При выводе данных о производительности и затратах учитываются трудозатраты и
основные затраты, понесенные при производстве программных продуктов.
Основные затраты, связанные с производством программных продуктов, включают:
непосредственные расходы на рабочую силу, накладные и транспортные расходы, а
также средства, используемые для технического обслуживания компьютерной техники.
3. Оценки трудозатрат, кадрового обеспечения, а также затрат, учитываемых в связи с
прошлым опытом.
■ По возможности должны применяться подобные проекты.
■ Производится разбиение на временные фазы.
■ Подготавливается оценка и распределение трудозатрат, кадрового обеспечения, а
также затрат, необходимых для поддержания жизненного цикла разработки ПО.
4. Оценки и допущения, выполненные на основе других оценок, должны быть
документированы, изучены и одобрены (утверждены).
Действие 11. Оценки критических вычислительных ресурсов проекта выполняются в
соответствии с документированной процедурой.
Критические вычислительные ресурсы могут находиться в хост-среде, в
интеграционной, испытательной среде и в целевой среде, либо в произвольной комбинации
указанных выше сред.
Выполнение процедуры обычно подразумевает следующие аспекты.
1. Идентифицируются критические вычислительные ресурсы, требуемые для
выполнения проекта. Сюда включается следующее: объем компьютерной памяти,

Оценка длительности и стоимости разработки ПО 369
степень загруженности центрального процессора, пропускная способность
коммуникационных каналов.
2. При оценке критических вычислительных ресурсов используются оценки размера
программных продуктов, степени загрузки при выполнении операций, а также
величины трафика при реализации коммуникаций.
3. Оценки критических вычислительных ресурсов документируются, изучаются и
утверждаются.
Действие 12. График выполнения программного проекта разрабатывается в
соответствии с документированной процедурой. Как правило, эта процедура включает
следующее.
1. График разработки ПО связан с оценками размера программных продуктов (либо с
оценкой объема изменений), а также со всеми затратами по разработке ПО.
2. График разработки ПО основывается на прошлом опыте. По возможности,
используются похожие проекты.
3. В графике разработки ПО выполняется адаптация дат ключевых стадий, дат
критических зависимостей, а также других ограничений.
4. График по разработке ПО предполагает определенную длительность, по ключевым
стадиям определяется точность выполнения графика и реализации проекта.
5. Документируются допущения, выполненные на этапе формирования графика.
6. График по разработке ПО документируется, изучается и одобряется (утверждается).
Группа, отвечающая за инжиниринг программных процессов (Software engineering
process group, SEPG), может оказать неоценимую помощь в деле улучшения оценки
затрат, понесенных при разработке ПО. Часто специалисты из этой группы
начинают с того, что читают краткий курс лекций по методике оценки ПО менеджерам
проектов (а также специалистам по оценке). Также в задачи этой группы входит
определение стандартов, применяемых для сбора всех метрических показателей, имеющих
отношение к проекту, включая показатели, применяемые для оценки графика и всех
затрат. Специалисты группы могут нести частичную ответственность за выполнение
работ по отбору моделей по мере роста количества точек данных. Группа SEPG тесно
сотрудничает со специалистами SQA/SQE при определении и документировании
политик, процессов и процедур, включая те из них, которые применяются при оценке
затрат. Эти рабочие группы могут выполнять задачи планирования, а также помогать
менеджерам в деле обучения, а также в приобретении и лицензировании
инструментов, применяемых для выполнения оценок.
Как вы помните, в начале изучения этого курса выдвигалось предположение о
необходимости создания программного продукта к началу выполнения оценки размера
ПО. Процесс оценивания сам по себе является итеративным (рис. 11.3), поэтому к
моменту его начала уже могут быть сформулированы некоторые требования. Эти
требования могут быть связаны с оценкой размера, графика и всех затрат. Сюда же
можно включить создание либо обновление структуры пооперационного перечня
работ (WBS), прогнозирование потребностей в ресурсах, проверку плана
управления программными проектами (Software project management plan, SPMP) для
проверки того, была ли изменена формулировка каких-либо потребностей. Сюда же
можно отнести моделирование имеющихся требований, создание либо
модификацию документа, в котором производится спецификация требований к ПО (Software

370 Глава 11
requirements specification, SRS), возврат к этапу сбора требований, а также
повторение описанного выше цикла до тех пор, пока документ SRS не будет вполне
приемлемым для достижения целей проекта.
На рис. 11.1 демонстрируется процесс оценивания, происходящий в ходе
выполнения интегральной задачи планирования управления проектом. Действия по
планированию происходят одновременно с фазами жизненного цикла по разработке
исследования концепции, системы и требований. На рис. 11.3 и 11.6 продемонстрированы
более точные шаги, предпринимаемые в ходе выполнения оценивания. На рис. 11.3
показаны шаги от 1 до 5 (выявление требований, оценка размера и трудозатрат по
разработке ПО, оценка графика и основных затрат). Эти шаги более подробно
определяются на рис. 11.6.
1. ВшатШ-к- •
■1ребомйкйу7-
заказчика^?;*.
z>
N
/ 7. размера Jj3 '
JA0, обзоры и другие действия
Методы аналогии, Delphi, функциональных точек,
точек свойств, хронологической базы данных
Методы СОС0МО, SLIM, контрольных точек Delphi,
опросов экспертов в данной области
Структурированные
методы, 00-методы
z>
Рис. 11.3. Шаги по определению размера и оцениванию ПО

Оценка длительности и стоимости разработки ПО 371
Каперс Джонс (Capers Jones) один из наиболее известных экспертов в области
выполнения оценок, заметил как-то, что первая оценка обычно не вполне соответствует
истинному значению, отклоняясь от него, как минимум, в четыре раза. Только по
мере эволюции проекта и накопления знаний, модифицированные оценки постепенно
приближаются к фактическому значению. При этом возникает некая разновидность
извечного философского вопроса о том, что является первичным — "курица или
яйцо". Достаточно трудно выполнить оценку, если не сформулированы в полном объеме
требования, но в то же время, если отсутствует какая-либо оценка, невозможно
заключить контракт (получить разрешение либо финансирование), без чего будет
невозможен дальнейший прогресс. Соответствующие схемы, приведенные на рис. 10.2,
впервые были предложены доктором Барри Боэмом (Barry Boehm), а позднее были
усовершенствованы Джонсом.
Определение размеров является первым и важным шагом в силу того, так все
последующие шаги согласованы с первым шагом. Если величина размера оценивается в
функциональных или объектных точках, перед тем, как будут готовы формулы и
инструменты оценивания, она транслируется в значение, выраженное в тысячах строк
кода (KLOC). Нравится нам это или нет, но за последние 30 лет не была создана
единица измерения, которая была бы столь же универсальной, как упоминаемая выше.
Размер обычно оценивается по аналогии с процессом Wideband Delphi или путем
подсчета функциональных точек, точек свойств либо объектных точек. Какой бы
метод не применялся с целью получения первичной оценки размера проекта, именно
эта величина будет ключевой в вопросе об оценке графика и всех затрат.
Оценивание трудозатрат
Под термином "трудозатраты" в процессе оценки ПО подразумевается объем
труда, который необходимо выполнить для достижения какой-то цели. Эта величина
может быть выражена различными единицами измерения. Но в качестве стандарта
фактически используются человеко-часы (персональные часы), человеко-дни
(персональные дни) либо (наиболее часто) человеко-месяцы (персональные месяцы).
В рамках текущего проекта его менеджер и команда могут совместно определять
единицу измерения, в результате чего обеспечиваются хорошие коммуникации и
"прозрачное" сравнение. Но помните, что, если показатели производительности
сравниваются для различных организаций, определение человеко-месяцев будет
одинаковым. (В каждом человеко-месяце содержится 320 часов, поскольку обычно четыре
недели состоят из пяти рабочих дней, каждый из которых включает восемь рабочих часов.)
Также имейте в виду, что каждый человеко-месяц определяет, что один человек
работает на протяжении одного месяца (либо два человека работают по две недели и т.д.).
Итак, одним из основных вопросов, рассматриваемых в главе, является
применение инструмента оценки трудозатрат, графика и остальных затрат, СОСОМО
(Constructive COst Model, конструктивная модель затрат). При этом предполагается,
что в каждом человеко-месяце содержится 19 рабочих человеко-дней и 152 человеко-
часа. Эти значения подсчитываются путем учета среднего количества праздничных и
выходных дней в США — в случае с другими странами эти значения могут отличаться.
Согласно исследованиям доктора Денниса Фрайли (Dr. Dennis Frailey), "если
измерение объема трудозатрат производится последовательно, необходимо представлять
размеры остальных затрат, сравнивать различные проекты, а также прогнозировать
производительность в будущем". Как и в случае с применением показателя количества

372 Глава И
строк кода, существует множество методов, используемых для измерения трудозатрат, а
также множество аргументов для определения того, "что такое хорошо и что такое
плохо". Невозможно производить значительные оценки в случае, если измерения
трудозатрат для каждого проекта производятся различным образом. Согласно доктору Фрайли,
типичные ориентиры, используемые для оценки трудозатрат, включают следующее:
* задачи, выполняемые в будущем (WBS):
- задачи но разработке ПО (проект, код, тестирование);
- дополнительные задачи по разработке (требования, система);
- задачи поддержки (CM, QA, менеджмент);
- задачи, требующие дополнительных трудозатрат (документы и т.д.);
а дополнительные денежные затраты (поездки, оборудование и т.д.);
■ оценка размера ПО;
* хронологические данные по трудозатратам и производительности;
■ график высокого уровня;
* процесс и методы;
* язык программирования;
* операционная система для целевой системы;
■ используемые инструменты;
■ уровень профессионального опыта.
Простое вычисление трудозатрат основывается на хронологических данных:
размер х хронологическая производительность = трудозатраты
Независимо от того, какова применяемая единица измерения, использование
хронологических данных обеспечивает лучший метод достижения требуемого
уровня точности.
Предположим, что текущие хронологические данные показали следующую
производительность:
сложное ПО: 4 SLOC на человеко-день;
простое ПО: 8 SLOC на человеко-день.
Таким образом, если размер нового ПО оценивается в 8000 SLOC, то в случае
разработки сложного ПО может потребоваться до 2000 человек-дней. Если программа
является простой, может потребоваться до 1000 человеко-дней.
Типичные значения производительности:
■ 50 — 300 SLOC/месяц B-15 SLOC/день) для языков высокого уровня;
* 60 — 500 SLOC/месяц для языков ассемблера.
Минимальные значения характерны для правительственных проектов, которые
имеют весьма серьезные ограничения (например, встроенные системы реального
времени, надежность которых жизненно важно для обеспечения безопасности
людей). Более высокие значения характерны для коммерческих приложений с
несколькими ограничениями. Высокие значения этого показателя могут также достигаться в
случае использования языков 4GL, высокой степени повторного использования и в
некоторых других подобных ситуациях.
Ниже приводится соответствующий пример.

Оценка длительности и стоимости разработки ПО 373
Трудозатраты на разработку сложного ПО варьируются от 2 До 8 строк SLOC на
человеко-день, причем среднее значение равно 5 SLOC на один человеко-день. В этом
случае ожидаемые трудозатраты на создание программного кода объемом в 5000
SLOC составят 1000 человеко-дней. Однако это значение может составлять 2500
человеко-дней либо 625 человеко-дней (минимальное и максимальное значения).
Использование альтернативных методов и повторных оценок обеспечивает
наилучшую защиту от проектных рисков, причина которых заключается в неточном оценивании
(которое часто является слишком оптимистичным). Цель, как показано на рис. 11.4,
позволяет выполнить сравнение по критерию "досягаемости и желательности".
График
1 I Досягаемый
Желаемый
Бюджет
Ресурсы
Рис. 11.4. Парадигма оценивания
Бюджет
Цели указывают атрибуты области
действия и качества программного
продукта: устойчивость,
способность к отображению,
пригодность к тестированию,
способность к измерениям
и техническая выполнимость
-► График
Активы
Активы включают персонал,
среду разработки, функции
поддержки, инфраструктуру
и организационные факторы
График х Бюджет х Активы = Желаемые цели
Рис. 11.5. Парадигма оценивания в "одной коробке"
Источник: Fairley, Dick. Software Cost Estimation.

374 Глава 11
Наибольшей проблемой при разработке ПО является (рис. 11.4 и 11.5) создание
полнофункционального высококачественного программного продукта за время,
определенное бюджетом, с учетом использования спрогнозированных активов.
Этапы оценивания
Общие этапы, используемые в процессе оценки всех затрат при разработке ПО,
показаны на рис. 11.6. Все они будут подробнее описаны в дальнейшем.
Этап 1. Достижение целей, связанных с оценкой затрат
■ Следует четко представлять, каким образом может применяться оценивание.
Может ли оно применяться при составлении контракта с фиксированной ценой
работ/услуг? Требуется ли внешнее финансирование?
■ При оценивании скорректируйте цели таким образом, чтобы они соответствовали
принимаемым решениям:
- абсолютное оценивание требуется при планировании ресурсов или рабочего
потенциала;
- относительные оценки могут использоваться для выбора какого-либо решения;
- либеральные оценки могут увеличить степень достоверности решения (по
сравнению с консервативными оценками).
■ Повторно проверьте цели процесса оценивания, реализуемые в ходе его
выполнения, а также измените их в случае необходимости. Оценки могут изменяться по
мере накопления дополнительных сведений о проекте.
1
~2
1
: 1. РеагабацгацатЙ,
.- «шейных:,., . V»
с оценкой saipe^
Рис. 11.6. Этапы оценивания

Оценка длительности и стоимости разработки ПО 375
Этап 2. Разработка плана действий при оценивании;
план распределения ресурсов
■ В плане определяется ожидаемая точность в процессе оценивания затрат.
■ Рассматривайте действия по оцениванию в разрезе "минипроекта". Качественное
оценивание, как и все другие действия по разработке ПО, предполагает
достаточное количество затраченного времени и труда (большие инвестиции приносят
больше прибыли). Оценка, выполненная за 30 минут, будет не столь точной, как
оценки отдельных системных компонентов на основе корректно разработанной
структуры WBS. Миниплан включает набор заметок, выполненных на ранних
стадиях проекта, в которых определяется порядок выполнения оценивания.
Этап 3. Определение требований по разработке ПО
■ Определите требования, необходимые для достижения целей оценивания.
■ Сформулируйте спецификации ПО таким образом, чтобы они были, по
возможности, четкими и однозначными (желательно исчисляемые). Соответствие ПО
имеющимся спецификациям проверяется с помощью тестов.
Этап 4. Учет максимального количества деталей
■ При определении целей оценивания учитывайте необходимость их совместимости.
■ Исследование дополнительного количества деталей потребует хорошего
понимания общей структуры, а также повышения точности оценивания.
■ По мере роста объема оцениваемого ПО согласно закону больших чисел,
уменьшается отклонение результатов оценивания от фактических значений.
■ Чем больше мы будем размышлять относительно всех программных функций, тем
меньшей будет вероятность того, что напрасно будут потрачены средства на
использование менее очевидных функций.
Этап 5. Использование нескольких
независимых методик
■ Ни один из методов не может быть лучше других методов во всех отношениях.
■ Преимущества и недостатки различных методов являются взаимно дополняемыми.
■ Комбинация применяемых методик позволяет преодолеть недостатки отдельных
методов.
Этап 6. Сравнение, понимание и последовательный
просмотр оценок
■ Каждый человек обладает уникальным опытом и набором побуждений (феномен
оптимиста/ пессимиста).
■ Применение нескольких независимых методик оценивания позволяет выполнить
исследование причин необходимости проведения различных оценок (особенно
сильно это сказывается в процессе обучения). В ходе выполнения итераций
постепенно достигается реалистичная оценка.

376 Глава 11
■ Проявляется феномен закона Парето (Pareto): 80% затрат приходится на
создание 20% компонентов. Обращайте более пристальное внимание именно на эти
компоненты.
Этап 7. Обзор точности оценивания
■ Правильно подбирайте методики и модели оценивания.
■ Как и в случае с оцениванием размера ПО, для оценки трудозатрат доступны несколько
моделей. Большинство из них основаны на фундаментальных математических и
экспериментальных понятиях, а также в них используется регрессионный анализ.
Исходя из предположения о незавершенности оценок ПО, можно заключить, что
сравнение оценок с фактическими данными обеспечивает улучшенный базис для
управления прочими частями текущего проекта либо для применения в будущем.
Программные проекты часто являются непредсказуемыми, а их область действия часто не может
быть переопределена. Менеджеры проектов выполняют повторные оценки с целью
отражения основных изменений. При разработке ПО, в отличие от многих других
отраслей промышленности, один и тот же продукт никогда не создается дважды. В
дополнение к оценкам, учитывающим различия между спецификациями нового и предыдущих
проектов, также должны приниматься во внимание различия в средах разработки и
доставки, учитывая быстрые пооперационные изменения в технологии, при этом могут
не использоваться хронологические данные вплоть до перехода в новую среду.
Рассмотрим некоторые из наиболее широко используемых моделей/методов, с
помощью которых оцениваются трудозатраты (а также обычные затраты); метод
Delphi (не является автоматизированным и используется для оценивания трудозатрат
точно таким же образом, как и в случае оценивания ПО (глава 10); модель,
основанная на применении регрессионного анализа (в дальнейшем она будет
рассматриваться как модель СОСОМО); математическая модель (модель SLIM), а также
эмпирические модели. Основное внимание в главе будет уделено регрессионной и
математической моделям, а также вспомогательным формулам и инструментам. Обсуждение
методов оценки размера ПО и необходимых трудозатрат будет неполным, если не
упомянуть об эмпирической модели центра исследований производительности при
разработке ПО (Software Productivity Research, SPR). Это центр фирмы Artemis
Management Systems, он занимает ведущие позиции в области планирования и оценок
ПО. Под руководством эксперта в области разработки ПО Каперса Джонса (Capers
Jones), в SPR был разработан инструмент, именуемый SPR KnowledgePLAN®. Этот
инструмент предназначался для выполнения планирования и оценок ПО. В состав
этого программного продукта входит мастер проектов, позволяющий упростить
процесс оценивания разрабатываемого ПО, мастер выполнения измерений, проводящий
пользователя по этапам процесса определения размеров, мастер целей, облегчающий
идентификацию пользователей и достижение ключевых целей проекта, а также
шаблоны, облегчающие быстрый запуск проекта пользователями. С моделью СОСОМО
часто связывают имя доктора Барри Боэма (Dr Barry Boehm). Имя Лоуренса Патнама
(Lawrence Putnam) ассоциируется с фирмой Quantitative Software Measurement (QSM,
производимый ею программный продукт именуется SLIM). А имя Каперса Джонса
(Capers Jones) обычно связано с SPR (KnowledgePLAN®). Эти эксперты работают в
области измерений и оценок ПО, успешно решая большинство сложных проблем. Им
принадлежат множество статей и исследований, а также выборки данных из тысяч
программных проектов.

Оценка длительности и стоимости разработки ПО 377
Регрессионная модель СОСОМО
Модель конструктивных затрат (Constructive COst Model, СОСОМО) относится к
числу наиболее широко применяемых технологий оценивания. Основанная на
использовании регрессии модель была разработана доктором Барри В. Боэмом (Dr.
Barry W. Boehm) в начале 1970 годов. В то время Барри работал в фирме TRW. Он
начал с анализа 63 программных проектов различных типов. При атом оценивался
фактический размер (показатель LOC), понесенные трудозатраты, а также фактическая
длительность разработки ПО. Регрессионный анализ используется на этапе
разработки экспоненциальных уравнений, которые лучше всего описывают связь между
разбросанными точками данных.
Общее описание регрессионных моделей
Регрессионная модель создается на основе статистической интерпретации
хронологических данных, описывающих средние значения либо "типичную" взаимосвязь
между переменными.
Определения.
Регрессионный анализ обладает следующими признаками.
■ Метод регрессии применяется для создания количественного прогноза значения
одной переменной, полученного на основе значений других переменных.
■ Используется статистическая техника при поиске взаимосвязей между
переменными в целях прогнозирования дальнейших значений.
■ Процедуры, применяемые при поиске математической функции, лучше всего
описывают взаимодействия между зависимой переменной и одной или большим
количеством независимых переменных. При использовании метода линейной
регрессии взаимосвязь ограничена прямой линией, а метод наименьших квадратов
применяется для определения наиболее применяемых значений.
Линейные модели. В статистических моделях значение параметра для данного
значения вычисляется по формуле а + Ьх, где а и b являются константами. В этих
моделях прогнозирование выполняется с учетом использования линейной регрессии.
При использовании множественной регрессии зависимая переменная
рассматривается в качестве зависящей от более чем одного независимого значения.
На рис. 11.7 показана диаграмма разброса (слева), а также демонстрируется попытка
подгонки результатов к прямой линии, проходящей через точки данных (справа).
В этом конкретном примере рассматривается взаимосвязь между скоростью
формирования кариозных полостей в зубной ткани и количеством потребляемого сахара.
Режимы модели СОСОМО
В ходе наблюдения над 63 проектами Боэм нарисовал множество графиков, но,
поскольку величина рассеяния данных была довольно большой, ему пришлось разработать
несколько уравнений, благодаря которым удалось выполнить моделирование с помощью
прямой линии, используемой при выполнении прогнозирования в будущем (рис. 11.8).
Используемая при этом техника, а также советы для тех, кто захочет повторить
эксперимент, сохранив при этом простоту уравнения наравне с применением дополнительных
объясняющих факторов, будут объяснены позднее. В этом случае сложная статистика не
даст особого результата, поскольку данные обычно содержат много погрешностей.

378 Глава 11
В модели СОСОМО используются три режима, с помощью которых
классифицируется сложность системы, а также среды разработки (табл. 11.2).
Органический режим. Органический режим обычно классифицируется как
платежная ведомость, опись либо научное вычисление. Другие характеристики
режима: небольшая команда по разработке проекта, требуются небольшие
нововведения, имеются нестрогие ограничения и конечные сроки, а среда разработки
является стабильной.
Количество граммов потребленного сахара Количество граммов потребленного сахара
Рис. 11.7. График рассеяния, подогнанная линия
Модель СОСОМО
2500
2000
1 1500
1000
500
т
т
Встроенный базовый режим
Встроенный промежуточный режим „
Сблокированный (базовый и промежуточный) режим >
Промежуточный
органический режим
J I I I
Базовый
органический
режим
75 100 125
Показатель KSL0G
150
200
Рис. 11.8. Исходные 63 проекта Боэма
Источник: Адаптированный текст из книги Boehm, Barry A976).
Software Engineering Economics. Englewood Cliffs, NY: Prentice Hall. c. 76.

Оценка длительности и стоимости разработки ПО 379
Сблокированный режим. Сблокированный режим типизируется прикладными
системами, например, компиляторами, системами баз данных либо редакторами.
Другие характеристики: небольшая команда по разработке проекта среднего размера,
требуются некоторые инновации, умеренные ограничения и конечные сроки, а среда
разработки немного нестабильна.
Внедренный режим. Внедренный режим характеризуется режимами реального
времени, например, системами контроля воздушного движения, сетями ATM или
военными системами. Другие характеристики: большая команда разработчиков
проекта, большой объем требуемых инноваций, жесткие ограничения и сроки сдачи. Среда
разработки в этом случае состоит из многих сложных интерфейсов, включая те из
них, которые поставляются заказчикам вместе с аппаратным обеспечением.
Уровни модели СОСОМО
Три уровня детализации обеспечивают пользователю последовательное
повышение степени точности на каждом последующем уровне.
Базовый уровень. На этом уровне для определения необходимых трудозатрат и
графика используется лишь значение размера и сведения о текущем режиме. Он
пригоден при выполнении быстрых и приближенных оценок при выполнении
небольших и средних по объему проектов.
Таблица 11.1. Характеристики режимов СОСОМО
Режим Размер про- Проект/команда
граммного
продукта
Потребность Срок сдачи Среда раз-
в инновациях и ограни- работки
чения

Органический


рованный

Внедренный
Обычно 2-50
KLOC
Обычно 50-
300 KLOC
Обычно
более 300
KLOC
Небольшой проект и
команда —
разработчики знакомы с
инструментами и языком
программирования
Средние проекты,
средняя команда,
обладающая средним
уровнем
возможностей
Большие проекты,
требующие большой
команды

Незначительная
Средняя
Максимальная

Либеральные
Средние
Серьезные

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

HW/Интерфейсы
заказчиков
Промежуточный уровень. На этом уровне применяются сведения о размере,
режиме и 15 дополнительных переменных с целью определения необходимых
трудозатрат. Дополнительные переменные называются "драйверами затрат" и имеют
отношение к атрибутам продукта, персонала, компьютера и проекта, которые могут
являться результатом более ли менее значительных трудозатрат. Произведение
драйверов затрат называется корректировочным множителем среды (Environmental
adjustment factor, EAF).

380 Глава 11
Детализированный уровень. Этот уровень надстраивается на промежуточном
уровне СОСОМО путем внедрения дополнительных множителей трудозатрат,
чувствительных к фазе, и трехуровневой иерархии программных продуктов.
Промежуточный уровень может быть настроен по фазе и по уровню разработки продукта с целью
достижения детализированного уровня. В качестве примера множителей
трудозатрат, чувствительных к фазе, можно рассматривать офаничения по памяти, которые
могут применяться при попытках оценивания фаз кодирования или тестирования
проекта. Однако в то же самое время показатели размера памяти могут не оказывать
влияния на величину затрат либо трудозатрат на фазе анализа. Это становится еще
более очевидным после описания множителей трудозатрат (либо драйверов затрат).
Множители, чувствительные к фазе, обычно резервируются для использования
зрелыми организациями и требуют применения автоматизированных инструментов.
Трехуровневая иерархия программных продуктов состоит из системы, подсистемы
и модуля, подобно тому, как реализовано расположение в структуре WBS. Большие
проекты могут разбиваться, как минимум, на три уровня, причем каждый из драйверов
затрат, введенный на промежуточном уровне модели СОСОМО, назначается на уровне
таким образом, чтобы он мог подвергаться воздействию вариаций. Например, опыт
инженера в области языков профаммирования может применяться только на уровне
модулей, в то время как способности аналитика могут применяться на уровнях
подсистем и модулей. Требуемый уровень надежности может применяться на уровне системы,
подсистемы и модуля. Как и в случае с множителями, чувствительными к фазе,
повышенная чувствительность проявляется после описания драйверов затрат. Как и в случае
с множителями, чувствительными к фазе, солидные организации, обладающие
автоматизированными инструментами, являются наиболее серьезными пользователями.
Базовая модель СОСОМО
Оценка трудозатрат. Показатель KLOC касается исключительно входной
переменной. Для вычисления трудозатрат используется экспоненциальная формула, как
показывается в примечании 11.1.
Примечание 11.1. Базовая формула оценки трудозатрат СОСОМО
Трудозатраты (Е) =" а х (размер)Ь <...*,...,'• -. '■}
аиЬ—константы, определенные на этапе регрессионного анализа *■ '
.; (»зависимости от проекта^^.^',/_-) £(,**-*.^чЛ»Г.у' ■ Л- :-.•' ,. *
Размере--тысячи строк кода (KLOC); ': ^f^v'v^'^*'* ■ <t .,-
Е—трудозатраты, выраженные в человеко-месяцах.". -1 * -г
Как указывал доктор Фрайли (Dr. Frailey), трудозатраты измеряются в человеко-
месяцах A9 дней в месяце либо 152 рабочих часа в месяце), константы а и b могут
определяться с помощью процедуры построения кривой по точкам (регрессионный
анализ), причем данные проекта сравниваются с помощью уравнения. Большинство
организаций не располагают массивом данных, достаточным для выполнения
подобного анализа, начиная с применения дерева уровней трудности Боэма (Boehm). Этот
метод может применяться для описания многих программных проектов. В
примечании 11.2 приводятся базовые формулы; в табл. 11.2 перечислены формулы,
применяемые для оценки трудозатрат и времени разработки в каждом режиме.

Оценка длительности и стоимости разработки ПО 381
В случае использования различных режимов проекты одинакового масштаба
требуют различных трудозатрат.
Предположим, что размер проекта равен 200 KLOC. Подставим данные в формулу:
Трудозатраты (Е) = а х (размер)Ь
Примечание 11.2. Базовые формулы оценки трудозатрат для трех режимов
модели СОСОМО
Таблица 11.2. Базовые формулы оценки необходимых для разработки
времени и трудозатрат в модели СОСОМО
Режим а Ь Формула для оценки тру- Формула для определения
дозатрат ■ а х (размерI* времени разработки
Органический 2,4 1,05 Е = 2,4х (SI05 TDEV = 2,5 х (Е)оммесяцы
Сблокированный 3,0 1,12 E = 3,0x(S)WJ TDEV - 2,5 х (Е)°ю месяцы
Внедренный 3,6 1,20 E = 3,6x(S),S0 TDEV = 2,5 х (Е)мг месяцы
Трудозатраты для органического режима подсчитываются по формуле:
2.4 х B00I,05 = 2,4B60,66) = 626 человеко-месяцев.
Для сблокированного режима может применяться следующая формула:
3,0 х B00I,12 = 3,0C77,71) = 1133 человеко-месяца.
Для внедренного режима:
3,6 х B00I,20 = 3,6E77) = 2077 человеко-месяцев.
После завершения оценки трудозатрат для определения периода внедрения
проекта либо времени завершения (времени разработки, TDEV) может применяться
экспоненциальная формула. Длительность проекта выражается в месяцах.
Оценка длительности базового проекта СОСОМО
Боэму (Boehm) принадлежат три формулы (примечание 11.3), применяемые для
оценки времени разработки таким же образом, как и в случае с оценкой трудозатрат.
Примечание 11.3. Оценка длительности проекта при использовании базовой
модели СОСОМО
Если известны трудозатраты (Е) и время разработки (TDEV), может быть
вычислена средняя численность персонала (SS), необходимого для завершения проекта
(примечание 11.4).

382 Глава 11
Примечание 11.4. Оценка средней численности персонала при использовании
базовой модели СОСОМО
Оценка производительности и средней численности персонала
в базовой модели СОСОМО
Если известна средняя численность персонала (SS), может быть определен
уровень производительности (примечание 11.5).
Примечание 11.5. Оценка производительности при использовании базовой
модели СОСОМО
Примеры реализации базовой модели СОСОМО
Ниже приводятся два примера реализации базовой модели СОСОМО. Первая
является простой, а вторая имеет среднюю степень сложности.
Пример 1
Размер разрабатываемого проекта оценивается 7,5 KLOC, из-за чего проект
определяется как простой (применяется органический режим).
Уравнение базовой модели СОСОМО, применяемое для оценки трудозатрат (Е),
выраженное в человеко-месяцах (SM) имеет следующий вид:
трудозатраты (SM) = 2,4(KLOCI,05 = 2,4G,5I,05 = 2,4(8,49296) =
= 20 человеко-месяцев
Время разработки (TDEV) также может определяться с помощью формул базовой
модели СОСОМО:
TDEV = 2,5(SMH,38 = 2,5B0H,38 = 2,5C,1217) = 8 месяцев
Средняя численность персонала (S) определяется по формуле:
персонал = трудозатраты/TDEV = 20 человеко-месяцев/8 месяцев =
- 2,5 члена команды (в среднем)
Производительность (Р):
производительность = размер / трудозатраты = 7,500 LOG / 20 человеко-
месяцев = 375 LOC/человеко-месяц
Пример 2
При разработке проекта его размер оценивается примерно в 55 KLOC, и
ожидается средний уровень сложности. Этот проект будет представлять собой Web-систему,
снабженную устойчивой серверной базой данных. Предполагается применение
сблокированного режима.
Для грубой оценки трудозатрат, необходимых для полного завершения проекта,
используется следующая формула:
Е (трудозатраты, выраженные в человеко-месяцах) = 3,0(KLOC) *'12
Е (трудозатраты, выраженные в человеко-месяцах) = 3,0E5I/12
Е = 3,0(88,96)
Е = 267 человеко-месяцы

Оценка длительности и стоимости разработки ПО 383
Для определения длительности работы над проектом применяется следующая
формула:
TDEV = 2,5 х (ЕH,35
TDEV = 2,5 х B67H'35
TDEV = 2,5G,07)
TDEV = 17,67 месяца
Для получения приближенной оценки необходимого количества разработчиков
проекта используется следующая формула:
S (среднее количество персонала) = трудозатраты / TDEV
S (среднее количество персонала) = 267 / 17,67
S (среднее количество персонала) = 15,11
Приближенная оценка производительности выполняется с помощью следующей
формулы:
Р (производительность) = размер / трудозатраты
Р (производительность) = 55,000 / 267
Р (производительность) = 206 LOG/человеко-месяцы
В базовой модели СОСОМО предлагается метод быстрых оценок трудозатрат,
времени разработки, количества персонала, а также производительности. При этом
исходными являются сведения о размере и режиме. При этом не понадобится ничего
более сложного, чем обычный калькулятор. Но и результат будет эквивалентен
оплате. Т.е. не составляет особого труда выполнить оценку трудозатрат на базовом уровне,
но полученные при этом результаты будут весьма приблизительными. С целью
улучшения процесса оценки Боэм (Boehm) разработал руководство по "настройке"
точности метода с помощью фактора корректировки сложности, описанного в
промежуточной модели СОСОМО.
Фаза распределения трудозатрат и пунктов графика в базовой
модели СОСОМО
В дополнение к оценке графика и трудозатрат во время разработки программного
проекта, зачастую требуется оценить, каким образом трудозатраты распределяются
среди действий первичного жизненного цикла. При использовании модели СОСОМО
обеспечивается упрощенный подход к применению фаз жизненного цикла. При
реализации этого подхода учитываются только планы и требования, разработка проекта
продукта, кодирование, а также интеграция и тестирование в качестве четырех фаз
разработки. Фаза поддержки рассматривается в качестве финальной фазы
жизненного цикла. Каждое из упомянутых действий может выполняться на протяжении любой
из перечисленных ниже фаз: анализ требований, разработка проекта продукта,
кодирование, планирование тестирования, проверка, офисные функции проекта,
управление конфигурацией и обеспечение качества, документирование и т.д.
А теперь будет рассмотрен пример фазы распределения трудозатрат и пунктов
графика (табл. 11.3). Предположим, что размер проекта, выполняемого во
внедренном режиме, составляет 80 KLOC.
Е (трудозатраты, выраженные в человеко-месяцах) = 3,6(KLOC) 1,2° =
= 3,б(80I-2° = 3,6A92,18) = 692 человеко-месяца
TDEV (время разработки) = 2, 5(EH,32 = 2, 5 F92) °'32 = 2,5(8,106) =
= 20 месяцев

Таблица 11.3. Пример фазы распределения трудозатрат и пунктов графика в базовой модели СОСОМО. Здесь
оцененное значение SM = 692, а оцененное значение TDEV = 20
Планы в требова- Разработка Кодирование
ния проекта продукта
Интеграция и Итого
тестирование
Трудозатраты (%) (%
трудозатрат на каждой
основной фазе на основе
хронологических данных)
Трудозатраты (SM) =
типичный % трудозатрат на
данной фазе х оцененный
SM
График (%) (% графика на
каждой основной фазе,
определенный на базе
хронологических данных)
График (месяцы) =
типичный % графика на данной
фазе х оцененный TDEV
10% 12%
50,5%
0,1 х 692 SM = 6,92
месяца
0,12 х 692 SM = 83,04 0,505 х 692 SM =
месяца 349,46 месяца
4% 33%
38%
27,5%
0,275 х 692 SM •
190,3 месяца
25%
0,04 х 20 = 0,8 месяца 0,33 х 20 = 6,6 месяца 0,38 х 20 = 7,6 месяца 0,25 х 20 = 5
месяцев
Средняя численность пер 6,92/0,8 " 8,65
сонала на основной фазе (в среднем)
(трудозатраты[8М]/график
[месяцы])
83,04 / 6,6 = 12,5818 349,46/7,6 = 45,98 190,3/5 = 38,06
(в среднем) (в среднем) (в среднем)
100% трудозатрат,
распределенных на
4 основных фазах
Итого 692 месяца
(из расчета на 1
человеко-месяц)
100% графика,
распределенного на 4
основных фазах
20 месяцев общей
длительности
(график)
692/20 = 34,6
(в среднем)

Оценка длительности и стоимости разработки ПО 385
Промежуточная модель СОСОМО
В промежуточной модели СОСОМО используются значения размера и режимы,
подобные тем, которые применялись в базовой модели. Дополнительно применяются
15 переменных, называемых драйверами затрат, с помощью которых могут быть
объяснены и модифицированы уравнения трудозатрат (табл. 11.4). Идея, применяемая в
этом случае, заключается в том, что характеристики данного проекта управляют
затратами (трудозатратами).
Оценка трудозатрат в промежуточной модели СОСОМО
Входными данными в промежуточной модели СОСОМО являются показатели
KLOC (точно, как и в случае с базовой моделью СОСОМО) и значения драйверов
затрат, с помощью которых производится корректировка и улучшение оценки.
Соответствующее уравнение приводится в примечании 11.6.
Примечание 11.6. Формула для промежуточной модели СОСОМО
Трудозатраты (Е^а ^(рудц^р),^*^,;^., ^\.^^*X4 *£&**? ^ '^ ^,L '1. ,,..,'.1';; ,^,.
Обратите внимание, что константы для экспонент и коэффициенты различаются
для каждого режима (см. примечание 11.7 и табл. 11.4).
Примечание 11.7. Формула для промежуточной модели СОСОМО:
коэффициенты и экспоненты, измененные по сравнению с базовой моделью
Трудозатраты для органического режима: Е-3,2 х (размер) ^ х С
Трудозатратып»,^^^^^?'^^^^^^^'^ ?|- ^
Трудозатраты для внедренного режима: Ё "= 2,8 х (размер) :*С *
Таблица 11.4. Формулы для оценки трудозатрат в промежуточной модели
СОСОМО
Режим а Ь Формула для оценки трудозатрат
Трудозатраты = а х (размер)Ь х С
Органический режим 3,2 1,05 Е = 3,2х (S)'05x С
Сблокированный режим 3,0 1,12 Е = 3.0 х (S)U2x С
Внедренный режим 2,8 1,20 Е = 2,8 х (SI,2U х С
Драйверы затрат
Концепция, связанная с фактором корректировки трудозатрат (Effort adjustment
factor, EAF), заключается в том, что он создает эффект увеличения либо уменьшения
трудозатрат, а следовательно, и затрат, в зависимости от набора факторов среды.
Факторы среды иногда называются факторами корректировки затрат [C,s] либо
драйверами затрат. Определение этого фактора-множителя происходит в два этапа.
На этапе 1 драйверам затрат назначаются числовые значения.
На этапе 2 происходит перемножение драйверов затрат, в результате чего
генерируется фактор корректировки трудозатрат, т.е. С.

386 Глава 11
Фактор EAF представляет собой произведение факторов корректировки затрат,
как показано во врезке 11.8.
Факторы корректировки затрат могут сказываться на оценках графика и затрат
проекта, изменяя их в 10 и более раз!
Примечание 11.8. Произведение драйверов затрат образует фактор
корректировки затрат
Драйверы затрат группируются в виде четырех категорий, как показано в табл. 11.5.
Таблица 11.5. Категории драйверов затрат в промежуточной модели СОСОМО
Программный про- Компьютер
дукт
Персонал
Проект
Требуемая
надежность ПО (RELY)'
Размер базы данных
(DATA)
Сложность
программного продукта
(CPLX)
Ограничения времени Способности анали-
выполнения (TIME) тика (АСАР)
Ограничения основно- Опыт в создании при-
го хранилища (STOR) ложений (АЕХР)
Изменяемость вирту- Способности про-
альной машины (VIRT) граммиста (РСАР)
Оборотное время ком- Опыт в области
виртуальных машин
(VEXP)
Опыт в области
языков
программирования (LEXP)
Использование
практики
современного
программирования (MODR)
Использование
инструментов
разработки ПО (TOOL)
План требуемой
разработки (SCED)
пьютера (TURN)
Атрибуты программного продукта
Некоторые из атрибутов, которые могут изменять величину затрат проекта, могут
применяться наравне с самим продуктом или выполняться в ходе соответствующей
работы. Ниже перечислены эти атрибуты:
■ требуемая надежность — как правило, применяется в системах реального времени;
■ размер базы данных — в основном применяется в приложениях обработки данных;
■ сложность продукта — ограничения на время выполнения.

Оценка длительности и стоимости разработки ПО S87
Атрибуты, связанные с аппаратными средствами
Другие атрибуты имеют отношение к компьютерной платформе и могут
применяться в качестве средства поддержки, а также при наличии работы, которая должна
быть выполнена:
■ ограничения времени выполнения — применяются в том случае, когда
быстродействие процессора является ограниченным;
■ ограничения основного хранилища— применяются в случае, когда размер памяти
является ограниченным;
■ изменяемость виртуальной машины — включает аппаратное обеспечение и
операционную систему на целевом компьютере;
■ оборотное время компьютера — применяется при разработке.
Атрибуты проекта
Атрибуты, связанные с практикой и инструментами:
■ практика современного программирования — структурные или ОО-технологии;
■ современные инструменты программирования— CASE-инструменты, хорошие
отладчики, инструменты, используемые при выполнении тестирования;
■ сжатие (или расширение) графика— отклонение от идеала всегда удручает, но
меньшая степень отклонения всегда лучше, чем большая.
Атрибуты персонала
Некоторые атрибуты применяются для описания исполнителей работ:
■ способности аналитика;
■ опыт в создании приложений;
■ способности программиста;
■ опыт в области виртуальных машин, включая операционную систему и аппаратное
обеспечение;
■ опыт в области языков программирования, включая инструменты и практику.
Другие драйверы затрат
Несмотря на то, что наиболее часто с приложениями в рамках промежуточной
модели СОСОМО связываются указанные выше четыре категории атрибутов,
менеджер проекта может добавлять дополнительные атрибуты:
■ изменяемость требований — некоторые из них являются ожидаемыми, однако
большинство из них могут представлять значительную проблему;
■ изменяемость машины, предназначенной для разработки— нестабильные ОС,
компиляторы, CASE-инструменты и т.д.;
■ требования безопасности — применяются для классифицированных программ;
■ доступ к данным — иногда является весьма затрудненным;
■ влияние стандартов и навязанных методов;
■ влияние физического окружения.
Драйверы затрат выбираются в соответствии с их общей значимостью для всех
программных проектов, причем они являются независимыми от размера проекта.

388 Глава 11
Каждый драйвер затрат определяет умножающий фактор, который позволяет
оценить эффект действия атрибута на величину трудозатрат.
Числовые значения драйверов затрат при их совместном перемножении образуют
фактор корректировки, т.е. С, как показано в примечании 11.9.
Примечание 11.9. Произведение драйверов затрат
Рис. 11.9. Эффект влияния драйверов затрат

Оценка длительности и стоимости разработки ПО 389
Поскольку драйверы затрат являются мультипликативными, в случае, если
драйвер затрат не влияет на трудозатраты, его значение равно 1. При этом конечное
значение С не изменяется. Подобные драйверы затрат называются нормальными либо
"номинальными". Например, если опыт в области языков программирования (LEXP)
команды в рассматриваемой организации больше, чем аналогичный показатель в
любой другой организации в этом городе, значение LEXP будет оставаться равным 1.
Это связано с тем, что превосходящие способности в области языков
программирования нормируются в данной среде. Оценщик может выполнять поиск условий, при
наступлении которых возрастает показатель трудозатрат (произведение всех
драйверов затрат превышает 1) либо значение этого показателя уменьшается (произведение
всех драйверов затрат меньше 1). При поиске применяется критерий "обычности"
для данной среды. Как правило, объем трудозатрат увеличивает в случае, если
применяется новая технология, команда разработчиков только что сформирована либо
состоит из неопытных в данной области программистов, имеет место повышенная
сложность технологической проблемы либо имеют место другие условия, отличные
от стандартных. Если же требуется меньше трудозатрат, то это означает, что
подобные проблемы были успешно разрешены ранее.
На рис. 11.9 демонстрируется эффект действия драйверов затрат,
перемещающихся от сверхбольших до сверхмалых значений. Например, сложность продукта (CPLX)
может принимать значение 0,70 (очень низкое) и 1,60 (очень высокое). Этот
показатель становится заметным в случае, если произведение драйверов затрат ( С )
оказывает влияние на оценку трудозатрат. Если показатель CPLX представляет только
драйвер затрат, который не является номинальным, а физические трудозатраты
составляют 24 человеко-месяца. Уровень сложности может оказывать влияние на
трудозатраты, он ранжируется в диапазоне от 16,8 до 38,4 человеко-месяцев.
Обратите внимание, что "трапециевидная" кривая SCED перемещается от очень
малых значений к очень большим. Каким же образом могут быть определены
значения атрибутов этого феномена?
Возможные значения исходных 15 драйверов затрат перечислены в табл. 11.6.
Логическое обоснование присваиваемых значений производится в табл. 11.7.
Таблица 11.6. Значения драйверов затрат при разработке ПО
в рамках модели СОСОМО
Драйверы
затрат
Показатели
Очень Низкий Номиналь Высокий Очень Сверхвы-
ннзкий ный высокий сокий
Атрибуты продукта
Требуемая надежность 0,75 0,88 1,00 1,15 1,40
ПО (RELY)
Размер базы данных 0,94 1,00 1,08 1,16
(DATA)
Сложность программно- 0,70 0,85 1,00 1,15 1,30 1,65
го продукта (CPLX)

390 Глава 11
Драйверы
затрат
Очень
низкий
Окончание табл. 11.6
Показатели
Низкий Номиналь Высокий Очень Сверхвы-
ный высокий сокий
Атрибуты компьютера
Ограничения времени
выполнения (TIME)
Ограничения главного
хранилища (STOR)
Изменяемость
виртуальной машины (VIRT)
Оборотное время
компьютера (TURN)
Атрибуты персонала
Способности аналитика 1,46
(АСАР)
Опыт в создании прило- 1,29
жений (АЕХР)
Способности програм- 1,42
миста (РСАР)
Опыт в области вирту- 1,21
альных машин (VEXP)
Опыт в области языков 1,14
программирования
(LEXP)
Атрибуты проекта
Использование практики 1,24
современного
программирования (MODP)
Современные инстру- 1,24
менты
программирования (TOOL)
0,87
0,87
1,19
1.13
1,17
1,10
1,07
1,00
1.00
1,00
1,00
1,00
1,00
1,00
1,00
1,00
1.11
1,06
1,15
1,07
0,86
0,91
0,86
0,90
0,95
1,30
1,21
1,30
1,15
0,71
0,82
0,70
1,66
1,56
Требуемый график
разработки (SCED)
1,23
1,10 1,00
1,10 1,00
1,08 1,00
0,91 0,82
0,91 0,82
1,04 1,10
Эта модель, которая является чувствительной к CPLX, представляет определения
оценок для текущего драйвера затрат в отдельном инструменте. В табл. 11.8-11.11
демонстрируется, каким образом CPLX определяется для пяти различных приложений:
контрольные операции, вычислительные операции, операции, зависящие от
устройств, операции менеджмента, а также требования и разработка проекта продукта.

Оценка длительности и стоимости разработки ПО 391
Таблица 11.7. Оценки драйверов затрат для ПО, разрабатываемого
с применением промежуточной модели СОСОМО
Атрибуты

программного продукта
RELY
DATA
CPLX
Атрибуты
компьютера
TIME
Очень
низкая
Эффект:
небольшое
неудобство
См.
отдельные
таблицы CPLX
Оценки драйверов
Низкая
Небольшие,
легко
возмещаемые
потери
БД
байт/прог.
DSI<10
См.
отдельные
таблицы CPLX
Номиналь
ная
Средние

возмещаемые потери
10<БД
байт/прог.
ELOC < 100
См.
Отдельные
таблицы
CPLX
Использует-
затрат
Высокая
Большие
финансовые
потери
100 < БД
байт/прог.
ELOC-1000
См.
отдельные
таблицы CPLX
Использует-
Очень
высокая
Риск для

человеческой жизни
БД
байт/прог.
ELOC =>
1000
См.
Отдельные
таблицы
CPLX
Использует-
Сверхвыс
окая
См.
отдельные
таблицы CPLX
Использует-
ся<=50% ся70%дос- ся85%дос- ся95%дос-
доступного тупного тупного тупного
времени времени времени времени
выполнения выполнения выполнения выполнения
STOR
VIRT
TURN
Атрибуты
персонала
АСАР
АЕХР
Изменения:
верхние
12 мес;
нижний 1 мес

Используется <= 50%
доступного
хранилища
Изменение:
верхние
6 мес;
нижние две нед
Интерак- Средний
тивный обход
(< 4 часов)

Используется 70%
доступного
хранилища
Изменение:
верхние
2 мес;
нижний одна
нед
4-12 часов
Использует-
Используется 85% дос- ся 95%
доступного
хранилища
Изменение:
верхние
2 нед;
нижние два дня
>12 часов
тупного
хранилища
15-й про-
центиль
Опыт <« 4
месяцам
35-й про-
центиль
1год
55-й про-
центиль
Згода
75-й про-
центиль
6 лет
90-й про-
центиль
12 лет

392 Глава 11
РСАР
VEXP
LEXP
Атрибуты
проекта
MODP
TOOL
SCED
Очень
низкая
15-й про-
центиль
Опыт <= 1
месяца
Опыт<= 1
месяца
Не
используется
Базовые

микропроцессорные

инструменты
75%
номинала
Оценки драйверов затрат
Низкая
35-й про-
центиль
4 месяца
4 месяца
Начальное

использование
Базовые
мини-

инструменты
100%
номинала
Номиналь
ная
55-й про-
центиль
1год
1 год
Некоторые
применения
Базовые
миди/макси

инструменты
75%
номинала
Высокая
75-й про-
центиль
Згода
Згода
Общее

пользование
Строго мак-
си прог./
тестовые

инструменты
130%
номинала
Окончание табл. 11.7
Очень вы- Сверхвыс
сокая окая
90-й про-
центиль

Использование
процедурами

Дополнительные
треб,
описание.
управление,
докум.
инструменты
160%
номинала
Таблица 11.8. Таблица корректировки трудозатрат CPLX для контрольных
операций
Описание
Оценка
Простой код, содержащий не вложенные SP-операторы: DO, CASE, IF THEN Очень низкая
ELSE, простые предикаты
Непосредственное вложение SP-операторов; преимущественно простые Низкая
предикаты
Преимущественно простое вложение; небольшой объем межмодульного Номинальная
контроля; таблицы решений
Высокая степень вложения SP-операторов наравне со многими сложными Высокая
предикатами; контроль стека и очереди; достаточный уровень
межмодульного контроля
Кодирование с применением рекурсии и повторного вхождения; обработка Очень высокая
прерываний с фиксированным приоритетом
Составление графика распределения ресурсов с динамически изменяющи- Сверхвысокая
мнея приоритетами; кодирование на уровне микрокода

Оценка длительности и стоимости разработки ПО 393
Таблица 11.9. Таблица корректировки трудозатрат CPLX
для вычислительных операций
Описание Оценка
Оценка простых выражений, таких как A=B + C*(D-E) Очень низкая
Оценка умеренных по сложности выражений, таких как D = SQRT Низкая
(В** 2-4.0* А* С)
Использование стандартных математических и статистических процедур; Номинальная
базовые операции с матрицами/векторами
Базовый числовой анализ: многомерная интерполяция, обычные диффе- Высокая
ренциальные уравнения, базовые операции усечения/округления
Сложный и структурированный числовой анализ: почти вырожденные Очень высокая
матричные равенства, уравнения в частных производных
Сложный и не структурированный числовой анализ: высокоточный ана- Сверхвысокая
лиз зашумленных стохастических данных
Таблица 11.10. Таблица корректировки трудозатрат CPLX для операций,
не зависящих от устройств
Описание
Оценка
Простые операции считывания/записи, имеющие простой формат
Отсутствие необходимости в знании характеристик конкретного процессора
либо устройства ввода/вывода. Ввод/вывод осуществляется на уровне
операторов GET/PUT; не требуется дополнительные знания либо перекрытие
Обработка операций ввода/вывода включает выбор устройства, проверку
статуса, а также обработку ошибок
Операции на физическом уровне ввод/вывода (трансляционный адрес
физического хранилища; поиск, чтение и т.д.); оптимизированное перекрытие
ввода/вывода
Процедуры, применяемые для диагностики прерываний, обслуживания,
маскировки; работа с коммуникационным каналом
Кодирование на базе устройств, зависимых от времени, микропрограммные
операции
Очень низкая
Низкая
Номинальная
Высокая
Очень
высокая
Сверхвысокая
Таблица 11.11. Таблица корректировки трудозатрат CPLX для операций,
реализующих управление данными
Описание
Оценка
Простые массивы, хранящиеся в основной памяти Очень низкая
Простые файлы, для которых не выполняется разбиение с изменением Низкая
структуры данных, отсутствует изменение данных и промежуточные файлы
Несколько входных файлов н один выходной файл; простые структурные Номинальная
изменения, простые изменения данных

394 Глава 11
Окончание табл. 11.11
Описание Оценка
Процедуры специального назначения, активизируемые содержимым потока Высокая
данных; сложная реструктуризация данных на уровне записей
Параметризованная процедура структурирования файлов, управляемая па- Очень высокая
раметрами; обработка файлов; обработка команд; оптимизация поиска
Динамические относительные структуры с высокой степенью запараллели- Сверхвысокая
нация; управление данными естественных языков программирования
Примеры реализации промежуточной модели СОСОМО
Ниже приводятся два примера промежуточной модели СОСОМО. В первой
модели применяются нормальные значения для драйверов затрат; в другой модели
увеличиваются оценки для показателей АСАР и РСАР.
Пример 1
Рассматривается программный проект внедренного режима, оцениваемый
показателем в 10 K.LOC, реализующий функции обработки коммуникаций в коммерческом
микропроцессоре.
■ Формула для внедренного режима обеспечивает номинальное значение
трудозатрат:
Еп = 2,8 A0I'20 = 2,8A5,85) = 44 человеко-месяца
■ В результате оценивания среды проекта получаются результаты, обеспечивающие
вычисление вариантов значений множителя драйвера затрат. Эти значения
перечислены в табл. 11.12.
■ Фактор корректировки применяется по отношению к номинальным
трудозатратам:
Е = 2,8A0I,20 X С = 44 X 1,17 = 51 человеко-месяц
Проект 2
При выполнении оценки проекта получается значение, равное 44 человеко-
месяцам (SM). Если при выполнении проекта привлекается более
квалифицированный персонал, оценки РСАР и АСАР уменьшаются от номинальных A,00) до
высоких @,86). Однако затраты на персонал возрастают с $5000 до $6000 из
расчета на один SM. Предположим, что значения других драйверов затрат будут
номинальными A,00).
Фактор корректировки трудозатрат (EAF) = С
= RELY X DATA X CPLX X TIME X STOR X VIRT X TURN X ACAP X AEXP X PCAP
X VEXP X LEXP X MODP X TOOL X SCED = 1,00 X 1,00 X 1,00 X 1,00 X 1,00
X 1,00 X 1,00 X 0,86 X 1,00 X 0,86 X 1,00 X 1,00 X 1,00 X 1,00 X 1,00
= 0,74
Скорректированный показатель человеко-месяцев: 44 SM X 0,74 = 32,6
Разница в затратах: 44 SM @ $5000/SM = $220000
32,6 SM @ $6000/SM = $195600
Разница: $220000 - $195600 = $24400

Оценка длительности и стоимости разработки ПО 395
Таблица 11.12. Значения драйверов затрат для промежуточной модели
СОСОМО, пример 1
Драйвер
затрат
Применение
Оценка
Множитель
трудозатрат
RELY Локальное применение системы. Не возникают
серьезные проблемы с восстановлением данных
DATA 30000 байт
CPLX Обработка коммуникаций
TIME Будет применяться 70% свободного времени
STOR 45 Кбайт из 64 Кбайт доступного хранилища G0 %)
VIRT Основано на коммерческом микропроцессорном
аппаратном обеспечении
TURN Среднее время обхода равно 2 часам
АСАР Опытный старший аналитик
АЕХР 3-летний опыт
РСАР Опытные старшие программисты
VEXP 6 месяцев
LEXP 12 месяцев
MODP Большинство технологий применяется более
одного года
TOOL На уровне базового миникомьютерного
инструмента
SCED 10 месяцев
EAF С = 1,00 х 0,94 х 1,30 х 1,11 х 1,06 х 1,00 х 1,00 х
0,86 х 1,00 х 0,86 х 1,10 х 1,00 х 0,91 х 1,10 х 1,00
Номинальная 1,00
Низкая
Очень высокая
Высокая
Высокая
Номинальная
Номинальная
Высокая
Номинальная
Высокая
Низкая
Номинальная
Высокая
0,94
1.30
1.11
1.06
1,00
1,00
0.86
1,00
0,86
1,10
1,00
0,91
Низкая
1,10
Номинальная 1,00
С=1,17
Заключение: В настоящем примере использование услуг более
квалифицированного персонала обходится дешевле, несмотря на возросшие при этом расходы
на оплату труда.
Как показано на рис, 11.10, при использовании в качестве базисного значения
размера, план использования кадрового обеспечения (трудозатраты, распределенные
по времени) будет изменен с учетом применения настроек драйверов затрат.
Хотя рассмотренные 15 драйверов затрат способствуют лучшему использованию
сред, в которых отсутствуют либо оказывают незначительное влияние хронологические
данные, они не могут применяться одинаковым образом в нескольких организациях
либо даже в одной организации на протяжении длительного периода времени. То, что
было разработано для TRW под руководством Боэма (Boehm) в конце 1970-х и начале
1980-х годов, вряд ли сможет применяться где-либо еще, возможно, даже не сможет
использоваться в самой TRW в 1990-х годах. В этом случае может помочь использование
модели (а не фактических данных), а также ее настройка с учетом применения в данной
среде. Согласно Боэму, настройка производится путем добавления, изменения и удаления
драйверов затрат, а также с помощью изменения оценок (от сверхвысоких до очень
малых). Данные из 63 оригинальных проектов Боэма могут применяться до тех пор, пока

396 Глава 11
не будут собраны фактические данные. После того как станут доступными фактические
данные, с их помощью будут изменены исходные данные, а модель будет калиброваться до
тех пор, пока она не будет полностью соответствовать данному типу приложения и данной
организационной среде либо среде и приложению одновременно. Многие производители
поддерживают автоматизированные инструменты, предназначенные для выполнения
оценок, имеющих заданные размер и сложность. Многие из этих инструментов
обеспечивают автоматизированную поддержку добавления фактических данных и калибровку
модели путем изменения показателя, коэффициента, значений драйвера затрат либо всех
трех параметров одновременно. Калиброванная модель может быть создана путем
использования пяти точек данных (проект, для которого определяются размеры, временной
период, а также трудозатраты, которые являются наблюдаемыми).
Рис. 11.10. Подгонка драйверов затрат, применяемых при работе с персоналом
Детализированная модель СОСОМО
Теперь рассмотрим наиболее сложную версию СОСОМО. Она включает
следующие дополнительные шаги.
■ Программа разбивается на специфические продукты и компоненты этих продуктов.
Согласно Боэму (Boehm), подобное разбиение называется трехуровневой иерархией
продуктов: система, подсистема и модуль. Верхний уровень, уровень системы,
используется для применения самых общих отношений, связанных с проектом, таких
как номинальные трудозатраты и уравнения графика, а также для применения
номинальных трудозатрат на уровне проекта и пофазной разбивки графика. Самый
нижний уровень, уровень модуля, описывается с помощью показателя KLOC в
модуле и драйверов затрат, которые могут варьироваться на этом уровне. Второй
уровень, уровень подсистемы, описывается с помощью оставшихся драйверов затрат
и может отличаться в различных подсистемах. Однако этот уровень не будет
изменяться в различных модулях, входящих в состав одной подсистемы.

Оценка длительности н стоимости разработки ПО 397
■ Анализ драйверов затрат производится отдельно для каждого компонента.
Подсистемы и модули наследуют драйверы затрат системы. Они называются: RELY,
VIRT, TURN, MODP, TOOL и SCED. Модули наследуют драйверы затрат
подсистемы. Эти драйвера называются: DATA, TIME, STOR, АСАР, АЕХР (проявляется
тенденция к применению одних и тех же модулей внутри подсистемы). Драйверы
затрат модуля имеют такие названия: KLOC, AAF, CPLX, PCAP, VEXP и LEXP.
Драйвер AAF является новым — результат адаптации существующих модулей.
Дополнительная информация доступна до этапа изменения существующего ПО —
благодаря этим данным обеспечиваются более корректные оценки. Как правило,
большинство создаваемых программных продуктов не разрабатываются "с нуля", а
являются результатом повторного использования существующих модулей,
реализуемых с помощью новейших методов (например, объектно-ориентированных).
Использование детализированной модели СОСОМО зачастую эквивалентно
дополнительным трудозатратам. Следует отметить, что затраты на этапе повторного
использования не всегда равны нулю. Ведь не обойтись без трудозатрат на этапе
работы с существующим кодом и разработки соответствующего интерфейса.
Затраты на переписывание системы могут быть меньшими, чем продолжение ее
поддержки (по причине энтропии структуры). Однако переписывание старой
системы может быть более дорогостоящим, чем создание "новой" системы.
Распространено мнение, согласно которому точка экономической безубыточности
достигается в результате изменения 20% кода; после прохождения точки
безубыточности повторное использование кода не будет эффективным.
■ Действия по разработке проекта разбиваются на фазы. В работах Боэма (Boehm)
используются четыре основных фазы: требования (RQ), разработка проекта
продукта (PD), детализированный дизайн продукта (DD), кодирование и
тестирование разрабатываемого модуля (CUT). Интеграция и тестирование (IT), а также
поддержка (MN) описываются на протяжении всего жизненного цикла. Фазы
могут применяться для разбиения систем, подсистем, и/или модулей. На каждой
фазе могут применяться различные множители трудозатрат. Различные значения
множителей драйверов затрат устанавливаются на каждом из трех уровней
иерархии программных продуктов (система, подсистема, модуль), а также на каждой
фазе (RPD, DD, CUT, IT) внутри иерархий.
Составление графика с помощью модели СОСОМО
После оценки размера и величины трудозатрат начинается этап составления
графика работ. В этот процесс включается настройка структуры WBS (при
необходимости), а также определение ответственности для членов команды. При составлении
графика также планируется начальная и конечная дата выполнения каждой задачи,
указываются зависимости между задачами и обеспечивается параллелизм выполнения
(если это возможно). При наличии зависимостей одна задача нуждается во входных
данных другой либо нескольких других задач. В силу этого приходится ожидать
завершения выполнения других задач, после чего может начаться выполнение текущей
задачи. При наличии параллелизма несколько задач могут выполняться
одновременно. Диаграммы Ганта и Перта представляют собой два наиболее широко
используемых метода, используемых для графического представления задач, зависимостей,
параллелизма и временных интервалов. При создании этих диаграмм используются
автоматизированные инструменты.

398 Глава 11
Подгонка модели СОСОМО
Организация-заказчик может заказать разработку специальным образом
калиброванной версии, которая должна более точно отражать текущие применяемые
практики и возможности. Существует три различных способа, применяемых для повторной
калибровки и корректировки уравнений промежуточной модели СОСОМО с учетом
применения локальных условий и с основой на локальной хронологической базе
данных для и проектов: коэффициент повторной калибровки уравнений трудозатрат,
настройка режима (повторная калибровка показателя и коэффициента), а также
проверка значений драйверов затрат. В этой книге мы не будем подробно рассматривать
формулы и детали, касающиеся повторной калибровки моделей. Подробные
инструкции могут быть найдены в книге Боэма (Boehm), Software Engineering Economics.
Точная повторная калибровка коэффициента требует наличия базы данных,
которая содержит, как минимум, пять проектов. Для точной повторной калибровки
показателя база данных должна включать, как минимум, десять проектов.
Преимущества модели СОСОМО
Ниже перечислены преимущества модели СОСОМО:
■ фактические данные подгоняются в соответствии со многими реальными
программами, поддерживающих набор констант СОСОМО и факторов
корректировки, которые могут идеально соответствовать организации;
■ применяемый в данном случае процесс является повторяемым:
■ метод позволяет добавлять уникальные факторы корректировки, связанные с
данной организацией;
■ он является достаточно универсальным и может поддерживать различные
"режимы" и "уровни";
■ идеально подходит для проектов, между которыми нет существенных отличий
относительно размера, сложности или протекания процесса;
■ возможна высшая степень калибровки с опорой на предыдущий опыт,
■ обязательная документация;
■ простота в применении.
Недостатки модели СОСОМО
Ниже перечислены недостатки модели СОСОМО:
■ игнорируется изменяемость требований (однако в организациях этот момент
может учитываться с помощью дополнительного фактора корректировки, EAF);
■ игнорируется документация и другие требования;
■ игнорируются атрибуты заказчика— навыки, кооперирование, знания и
способность к реагированию;
■ слишком упрощается влияние вопросов безопасности;
■ игнорируются проблемы обеспечения безопасности ПО;
■ не учитывается среда разработки ПО;
■ игнорируются уровни взаимодействия персонала;

Оценка длительности и стоимости разработки ПО 399
■ игнорируются многие вопросы, связанные с аппаратным обеспечением.
■ все уровни зависят от оценки размера — точность оценки размера оказывает
влияние на точность оценки трудозатрат, время разработки, подбор персонала и
оценку производительности;
■ оценки, основанные на опыте, могут быть некорректными по причине
устаревания используемых хронологических данных либо по причине забывчивости
специалиста по оценке;
■ существует зависимость между знаниями по драйверам затрат и количеством
времени, затраченного на каждой фазе.
Доктор Фрайли (Dr. Frailey) отметил некоторые другие потенциальные моменты,
указанные в следующем перечне.
■ Модель СОСОМО изначально представляет трудозатраты на этапе разработки (от
фазы планирования до фазы реализации). Проблемы поддержки, повторного
рабочего процесса, переноса и повторного использования не могут четко
описываться в рамках одной и той же модели. Эти действия могут быть также оценены с
помощью применяемых вариаций базовой модели.
■ При использовании модели СОСОМО предполагается наличие очень простого
базового уровня трудозатрат, используемого при управлении конфигурацией и
обеспечении качества. В этом случае используется примерно 5% общего бюджета
(основываясь на типичной коммерческой практике, принятой при использовании
модели СОСОМО). Показатели затрат могут быть увеличены в 2-4 раза при
разработке современного ПО с учетом сложности современных программных продуктов.
Ш Ваши данные не должны соответствовать данным, применяемым при разработке в
рамках модели СОСОМО, — если это условие не выполняется, потребуется сбор
данных, необходимых для корреляции модели.
■ В модели СОСОМО предполагается использование базовой модели процесса каскада:
разработка проекта C0%), кодирование C0%), интеграция и тестирование D0%).
■ В модели СОСОМО исключаются следующие компоненты:
- разработка и спецификация требований, которые не слишком часто
применяются в некоторых коммерческих приложениях (даже, несмотря на то, что эта
часть выполненной оценки обычно рассматривается в качестве области
ответственности функций инжиниринга систем или анализа систем, она будет
завышаться до тех пор, пока программисты не выполнят точную оценку затрат);
- прирост на 20% обычно требуется на фазе формулирования требований, —
даже если применяются объектно-ориентированные методы (рис. 11.10);
- менеджмент (обычно выполняется менеджмент на уровне строк, а не общий
менеджмент);
- накладные расходы;
- расходы на командировки и другие побочные расходы;
- системная интеграция и поддержка тестирования;
- поддержка тестовых полей;
- компьютеры;
- источники поставок;
- определенное место в офисе.

400 Глава 11
Согласно Боэму (Boehm), трудозатраты изначально были распределены таким
образом, чтобы 30% приходилось на дизайн, 30% — на кодирование и тестирование
модуля, а 40% — на интеграцию и тестирование.
Если добавить 20% трудозатрат к общему показателю трудозатрат для анализа
требований, получаем 17% на фазе анализа требований, 25% — на фазе разработки
проекта, 25% — на фазе кодирования и тестирования модуля И 33% — на фазе
интеграции и тестирования.
Объем затраченного времени является максимальным на фазе анализа требований
и разработки проекта, но конкретная специфика зависит от используемого процесса.
Обычные значения для распределения времени составляют 30% на фазе анализа
требований, 30% — на фазе разработки проекта, 15% — на фазе кодирования, а 25% —
на фазе интеграции и тестирования.
Некоторые типичные проблемы, влияющие
на выполнение графика или уменьшение
трудозатрат
Препятствия общего характера, затрудняющие достижение целей типа "быстрее,
дешевле»:
■ отсутствие адекватного оборудования, ПО, инструментов, квалифицированного
персонала и т.д.;
■ замедленные циклы утверждения;
■ плохая координация с другими дисциплинами, другими компаниями и т.д.;
■ недостаточно подготовленные заказчики и менеджеры;
■ иррационально мыслящие заказчики и менеджеры;
■ преднамеренные препятствия в лице конкурентов.
Системный
анализ
Системные
требования
Разработка
программного
проекта
де
Кодирование
льСОСОМОвкг
ю
Системная
интеграция
и тестирование
Системная
интеграция
и тестирование
Рис. 11.11. Фазы, включенные в модель СОСОМО
А теперь последнее замечание. Накапливайте данные, особенно оценки и
фактические результаты (рис. 11.12). Чем больше фактов окажется в вашем распоряжение,
тем более аргументированной будет ваша позиция во время ведения переговоров.
Подготовьтесь к выполнению частой повторной оценки, начиная с ранних стадий.
Воспользуйтесь моделью и инструментами моделирования по мере возможности;
учитывайте факторы среды, а также калибруйте модель/инструмент в соответствии с
потребностями вашей организации.
Модель СОСОМО II
Модель СОСОМО II является улучшенной версией исходной модели СОСОМО,
обладающей улучшенными возможностями. Благодаря этой модели облегчается
выполнение оценки для объектно-ориентированного ПО, программ, созданных с при-

Оценка длительности и стоимости разработки ПО 401
менением спиральной либо эволюционной моделей, а также приложений,
разработанных на базе готовых коммерческих программ. В частности, эта модель
применяется при оценке программных затрат на разработку баз данных и возможностей
поддержки инструментов в процессе непрерывного улучшения модели. Эта модель также
формирует аналитическую основу, набор инструментов и техник, применяемых при
оценке эффектов, связанных с улучшением технологии разработки ПО на базе
графиков и затрат на фазе жизненного цикла разработки ПО.
На ранних концептуальных стадиях проекта в модели применяется оценка на основе
метода объектных точек с целью вычисления трудозатрат. На ранних стадиях
разработки проекта, когда еще практически ничего не известно о размере проекта и о его
разработчиках, не скорректированные функциональные точки применяются в качестве
входных данных для модели. После того как была выбрана архитектура, фазы
разработки проекта и кодирования начинаются с ввода параметра SLOC для модели.
120
100
2 80
Л
е
Я 60
I
*- 40
20
0
123456789 10
График—месячный календарь
Рис. 11.12. Отслеживание оценок и фактических данных
В модели СОСОМО II поддерживаются вероятностные диапазоны оценок,
представляющие одно стандартное отклонение на фоне наиболее благоприятных оценок.
Аккомодирующие факторы, которые получили не слишком большое
распространение в первой версии модели СОСОМО, в настоящее время применяются для создания
возможности повторного использования ПО, а также повторного инжиниринга. Две
последние возможности представляют собой автоматизированные инструменты,
используемые для трансляции существующего ПО. В модели СОСОМО II также
учитывается изменчивость требований для выполняемых оценок.
В то время как показатель размера в уравнении оценки трудозатрат в
оригинальной модели СОСОМО варьируется в зависимости от текущего режима разработки, в
модели СОСОМО II применяются факторы масштабирования с целью обобщения и
замещения эффектов в режиме разработки.
В композиционной прикладной модели СОСОМО II для выполнения оценок
применяется метод объектных точек. При использовании этой модели предполагается
использование интегрированных CASE-инструментов с целью выполнения быстрого
прототипирования. Объекты включают экраны, отчеты и модули, имеющие
отношение к языкам программирования третьего поколения. Оценивается количество
физических объектов, сложность каждого объекта, а также вычисляется взвешенный
' Оценка
' Фактические затраты

402 Глава 11
итог (подсчитывается количество объектных точек). Также оценивается процентное
соотношение показателей повторного использования и ожидаемой
производительности. На основе этой информации может выполняться оценка трудозатрат.
В модели СОСОМО II явным образом обеспечивается доступ к дополнительной
информации на поздних стадиях проекта, обрабатываются нелинейные затраты при
повторном использовании программных компонентов, а также оцениваются эффекты
воздействия нескольких факторов по шкале показателей убытков. Некоторые из
перечисленных параметров представляют собой оценку оборота персонала, географическое
распределение команды, а также "зрелость" процесса разработки в том виде, в котором
она описывается Институтом SEI. В этой модели также проверяются некоторые
значения коэффициента, и устраняется присутствие "сосредоточенных неоднородностей" в
старой модели (связанных с "режимами разработки", поддержкой и адаптацией).
Фактически СОСОМО II включает три различные модели.
■ Композиционная прикладная модель — эта модель подходит для проектов,
созданных с помощью современных инструментальных средств, применяемых для
"строительства" GUI. Модель основывается на новых объектных точках.
■ Модель ранней разработки проекта — Эта модель применяется для получения
приближенных оценок проектных затрат и периода выполнения проекта перед тем, как
будет определена архитектура в целом. В этом случае используется небольшой набор
новых драйверов затрат и новых уравнений оценки. Также в качестве базы
используется набор не настраиваемых функциональных точек либо KSLOC.
■ Пост-архитектурная модель— наиболее детализированная модель СОСОМО II,
которая используется после разработки общей архитектуры проекта. В состав
этой модели включены новые драйверы затрат, новые правила подсчета строк, а
также новые уравнения.
Усилиями фирмы Rational, Inc. модель СОСОМО II интегрирует фазы и основные
стадии с аналогичными объектами, разрабатываемыми фирмой Rational Unified
Process, которая, в свою очередь, поддерживает распределение фаз и действий для
оценщиков, использующих модель СОСОМО П.
Математическая модель SLIM
В регрессионном моделировании делается упор на создание формулы, которая
лучше всего представляет точки данных рассеяния. В математическом
моделировании главным является сопоставление данных с формой существующей
математической функции. В начале 1960-х годов, Питер В. Норден (Peter V. Norden) из фирмы
IBM пришел к выводу, что при внедрении проектов по исследованию и разработке
могут применяться хорошо определенные прогнозируемые шаблоны нагрузки персо-
нала. При описании этих шаблонов используется математическая формула описания
Рейлайха (Rayleigh) (примечание 11.10), график которого приводится на рис. 11.12.
Позднее, в 1970-х годах, Лоуренс Ш. Патнам (Lawrence H. Putnam) (см.
Менеджмент качества ПО (Quality Software Management), QjSM) применил результаты Норде-
на к жизненному циклу разработки ПО. При этом проверялось существование
оптимальной кривой подбора персонала для текущего проекта. Он начал свою работу с 50
проектов, имеющих отношение к американской армии, а теперь располагает
эмпирическими сведениями о нескольких тысячах проектов. Используя статистический
анализ проектов (QSM представляет собой собранные данные по завершенным проек-

Оценка длительности и стоимости разработки ПО 403
там, начиная с 1975 года), Патнам обнаружил, что взаимосвязь между тремя
основными элементами, возникающими при оценке ПО (размер, график и трудозатраты)
весьма напоминает функцию Нордена/Рейлайха. По мере роста размера ПО то же
самое происходит с трудозатратами, временем и количеством дефектов, но при этом
проявляются различные типы взаимосвязей (экспоненциальная и логарифмическая).
Он пришел к выводу, что уменьшение размера является одним из способов
сокращения графика, трудозатрат и количества дефектов. Размер может быть уменьшен
несколькими способами, включая "зачистку требований" (устранение "украшательств" и
второстепенных свойств), разбиение на фазы либо последовательную доставку,
повторное использование, а также применение коммерческих готовых продуктов.
Примечание 11.10. Функция Нордена-Рейлайха
О'г-'г-ООО0>'«ГС\|С0ОС0С'ЭС\|1ЛООС'Э0>С\|Г"~О<0ОООО
■«frCOC\|<OOCOCOOJ<OOCOCOOJ<Oi-'^-f-i-<00>'*-CO<N<00->*
--'■-cMc\i<Ncoc')'«fr'«fr'«frmm<oto<oh-r--r-eocoo>o>oo
Время
Рис. 11.13. Кривая подбора персонала Рейлайха
Подобно Боэму (Boehm), Патнам использовал диаграммы рассеяния и методики
подгонки кривых с целью поиска взаимосвязей с наблюдаемыми им данными. После
построения линии основного тренда, представляющей все наблюдаемые точки данных
(шкалы размера и месяцев), вычисляется среднее значение E0% проектов находится
над линией, а 50% проектов находится ниже линии), наряду со значениями для +1сг
(только 16% точек данных находится над линией; 84% точек данных— ниже линии) и

404 Глава 11
для -la (только 16% точек данных находится под линией; 84% точек данных находятся
над линией, как показано на рис. 11.14. Если в результате выполненной оценки проекта
выясняется, что он находится над линией, определяемой параметром +1о, это означает,
что продукт не может быть разработан, — проект находится в так называемой зоне
недосягаемости. Если в ходе выполнения оценки проекта выясняется, что он попадает в
область под линией -1с, это означает невозможность создания продукта в этой зоне (эта
.юна известна под названием зоны невозможности, хотя многие менеджеры проектов и
и пом случае будут пытаться продвигаться вперед любой ценой).
1о
Зона недосягаемости
{
о о о .»—-*
j;.»—-* О Зона недосягаемости
Среднее
значение
Время
(фиксировано)
Размер (фиксирован)
Рис. 11.14. Зоны непрактичности и невозможности
Процесс управления жизненным циклом разработки ПО QSM (QSM's Software Life-
(\ tie Management, SLIM) состоит из методологий, связанных воедино с помощью инст-
pwieiiToB принятия решений: SLIM-Estimate©, SLIM-Control© и SLIM-Metrics©.
Инструмент SLIM-Esrimate© поддерживает оценивание и планирование, SLIM-Control© — от-
к-жипапие и прогнозирование, a SLIM-Metrics©—захват данных и анализ.
Клаимосвизь, установленная при разработке ПО, описывается в примечании 11.11.
Примечание 11.11. Взаимосвязь QSMSPR
Производимое ПО (размер) «■ трудозатраты/время на производственномуроьщ
Как и в случае с почти всеми моделями оценки и измерения, парадигма
оценивания может быть проиллюстрирована с помощью треугольников (рис. 11.4) либо квад-
}мгиков (рис. 11.5). При этом обеспечивается наличие многих степеней свободы. Ес-
.111 производительность возрастает, расширяется график либо добавляются ресурсы.
1 акже может увеличиваться размер (обратная взаимосвязь тоже возможна).
lice методы и процессы, реализующие измерение и оценивание, взаимодействуют
t коллекциями фактических данных. Преимущество, проявляющееся при использо-
Н.Ш1Ш автоматизированного инструмента, заключается в том, что большинство из
.mix инструментов поддерживают "стартовые наборы" данных, основанных на
наблюдаемых проектах. Исходя из этой точки зрения, можно отметить, что модель
SLIM является особенно полезной в связи с тем, что могут собираться данные из
более чем 5500 проектов. Программные уравнения Патнама связывают размер ПО со
временем разработки и общим объемом трудозатрат. Уравнение может быть
выведено путем связывания двух математических определений производительности:
количество/численность персонала и формулы Патнама, связывающей нроизводитель-
погт1. и сложность (примечание 11.12).

Оценка длительности и стоимости разработки ПО 405
Примечание 11.12. Уравнение Патнама
Источник: Putnam, Larry H. and William Nfyers. Measures for Excellence: Reliable Software
on Time, Within Budget Englewood Cliffs, NJ: Yourdon Press, 1992.
Продукт = производительность x трудозатраты х время
S = CxK,/sxt//J
где
S = размер ПО (в LOC)
С = фактор среды, зависящий от состояния технологии
К = общие трудозатраты для всего проекта: ■ ;.? .
t„ = ограничения времени поставки (график), выраженные в годах
Фактор среды может быть вычислен следующим образом:
c=s/kvV/s " ''" '
Коэффициенты К и td определяются на базе хронологических данных, относящих
ся к предыдущим проектам с размером S. Настраиваемое значение С может
применяться для будущих оценок.
Технологическая константа С объединяет эффект использования инструментов,
языков программирования, методологии, процедур гарантирования качества, стандар
гов и т.д. Она определяется на основе хронологических данных (прошлые проекты).
Значения технологической константы могут варьироваться от 610 до 57314. Констант:»
С определяется, исходя из размера проекта, размера области под кривой трудозатрат, -л
также длительности проекта.
С-ценка: С = 2000 — плохо, С = 8000 — хорошо, С = 11000 — превосходно
Например, предположим, что значение технологической константы С равно 4000
(среднее значение), а размер ПО оценивается величиной в 200000 LOG. Л теперь
подставим эти значения в формулу:
:тзщие трудозатраты жизненного цикла В = A/Т4) (S/CK
'.■■"Г'щие трудозатраты жизненного цикла В = A/Т4) B00000/4000K = а/Т4) E0)'
трудозатраты на разработку Е = 0,3945 В
Если период целевой разработки равен двум годам, то
■15щие трудозатраты жизненного цикла В = A/16) E0K = 7812,5 человеко-лс."
трудозатраты на разработку Е = 0,3945 В = 3,082 человеко-лет
Согласно рекомендациям Патнама, значение С для различных типов проектов
будет следующим:
■ внедренный в режиме реального времени — 1500;
■ пакетная разработка — 4894;
■ поддерживаемый и организованный — 10040.
li случае изменения времени разработки в промежутке между двумя и тремя
годами, трудозатраты и производительность варьируются следующим образом:
т
2
Е
3082
В
7814
Т
2,5
Е
1262
В
3200
т
3
Е
609
В
1513

406 Глава 11
Чкцептнрование на уровне производительности порождает одно из основных раз-
niMiiii между моделями Боэма и Патнама. Это значение может быть вычислено на
основе показателей размера, времени и трудозатрат, полученных из ранее завершенных
папский!. Пашам «-комбинировал атрибуты процесса и продукта в виде собственного
'.ире.челепня производительности. При этом он разделил широкий диапазон
значении производительности, образовав индекс, значения которого ранжируются в ин-
; ерыис от О до 40. Подобный процесс получил название индекса производительности
; П i. основанного на атрибутах продукта, таких как сложность алгоритма и атрибуты
!■;!■ щеп.i (стандарты и возможности команды). При этом Патнам проявил осторож-
ч<1> п.. лаяшш. что PI не является точным количественным выражением производи-
! слынк in персонала, поскольку некоторые из атрибутов могут не попадать в область
контроля команды разработчиков.
Благодаря использованию индекса PI создается большая разница между трудоза-
i расами, графиком и остальными затратами проекта. Организации могут улучшать
\ ;и >ti показатели PI точно так же, как и могут усовершенствовать уровень зрелости SEI
< ММ. Разным тинам приложений соответствуют различные PI. Например, для
деловых иктем средним значением является 17,3, для научных систем— 14,8, для
телекоммуникационных систем— 11,4, для систем реального времени — 8,3, для систем,
о< пшенных па использовании микрокода,—6,3.
Значения размера и производительности представляются константами, а показатели
i.;i<-\ii-iin и трудозатрат могут быть скорректированы до определенной степени. Соглас-
'!■• Фреду Бруксу (Fred Brooks, закон Брукса), увеличение количества исполнителей на
.'!■ .здннх i гадпях проекта обычно приводит только к увеличению времени выполнения
i.poi-M-.i Однако существует решение, позволяющее достичь минимальных значений
• -.к.-мши разработки, а также минимальных значений трудозатрат/затрат.
Базовые шали оценивания в рамках рассматриваемой математической модели мо-
( <"чл i ь облегчены путем использования автоматизированных инструментов.
Дтан 1. Оценивание размера ПО
Применение бета-раенределения обеспечивает один из методов выполнения этой
■.,;дачи (либо используется мнение экспертов, метод аналогии, метод Wideband Delphi).
'.--;, ь!. + 4S, + snaK)/6
г/о .
Si ( прогнозированный номинальный размер программного продукта;
S р - минимально возможный размер;
S - наиболее подходящий размер (возможно, 50%);
S чикс имальпо возможный размер.
1-iiau 2. Определение производительности и факторов среды (PI, С).
;Ьан 3.1 1деш пфикацпя ограничения разработки (максимум затрат и т.д.).
Этап 4. Создается зона планирования (вероятная область с зонами невыполнимо-
< .и liido невозможности), подобная изображенной на рис. 11.14.
Этап 5. i 1дет поиск соответствующей точки планирования.
i ш \молчанию модель QSM основывается на четырех фазах (настраиваемых
пользователем к требования, разработка проекта, кодирование и интеграция. Третья фаза
определяется путем оценки размера и показателя PI; фазы 1 и 2 определяются в виде про-
иен шмх значений от фазы 3 путем анализа хронологических данных; фаза 4
представал! i i обой экс траиоляцию кривой управления персоналом фазы 3. (см. рис. 11.15.)

Оценка длительности и стоимости разработки ПО 407
Максимум персонала ^-ч
ГС
<И
<И
О.
3
5^
5
s
х
2£
BHHHP^w
Минимум персонала
Максимум затрат
ремени
/S
>*
г
X
X
2
Минимум затрат
Время (фиксировано)
Рис. 11.15. Зона планирования
Преимущества модели SLIM
Модель SLIM обеспечивает следующие преимущества:
■ поддерживает исчерпывающий набор инструментов менеджмента разработки ПО,
выполняющих поддержку программ на протяжении всего жизненного цикла;
■ способствует приобретению "хороших привычек" членами команды инжиниринга
и менеджмента (планирование программных проектов, отслеживание
программных проектов и надзор над областями ключевых процессов на уровне 2 SEI СММ);
■ предлагает эффективное планирование с добавлением значений, особенно при
работе с большими проектами;
■ использует линейное программирование, статистическое моделирование,
оценку программ, а также техники обзора, применяемые при оценке затрат на
разработку ПО (благодаря применению метода линейного программирования
пользователь может "навязать" максимум затрат, максимально возможное
соблюдение графика, верхние и нижние границы оценки численности персонала, а
также располагать приемлемым диапазоном времени и результативными
решениями по трудозатратам.);
■ позволяет выбирать "разработку проекта по затратам", если пользователь
выбирает ввод размера и желаемого количества человеко-месяцев; модель позволяет
также оценщику затрат, понесенных при разработке ПО, выполнять следующие
функции:
- калибровка— точно настраивайте модель с целью представления локальной
среды программной разработки путем интерпретации хронологической базы
для прошлых проектов;

408 Глава 11
- построение — создайте информационную модель программной системы,
объединив характеристики ПО, атрибуты персонала, атрибуты компьютера и т.д.;
- измерение ПО — Используется автоматизированная версия техники оценки
затрат с помощью LOC;
позволяет организации настраивать фазы жизненного цикла и ключевые стадии
для данной среды;
упрощает стратегический процесс принятия решений;
поддерживает оптимальную политику управления персоналом в контексте среды
разработки, реализует анализ типа "что-если"; генерирует отчеты и графики для:
- месячных профилей персонала;
- месячных профилей бюджета;
- профилей риска для затрат, графика и трудозатрат;
- прогнозов надежности ПО;
- прогнозов начальной и конечной ключевых стадий;
поддерживает информацию о количестве дефектов;
в модели SLIM выводится минимальное время, а также соответствующие затраты
(в том числе трудозатраты), включая анализ чувствительности, в ходе выполнения
которого показывается, как изменяются значения, т.е. подобно тому, как
варьируются оценки размеров в трех стандартных реализациях.
Янв
'99
18
И юл
Рис. 11.16. Профиль персонала

Оценка длительности и стоимости разработки ПО 409
Недостатки модели SLIM
Ниже перечислены некоторые недостатки модели SLIM:
■ ее лучше всего использовать при работе с большими проектами (когда размер кода
превышает 5000 строк, трудозатраты больше 1,5 человеко-лет, а время разработки
превышает 6 месяцев);
■ для использования модели необходимо заранее определить размер ПО;
■ оценки являются сверхчувствительными к технологическому фактору;
■ модель очень чувствительна к времени поставки (td);
■ модель очень чувствительна к оценке размера;
■ предполагается использование жизненного цикла каскада, который не
отображается на инкрементальный итеративный (спиральный) процесс разработки либо на
рациональный унифицированный процесс (Rational Unified Process);
■ пользователи должны помнить о необходимости добавления фаз и интегральных
задач, таких как программный менеджмент;
■ этот инструмент является сложным, — вряд ли будет возможным с его помощью за
2-5 минут модифицировать модель;
■ при использовании модели часто получается так, что общая сумма трудозатрат при
выполнении малых проектов будет меньшей, чем трудозатраты при выполнении
большого проекта. Поэтому требуется проявлять осторожность при разбиении
больших проектов на меньшие структурные единицы, учитывая при этом
существование интерфейсов.
Резюме
При оценке размера программного продукта, трудозатрат персонала, графика
проекта и остальных затрат наблюдаются сложные взаимосвязи с процессом
планирования проекта, который первый раз происходит в начале жизненного цикла
разработки проекта, а затем несколько раз повторяется (обычно к концу каждой основной
фазы). Точность оценки обычно далека от идеала в начале осуществления проекта,
однако она улучшается по мере сбора сведений о проекте на каждой фазе, в
результате чего точность оценки постоянно повышается, совпадая в итоге фактическими
значениями размера, трудозатрат, графика и остальных затрат (рис. 11.16).
Необходимо оценить трудозатраты (человеко-часы) и длительность (календарные
дни) выполняемого проекта, благодаря чему менеджеры смогут определять затраты
на производство продукта, срок возврата инвестиций, время выхода на рынок и
качество. Процесс оценки зачастую является затруднительным, поскольку проекты часто
должны удовлетворять взаимоисключающим требованиям (поддержка
функциональных специфических свойств наравне со специфическими требованиями к
производительности, учитывая специфические затраты и график, а также некоторый желаемый
уровень качества). Множество ограничений приводит к усложнению процесса
оценивания. Помимо этого, оценки производятся еще до того, как будут хорошо
определены спецификации. Разработка архитектурного либо высокоуровневого проекта лишь
намечает понятийную область в терминах поддержки исчисляемости и
тестируемости требований, даже если первая оценка предшествует подобной деятельности.

410 Глава 11
— Верхний предел
— Фактические данные
— Нижний предел
• Типичная оценка
лштшт
Выполнимость Планы Разработка Разработка Кодирование Выпуск
проекта детализиро- и
тестированного вание
проекта
Согласно данным Grady and Gaswell, обычно 20-25% оценок
являются оптимистичными, даже для опытных оценщиков
Рис. 11.17. Отчет компании Grady and Gaswell
Источник: Grady, Robert B, and Deborah L. Gaswell, Software
Metrics: Establishing a Company-Wide Program, 1-е издание.
Englewood Cliffs, NJ: Prentice Hall.
Процесс оценивания обычно относится к области навыков менеджмента
проектов, которая связана с документированием планов, оценкой затрат (трудозатрат),
составлением графика и выбором метрических показателей. При осуществлении всех
действий в рамках менеджмента программных проектов в "игру вступает"
большинство навыков из области менеджмента персонала.
Организация, которая ведет документацию, следует инструкциям и постоянно
улучшает процесс оценивания, будет соответствовать требованиям относительно
ключевых процессов уровня 2 SEI СММ, а также требованиям планирования про-
1раммных проектов. Описание цели 1 звучит следующим образом, "Программные
оценки документированы с целью использования при планировании и отслеживании
программных проектов".
Наибольшей проблемой при разработке ПО является создание полнофункцио-
налыюго высококачественного продукта в пределах бюджета, используя
спрогнозированные активы. Эти ограничения называются парадигмой оценивания ПО.
Первый шаг на пути оценки программ заключается в определении размера
программного продукта. Размер продукта обычно выражается в количестве KLOC,
однако могут также применяться функциональные точки, точки свойств, объектные точки
либо другие единицы измерения. Обычно перед переходом к следующему шагу
оценивания (оценка затрат (трудозатрат) и затрат графика) происходит преобразование
других единиц измерения в единицы измерения KLOC. Для любого современного
широко применяемого языка программирования разработаны таблицы
преобразования, позволяющие выполнять преобразование в единицы измерения LOC. Для
оценки величины размера ПО используются следующие методы: Wideband Delphi, метод
аналогии, экспертных оценок, анализ функциональных точек, анализ точек свойств,
анализ объектных точек и т.д.
Для оценки трудозатрат (количества труда, использованного при создании
программного продукта заданного размера) применяются эмпирические, регрессионные
4
3.5
3
2.5
2
1.5
1
0.5'

Оценка длительности и стоимости разработки ПО 411
и математические модели. В главе рассматриваются только регрессионные модели.
Все модели оценки трудозатрат зависят от размера ПО.
Если определены трудозатраты (обычно выраженные в человеко-месяцах), может
быть оценен график и остальные затраты программного проекта. График обычно
основывается на факторах производительности, количестве доступного персонала, а
также фазе распределения трудозатрат.
Регрессионная модель СОСОМО является наиболее широко используемой и
известной среди всех моделей оценивания. В модели СОСОМО поддерживается три
режима (органический, сблокированный и внедренный), а также три уровня
сложности (базовый, промежуточный и детализованный). "Режим" просто описывает тип
проекта (большой, малый, простой, сложный и т.д.). "Уровень" описывает
количество входных данных — с увеличением количества входных данных улучшается точность
оценки. Разработчиком модели СОСОМО является доктор Барри Боэм (Dr. Barry
Boehm); свои исследования он начал в TRW, а затем продолжил их в Южно-
Калифорнийском университете.
В базовой модели СОСОМО используется формула, с помощью которой рисуется
кривая, аппроксимирующая набор точек данных. Затем применяется простой
регрессионный анализ. В промежуточной модели СОСОМО усовершенствуется базовая
модель путем добавления драйверов затрат (либо факторов среды), с помощью которых
изменяется величина трудозатрат при разработке программного продукта. В
детализированной модели СОСОМО поддерживаются дополнительные аналитические
инструменты, а оценка производится в соответствии с уровнями структуры WBS
(трехуровневая иерархия: система, подсистема, модуль). Также на каждой фазе
жизненного цикла применяются корректировочные формулы. В большинстве случаев
применяется промежуточная модель, поскольку в этом случае могут применяться
электронные таблицы. Для получения оценок могут применяться многие
автоматизированные инструменты.
Модель СОСОМО, подобно другим моделям и инструментам оценивания, имеет
свои преимущества и недостатки. Ей присущи простота в применении, а также общий
язык, применяемый для общения в сообществе специалистов в области планирования
/менеджмента программных проектов. С другой стороны, эта модель может
принести реальную пользу, если она будет калибрована на базе хронологических данных ор
ганизации. Возможно одним из наибольших недостатков этой модели является то,
что она основана на использовании оценки размера программного продукта,
выраженной в LOC. Однако ни доктор Боэм (Dr. Boehm), ни создатели других моделей и
инструментов не предложили лучшего способа для начала— даже если оценивание
начинается с применения функциональных свойств вместо размеров, а трансляция
функций в значения размера происходит до продолжения оценивания затрат
(трудозатрат) и затрат графика.
Модель СОСОМО может быть настроена с учетом нужд конкретной организации.
В процессе подобной настройки происходит калибровка на основе общедоступных
хронологических данных и формул. Соответствующие сведения можно найти в
классической книге Боэма, Software Engineering Economics.
Результаты оригинальной работы, выполненной Боэмом и его коллегами в
компании TRW в 1975-1980 годах, должны быть скорректированы с учетом использования
современной терминологии. Доктор Боэм, профессор Южно-Калифорнийского
университета, постоянно улучшает свои результаты и регулярно публикуется во

П2 Глава 11
"несмирной паутине". Так, в 2000 году появилась новая работа, именуемая Software Cost
Intimation with Cocomo II. Каждому новому пользователю модели СОСОМО (I или II)
придется выполнить следующее: 1. собрать данные; 2. запустить на выполнение
модель СОСОМО; 3. если имеет место расхождение результатов, повторно калибровать
модель с учетом среды (и реструктуризации уравнений). В главе рассказывается о
том, каким образом Боэм достиг своих замечательных результатов, объясняется ме-
тлмодель, а также предлагаются направления, используемые при конструировании
моделей, специфичных для организации. Модель СОСОМО II является наиболее
современной: Она поддерживает эволюционный, управляемый рисками и совместный
программный процесс; языки четвертого поколения и генераторы приложений;
подходы с применением коммерческих готовых продуктов и управляемого методом по-
нторпого использования ПО; подходы с разработкой ПО быстрого отслеживания;
инициатив но обеспечению зрелости программных процессов.
Применяется также другая математическая модель оценивания, называемая
менеджментом жизненного цикла разработки ПО (Software Lifecycle Management,
SI.IM). Этот инструмент имеет отношение к QSM. Благодаря использованию модели
SI.1M специалист по оценке может использовать анализ линейного
программирования, в котором рассматриваются ограничения разработки, имеющие отношение к за-
1 ратам (трудозатратам), и поддерживается помесячное распределение трудозатрат и
иронерка совместимости для данных, имеющих отношение к программным системам
одного размера.
Модель SLIM основана на анализе жизненных циклов разработки ПО,
производимого в терминах распределения Рейлайха (Rayleigh), связывающего уровень
квалификации персонгиш и затраченное время. Эта модель была разработана Патнамом
М'Шпат). При этом применяется следующий алгоритм:
;• г<№р - С X К1/3 X td4'3
Размер определяется с помощью количества строк кода, коэффициент К
представляет гобой общий объем трудозатрат жизненного цикла разработки ПО (в рабочих го-
,;а.ч), а коэффициент t определяет время разработки (в годах). Оценивание размера, за-
: j - vr (трудозатрат) и затрат графика для каждого нового программного проекта не от-
\1>н ичея к области точных наук. В связи с этим эксперты настоятельно рекомендуют при
выполнении измерений и оценивания использовать несколько методов.
Ниже приводится контрольный перечень вопросов, имеющих отношение к
процессу оценивания.
■ Был ли заложен "твердый фундамент" в основу процесса оценивания размера ПО?
■ Были ли ознакомлены заказчики, менеджеры и разработчики с основами
измерений и выполнения оценок?
я Были ли корректно использованы хронологические данные (в случае их наличия)?
* Корректно ли используется модель?
и Был ли метод оценивания корректно отображен/калиброван по отношению к
процессу разработки?
■ Были ли сделаны приемлемые предположения относительно факторов продукта и
процесса, оказывающих влияние на производительность?
■ Существуют ли реальные стратегии, позволяющие достигать трудновыполнимых
целей?

Оценка длительности и стоимости разработки ПО 413
■ Были ли использованы при проведении сравнения альтернативные методы
оценивания?
■ Используется ли несколько методов? В большинстве случаев никакой
единственный метод не будет достаточно надежным. Если два метода дают не согласующиеся
результаты, причина этого может заключаться в упущении из рассмотрения
некоторых фактов.
■ Учитывает ли модель явным образом затраты, понесенные на этапе оценивания,
либо эти затраты исключаются?
■ При оценках отслеживания будут ли результаты оценок близки к величинам
фактических затрат проектов?
■ Определена ли цель использования модели? Имеет ли отношение большинство
отклонений в оценке затрат к плохо определенным субъективным факторам
(например, фактор сложности)?
■ Будет ли модель аккомодировать оценки подсистем и модулей? Обеспечивает ли
она разбивку (точную) на фазы и действия?
■ Будет ли инструмент стабильным? Могут ли небольшие расхождения во входных
данных спровоцировать выходные расхождения при оценке затрат?
■ Может ли модель охватывать класс программных проектов, данные о затратах по
которым требуются нам для проведения оценки?
■ Можно ли в рамках модели избежать использования информации, которая будет
неизвестной до момента завершения проекта?
■ Можно ли в модели избежать факторов с высокой степенью избыточности либо
факторов, которые вносят едва заметный вклад в конечные результаты?
В дополнение к советам по выбору инструментов, Боэм (Boehm) и другие
эксперты дают еще несколько полезных советов.
■ Оценивайте разницу между фактическими и плановыми данными с целью
определения величины расхождения.
■ Установите базовую линию (фазы, основные стадии, размер,
трудозатраты/персонал/затраты, дефекты).
■ В целях достижения эффективности и совместимости воспользуйтесь шаблонами.
■ Поддерживайте установку позиционирования данных.
■ Не используйте решения, вероятность успеха которых не превышает 50%.
■ Собирайте данные для завершенных проектов, используя автоматизированные
методы, не оказывающее влияние на происходящие процессы.
■ Поддерживайте основную базу данных, содержащую данные по каждому
завершенному проекту.
■ По мере роста количества собранных проектов воспользуйтесь техникой
статистического анализа с целью распределения данных по различным значимым
подмножествам.
■ Выполняйте повторную оценку бюджета и плана. При этом в качестве основы
используйте новые и/или пересмотренные данные (предположения, гипотезы
футурологов). Неопределенность, присутствующая на начальных стадиях проекта,

414 Глава 11
влечет за собой необходимость выполнения регулярных обзоров, а также
приводит к тому, что требуется выполнение повторных оценок.
■ Вовремя обновляйте прогнозы.
Между различными моделями существует определенное сходство. И хотя лишь
одна модель называется "математической", все они реализованы на основе
математических формул (табл. 11.13). Несмотря на то, что лишь одна модель именуется
"эмпирической", все модели основаны на данных наблюдений за реальными
проектами. Каждая модель оценивания обладает своими преимуществами и недостатками,
поэтому при оценивании размеров, затрат (трудозатрат) и графика лучше
воспользоваться несколькими моделями. Даже при рассмотрении минипроекта процесс
оценивания должен документироваться, изучаться и выполняться согласованно.
Таблица 11.13. Параметры и уравнения моделей СОСОМО и SLIM
Базовая и
промежуточная модель
СОСОМО
График = 2,5 трудозатраты'
Органический: с - 0,38
Сблокированный: с - 0,35
Внедренный: с " 0,32
Модель СОСОМО 2.0 График = с[трудозатраты'
(SCED%/100)
b = 1,01 + A/100I5^
Модель SLIM Патнама Упрощенная модель:
0.3Э»0,2(Ь-1.01)
(Putnam)
Трудозатраты = 8,14(SLOC/P)'
]/ с = 3,0
SFj1* фактор масштабирования
SCED96 « параметр
сжатия/расширения графика
Р = параметр
производительности
Контрольные вопросы
Являются ли все модели оценивания математическими? Эмпирическими?
Регрессионными? Объясните ваш ответ.
Используя приведенные ниже краткие описания проекта, выполните следующее:
a. определите тип проекта;
b. используя базовую модель СОСОМО, выполните следующее:
i. определите трудозатраты, понесенные при разработке проекта,
ii. определите время разработки, основываясь на показателе трудозатрат;
c. используя промежуточную модель СОСОМО, выполните следующее:
i. определите трудозатраты, понесенные при разработке проекта;
ii. определите время разработки, основываясь на показателе трудозатрат;
d. сравните результаты, полученные на шагах b и с;
e. пересчитайте оценку, воспользовавшись промежуточной моделью СОСОМО,
причем значения всех драйверов затрат должны быть минимальными;
f. пересчитайте оценку, воспользовавшись промежуточной моделью СОСОМО,
причем значения всех драйверов затрат в этом случае будут максимальными;

Оценка длительности и стоимости разработки ПО 415
g. оцените трудозатраты, необходимые для разработки проекта, а также время
разработки в случае, если проект будет разбит на четыре небольших проекта,
выполняющихся в параллельном режиме. Размер каждого небольшого проекта
будет составлять 500 KLOC. Сравните результаты оценки четырех небольших
проектов с результатом оценки одного большого проекта.
Краткое описание проекта.
■ Результат оценки размера программного проекта соответствует 2 миллионам LOC.
■ Опыт аналитиков и разработчиков достаточен для разработки подобных систем.
■ Аналитики обладают семилетним опытом работы.
■ Хотя система напоминает некоторые другие ранее разработанные системы, в
данном случае был все же использован некоторый инновационный дизайн, в
результате чего возросла степень риска и возникла потребность в использовании
спиральной модели разработки.
■ Компания не желает нести затраты на приобретение новых средств разработки ПО.
■ Системная архитектура является завершенной; разработка аппаратного
обеспечения осуществляется параллельно с разработкой ПО.
■ Компания получила правительственный грант на разработку обширного набора
серверов— образующих хранилище данных, достаточное для размещения
наибольших баз данных.
■ В состав системы входит компонент, функционирующий в режиме реального
времени, который требует моделирования поведения системы.
■ Программисты достаточно опытны, но у них отсутствует опыт работы с языком
программирования, выбранным для реализации.
■ Имеют место встроенные процессы; организация соответствует условиям
уровня 2 SE1.
■ Разработчики имеют адекватный опыт работы с операционными системами.
Практическое занятие
Отдел маркетинга вашей корпорации проявляет особый интерес к проекту ARRS,
основанному на ваших позитивных ответах на вопросы относительно повторного
использования ПО. Мистеру Адаме из отдела маркетинга поручен мониторинг вашего
проекта на предмет немедленного выполнения. Он попросил вас оценить влияние на
способность производства ARRS в качестве открытого для повсеместного
использования набора инструментов, предназначенного с целью создания ПО, управляющего
работой железнодорожного транспорта.
Ссылки
Boehm Barry. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1976.
DeMarco Tom. Why Does Software Cost So Much? and Other Puzzles of the Information Age. NY: Dorset
House, 1995.
Grady, Robert В., and Deborah L. Caswell. Software Metrics: Establishing a Company-Wide Program, 1-е
издание. Englewood Cliffs, NJ: Prentice Hall, 1987.

416 Глава 11
Литература
Abctel-Hantid, Tarek and Stuart E. Madnick. Software Project Dynamics: An Integrated Approach. Upper
Saddle River, NJ: Prentice Hall, 1991.
Basili Victor. Tutorial on Models and Metrics for Software Management and Engineering. NY: Institute of Elec-
tiical and Electronics Engineers, 1980.
Unehni Barry W., et ah Software Cost Estimation with CocomoII. Englewood Cliffs, NJ: Prentice Hall, 2000.
brooks Fredrick P. The Mythical Man-Month: Essays on Software Engineering, дополнительное издание,
(изначально опубликовано в 1975 г). Reading, MA: Addison-Wesley,1995.
CoiineU John and Linda Shafer. The Professional User's Guide to Acquiring Software. NY: Van Nostrand Re-
inliold. 1987.
DeMarco Tom. Controlling Software Projects. Upper Saddle River, NJ: Prentice Hall, 1982.
Fail ley R.E. "Recent Advances in Software Estimation Techniques." Материалы 14 международной
конференции IEEE no программному инжинирингу, NY: IEEE Computer Society Press, pp. 382-391.
1 lalsu-ad Маш ice. Elements of Software Science. NY: Elsevier North-Holland, 1977.
I i uinphrey Watts. Managing the Software Process. Reading, MA: Addison-Wesley, 1989.
Jones Capers. Applied Software Measurement, 2-е издание. NY: McGraw-Hill, 1997.
Jones Capers. Programming Productivity, 1-е издание. NY: McGraw-Hill, 1986.
Norden Peter V.'Curve Fitting for a Model of Applied Research and Development Scheduling." IBM
journal of Research and Development, Endicott. NY. 2C), 1958.
I'm nam Lawience II. "A General Empirical Solution to the Macro Software Sizing and Estimating
Problem." IEEE Transactions on Software Engineering, SE4G):345-361, 1978.
Sommerville Lan. Software Engineering 6-е издание. Workingham, England: Addison-Wesley, 2000.
Stul7ke Richard D. Software Estimation: Projects, Products, Processes. Addison-Wesley, 2001.
Von Mayihaiiser Anneliese. Software Engineering: Methods and Management Boston, MA- Academic
Tress. 1090.
Walstou C.E. and C.P. Felix. "A Method of Programming Measurement and Estimation." IBM Systems
fmimal, 16AM4-73, 1977.
Yourdon Edward. Death March. Upper Saddle River, NJ: Yourdon Press/Prentice Hall, 1997.
Дополнительные сведения в Internet
ca . com /products /superproject.htm. Компьютерная ассоциация (Computer Associates).
mijuno.larc.nasa.gov/dfc/societies/lspa.html. Международное общество параметри-
ме« кого анализа (The International Society of Parametric Analysts).
www.bjmath.com/bjmath/least/curve.htm. Richard Reid, "Curve Fitting" (ссылка "Schaums
Outline Series: Theory and problems of Probability and Statistics" by Murray R. Spiegal, Ph.D.).
www. cost engineer, com.au/prod01 .shtml. Экспертные оценки.
www.cpsc.ucalgary.ca/~hongd/SENG/621/report2.htmHf2.6.5. Danfeng Hong, "Software
С.041 Estimation", Department of Computer Science, University of Canada, Alberta, Canada.
www.dacs .dtic.mil/databases/url/key.hts?keycode=4: 7&islowerlevel=l. Центр ана-
tiija и данных ПО (Data & Analysis Center for Software, DACS) является информационным аналитиче-
i ким центром Министерства обороиы США (Department of Defense, DoD) (IAC). Оценка затрат: ана-
.iii.i методом функциональных точек.
www. iconixsw. com/spec_sheets/CoCoPro. html. Инструмент оценивания СоСоРго.
www .jsc.nasa. gov/bu2/. Космический центр NASA имени Джонсона (JSC), группа оценки затрат.
www .pri cesystems. com/pri ces. h tm. Инструмент оценивания PRICE-S от фирмы PRICE Systems.
www.qsm.com/products.html. Инструмент оценивания в соответствии с моделью SLIM от
Oii.iimtaiive Software Management, президент Лоуренс Патнам (Lawrence Putnam, President).

Оценка длительности и стоимости разработки ПО 417
www.rcinc.com/. Фирма Resource Calculations, Inc., предлагает инструменты моделирования
для оценки размеров и затрат, включая ASSET-R, SSM и SOFTCOST-R.
www. rcinc. com/so ftcostr. html. Инструмент оценивания Softcost-R.
www.resourcedesigninc.com/RDImam.html. Ecomodeler поддерживает автоматизированный
проект интерфейса, предназначенный для создания ПО для World Construction Set (от фирмы Views-
capeSD Ltd).
www. sciam. com/1998/1.298issue/1298jones. html#fnrther. Capers Jones, "Sizing Up
Software: Unlike oil, steel or paper, software is an intangible commodity."
www. sepo. nose.mil/revic. html. Инструмент оценивания REVIC.
www. SoftstarSystems. com/. Компания Softstar Systems предлагает Costar, автоматизированную
реализацию модели СОСОМО. www.softwaremetrics.com/Articles/default.htm. Longstreet
Consulting Inc.
www. spr. com/index. htm. Фирма Software Productivity Research выполняет определение
размеров ПО, оценивание пригодности и затрат для продуктов и услуг. Президентом и основателем
является Каперс Джонс (Capers Jones).
www. spr. com/1 ibrary/Ofimcmet.htm. Jones, Capers, Chairman, Software Productivity Research,
Inc., "What are Function Points?"
www.stsc.hill. af.mil/crosstalk/. Оценивание ПО: проблемы и исследования.
www.stsc.hiIl.af.mil/CrossTalk/1995/nov/Living.asp. Лоуренс Бернштейн (Lawrence
Bernstein) и Алекс Любашеский (Alex Lubashevsky), AT&T, "Жизнь с функциональными точками".
www. sunset. тс. edu/cocomo2. 0/cocomo. html. Инструмент оценивания СОСОМО.
www.wwk.com/coolsoft.html. Инструмент COOLSoft™ является количественным
инструментом, применяемый для оценки средств, затрачиваемых на разработку ПО.

Распределение
ресурсов
Если в распоряжении менеджера имеется перечень настраиваемых действий,
которые соответствуют жизненному циклу проекта и имеют отношение к структуре
WBS, он сможет выделять соответствующие ресурсы для выполнения этих действий.
Эта операция должна быть довольно простой, не так ли? Персонал поддержки баз
данных реализует выделение ресурсов для этой базы данных, а тестеры выполняют
назначения ресурсов, необходимых для проведения тестирования. Но этот процесс
не является столь простым и легким в реализации. Проблема распределения ресурсов
имеет несколько аспектов, каждый из которых должен учитываться менеджером
программных проектов при распределении работы. Программисты не могут создавать
одинаковые программы. При выполнении распределения ресурсов различного рода
разногласия между членами команды затрудняют деятельность менеджеров проекта,
вынужденных решать не свойственные ему задачи. В результате ставится под угрозу
успешный карьерный рост менеджеров. Рабочая нагрузка становится
несбалансированной, что в свою очередь приводит к "срыву" графика работ и появлению проблем
морального характера в коллективе.
При рассмотрении вопросов подобного характера авторы книги, прежде всего,
стремились продемонстрировать роль менеджеров при управлении персоналом
разработчиков проектов, а также в процессе распределения ресурсов. Эти вопросы
имеют отношению к управлению персоналом. В главе будут рассмотрены концепции и
инструментальные средства, которые могут оказать помощь персоналу на этапе
отождествления собственных требований и выделенных ресурсов. Также будет
продемонстрировано, каким образом простое инструментальное средство (электронная
таблица) сможет облегчить понимание ролей, назначаемых в ходе выполнения
проекта, а также обеспечить отслеживание поставляемых продуктов. Навыки и
компетенции, рассматриваемые в главе, являются жизненно необходимыми для
современных менеджеров программных проектов. Далеко не все сводится к транзакциям.
Большую роль также играет менеджмент взаимосвязей.

Распределение ресурсов 419
Стадии жизненного цикла разработки
продукта
Л теперь пришло время выяснить, на какой стадии основного жизненного цикла
разработки продукта мы находимся в настоящее время. Как показано на рис. 4.1 и
12.1, мы все еще находимся в начале жизненного цикла разработки ПО. Но поскольку
на данный момент времени была создана структура WBS, которая ориентирована на
продукты и отвечает на вопрос что (цель), происходит перемещение на следующий
этап жизненного цикла разработки ПО. Здесь уже определяется, каким образом
производятся действия, необходимые для достижения цели, сформированной на первой
стадии жизненного цикла.
Исследование
концепции
■
Формулирование

потребности
Исследование
системы
■ Спецификация
интерфейса
системы
Требований
■ Спецификация
требований
к ПО
Разработка
проекта
Идентификация
циклов SLC
' Описание

разработки ПО
' Циклы SLC
Внедрение
Выбор
модели
■ План

тации/верификации ПО
■ Модель SLC
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
Выбор модели
жизненного цикла
разработки ПО
Установка
■Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
■SIC
Распределение
ресурсов
■
Пользовательская
документация
Сопровождение
■ Бюджет
1 Документация
по
сопровождению
Вывод из
эксплуатации
• Архивный
отчет
Рис 12.1. Жизненный цикл разработки ПО

420 Глава 12
Почему ?
• Коэффициент
КОИ
Что?
■ Техническое
задание
(на проект)
Распределение
ресурсов
Как?
•ПланБРМР
Выполнение
• Жизненный
цикл
Сделано
• Процесс РРА
Рис. 12.2. Схема процессов проекта
Связь главы 12 с 34 компетенциями
Материал главы связан с рассматриваемыми в книге компетенциями. При выполнении
распределения ресурсов реализация методики разработки ключевых продуктов требует
использования сведений о различных жизненных циклах разработки ПО. При этом
необходима оценка и настройка жизненных циклов в соответствии индивидуальными
потребностями каждого проекта. В число компетенций, требуемых при идентификации задач и
действий в данном случае, входят общее представление о действиях по разработке ПО
(программный инжиниринг), а также методы определения программных продуктов.
Навыки по управлению проектами, требуемые в данном случае, представляют собой
органическое продолжение навыков, требуемых при создании структуры WBS. В
частности, в данном случае идет речь о документировании планов, входящих в состав
упорядоченной структуры, а также осуществление поиска задач и действий, необходимых
при разработке графика. При этом от персонала требуются навыки лидерства,
взаимодействия и общения, а также способности к эффективной презентации своих идей в
ходе осуществления процесса идентификации.
В рассматриваемом случае основную роль играют навыки по управлению
персоналом. Навыки взаимодействия и общения являются жизненно важными при выборе
нужных людей, выполняющих требуемые действия. Набор персонала, необходимого
для реализации проекта на практике, производится путем проведения интервью, а
также с помощью процесса вербовки персонала. Навыки по оценке производительности
также являются необходимыми в деле отслеживания хода выполнения процесса и
поддержки планирования карьерного роста. Отбор и формирование команды участников
проекта осуществляется после того, как будут выделены ресурсы, необходимые для
выполнения действий. Эти навыки и компетенции будут рассмотрены в данной главе.
Методики разработки продукта
1. Управление субподрядчиками— планирование, управление и осуществление
контроля.
2. Понимание действий по разработке продукта— изучение цикла разработки ПО.
Навыки менеджмента проектов
3. Составление графика — разработка графика и ключевых меток.
4. Отслеживание процессов — мониторинг совместимости проектной команды.

Распределение ресурсов 421
Навыки менеджмента персонала
5. Оценка производительности— оценка действий команды, направленная на
улучшение ее производительности.
6. Взаимодействие и общение — взаимодействие с разработчиками, высшим
руководством и другими командами.
7. Успешное ведение переговоров — разрешение конфликтов и успешное ведение
переговоров.
8. Планирование карьерного роста— структурирование и управление ходом
реализации карьеры.
9. Набор персонала—успешный набор персонала и собеседование с членами команды.
10. Отбор команды — отбор высококомпетентных команд.
11. Создание команды— формирование, руководство и поддержка эффективной
команды.
Учебные цели главы 12
После изучения материала главы читатель должен уметь выполнять следующее:
■ описывать несколько различных ролей, требуемых в данном программном проекте;
■ описывать содержание и назначение плана управления персоналом;
м объяснять методы применения в программных проектах матрицы назначения
ответственности;
■ обосновывать, насколько данный индивидуум соответствует той или иной роли,
основываясь на характеристиках, отличных от специальных навыков;
■ перечислять и описывать характеристики каждой из ролей.
Организационное планирование
Если в распоряжении менеджера оказывается перечень настроенных действий из
структуры WBS, соответствующих выбранному для данного проекта жизненному циклу
разработки ПО, он сможет распределить необходимые ресурсы. Однако при этом следует
учитывать, что процесс распределения ресурсов имеет несколько важных аспектов.
Следует понимать, какого рода ответственность и права имеют отношение к каждому
действию проекта, а также определить, каким образом участник команды разработчиков
выполнит действие, результаты которого поддаются учету. Необходимо систематизировать
и описать требования к взаимосвязям и ролям, возникающим при выполнении
определенных задач. Нужно поддерживать баланс между карьерными целями и нуждами проекта,
оптимизируя человеческий фактор и устраняя барьеры, возникающие на пути к
успешному выполнению задачи. Это достаточно сложные задачи для каждого менеджера проекта.
Менеджер проекта ответственен за планирование персонала, необходимого для
осуществления проекта. В его задачи входит следующее:
■ идентификация и документирование ролей и навыков, необходимых для
осуществления проекта;
м назначение обязанностей отдельным индивидуумам;
■ Определение требований к взаимоотношениям;

422 Глава 12
Идентификация и документирование
ролей и навыков, необходимых
для осуществления проекта
Менеджер проекта должен принять решение относительно того, кто есть кто и кто
какие вопросы решает в ходе выполнения данного проекта. Ответ на первый вопрос
затрагивает планирование карьерного роста, балансировку возможностей по обучению,
своевременному выполнению работы и менеджменту персонала. При этом потребуется
учитывать определенные навыки, необходимые для выполнения каждого действия.
В случае, если вы или ваша команда сталкиваетесь с новой категорией действий, иногда
будет полезным составить перечень необходимых навыков. Подобное
документирование требуется в случае, если набор этих навыков очень велик и разнообразен. Затем
сравните необходимые навыки и те навыки, сведения о которых можно получить,
изучив цели карьерного роста каждого кандидата, а также его личную мотивацию.
Типы ролей
Следует учитывать важное обстоятельство, что при наборе проектной команды
назначение требуемых людей на нужные места приведет к достижению гармонии и
производительности в работе всей команды. Конечно, в данном случае весь персонал
можно отнести к инженерам-программистам, но при этом следует учитывать, что эта
профессия имеет множество специализаций:
■ разработчики баз данных;
■ эксперты в области управления конфигурацией;
■ дизайнеры, разрабатывающие пользовательский интерфейс;
м Web-мастеры;
■ специалисты по обеспечению качества;
■ специалисты в области разработки и поддержки сетей;
■ системные архитекторы;
■ эксперты по языкам программирования (С, C++, Java и т.д.);
■ специалисты в области компиляции;
■ инженеры по проведению тестирования.
Обратите внимание, что этот список может включать некоторые навыки, которые
не являются типичными для инженеров-программистов, но которые могут оказаться
весьма полезными для успешного завершения всего проекта. Например, в команде
разработчиков проекта часто бывает человек, который не отвечает ни одному из
критериев, указанных выше, но благодаря своим личностным и общественным качествам,
служит катализатором, необходимым при выполнении задач. Иногда эти люди именуются
"кротами", поскольку они не являются ведущими специалистами, но входят в состав
команды разработчиков любого проекта и являются незаменимыми помощниками. Их
вклад нелегко оценить с помощью количественных показателей, но если они не будут
привлечены к работе, ход ее выполнения будет сильно замедлен либо вообще
приостановлен. Эти люди поддерживают необходимую степень согласованности среди членов
команды, выступая в роли своего рода "посредников" между своенравными членами ко-

Распределение ресурсов 423
манды и другими специалистами. Их роль часто сводится к выполнению функций
некоего "социального клея", и они являются абсолютно необходимыми для обеспечения
продуктивной и слаженной работы всей команды. Учитывайте это обстоятельство и
планируйте соответствующим образом всю свою работу.
Очевидно, что при использовании формализованных категорий навыков,
определение набора требуемых навыков может изменяться с течением времени, по мере
того, как проект проходит через различные фазы жизненного цикла. В начале
жизненного цикла разработки проекта возникает повышенная потребность в услугах
архитекторов и дизайнеров. Программисты, web-мастера и специалисты в области
сетевых технологий больше всего нужны на средних стадиях жизненного цикла
проекта. Специалисты по компиляции и тестеры наиболее востребованными становятся
на последних стадиях жизненного цикла. Специалисты по обеспечению качества
программного обеспечения и эксперты по управлению конфигурацией необходимы в
течение всего жизненного цикла. Точные потребности и необходимые интервалы
времени могут определяться с помощью жизненного цикла разработки, выбранного
для данного проекта.
Характеристики ролей
Для каждой операции, определенной в проекте, должен быть в наличии набор
ролей, предполагающий ряд специфических навыков (или их комбинацию). Для каждой
роли, менеджер проекта должен определить три рабочих аспекта.
■ Обязанности — обязанность, заключающаяся в выполнении назначенного
действия при наличии (или отсутствии) специального руководства или специальных
полномочий.
■ Полномочия — право представления, руководства или принятия решений.
■ Ответственность — возложение ответственности за выполнение операций или
каких-либо важных действий в рамках проекта.
Общеизвестно, что происходит в случае, если какие-либо обязанности возлагаются
на людей, у которых отсутствуют законные полномочия, существующие в данной
организации для выполнения подобного рода работы. Окончательная оценка становится
недостоверной, поскольку в данном случае уполномоченная персона в глазах других
сотрудников организации обладает представительскими обязанностями, а не
исполнительскими правами. Взаимодействие и взаимная поддержка в этом случае значительно
затрудняется либо становится вообще невозможной. Поэтому убедитесь в том, что для
каждой роли в проекте четко различаются права и пределы ответственности.
Довольно часто упускается из виду момент, когда следует уделять пристальное
внимание процессу определения роли. В этих случаях менеджер проекта должен
определить метод, применяемый для оценки возможности исполнения для каждой
роли. Благодаря этому минимизируются дальнейшие проблемы, связанные с оценкой
производительности при выполнении работ в рамках проекта.
В качестве примера рассмотрим обязанности инженера по проведению
тестирования. В его обязанности входит следующее:
■ сотрудничество с архитекторами и дизайнерами;
■ разработка контрольного примера;
■ генерирование проверочных данных;

424 Глава 12
■ выполнение тестового модуля и возвращение в исходное состояние с набором тестов;
■ отчет о результатах.
Полномочия, предоставленные в рамках проекта внутри организации, включают
следующее:
■ участие в разработке и контроле осуществления встреч;
■ контроль прав на осуществление тестирования для всех связанных с этим
процессом действий;
■ авторизация версий компонентов;
■ представление информации относительно официальных результатов
тестирования, а также о результатах измерения качества продукции.
Ответственность за проводимые тесты может быть определена как поддающаяся
количественному определению и с легко измеряемыми параметрами, такими как:
■ количество проводимых встреч с дизайнерами и службой технической поддержки;
■ качество и количество подготовленных и выполненных тестов;
■ процент успешно созданных версий компонентов, используя составляющие
элементы, передающие входные данные о качестве;
■ достоверность и своевременность отчетов о результатах тестирования и
относительно данных оценки качества продукта.
Определение для каждой роли может быть не документировано, если команда
разработчиков проекта невелика и является сплоченной. Если же организация
настолько мала, что роли, как правило, не разграничиваются, и каждый выполняет всю
необходимую работу (как во многих вновь созданных фирмах, специализирующихся
на разработке ПО), или если уровень зрелости проектной организации является
достаточно низким, документирование ролей необходимо. Однако в больших
организациях, курирующих одновременно множество проектов, должен быть установлен
стандартный набор определений ролей. При создании этих определений большую
помощь могут оказать специалисты из отдела кадров организации.
Другим важным при распределении ролей является надежность фактором. Этот
фактор в любом случае учитывается для большинства индивидуумов, принимающих
участие в распределении ролей, и также не столь часто документируется в качестве
одной из составляющих роли. Это может сказаться на ранее полученных оценках
производительности либо отразиться на данных, переданных другими менеджерами
или руководителями проектов. Надежность связана с моральными качествами,
такими как рассудительность, знания, навыки и привычки. Достижение надежности
подразумевает то, что конкретный исполнитель проекта готов приложить максимум
усилий при осуществлении присущей ему деятельности. Прямо или косвенно, менеджер
проекта хочет быть уверен в том, что каждый участник несет ответственность за
выполнение проекта, а также озабочен успешным выполнением данного проекта.
Назначение обязанностей для отдельных
исполнителей
Роль любого менеджера проекта при подборе персонала и назначении
соответствующих ему обязанностей заключается в определении количества времени, затрат и
объема ресурсов, необходимых для завершения проекта. Эти условия должны быть

Распределение ресурсов 425
выполнены для каждого действия. Некоторые из них не могут быть завершены до
того, как будет выполнено дополнительное планирование (например,
детализированные оценки действий (глава 11), которые являются производными от оценок размера
ПО (глава 10)). Роль менеджера проекта также включает проведение необходимых
переговоров с распределителями ресурсов, необходимых для выделения участникам
проекта, обладающим требуемым набором навыков.
Учет начальных и заключительных операций
Менеджер проекта также должен планировать возможные начальные и
заключительные операции, имеющие место при распределении ресурсов. В качестве примера
рассмотрим проект по созданию компонента Java, где разработчику выделяется пять
рабочих недель, начиная с первого марта. При разработке столь жесткого
временного графика предполагалось, что разработчик кода на языке Java будет "рвать
подметки" и не терять зря время на выяснение таких вопросов, как, например, кто и за что
отвечает, каково общее состояние дел, как выглядит общая архитектура проекта,
либо каким образом продукт разработки на Java будет соответствовать архитектуре
продукта и плану проекта. Вместо этого целесообразно заблаговременное
резервирование либо получение ресурса, что позволит вовремя сориентироваться при ответе на
вопрос относительно требуемых навыков. При использовании ресурсов из соседних
отделов в большой организации может потребоваться лишь небольшой период
времени на резервирование, поскольку приходится учитывать общепринятую в
компании практику (акронимы, процедуры, ожидания и т.д.). Однако этот период времени
может существенно увеличиться в случае набора новых сотрудников, выпускников
колледжей либо неместных сотрудников (особенно из отдаленных областей и стран).
Эти факты являются очевидными, но они часто упускаются из виду при подготовке
плана проекта разработки ПО.
По завершению действия сотруднику может понадобиться выполнение
заключительных операций прежде, чем он прекратит активное участие в ходе осуществления
проекта. Заключительные операции могут включать передачу знаний остальным
членам команды, очистку локальных файлов и рабочего пространства,
документирование и отмену применяемых паролей, идентификацию мест размещения рабочих
продуктов проекта, а также выполнение ряда других операций, обязательных при
увольнении сотрудника.
Как правило, начальное и завершающее время не включается в оценку
трудозатрат, определенных на основе размеров компонентов. В этом случае мало подходит
обычное расширение оценок действий с целью включения дополнительного
времени, необходимого для выполнения начальных и завершающих операций. Если же
оценка была выполнена командой либо инженером средней квалификации, логично
предположить, что, возможно, источник ресурсов просто не был включен в
калькуляцию. Конечно, если уже назначено ответственное лицо, выполняющее работу,
необходимое начальное и завершающее время может быть включено в результаты оценок
времени и трудозатрат.
Стратегия распределения ресурсов
А теперь исследуем некоторые стратегии, применяемые при назначении ресурсов
для различных выполняемых действий. В ходе распределения ресурсов
обеспечивается не только возможность передачи различных действий, описанных в вашем за-

426 Глава 12
ключительном списке, наличному персоналу. На самом деле этот процесс является
более тонким, а также более существенным. Менеджер проекта должен "заглядывать"
далеко за пределы одного проекта. Это связано с тем, что любой отдельный проект
может оказаться лишь еще одним шагом, предпринятым в процессе формирования
вашей команды. Назначение действий определенным исполнителям также может
означать усовершенствование навыков и углубление опыта работы вашей команды. По
завершению работы участники команды должны получить вознаграждение.
Говоря проще, потребуется учесть, на что способен каждый член вашей команды,
а также распределить в соответствии с полученными сведениями действия и задачи,
имеющие определенную степень сложности (но лучше немного занизить показатель
сложности). Если все это возможно, тогда должны формироваться действия с целью
достижения соответствия с уровнем подготовки персонала. Эффективность этого метода
превосходит эффективность всех остальных. Например, предположим, что Джо
узнал что-то новое в ходе осуществления данного проекта. В результате выполняемая
им задача либо операция будет упрощена, поскольку Мэри ответственна за
руководство проектом и проверку результатов работы. Если же задача Энди заключается в
том, чтобы способствовать карьерному росту Мэри, происходит комбинирование
достаточного количества операций таким образом, что в результате ее
ответственность существенным образом возрастет. Если к Перри вы не испытываете большого
доверия, назначенные ему действия должны конвертироваться в меньшие по размеру
модули, которые могут часто завершаться.
Некоторые действия могут группироваться совместно и назначаться одному
исполнителю либо группе с целью достижения наибольшего эффекта. Например,
некоторые действия, которые кажутся независимыми, могут быть более эффективными
при совместном выполнении. Причина этого заключается в том, что при выполнении
подобных действий используются общие идеи, информация, и таланты. Если
подобные действия назначены для выполнения лишь одним исполнителем, при этом будет
исключено начальное время для одного из действий. Иногда назначение двух
сотрудников там, где достаточно одного, позволяет им помогать друг другу, что
способствует успешному карьерному росту.
Подбор исполнителей, соответствующих ролям
Еще в 1980-х годах, занимаясь исследованиями информационных технологий,
Билл Куртис (Bill Kurds) пришел к выводу, что при приеме на работу сначала следует
учитывать черты характера кандидатов, а уж затем — уровень их квалификации,
указанный в резюме. По мере возможности осуществляйте отбор членов команды
прежде всего по критерию их совместимости и дополнительным личным чертам
характера, а не только на основании способностей, продемонстрированных в определенной
области. Такой принцип является в корне противоположным используемому ранее
методу. Целесообразность нового принципа проще осознать, если принять во
внимание то обстоятельство, что легче обучить персонал новым техническим (часто
быстро изменяющимся) навыкам, чем изменить их черты характера. В любом случае,
общеизвестным является тот факт, что большинство людей любят учиться чему-либо
новому. Тренинг не должен носить формальный характер. Общие способности к
быстрому изучению и адаптации к непрерывно изменяющейся информации при
наличии базовых познаний современных технологий часто более важны, чем наличие
глубоко опыта в одной либо двух областях знаний. Конечно, если личные качества со-

Распределение ресурсов 427
трудника совершенно не соответствуют выполняемым им обязанностям, возникают
стрессовые ситуации и появляется ощущение дисгармонии.
Существует полезный инструмент, используемый при идентификации
потенциально "слабого звена" (задачи или действия), отрицательно сказывающегося на общей
производительности. Этот инструмент именуется WorkStyle Patterns™ Inventory
(WSPI) (разработка компании McFletcher Corporation). Цель, выдвигаемая при
оценивании, заключается в определении того, предпочитает ли сотрудник рабочий
подход, либо подход, продиктованный той либо иной должностью либо обязанностью.
Процессом оценивания может управлять помощник, аттестованный фирмой
McFletcher. В процессе анализа расхождения между предпочтительным рабочим
стилем сотрудника и его настоящим стилем работы, можно наблюдать различные уровни
стресса, которые устанавливаются различными методами.
Согласно исследованиям компании McFletcher, существует две разновидности
стресса: личный и организационный. Признаки типичного личного стресса
включают апатию и/или низкую производительность, частые жалобы, а также высокий
уровень заболеваемости. Причина личного стресса обычно заключается в том, что
человек хочет взять на себя дополнительные обязанности, количество которых
превышает его возможности. Причины организационного стресса могут заключаться в том,
что формируются некорректные представления относительно ожидаемого от работы
результата, качества продукта и проблем, связанных с обслуживанием заказчиков.
Организационный стресс также может возникать из-за "срыва" сроков выполнения
задания, а также большой текучести кадров. Организационный стресс также может
возникать в том случае, когда положение сотрудника в организации требует
выполнения такого объема обязанностей, который он просто не в состоянии выполнить.
В табл. 12.1 показано, что сотрудник может относиться к одной из определенных
категорий. Каждый из указанных в этой таблице профилей объясняется подробнее в
дальнейшем, а их удельный вес в организации описан в инвентарной ведомости.
Учетные (анкетные) записи изображены в виде расхождения предпочтений в
сравнении с действительностью, как показано в примере на рис. 12.8.
Таблица 12.1. Модель инвентарной ведомости, полученная с помощью
инструмента McFletcher WorkStyle
Категория
Область применения Типы
Работник
Руководитель
Менеджер
Задача
Проект
Организация
специалист
исполнитель
техник
рабочий
старший рабочий
совместитель
опекун
руководитель
специалист по адаптации
специалист по синтезу
новатор
оппонент
менеджер

428 Глава 12
Категория
Менеджер
Область применения
Организация
Окончание табл. 12.1
Типы
■ патрон
■ оценщик
■ менеджер проекта
График, приведенный на рис. 12.8, демонстрирует показатели профиля для
руководителя команды с предпочтительным рабочим стилем совместителя, а также
фактическую позицию рабочего стиля руководителя. Подобный работник предпочитает
трудиться на независимой основе, самостоятельно контролируя результаты своей работы.
Подобная позиция требует умения координирования по отношению к другим
сотрудникам. Вполне возможно, что руководитель команды хочет заниматься работой,
связанной с применением компьютеров, в то время как его должность требует выполнения
действий по координации, обучению и составлению обязанностей, объем которых
превышает его возможности. Подобная ситуация типична для многих технологов,
занявших позицию руководителя. Подобному руководителю команды придется приобретать
некоторые дополнительные навыки либо даже задуматься относительно смены работы.
Используя описанные выше инструменты, можно начертить рабочие стили
каждого члена команды на общей диаграмме, благодаря чему можно будет проверить
наличие взаимной дополняемости различных рабочих стилей либо обнаружить
имеющийся конфликт/дисбаланс.
48
44
40
36
32
28
24
20
16
12
Работник Руководитель Менеджер
(задача) (проект) (организация)
48
44
40
^s^" \ ^ 32
^" \^ SX 28
20
16
12
„
Фактические данные
Рис. 12.3. Пример инвентарной ведомости,
сформированной с помощью инструмента McFletcher WorkStyle
План управления персоналом, участвующим
в выполнении проекта
Как и распределение ресурсов, при котором учитывается соответствие между
работой и выполняющей ее командой, планы по карьерному росту и нужды в рамках

Распределение ресурсов 429
проекта, которые реализуют действия в структуре пооперационного перечня работ, и
план по менеджменту персонала, выполняющего проект, также имеют свои
особенности. Обычно подобная информация вводится с помощью инструмента
календарного планирования управления проектом (Microsoft Project либо другие подобные
программы), после чего начинается выполнение действий по планированию
менеджмента персонала. В конечном итоге эта информация становится частью плана
менеджмента программными проектами (SPMP), обсуждаемого в других главах книги.
Благодаря плану управления персоналом можно выяснить, какое количество ролей
требуется в рамках проекта, а также определить назначение этих ролей. Некоторый объем
этой информации может быть получен при рассмотрении зависимостей и действий
по календарному планированию, описанных в главах 14 и 15. План управления
персоналом может оказаться особо полезным для больших программных проектов, когда
для успешного выполнения требований проекта на многие месяцы и годы вперед
может потребоваться множество квалифицированных кадров. Обычно полученные
данные представляются в виде гистограмм, пункты которой эквиваленты временным
промежуткам либо соответствуют полной занятости (FTE). Пример гистограммы
плана управления персоналом приводится на рис. 12.4.
План управления персоналом включает информацию о навыках, необходимых
затратах, синхронизации графика, а также о том, каким образом будет выполняться
отбор персонала, необходимого для выполнения каждой из ролей. Эти действия будут
выполняться формальным или неформальным способом, в деталях или в общих
чертах, основываясь на нуждах проекта и на уровне организационной зрелости. Если
необходим поиск ресурсов и их привлечение с целью успешного функционирования
команды, профессионалы в области управления персоналом захотят иметь доступ к
описанию наличного персонала, содержащему следующую информацию:
■ необходимые навыки и квалификация;
м опыт работы;
м плановая заработная плата;
■ личные характеристики и интересы, удовлетворяющие целям команды;
■ соответствие требованиям.
300
3 250
? 200
о
I 150
8
¥ 100
50
0
9
16
23
30
январь
6
13
20
27
февраль
6
13
20
27
март
3
10
17
24
апрель
1
8
15
22
май
Рис 12.4. Гистограмма, соответствующая плану управления персоналом

430 Глава 12
Профессионалы в области поиска персонала могут нуждаться во множестве других
характеристик, отличных от указанных выше. План менеджмента персонала может
также включать информацию об отчетности по взаимосвязям, необходимым для
выполнения проекта.
Отчеты о взаимосвязях
Как только был запущен на выполнение план управления персоналом и были
распределены роли, менеджер проекта может определить ожидаемые взаимосвязи
отчетности при выполнении действий в рамках проекта. В организации описание
проекта разработки ПО может быть получено в нескольких различных вариантах.
Первое и наиболее понятное представление отчетности о взаимосвязях — классическая
организационная диаграмма. В случае с большими проектными организациями
подобная диаграмма может выглядеть довольно беспорядочной, особенно на нижних
уровнях подобной организации. Иногда при этом нивелируется индивидуальность.
Другой вид диаграммы, описывающий взаимоотношения в структуре
пооперационного перечня работ (OBS) для проекта на уровне организации, связывает части
организации с элементами структуры пооперационного перечня работ (WBS). При этом
также демонстрируется, какие отделения организации ответственны за каждый пакет
работ. Как правило, организационная диаграмма отображает, кто и кому делегирует
полномочия, а также определяет методы контроля для выполнения операций
проекта в структуре пооперационного перечня работ. Структура OBS демонстрирует, какие
части общего продукта назначаются рабочей группе. Эти части являются полезными
представлениями для больших проектов, но они становятся громоздкими в случае
использования небольших проектов, когда структура WBS относительно мала, а
отдельные исполнители отвечают за определенный пакет работ.
Другим полезным инструментом является каталог проекта. Он представляет собой
простой список сотрудников, выполняющих проект, с надлежащей контактной
информацией и описанием группы. В этот перечень могут даже включаться
организаторы совместного дела, которые не входят в состав проектной команды. В любом случае
полезно поддержать взаимоотношения с организаторами совместного дела. Даже
если все члены команды из одной и той же компании, сгруппируют участников проекта
в отдельном каталоге, эта операция может оказаться удобной и полезной. При этом
также появляется ощущение смысла идентичности группы. В случае, если члены
команды находятся далеко друг от друга, либо относятся к различным компаниям либо
организациям (например, субподрядчики), степень полезности каталога возрастает.
Матрица распределения обязанностей
Одним из наиболее полезных инструментов, используемых при выполнении
назначений ресурсов, является матрица распределения обязанностей (Responsibility
assignment matrix, RAM). Для этой матрицы существует несколько вариантов названий,
например, матрица обязанностей, матрица управления персоналом, линейная диаграмма
назначения обязанностей (Linear responsibility chart, LRC) и др. Матрица RAM явным
образом идентифицирует обязанности отдельных работников, а также роли при
изготовлении рабочих продуктов и выполнении действий. При этом определяется
исполнитель и содержание действий в рамках проекта. Эта матрица может быть легко развернута
в виде листа отслеживания процесса производства рабочего продукта. Основные
компоненты матрицы распределения обязанностей (RAM) показаны на рис. 12.5.

Распределение ресурсов 431
Матрица
распределения
обязанностей
Содержание
1 1 1 1
Исполнитель
Роль
Рис. 12.5. Матрица распределения обязанностей
Если при выполнении определенной задачи используются усилия более чем
одного человека, матрица RAM позволяет идентифицировать тех, кто выполняет главные
обязанности, а кто находится в резерве, а также тех, кто выполняет действия по
утверждению либо проверке. Это помогает менеджеру проекта разграничивать
обязанности, полномочия и ответственность при выполнении той или иной задачи. Личные
качества и соответствие выполняемой работе являются главными доминантами
надежности при выполнении роли индивидуумом. Ниже приводятся типичные
распределения ролей.
■ Утверждающее лицо — отвечает за утверждение элемента продукта как
завершенного (правами утверждение обладает Н, если другое не указывается).
■ Начальник—несет личную ответственность за производство элемента продукта.
■ Заместитель начальника— замещает руководителя при производстве элемента
продукта (в его роли могут выступать А и Н).
■ Ассистент— вносит материальный вклад в производство элемента продукта
(включая Р).
■ Рецензент— выполняет обязанности рецензента только для каждого отдельно
рассматриваемого элемента.
■ (Никто) — не ожидается участие в производстве или утверждении элемента
продукта.
На рис. 12.6 приводится пример матрицы распределения ресурсов (причем в
рамках программного проекта используются коды А, 3, Р, У, Н). Также демонстрируется,
каким образом матрица RAM может использоваться для балансировки рабочей
нагрузки, а также для гарантирования того, что руководящие роли корректно
распределены. С правой стороны таблицы могут добавляться дополнительные столбцы,
позволяющие отслеживать состояние рабочего продукта.

**
s
1
2
3
4
S
6
7
8
9
10
II
t2
13
14
15
16
t7
18
102
Проект X
Промежуточный
или готовый рабочий продукт
(V2.2 12/1/98)
WBS#
■
. .3
. .4
. ,5
. ,6
. .7
. .8
.
.
2.0
2.4
2.6
3.0
Э.1.6
3.2.2
4.0
4.2.6
4.3.1
4.3.2
4.4
4.5.5
,2.0
Инициализация проекта
Начальный план менеджмента проекта SW (SPMP)
Начальный Web-узел
Начальный календарь — установка текущей даты
Начальный план менеджмента конфигурации (SCMP) - AOP,
Начальный план обеспечения коммуникаций (СР)
Начальный план управления рисками (RMP)
Начальная структура WBS
Резюме симпозиума консультативного комитета ОА '97
Начальный план гарантирования качества SW ISOAP)
Предварительный реестр
Предварительный реестр SRS
Загружаемый документ предварительного реестра
Средства автоматизации исследований и оценок
Матрица инструмента оценивания
Отчет инструмента оценивания
Контейнер — процедура, связанная с документами
QS 9000 связанные процедуры для TX
Рабочий лист для записи реестра данных
Матрица связанной процедуры тестовой программы (индикатор Стоп)
Тестовые узлы/отчеты тестеров из реестра
OS 9000<вязанные процедуры (обновлено)
Фаза 1 пооекта — закрытие системы
Отчет о постпроектнои анализе
Завершено |
X
X
X
X
X
X
X
X.
X
X
X
X
X
X.
X
X
X
Советник Cmte
С
с
Управляющий Cmte
У
У
У
Старший советник
У
Старший советник
Р
У
Р
Р
У
У
у
у
Y
У
S
о
о.
S
Отдел поддержки пользователей
Р
Р
Р
Р
Р
Р
Р
Р
Р
Р
I
А
Менеджмент программ
Н
Р
Р
Р
А
3
Н
Р
Р
А
А
3
3
?
з
3
А
Инжиниринг систем
Обозначения
У уттирдитель Утверждение элемента продуктами завершенного (правши утверхдентобляомтН.еомлрупмнвухазывмтся)
В Ведущий разработчик несет яичную ответственность за производство элемента продукта
Э Заместитель разработчика Замеи«тругов(»^етлрнпр<)юводствеэлемент1г^)одут(«егорот1югут»ысту11«тьАиН
А Ассистент Вносит материальный вклад в производство элемента продукта (включая Р)
р Рецензент Выполняет обязанности рецензента только для каждого отдельно рессматгжваамоге элемента
Никто Не ожидается принятие участия в производстве или утверждении элвьмитя Гфодукта
Итого
Инжиниринг систем
Т
Р
Р
Н
Н
Н
3
Р
Р
Н
н
н
|Н_
iL
JL
н
ЕЕ
Инжиниринг систем
А
Н
Н
н
р
р
А
А
н
н
н
А
А
А
А
А
А
А
Менеджмент данных
S
S
Начальник отдела технических устройств
Технический разработчик
Технический разработчик
Технический разработчик
Технический разработчик
Технический советник
1
У
0
X
2
Ведущий
разработчик
в
1
1
1
1
1
1
1
1
i
1
1
1
1
(
1
1
1
1
1
Заместитель ведущего
разработчика
3
0
1
1
0
0
о
Ассистент
А
■
0
0
0
0
2
1
2
0
0
0
2
2
2
Рецензент
Р
1
2
2
0
2
2
1
1
0
2
?
2
2
0
1700000000000000
0000020 II 60000000
0000060102000000
0000140090000000
020 10 030220000000
1 9 0 10 1 15 0 14 17 2 0 0 0 0 0 0
Рис. 12.6. Пример матрицы распределения обязанностей

Распределение ресурсов 433
Выравнивание распределения ресурсов
Часто необходимость в каких-либо навыках, требуемых для работы с проектами,
вызывает определенные неудобства для поставщиков ресурсов. В силу этого
согласование деятельности поставщиков будет неоднозначным, как показано на гистограмме
из рис. 12.4. Если говорить об идеальном варианте, желательно, чтобы начальные и
завершающие действия происходили лишь один раз для каждого ресурса проекта.
Например, в случае с программным проектом может потребоваться сконцентрировать
деятельность инженеров-тестеров на нескольких последних месяцах цикла
разработки, а не привлекать их заранее. Это означает, что потребуется, если это возможно,
попытаться спланировать перечень действий, используемых в различных
компонентах продукта. В этом случае максимизируется эффективность использования этих
компонентов. Иногда это необходимо (как в случае с наемными рабочими), поскольку
один и тот же ресурс может стать недоступным далее в проекте. Еще один пример
показан на рис. 12.7. Здесь, в соответствии с планируемой работой, требуется слишком
много ресурсов в один или несколько периодов времени (превышается наличный
объем свободных ресурсов). В этом случае можно распределить действия
(выравнивание гистограммы) таким образом, чтобы пользователь никогда не затребовал
объем, превышающий имеющееся предложение. В этом случае можно более эффективно
использовать ресурсы до тех пор, пока они доступны (сгладить значения между
пиками кривой). Эти действия практически всегда могут занимать время, необходимое для
завершения работы, как показано стрелкой на рис. 12.7. Однако в этом случае
достигается более эффективное использование ресурсов. Дополнительное обсуждение
эффективности выравнивания ресурсов производится при рассмотрении зависимостей
(глава 14), а также календарного планирования (глава 15).
г"*т—:—I—I—I
Рис. 12.7. Выравнивание распределения ресурсов
Действия по управлению ресурсами проекта
во время его выполнения
Назначение ресурсов выполняемым действиям для проекта разработки является
лишь частью работы менеджера проекта. Также в обязанности менеджера входит
включение ресурсов в работу, когда формируется высокопроизводительная команда,
способная быстро выполнять сложные распределения, а также подстраиваться по
мере необходимости под изменяющиеся обстоятельства выполнения проекта.
Руководитель должен обеспечивать связь с другими разработчиками и группами,
связанными с продуктом и проектом. Этот процесс именуется управлением взаимодействия.

434 Глава 12
Он включает идентификацию, документирование, календарное планирование,
общение, а также мониторинг взаимодействий на всех этапах выполнения проекта.
Особое внимание следует обратить на три вида взаимодействия: личное,
организационное и на уровне системы. Личное взаимодействие связано со всеми
конфликтами, возникающими между людьми или в рамках выполняемого проекта. Поскольку
неизменность проекта порождает причины возникновения конфликтов, менеджеру
проекта приходится играть роль "судьи" либо "миротворца", улаживающего
возможные конфликты между сотрудниками организации. Конфликты на уровне
организационного взаимодействия связаны с изменяющимися целями организации и различными
стилями управления проектом, а также провоцируются организациями,
выполняющими поставки ресурсов. Менеджер проекта обязан устранять различия и налаживать
коммуникации как внутри, так и снаружи непосредственно на уровне организации
или в рамках выполняемого проекта. Системное взаимодействие связано с продуктом,
оборудованием или другими не связанными с людьми взаимодействиями,
возникающими на этапе разработки проекта. К этой области обычно относятся все
технические проблемы, связанные с проектом.
Таким образом, менеджер проекта должен уметь управлять взаимодействиями с
целью балансировки и оптимизации взаимодействия с людьми и устранения
барьеров, мешающих нормальному завершению работы.
Резюме
Глава была посвящена методам распределения ресурсов в случае, когда
существует перечень настраиваемых действий в составе структуры WBS, соответствующих
выбранному жизненному циклу разработки продукта. Во время распределения
ресурсов менеджеру программного проекта следует учитывать очень многие аспекты
этой проблемы. Уровни мастерства отдельных программистов редко совпадают.
Подозрительность и пререкания могут проявляться на этапе создания
распределения, что, в свою очередь, добавляет работы менеджеру проекта, вынужденному
устранять возникающие внутри команды конфликты. Интересы карьерного роста
для различных членов команды являются взаимоисключающими.
Несбалансированная рабочая нагрузка приводит к появлению моральных проблем, а также к
нарушению календарного графика.
В завершение была проанализирована роль менеджера проекта в наборе
персонала для проекта и выборе ресурсов. Эта область имеет отношению к менеджменту
человеческих ресурсов. В главе исследовались роли, назначаемые в программных
проектах, а также рассматривались некоторые стратегии, применяемые для приведения
в соответствие персонала и выполняемых им ролей. Была продемонстрирована
необходимость планирования менеджмента персонала, а также выравнивания ресурсов
при их распределении для выполняющегося проекта. Описывались матрицы
распределения обязанностей в качестве одного из инструментов, применяемых для
распределения ресурсов проекта.
Контрольные вопросы
1. Опишите свою роль, имевшую место в вашей карьере, когда главным был один из
трех аспектов работы: обязанности, полномочия и ответственность. Успешно ли
вы справлялись с этой ролью?

Распределение ресурсов 435
2. При каких особых обстоятельствах не требуется обязательное применение
матрицы распределения обязанностей? Почему?
3. Какую дополнительную информацию вы бы добавили к матрице распределения
обязанностей и почему?
Практическое занятие
Мистер Адаме просмотрел оценки, выполненные для продукта с помощью
инструментального набора ARRS, и остался недоволен. В ходе обсуждения этой проблемы
с мисс Пайтель он пришел к выводу о наличии трех возможностей, которые стоит
исследовать в связи с кадровыми вопросами в рамках проекта.
1. Используйте CRM-персонал, как и планировалось изначально, но улучшите его
возможности с помощью специальной программы для новичков, обучающей
программному инжинирингу.
2. Позвольте CRM-персоналу самостоятельно продолжить работу, и вы получите
продукт, который на 100% будет создан с помощью BSD.
3. Воспользуйтесь данными о разработке, предоставленными SourceForge
(www.sourceforge.net), и управляйте разработкой параллельно с министерством CRM.
Литература
Kerzner Harold. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 6-е
издание. NY: John Wiley & Sons, Inc., 1998.
Lewis James P. Project Planning, Scheduling, and Control- A Hands-On Guide to Bringing Projects in on Time and
on Budget, повторное издание. NY: McGraw-Hill. 1995.
Paulk, Mark С и др. The Capability Maturity Model: Guidelines for Improving the Software Process. NY: Addi-
son-Wesley, 1994.
Pressman Roger S. Software Engineering: A Practitioner's Approach, 5-е издание. NY: McGraw-Hill, 2001.
Дополнительные сведения в Internet
computer. org/software/. Журнал IEEE Software Magazine.
www.pmi . org/publictn/pmboktoc .htm. Руководство PMI по управлению проектами, основы
знаний (РМВООК® Guide), глава 7.
www. sei . стп. edu/. Институт качества ПО.
www.swebok.org/. Руководство по программному инжинирингу, основы знаний. Проект
компьютерного общества IEEE, Координационный комитет по программному инжинирингу.
www2.umassd.edu/SNPl/sei/tr25f/tr25_12b.html. Планирование программных проектов,
ключевая область процесса для уровня 2: повторяемый.
www2. umassd. edu/SWPI/sei/tr25f/tr25_12c.html. Отслеживание и контроль программных
проектов, ключевая область процесса для уровня 2: повторяемый.

Выбор
организационной
формы
Наличие огромного выбора жизненных циклов разработки продукта,
применение которых обеспечивает выполнение программного проекта, способствует
большому выбору соответствующих организационных форм. При этом неизбежно
возникают некоторые вопросы. Сколько существует подобных форм? Каково их
происхождение? Для чего они предназначены? Какая из них наиболее приемлема в
том или ином случае? Что именно подразумевается под понятием "организация"?
С этими и другими вопросами сталкиваются менеджеры в процессе планирования
программных проектов.
В главе раскрывается понятие организации, а также исследуются типичные
организационные формы, характерные для программного проекта. Кроме того,
рассматриваются преимущества и недостатки каждой из этих форм. Важно определить
тип организации, в которой будет выполняться проект, а также наиболее
приемлемый тип проекта.
Стадии жизненного цикла разработки
продукта
На какой стадии основной модели жизненного цикла разработки продукта
находимся мы в настоящее время? Как показано на рис.13.1, в данном случае речь идет о
самом начале жизненного цикла разработки программного продукта—о
планировании проекта. В частности, рассматриваются методы (как?) разработки проекта,
определенного в главах 7-9. Порядок выполнения действий по выбору организационной
формы представлен на рис. 13.2.
Связь главы 13 с 34 компетенциями
Чтобы правильно понять и выбрать соответствующую организационную форму
программного проекта, необходимо определиться с выбором компетенций.

Выбор организационной формы 437
Исследование
концепции
•
Формулирование

потребности
Исследование
системы
• Спецификация'
интерфейса
системы
Идентификация
циклов SLC
' Циклы SLC
Выбор
модели
' Модель SLC
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
■SLC
Распределение
ресурсов
■ Бюджет
Требования
1 Спецификация
требований
к ПО
Разработка
проекта
■ Описание i'

разработки ПО
Внедрение
■ План

тации/верификации ПО
Выбор модели
жизненного цикла
разработки ПО
Установка
■Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
'
Пользовательская
документация
Сопровождение
■ Документация
по
сопровождению
Вывод из
эксплуатации
• Архивный
отчет
Рис. 13.1. Жизненный цикл разработки программного продукта
Почему?
• Коэффициент
КОИ
Что?
• Техническое
задание
(на проект)
Выбор
организационной
формы
Как?
• План SPMP
Выполнение
• Жизнент
цикл
м
Сделано
• Процесс РРА
Рис. 13.2. Схема процессов выполнения проекта

438 Глава 13
Разумеется, при использовании технологии разработки программного продукта
следует разобраться в действиях, направленных на разработку ПО, а также уметь
оценивать различные подходы и выбирать соответствующие методы и
инструментальные средства. Подгонка существующих структур с учетом выполнения текущего
проекта имеет важное значение для организационной модели. В этом случае можно
эффективно управлять и контролировать любые субподрядные отношения, если в
них возникнет необходимость. Применяемые в этом случае навыки управления
проектом подразумевают выбор инструментов и процессов менеджмента проекта, а
также документирование результатов выбора, выполненного внутри организации, и
мотивирование данного выбора. Необходимые навыки управления персоналом
подразумевают руководство, взаимодействие и навыки общения. В этом случае правильный
выбор организационной формы и контроль изменений, возникающих в процессе
применения новой организационной структуры. Эти компетенции связаны с
обучением персонала, а также определяют формирование на этой базе эффективной
команды, члены которой в ходе выполнения проекта будут "расти" в профессиональном
плане. Успешное освоение подобных компетенций повышает шансы успешного
исхода при выполнении программного проекта.
Методики разработки продукта
1. Оценка альтернативных процессов — выполнение оценки с применением
различных подходов.
2. Управление субподрядчиками— планирование, управление и отслеживание
производительности при выполнении проекта.
3. Отбор методов и инструментов— определение процессов отбора
инструментальных средств.
4. Подгонка процессов— модификация стандартных процессов с целью
достижения их соответствия с выполняемым проектом.
5. Понимание действий по разработке продукта — изучение цикла разработки ПО.
Навыки менеджмента проектов
6. Документирование планов — идентификация ключевых компонентов проекта.
7. Отбор инструментов менеджмента проектов — методика, используемая при
выборе инструментов управления проектами.
Навыки менеджмента персонала
8. Взаимодействие и общение— контакты с разработчиками, руководителями
верхнего звена и другими членами командами.
9. Лидерство — обучение команд разработчиков проекта с целью достижения
оптимальных результатов.
10. Управление изменениями—способность быть эффективным агентом изменений.
11. Планирование карьерного роста— структурирование и управление ходом
реализации карьерного роста.
12. Набор персонала— успешный набор персонала и собеседование с членами команды.
13. Отбор команды — отбор высококомпетентных специалистов.
14. Создание команды — формирование, управление и поддержка эффективной
команды.

Выбор организационной формы 439
Учебные цели главы 13
После изучения материала главы читатель должен уметь выполнять следующее:
■ объяснить, каким образом организации приобрели существующие ныне формы;
м перечислить и описать организационные структуры, в рамках которых может
разрабатываться проект;
■ описать общую модель организации;
■ определить, какая из организационных форм наиболее приемлема в
определенных условиях;
■ определить понятие об организации с помощью, по крайней мере, четырех
характеристик;
■ перечислить формы полномочий, необходимых для организации;
■ перечислить этапы и описать способы выполнения эффективности
организационных изменений.
Определение организации
В результате достижения текущей стадии жизненного цикла управления проектом
происходит выполнение планирующих действий этапа как, в результате которых
создается продукт, определяемый заказчиком на этапе что. Как только в нашем
распоряжении окажется структура пооперационного перечня работ (Work breakdown structure,
WBS), можно рассматривать возможные пооперационные разбиения на уровне
организации, которые будут выполняться в дальнейшем. Что же такое организация, и почему
этому вопросу придается такое большое значение? В случае, если организационная
структура выбрана неправильно, управление проектом может оказаться намного
сложнее, чем кажется на первый взгляд. В этой ситуации вполне уместна "транспортная"
аналогия: при выборе неподходящего корабля значительно затрудняется продвижение
к цели, и что еще хуже, можно просто утонуть. Если команда корабля многочисленна и
впереди ее подстерегает шторм, то в этом случае необходим прочный, хорошо
защищенный корабль, командование и управление сосредоточено в руках уверенно стоящего
на мостике капитана. При условии хорошей погоды допускается свободное плавание,
когда флотилия из нескольких небольших судов, управляемых своими капитанами,
следует общему курсу согласно имеющимся навигационным картам.
Чтобы разобраться в основной теории организации с целью лучшего понимания
сущности различных организационных форм, рассмотрим некоторые классические
идеи и характеристики.
Возникновение организаций
Почему организациям придается такое первостепенное значение? Разве они чем-
то отличаются друг от друга? Естественно, и отличия достаточно серьезны.
Организации возникли тысячи лет назад. Очевидно, что еще при строительстве пирамид в
Египте и Центральной Америке требовалась организация, выраженная в некоторой
форме. В каждой первобытной семье был предводитель, руководивший
необходимыми для выживания сельхозработами. Возникновение рядовых военных организаций
диктовалось целями нападения и защиты. Это были лишь ростки различных
существующих ныне организационных форм.

440 Глава 13
В эпоху развития земледелия понятие "проект" еще не было достаточно четко
сформировано. Основные производства сосредотачивались в хозяйствах или
небольших деревнях. Торговля и организация объединений (как правило) происходила
на рынках. Изобретение парового двигателя знаменовало начало промышленного
века, и поэтому на производственной сцене уже доминировали крупные машины. В силу
этого рабочие были вынуждены покидать свои хозяйства и заниматься
производством товаров на заводах. С целью контроля деятельности рабочих (как правило,
малограмотных) создавались управленческие структуры. Самой доступной была военная
структура со своей иерархической цепочкой команд. Действительно, наше
организационное мышление основывается на иерархической структуре, напоминающей
армию (генеральный директор (главный администратор) имеет сходство с генералом,
вице-президенты—с полковниками, начальники отдела—с майорами, начальники
участков— с капитанами и т.д.). Поэтому, наверное, работники, находящиеся на
самой низкой ступени организации, именуются "армией".
Современная корпоративная структура в значительной степени определяется
трудами Генри Файола (Henri Fayol) A841-1925), французского горного инженера из
компании Comambault Co., работающего в конце XIX века. Также плодотворно
использовались идеи Макса Вебера (Max Weber) A864-1920), который считается "отцом
бюрократии". Действительно, термин бюрократия происходит от немецкого слова, означающего
"управление офисом", причем изначально этот термин не носил негативный оттенок.
Заслугой Файола является разработка ряда организационных идей, называемых
"принципами менеджмента". Ниже приводится соответствующий перечень:
■ разделение труда;
■ централизация;
■ управление;
■ дисциплина;
■ иерархическая структура;
■ функциональное ориентирование;
■ "стартовая ниша" специальности;
■ путь решений и продвижения, который направлен вертикально вверх из
"стартовой ниша", наравне с действиями в рамках проекта, распределенным на
категории в соответствии с дисциплинами и специальностями.
Если организация сформирована на основе применения подобных принципов, то
вполне естественно, что маркетологи работают в отделе маркетинга, а инженерно-
технический персонал— в техническом отделе и так далее. В начале века основная
масса рабочих была неграмотной, поэтому все решения, имеющие отношение к их
деятельности, принимались высшим руководством, а затем передавались
непосредственным исполнителям, которые считались лишь "винтиками" огромного механизма.
В те времена подобная схема руководства была вполне приемлемой.
На рубеже XIX века инженером-механиком Фредериком Тейлором (Fredrick
Taylor) была предложена научная организация менеджмента. Этот подход подразумевал
наличие специалистов по научной организации труда, а также анализ временных затрат
и изучение проблем, возникающих в ходе трудовой деятельности. Это учение нашло
множество последователей, таких как Фрэнк и Лилиан Гилберт (популярный труд
Cheaper-by the Dozen), Генри Л. Гант (Henry L. Gannt). Например сегодня мы пользуемся

Выбор организационной формы 441
диаграммами Ганта. Немного позже их представления о рабочих как о "винтиках"
механизма уступили место понятиям о продуктивности, которая напрямую зависит от
работников и степени их удовлетворенности имеющимися возможностями.
Благодаря росту образованности среди рядовых рабочих отпала необходимость в
иерархическом менеджменте. Организации, столкнувшись в 80-х годах прошлого века с
проблемой давления цен и низкого качества, стали стремиться к структурному упрощению.
При этом уменьшалось количество менеджеров, а также сокращался количественный
состав исполнительных и контролирующих органов. Вместо этого появились
обладающие полномочиями команды, принимающие решения на более низком уровне
организации, например, в рамках производственного отдела. Матричный метод
управления, появившийся в 60-х годах XX века, совместно с универсальными командами,
возникшими в 80-х годах XX века, привели к формированию организационной
формы, преобладающей в настоящее время.
Изменяются ли организационные стили?
На рубеже XX столетия, когда все начинает изменяться намного быстрее, чем
раньше (можно сказать, со скоростью Internet), организационные стили также
изменяются с "космической" скоростью. На рис. 13.3 представлен процесс превращения
иерархических форм в командные стили, которые являются свободно
структурированными и обладают дополнительными преимуществами. Об этом говорит и наличие
различий между классическим структурным программированием в среде мейнфрей-
мов и объектно-ориентированным программированием в клиент-серверных средах.
19хх 20хх
Формальный стиль Неформальный стиль Стиль, основанный на командах
4 _"ь*^.с^-0* 0еэ~ уА^ п"^
——^——— |о •}
Субподрядная "
работа Субподрядная
работа
Рис. 13.3. Изменение организационных стилей
Изучая данный рисунок, можно прийти к выводам о наличии как формальной, так и
неформальной организации, существующей в любой мыслимой ситуации. Формальная
сторона выражается в организационной схеме. Неформальный компонент
представляет собой сеть отношений, переходящих обычно за формальные рамки (меткое название
"мировая паутина World Wide Web" является неплохой метафорой одноранговой сети,
выходящей за рамки формальных организаций). В командной организационной модели
ее члены входить в состав нескольких команд, имеющих различные цели. Как правило,
намерения всех команд ориентированы на достижение стратегической цели,
намеченной управляющей верхушкой более крупной организации. Некоторые из этих команд

442 Глава 13
могут быть нацелены на совершенствование текущих операций; задачей других команд,
работающих над проектом, может быть достижение одноразовых целей проекта. Как
показано на рис. 13.3, в случае, когда участники различных команд интенсивно
обмениваются информацией друг с другом, могучий информационный поток буквально
"пронизывает" всю структуру организации. В результате мы видим, что неофициальная
структура способна передавать информацию быстрее, чем официальные каналы связи.
Характеристики организации
При установлении организационного климата, необходимого для управления
программным проектом в той или иной организации, следует учитывать наличие
нескольких компонентов:
■ модель;
■ зрелость;
■ плотность;
■ размер;
■ рассеивание;
■ структура.
Но сначала определимся все же с понятием организации. В литературе по теории
управления приводится несколько определений организации.
■ "Организация представляет собой систему, которая обменивается материалами,
кадрами, рабочей силой и энергией с окружающей средой" (Джеймс Л.Боудич и
Энтони Ф.Буоно) .
■ "Организация— это группа людей, имеющих определенные формальные цели"
(Пол Херси и Кеннет Х.Бленчард) .
■ "Организации можно определить как группы людей, координирующих свои
действия для достижения организационных целей" (Гарольд Керцнер) .
Некоторые из данных определений делают упор на различные характеристики.
Определение, которого мы будем придерживаться, проводит грань между
совокупностью и группой, а также группой и организацией. Совокупностью является просто
группа людей, не взаимодействующих между собой, которые могут как иметь, так и не
иметь общих целей. Пассажиры лифта являются, как правило, случайной
совокупностью людей, делящих общественное пространство. Группой они становятся в том
случае, если начинают взаимодействовать друг с другом, а организацией они станут
лишь тогда, когда у них определится общая цель и выработаются определенные
правила группового поведения (явно или неявно). Поэтому организацией называется
группа взаимодействующих и имеющих общую цель людей. Совокупность случайных
людей, застрявших в лифте, вскоре станет группой, а затем и организацией, имеющей
Bowditch James L. and Anthony F. Buono. A Primer on Organizational Behavior, 4-я редакция, NY:
Jossey-Bass, 1996.
Hersey Paul and Kenneth H. Blanchard. Management of Organizational Behavior, 6-е издание.
Englewood Cliffs, NJ: Prentice Hall, 1993.
Kerzner Harold. Project Management: A Systems Approach to Planning, Scheduling and Controlling, 6-e
издание. NY: Prentice Hall. 1998.

Выбор организационной формы 443
общую цель— выбраться из лифта, т.е. когда начинается важное взаимодействие.
В устной форме устанавливаются цели, роли и правила. И, будем надеяться, в
конечном итоге в составе этой группы определятся лидеры и специалисты.
Но это только словесная модель. Необходимо также разработать некоторую
визуальную организационную модель. Ее не так уж сложно сформировать, поскольку в
литературе, описывающей теорию менеджмента и поведение работника в организации,
можно найти множество таких моделей. Однако важно установить соответствие
между организацией и определенной моделью, поскольку это является основой
правильного понимания и выполнения требуемых изменений.
Обобщенная модель организации
Казалось бы, в мире существует почти столько же организационных моделей,
сколько и организаций. Рассмотрим обобщенную модель организации, что позволит
лучше понять ее основные элементы. Обобщенная организация, описанная Генри
Минтсбергом (Henry Mintzberg), состоит из пяти основных частей.
■ Стратегическая верхушка — руководство, задающее стратегическое направление.
■ Управление среднего звена— воплощение стратегического направления в виде
тактических планов.
■ Операционное ядро — выполнение планов по производству продукции или услуг.
■ Техноструктура — техническая инфраструктура, поддерживающая операционное
ядро.
■ Обслуживающий персонал— человеческая инфраструктура, поддерживающая все
звенья организации.
Стратегическая
верхушка
Среднее
звено
Операционное адро
Рис. 13.4. Общая организационная структура
Источник: Mintzberg, Henry. Structures in Fives:
Designing Effective Organizations. NY: Prentice Hall. C. 11,1993
Все это представлено на рис. 13.4. Некоторые называют такую структуру
организации "грибовидным облаком" (шутка). Центральная часть рисунка представляет

444 Глава 13
основную функцию бизнеса (производство таких услуг, как программный
инжиниринг, а также исполняемые программные продукты). Техноструктура обычно
формируется инженерными функциями, определяющими основной бизнес
(производство полупроводников, службы Web-дизайна и т.д.), а обслуживающий персонал
включает административные службы, обслуживание компьютеров и сети,
человеческие ресурсы и т.д.
Для эффективной работы в любой проектной организации необходимы выше
названные элементы. Если разработка проекта осуществляется в более крупной
организации, то для удовлетворения основных операционных потребностей используется
техноструктура и обслуживающий персонал. Стратегическое управление проектом
осуществляется его руководителем через интерпретацию целей заказчика.
Обслуживающий персонал и техноструктура проектов программного инжиниринга включает
управление конфигурацией, сетевую поддержку и административные услуги типа
копирования и управления поставками. Операционное ядро проекта состоит из
разработчиков ПО, моделирующих и внедряющих проект с помощью компьютерных
технологий, зачастую представляющих собой небольшие команды, управляемые
менеджерами среднего звена или менеджерами подпроекта.
Имеет ли значение размер организации?
Очевидно, что размер является важной характеристикой организации, разраба-.
тывающей проекты и программы. Размер желаемого системного продукта определяет
размер организации, необходимой для его разработки. Количество допустимых и
необходимых для проектной организации взаимодействий сотрудников является
определяющим фактором климата управления проектом в организации. Хотя, с другой
стороны, большее количество работников не всегда оправдано.
Поскольку немаловажное значение имеет объем понесенных трудозатрат,
возникает вопрос: какова величина размера, которая начинает сказываться на
деятельности многих компаний? Проекты и программы выполняются в рамках контекста
деловых систем, и естественно, многие производства полностью организованы на основе
проектов. Молодые компании стремятся запустить в работу одновременно множество
проектов с целью быстрейшего ввода в эксплуатацию сулящих прибыль продуктов.
Данные производства полностью организованы вокруг продуктов и услуг, которые
должны реагировать на рыночные изменения. Имеет смысл рассматривать ряд
возможных проектов на основе двух измерений: количество персонала и
длительность осуществления проекта. На рис. 13.5 показано, что недостаточное
количество персонала, работающего над проектом, ведет к существенному замедлению
работы и к слабому реагированию на запросы рынка, в то время как слишком
большим количеством людей, работающих над "аварийным" проектом, невозможно
управлять. Новые продукты и основные средства представлены линией, идущей из
нижнего левого угла в верхний правый угол. Размер осей х и у на данном рисунке и
полоса "желаемого товара" будут отличаться в различных компаниях, но общие
принципы и взаимосвязи не изменяются.
Рассеянные и сосредоточенные организации
Еще один фактор, имеющий отношение к размеру— наличие рассредоточения.
Чем больше рассредоточена организация команды разработчиков проекта, тем
сложнее работникам данной организации взаимодействовать друг с другом. Современные

Выбор организационной формы 445
i
телекоммуникационные технологии стерли многие границы, однако ничто не
сравнимо с непосредственным взаимодействием людей при решении определенных задач.
На рис. 13.6 иллюстрируется взаимодействие между удаленными членами команды.
Члены сосредоточенной команды находятся в одной комнате, на одном этаже, в
одном здании или в одном офисном кампусе A), в то время как рассеянные по всему
миру члены команды находятся в совершенно различных областях A, 2, 3 и 4). Такая
ситуация доставляет множество проблем менеджеру программного проекта. Нельзя не
принимать во внимание культурные различия, языковые барьеры, разницу во
времени, трудности обеспечения общей технической и проектной инфраструктурой.
Дополнительная информация относительно выполнения проекта с помощью методов
дистанционного управления находится в приложении Е.
1 2 4 8 16 >32
Количество разработчиков проекта
Рис. 13.5. Реагирование рынка на размер и длительность
осуществления проекта
Члены сосредоточенной команды Члены рассеянной команды
Рис. 13.6. Примеры рассеянных и сосредоточенных организаций

446 Глава 13
Относительные полномочия менеджера проекта
Еще одна важная характеристика проектной организации заключается в
определении того, насколько велики полномочия и власть менеджера проекта. Идеальным
менеджером программного проекта можно считать генерального директора проекта,
перед которым (и больше ни перед кем) отчитывается каждый занятый в
производстве работник. К сожалению, такой вариант является весьма редким. Однако
руководитель проекта, не имеющий реальной власти, бессилен. Согласно Херси и Бленчарду,
менеджер проекта должен обладать следующими полномочиями.
1. Легитимность— осознание того, что руководитель может принимать решения в
соответствии с его званиями или положением в организации.
2. Вознаграждение — осознанная способность обеспечивать работников всем, что
необходимо в дальнейшем.
3. Контакты — осознанная связь (сотрудничество) с влиятельными людьми или
организациями.
4. Обязательность — воспринимаемая способность принимать санкции или
заключения по фактам простоев в работе.
5. Эксперт — осознание того, что руководитель имеет соответствующее
образование, опыт и мастерство.
6. Информация — воспринимаемый доступ к данным или владение полезной
информацией.
7. Референт— воспринимаемая привлекательность общения (взаимодействия) с
другими людьми.
Пункты 1, 2, 3 и 4 в данном списке подразумевают положение работника в
организации и называются позиционными типами власти. Пункты 5, 6 и 7 называются персо-
налъными типами власти. Ориентированные на решение исключительно технических
задач, разработчики ПО, которые поднимаются до руководящих должностей, очень
часто имеют значительную экспертную и информационную власть. Если к тому же
они симпатизируют подчиненным, то можно сказать об их силе в качестве референта.
Благодаря их руководящему положению они имеют значительную позиционную
власть, которая зависит от организационной структуры среды.
Организационная зрелость
А теперь рассмотрим характеристики степени зрелости организации. Поведение
молодых компаний во многом отличается от поведения долго существующих
корпораций. Они часто характеризуются как гибкие, изменчивые (нестабильные),
энергичные и обычно небольшие. Зрелость достигается в том случае, когда
формализуются определяемые и выполняемые процессы.
Для незрелых организаций характерно следующее:
■ специальные процессы, импровизированные их исполнителями и руководством;
■ процессы и правила, строго не соблюдаемые или не обязательные;
■ высокая степень зависимости от практикующих в данный момент разработчиков;
■ возможность возникновения проблем, связанных с ценами и графиками;
■ несоответствие графиков функциональных свойств, качества продукта или услуги;
■ трудно предсказуемый уровень качества.

Выбор организационной формы 447
Для непосвященных процессы незрелых организаций могут выглядеть так, как это
показано на рис. 13.7. Для сравнения ниже приведены некоторые характеристики
зрелых организаций:
■ определенные, документированные и постоянно совершенствуемые процессы;
■ документированные процессы, которые являются совместимыми с фактическим
способом производства;
■ видимая поддержка со стороны руководства и разработчиков;
■ хорошо контролируемые, проверяемые и приводимые в исполнение политики;
■ выполняемые и используемые измерения продуктов и процессов
■ дисциплинированное использование технологии.
Для неопытного работника процессы в зрелой организации могут иметь вид,
представленный нарис.13.8.
ВХ0Д*Ш*Ъ*ВЫХ0Д
Рис. 13.7. Процессы в незрелой организации, наблюдаемые извне
ВХ0Д-ш*ш*ш- ВЫХОД
Рис 13.8. Процессы в зрелой организации, наблюдаемые извне
Помимо понятия зрелости, немаловажное значение имеет также
плотность/неплотность культуры организации. Доступные для понимания и соблюдаемые нормы,
правила и процессы характеризуют плотную культуру. Компания IBM в 80-х годах
описывалась обычно как плотная корпоративная культура с общепринятыми и
установленными способами поведения, которые заключались в формальных процессах в
производстве почти всех видов продукции. Многие аналитики полагали, что
компания стала слишком плотной, чтобы нести ответственность за быстро изменяющийся
компьютерный рынок. Неплотные культуры имеют тенденцию к тому, чтобы быть
более свободными и индивидуальными. Под описанную модель хорошо подходит
средняя компания, имеющая относительно короткую историю.
Организационные структуры
Получив общее представление об организации, можно приступать к
рассмотрению общих форм, с которыми может столкнуться менеджер программного проекта.
В 60-70-х годах XX века в специальной литературе обсуждалось несколько форм
организации. Все они представлены в табл. 13.1.
В 1977 году в одной из статей издания Project Management Quarterly
("Организационные альтернативы проектному менеджменту") Роберт Юкер (Robert Youker)
заявил, что различные организационные формы, представленные в литературе того
времени, имеют спектральную характеристику, благодаря чему можно определить

448 Глава 13
Таблица 13.1. Типы организаций
Типы организаций
Структура навыков
Соблюдение субординации,
отчетность
Функциональный
Матричный
Слабый, сбалансированный
либо сильный, в зависимости от
относительной силы
функциональных руководителей
либо руководителей проекта
Проективный
Комбинация трех
указанных типов
Группировка в виде
функциональных специальностей
Группируется в виде
функциональных специальностей, но
назначаются проектам по мере
необходимости
Все навыки, требующие
назначению в рамках проекта,
выполняемого в режиме полной
занятости персонала
Варьируется
Только руководителю
функциональной группы
Руководителю
функциональной группы и руководителю
(ям) проекта
Только руководителям
проекта
Варьируется
формы, наиболее подходящие для определенного типа проекта. С одной стороны,
спектр имеет классическую, высокоструктурированную функциональную
организацию (при которой функциональные специалисты отчитываются только перед
руководителем функциональной области). При этом организация находится полностью
"в собственности" менеджеров проектов (каждый специалист, независимо от своей
специальности, отчитывается перед менеджером проекта, не являющимся одним из
функциональных руководителей). Между этими двумя типами организаций
располагаются еще несколько форм матричных организаций. В следующих разделах будут
рассмотрим некоторые из них.
Функциональные организации
Функциональная организация представляет собой то, что многие из нас привыкли
считать стандартной устаревшей организацией (сторона 19хх на рис.13.3). В такой
организации работники разделены по своим функциональным специальностям
(вспомните "Принципы менеджмента" Файола (Fayol's Principles of Management),
рассмотренные выше) и отчитываются перед менеджером функциональной области.
Например, все разработчики ПО той или иной компании находятся в техническом
отделе и отчитываются перед руководителем технического отдела. По такому же
принципу отчитываются менеджеры, отдел сбыта и т.д. Схема типичной функцио-
н;1Льной организации имеет вид, представленный на рис. 13.9.
Функциональная организация имеет свои преимущества:
■ четкое разделение полномочий — каждый специалист отчитывается только перед
одним менеджером;
■ избежание дублирования функций — все разработчики находятся в одной группе,
специалисты по продажам в другой и т.д.;
■ содействие в совершенствовании технического мастерства и специализации—
разработчики трудятся совместно с другими разработчиками;

Выбор организационной формы 449
Президент
Инжиниринг
Производство
Финансы
Маркетинг
I
Операции
1 1

Исследования

Разработка
Продукт
А
Продукт
В
1 1
Продукт
А
Продукт
В
1 1
Продукт
А
Продукт
В
1
Продукт
А
Продукт
В
Рис. 13.9. Типичная функциональная организация
Источник: Cable, Dwayne, и John R. Adams. Organizing for Project Management. С П-20.
■ возможность служебного продвижения для квалифицированных работников —
внутри отдела работникам предоставляется возможность служебного роста;
■ акцентирование внимания на основных функциях— приветствуется
сосредоточение на основных компетенциях.
Функциональная форма организации имеет также и некоторые недостатки:
■ отсутствие ориентации на интересы заказчика, и, кроме того, существование
"стены", через которую можно перебросить работу следующему функциональному
звену данного процесса;
■ длинный цикл принятия решений, поскольку необходимо конструирование
функциональных "накопителей" с целью получения перекрестных групповых
решений;
■ отсутствуют функциональные подотчетные лица в рамках всего проекта, поэтому
менеджеры проектов имеют недостаточный объем полномочий;
■ затрудненная координация действий специализированных функций из-за
длинного цикла принятия решений;
■ возможность возникновения конфликтов между функциональными областями,
ссор и споров по причине отсутствия ориентации на заказчика.
Функциональная организация в чистом виде не руководит перекрестными
функциональными проектами. В случае необходимости использования ресурсов
других отделов, следует получить разрешение функционального менеджера.
Диаграмма проектной организации может нуждаться в "обрезке" вдоль
функциональных "накопителей" большей организации. Данная форма имеет две производные
формы — организация диспетчера проекта и организация координатора проекта.
Диспетчер проекта
В функциональной организации диспетчер имеет недостаточные полномочия.
Как правило, весомость его позиции зависит от менеджера, перед которым тот
отчитывается, причем в служебной иерархии диспетчеру обычно отводится самое
последнее место. Данный вид проектной организации подходит для высоко
функциональных организаций и небольших проектов. Разработчики проекта остаются в своих
функциональных организациях. Чтобы работа диспетчера была эффективной, ему
необходимо уметь убеждать работников при отсутствии достаточно высокого уровня

450 Глава 13
полномочий. Это, в свою очередь, требует от менеджера проекта гораздо больше
личной власти. Роль же диспетчера характеризуется следующими параметрами:
■ выполнение роли помощника сотрудников (персонала, штата);
■ принятие некоторых решений;
■ ответственность за доставку материала и выполнение задач;
■ первоначальная ответственность за переговоры в рамках проекта;
■ обладание специальными человеческими качествами и уникальными
техническими способностями;
■ передача решений, принятых руководством, работающим над проектом
сотрудникам.
Организация работы диспетчера представлена на рис. 13.10.
1—►
кп 1—
1
Инжиниринг
-<™>~
1
Производство
.--/linV-
\аи/
Президент
Финансы
r^v_.
^Лгу__.
Маркетинг
—<^ЛгЛ
v!V
КП — Координатор/менеджер проекта
ЛП — Люди, работающие над различными аспектами проекта
Рис 13.10. Организация работы диспетчера проекта
Источник: Cable, Dwayne, и John R. Adams. Organizing for Project Management. С 11-20.
Координатор проекта
Данный подкласс функциональной формы имеет большое сходство с диспетчер
ской формой, однако в ее рамках координатор обычно отчитывается перед
руководителем высшей ступени функциональной иерархии. Координатор проекта
уполномочен распределять работу, но, тем не менее, кроме него, данным полномочием
обладают также функциональные менеджеры, руководящие деятельностью работников.
Организационная форма структуры координатора приводится на рис. 13.11.
Данная форма организации имеет некоторые недостатки:
■ руководство высшего звена обычно не склонно передавать власть и полномочия
менеджерам проекта;
■ руководство высшего звена обычно не готово справиться с проблемами
распределения полномочий;
■ менеджеры проектов, руководящие деятельностью линейного персонала,
отчитывающиеся перед руководителями отделов, не имеют полномочий или права
осуществления контроля за работой над частями проекта в других отделах.

Выбор организационной формы 451
Президент
&
Персонал
КП
Персонал
1 гу—I—^i т^;—
Инжиниринг S Производство чч Фийансу
у'' ± V "^
®
®
^v
Маркетинг
"*®
КП — Координатор/менеджер проекта
ЛП — Люди, работающие над различными аспектами проекта
Рис. 13.11. Структура организации координатора проекта
Источник: Cable, Dwayne, и John R. Adams. Organizing for Project
Management. С 11-20.
При внедрении любой из этих организационных форм менеджер проекта
обладает недостаточной позиционной властью. Организационная форма координатора
предоставляет менеджеру проекта немного больше полномочий, поскольку он
отчитывается перед вышестоящим руководством в более крупных организациях. В любой
из данных организаций менеджеру проекта трудно выполнять что-либо вовремя,
поскольку различные специалисты получают инструкции от (очень влиятельных)
функциональных менеджеров.
Матричные организации
Матричный менеджмент—относительно новое изобретение, которое возникло в
60-х годах прошлого века и начало широко использоваться десятью годами позже.
В матричных организациях существует баланс сил (власти) между функциональными
менеджерами и менеджерами проекта. Разработчику проекта в матричной
организации предоставлена множественная командная система ответственности и
распределения обязанностей. Несмотря на то, что данная форма может варьироваться в
различных организациях, в матричной организации можно обнаружить несколько цепей
команд. Они могут быть связаны функцией, географическим положением, проектом,
продуктом или клиентом (заказчиком). Типичная матричная структура организации
показана на рис. 13.12.
Матричные организации обычно представлены тремя типами: слабые,
сбалансированные и сильные (устойчивые). Эти виды организации отличаются друг от друга
относительным балансом власти между функциональным менеджером и менеджером
проекта. На сегодняшний день матричная организация является наиболее распространенной.
Преимущества матричных организаций многочисленны:
■ четко формулируются цели проекта;
■ возможность выполнения интеграции проекта вдоль функциональных линий;
■ эффективное использование ресурсов;
■ обеспечение информационного потока внутри организации;

452 Глава 13
Нисходящее функционально-
техническое направление
I
Президент
Проекты
h
Ц
м.
гЭ
п
Инжиниринг
Менеджмент
проекта
Менеджмент
-) проекта
Менеджмент
проекта
Производство
Операции
Маркетинг
Финансы
Люди, работающие
над проектом
Рис. 13.12. Матричная организация
Источник: Cable, Dwayne and John R. Adams. Organizing for Project Management. С 11-20.
■ способствует формированию функционально дисциплинированных команд;
■ поощрение высокой деловой дисциплины;
■ возможность совершенствования умений и навыков менеджеров проекта;
■ менее болезненное завершение работы над проектом;
■ конфликты минимальны и разрешаются гораздо легче.
Тем не менее, матричные организации не лишены недостатков:
■ разработчики проекта должны отчитываться, по крайней мере, перед двумя
руководителями;
■ сложности при управлении и контроле;
■ возможность конфликта между распределением ресурсов и приоритетами
проекта;
■ функциональный менеджмент и менеджмент проектов могут иметь различные
приоритеты;
■ потребность в дополнительных усилиях для установки действующих политик и
процедур;
■ рост административного аппарата, управляющего организацией;
■ дублирование трудозатрат.
Проективные организации
Проективные организации представляют собой новейшую форму организации,
возникшую на почве мировоззрений 80-х — 90-х годов прошлого века, хотя на самом
деле первым проектом, такого рода был Манхэттенский проект (Manhattan Project),
увенчавшийся разработкой первой атомной бомбы D0-е годы прошлого века). В
проективных организациях менеджер проекта (иногда называемый менеджером
программы) обладает всей полнотой власти, являясь по сути мини-президентом. Весь

Выбор организационной формы 453
штат сотрудников, работающий над проектом, отчитывается перед менеджером
проекта обычно по вертикальной схеме, поэтому компания становится похожей на
многоуровневую матрицу. Структура проективной организации приводится на рис. 13.13.
Примерами таких организаций могут служить крупные военные подрядчики,
разрабатывающие авиационную радиоэлектронику в составе авиационных проектов, а
также организации, принимающие участие в любом другом исключительно
конструкторском проекте. Подобная организационная форма используется в киноиндустрии,
при производстве каждого отдельного фильма.
Явные преимущества проекта, реализованного в данной форме организации,
заключается в единстве команд разработчиков и обеспечении более эффективного
сотрудничества.
Недостатком же является дублирование усилий и неэффективное использование
ресурсов. Члены работающей над проектом команды, оставшись без работы (по
завершению выполняемого проекта), предоставлены самим себе.
Последний фактор наиболее важен, поскольку, приближаясь к завершению
проекта, внимание разработчиков начинает рассеиваться, потому что каждый из них уже
начинает думать о следующем проекте. Это необходимо учитывать при планировании
работы на завершающей стадии разработки проекта в проективных организациях.
Каким же образом следует применять данные структуры по отношению к
ситуациям, возникающим в программных проектах? Ни для одного проекта не существует ни
одного ответа, существует лишь спектр возможностей. Термины (проективный,
функциональный, матричный и некоторые другие) имеют множество значений. Таблица 13.2,
разработанная Робертом Юкером (Robert Youker), помогает в выборе необходимого
вида организационной структуры.
Прмидмгт
— Проект Инжиниринг Производство Финансы Маркетинг Операции Персонал
•— Проект
Т
I
Инжиниринг Производство Финансы Маркетинг Операции Персонал
Инжиниринг
Производство
Финансы
Маркетинг
Операции
Персонал
Рис. 13.13. Проективная организация
Источник: Cable, Dwayne and John R. Adams. Organizing for Project Management. С 11-20.
При использовании данной схемы принимаются во внимание характеристики
проекта по разработке ПО и ряд наиболее подходящих признаков в каждом ряду.
После завершения составления характеристики посмотрите на столбец, содержащий
больше всего "округленных" описаний, благодаря которым организационная структура
будет лучше соответствовать данному проекту.

454 Глава 13
Некоторые современные организации используют что-то вроде "смеси" названных
форм в зависимости от определенных потребностей. Те из нас, кому приходилось
когда-либо работать на производстве или в государственных учреждениях, знакомы с
преимуществами и недостатками вышеназванных типов организаций. Во многих
организациях ведется постоянная борьба за власть между функциональными
менеджерами и менеджерами проектов. Данное положение представлено на рис.13.14.
Применение организационной структуры
Выбрав соответствующую условиям окружения организационную структуру,
можно столкнуться с некоторыми препятствиями по ее применению, особенно это
заметно при недостатке властных полномочий. В этом разделе излагаются некоторые
базовые сведения, облегчающие реализацию изменений в рамках "инкубатора" для
команды разработчиков проекта.
Предположим, что характеристики вашего проекта, полученные при анализе
табл. 13.1, свидетельствуют о том, что наибольший шанс на успех имеет проект,
разрабатываемый сильной матричной организацией. Однако функциональные
менеджеры вашей организации, давно занимающие данный пост, имеют больше властных
полномочий, чем менеджеры проекта. Возможно ли "купить" спонсоров идеей
изменения формы организации на такую, при которой менеджер программного проекта
будет иметь больше полномочий, чем функциональные менеджеры отделов? Такая
стратегия аналогична "политическому минному полю", но этот вопрос все же решаем
в силу некоторых важных соображений.
Таблица 13.2. Характеристики проектов, реализуемых различными
организационными структурами
Характеристики проекта Функциональная Матричная Проективная
Неопределенность
Технология
Сложность
Длительность
Размер
Важность
Заказчик
Взаимная зависимость
(внутри)
Взаимная зависимость
(между)
Критичность по времени
Дифференциация
Низкая
Стандартная
Низкая
Короткая
Малый
Низкая
Различный
Низкая
Высокая
Зависит
Низкая
Слабая
Умеренная
Стандартная
Низкая
Средняя
Малый
Средняя
Различный
Средняя
Средняя
Зависит
Низкая
Сильная
Высокая
Сложная
Средняя
Средняя
Средний
Средняя
Зили4
Средняя
Средняя
Зависит
Высокая
Высокая
Новая
Высокая
Длинная
Большой
Высокая
Один
Высокая
Низкая
Зависит
Средняя
Источник: Youker, Robert. "Organizational Alternatives for Project Management." Project
Management Quarterly, 8A):21, 1977.

Выбор организационной формы 455
Высокий
ё
X
СК
I
оэ
епень
С
Низкий
\
-> ^ Влияние проекта
^ <* ^ при принятии решений
"-«ч
«*^
^
"*,.
Влияние функциональности """"^
при принятии решений ** «•~
\
\-
Чистая Слабая матрица ^^ Сильная матрица Чистый
функциональность ^^Ъ. проект
Баланс силы
Рис. 13.14. Относительный баланс полномочий между менеджером
проекта и функциональным менеджером
Источник: Cable Dwayne, and John R. Adams. Organizing for Project
Management, c. 11-20.
Прежде всего следует признать, а затем убедить коллег в том, что специфические
условия разработки проекта требуют специальной организации. Следует обратить
внимание, что проект представляет собой временное усилие, направленное на
достижение некоторых целей, и не отождествляется с постоянным силовым вектором.
Иногда укоренившиеся функциональные менеджеры совершенно не верят в идею
руководства проектом (следует ли им ее принимать или нет), так как если бы они сами
руководствовались данными концепциями, они не смогли бы занять руководящие посты.
Важно понимать, что культура любой организации находится в равновесии и что
любое изменение в ней может иметь губительный результат. Изменять необходимо
поведение всей группы, чтобы признать и принять новый организационный подход.
Внося значительные изменения в свой мир, люди обычно проходят через
представленные ниже четыре этапа.
1. Осведомленность — люди знакомятся с условиями, представляющими инициативу
или новый процесс и осознают сопутствующие моменты.
2. Опрос/понимание — люди получают представление о том, что означает то или
иное изменение или инициатива, и оценивают ее последствия и важность
применительно к своей организации.
3. Принятие — люди приобретают знания, чтобы быть подготовленными, а также
чтобы понять, каким образом инициатива влияет на их работу и/или
функциональную организацию и какой вклад они могут сделать в успех или провал этой
инициативы.
4. Владение — люди несут личную ответственность за успех инициативы в своем
отделе и в своей организации.
Чтобы реализовать какие-либо изменения, необходимо пройти эти четыре этапа. По
достижении этапа 4 люди принимают изменения, стараясь заставить их работать на
себя. Этапы 1, 2 и 3 требуют коррекции индивидуального отношения на основе
имеющихся знаний. На рис. 13.15 показано, что личные усилия являются неплохим приемом
изменения знаний и личного отношения к этим изменениям. Эта убежденность
основывается на опыте специалиста в области информации в сочетании с личной харизмой.

456 Глава 13
Рис. 13.15. Путь к видоизмененному групповому поведению
Источник: Hersey, Paul, and Kenneth H. Blanchard. Management of Organizational Behavior,
6-е издание. Englewood Cliffs, NJ: Prentice Hall, 1993.
Позиционная власть может способствовать выработке группового поведения (как,
например, объявление влиятельным спонсором какого-либо изменения), однако, она не
влияет в значительной степени на изменяющиеся индивидуальные отношения.
Воздействие подхода к изменению, направленного от стороны личной власти к левому
нижнему краю уменьшается по мере приближения к области, расположенной вверху справа.
Таким же образом воздействие позиционной власти, направленной из верхнего правого
края, уменьшается по мере приближения к области, расположенной внизу слева.
Поэтому подход к проблеме культурных перемен должен быть двусторонним.
Признайтесь, что страх перед изменениями является отталкивающим фактором
для многих организаций. Люди боятся изменений, поскольку они подразумевают под
ними нечто неизвестное, что может нарушить устоявшийся порядок вещей. Курт
Левин (Kurt Lewin) предложил модель, называемую моделью анализа силового поля
(Force Field Analysis), вносящую культурные изменения в организации (см. рис. 13.16).
В модели указывается на то, что существует набор удерживающих сил и набор
движущих сил, находящихся в равновесии в любой культурной ситуации. Чтобы выполнить
изменение, необходимо тщательно изучить культуру для определения сил, чтобы
впоследствии предпринять соответствующие действия, которые ограничивают
удерживающие и приумножают движущие силы.
Часто это означает поощрение желаемого поведения и осуждение
нежелательного. Поощрения могут быть как материальными, так и социальными, но независимо от
этого они должны непосредственно влиять на достижение желаемого поведения.
Внедрение организационных изменений без изменения структуры поощрений
приводит к неудаче, ведь люди инстинктивно чувствуют благоприятные обстоятельства.
И наконец, необходимо признать разрушительную природу изменения. Мы верим,
что организационные изменения улучшат сложившуюся ситуацию. Критики зачастую
констатируют ухудшение производительности из-за беспорядочной реализации
изменений, утверждая, что именно по этой причине ухудшается положение вещей.
Они обычно правы, однако, немного терпения улучшает ситуацию. Как показано
на рис. 13.17, внедрение изменений обычно не является прямым путем к лучшей
производительности. Все изменения разрушительны, однако, через некоторое время они
обычно приводят к лучшей производительности.

Выбор организационной формы 457
Желат
ситу
I
Теку
ситу
ельная
ация
щая
Сдерживающие силы
1
t
1
t
Движущие силы
t
Устойчивость
системы
Рис. 13.16. Модель анализа силового поля
Желательная производительность
&
Фактическая производительность
Время Время
Рис. IS. 17. Эффекты от внедрения изменений подчиняются нелинейному закону
Резюме
В главе был рассмотрен вопрос выбора организационной формы, наиболее
подходящей для проекта, или наоборот. Были рассмотрены характеристики организации,
ее история и будущие возможности, кроме того, приводились некоторые
характеристики, придающие эффективность деятельности организации.
Были также рассмотрены преимущества и недостатки каждого типа организации,
а также объяснены особенности их функционирования. Данная информация может
помочь в вопросах управления политическими и социальными перспективами
будущих проектов.
Контрольные вопросы
Исследования подтверждают, что матричная структура во многих случаях
является сложной, поскольку предоставляет людям множество ролей, что и
приводит к появлению некоторых проблем. К сожалению, не все менеджеры
программ, менеджеры и разработчики проектов обладают необходимыми
качествами для работы в данной среде. Как-то Стакенбрук (Stuckenbruck) заявил:
"Дорога к успеху усеяна телами менеджеров проектов, которые сначала были
функциональными линейными менеджерами, став затем менеджерами
проектов". Как вы думаете, что является основной причиной подобного краха?
Мотивируйте свой ответ.
При каких обстоятельствах для функциональной организации будет выгодно
заниматься проектом разработки ПО? Приведите пример.

458 Глава 13
Практическое занятие
Во время деловой встречи в Гуанчжоу между м-ром Лу и корпоративным шефом мисс
Пайтель м-р Лу заметил, что, ваша компания в настоящее время является единственным
представителем на рынке. Конкурирующие организации объявили о всеобщей
реорганизации и переводе своего старого корпоративного штаба из Сиэтла в Даллас. Из-за этого
переезда вся работа в Азии будет осуществляться под руководством японских дочерних
компаний. Эти компании завершили работу над чисто программным проектом 18 месяцев
назад после приобретения ряда предприятий по производству полупроводников, ранее
принадлежащих убыточной телекоммуникационной компании.
Чтобы гарантировать успех данного предприятия, необходимы сильные позиции
в области разработки программ в Азии. Разумеется, CRM не могла ослабить прежние
внутренние ограничения по кадровым ресурсам, однако, будучи представителем
творческой компании, м-р Лу был уверен, что вы могли бы разрешить такую
незначительную проблему. Данный проект имеет важное значение для вашей компании.
Каким образом вы организуете свой проект, чтобы воспользоваться имеющейся
информацией? Как это скажется на вашем плане по осуществлению текущего проекта?
Ссылки
Bowditch James L. and Anthony F. Buono. A Primer on Organizational Behavior, 4-е издание. NY: Jossey-
Bass, 1996.
Hersey Paul and Kenneth H. Blanchard. Management of Organizational Behavior, 6-е издание. Englewood
Cliffs. NJ: Prentice Hall, 1993.
Mintzberg Henry. Structures in Fives: Designing Effective Organizations. NY: Prentice Hall, 1983.
Литература
Frame J. Davidson. Managing Projects in Organizations. NY:Jossey-Bass, 1987.
Frame J. Davidson. The New Project Management NY:Jossey-Bass, 1994.
Kcrzner Harold. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 6-е
издание. NY: John Wiley & Sons, Inc, 1998.
Lewis James P. Project Planning, Scheduling, and Control: A HandsOn Guide to Bringing Projects in on Time and
on Budget, дополнительное издание. NY: McGraw-Hill, 1995.
Martin Charles C. Project Management: How to Make It Work. Amacom, 1976.
Paulk Mark С. и др. The Capability Maturity Model: Guidelines for Improving the Software Process. NY: Addison-
VVesley, 1994.
Pressman, Roger S. Software Engineering: A Practitioner's Approach, 5-е издание. NY: McGraw-Hill, 2001.
Дополнительные сведения в Internet
www.pmi . org/pmi2001/papers/quality.htm. "Вопросы качества при менеджменте проектов:
организация непрерывного улучшения в деле менеджмента проектов".
www.pmi.org/publictn/pmboktoc.htm. PMF. Руководство по менеджменту проектов, основы
знаний (РМВОК® Guide).

Учет зависимостей
Как известно, большинство действий не выполняется вне проекта.
Идентификация соответствующих зависимостей является ключевым моментом, обеспечивающим
составление корректного графика. В главе рассматриваются некоторые соображения
по поводу зависимостей, носящих общий характер в программных проектах. При
этом учитываются модели жизненного цикла разработки ПО (глава 4), структура
пооперационного перечня работ (глава 8), идентификация действий (глава 9), а также
распределение ресурсов (глава 12).
Также будут рассматриваться зависимости и некоторые их типы, находящие
применение при составлении графика работ. Кроме того, будут исследованы
некоторые типичные зависимости, проявляющиеся в различных программных
проектах. Также будет уделено внимание технике "мозгового штурма" (группового метода
решения сложных проблем), используемого при идентификации действий и
зависимостей. Этот метод применяется в случае, если действия, относящиеся к модели
жизненного цикла, будет невозможно преобразовать в рабочий план проекта. Все
эти исследования помогут создать реальный и правдоподобный график
выполнения проекта (глава 15). В данной главе будут рассмотрены некоторые вводные
концепции, обеспечивающие представление действий в виде сетевой диаграммы.
В главе 15 будет завершено рассмотрение календарного планирования, а затем
создан фактический график.
Имейте в виду, что в данном случае предпринимается попытка построения
реального графика, приемлемого для спонсоров, руководства и заказчиков, которому
сможет доверять и придерживаться в дальнейшей деятельности команда разработчиков.
Это означает, что планирование данной деятельности (определение целей и
возможностей, создание структуры пооперационного перечня работ, установление задач и
действий) должно быть выполнено профессионалами.

460 Глава 14
Стадии жизненного цикла
разработки продукта
На какой из стадий основного жизненного цикла разработки ПО мы находимся?
Как показано на рис. 14.1, мы все еще находимся в начале жизненного цикла
разработки продукта. В частности, мы все еще планируем, как выполнить проект,
определенный в главах 7, 8 и 9. Расположение действий, выполняемых с целью учета
зависимостей, проиллюстрировано на рис. 14.2.
Связь главы 14 с 34 компетенциями
Для понимания вопроса о зависимости необходимо ознакомление с технологией
разработки продукта. Навыки менеджмента проектов требуются для оценки затрат и
трудозатрат (особенно при внедрении новых действий), построения структуры
пооперационного перечня работ, составления графика, и, конечно,
документирования планов. Для эффективного выполнения этих работ, а также для проведения
эффективных встреч, и создания рабочей команды необходимы навыки
менеджмента персонала (взаимодействие и коммуникационные возможности). Все
упомянутые зависимости перечислены ниже.
Методики разработки продукта
1. Подгонка процессов — модификация стандартных процессов с целью
удовлетворения требований проекта.
2. Понимание действий по разработке продукта — изучение цикла разработки ПО.
Навыки менеджмента проектов
3. Создание структуры пооперационного перечня работ— создание структуры
WBS для проекта.
4. Документирование планов — идентификация ключевых компонентов плана.
5. Оценка стоимости — оценка стоимости завершения проекта.
6. Оценка трудозатрат — оценка трудозатрат, необходимых для завершения проекта.
7. Создание графика — разработка графика и ключевых меток.
Навыки менеджмента персонала
8. Организация эффективных встреч — планирование и проведение
эффективных встреч.
9. Взаимодействие и общение — взаимодействие с разработчиками, высшим
руководством и другими командами.
10. Лидерство— обучение проектных команд с целью получения оптимальных
результатов.
11. Создание команды — формирование, руководство и поддержка эффективной
команды.

Учет зависимостей 461
Исследование
концепции
•Формули-''
рование

потребности
Исследование
системы
' Спецификация'
интерфейса
системы
Идентификация
циклов SLC
■ Циклы SLC
Выбор
модели
' Модель SLC
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
■SLC
Распределение
ресурсов
'Бюджет
Требования
■ Спецификация
требований
к ПО
Разработка
проекта
' Описание

разработки ПО
Внедрение
1 План

тации/верификации ПО
Выбор модели
жизненногоцикла
разработки ПО
Установка
■Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
■
Пользовательская
документация
Сопровождение
■ Документация
по
сопровождению
Вывод из
эксплуатации
• Архивный
отчет
Рис. 14.1. Жизненный цикл разработки ПО
Почему ?
Коэффициент
КОИ
Что?
Техническое
задание
(на проект)
Зависимости
Как?
ПланБРМР
Выполнение
Жизненк
цикл
ый
Сделано
Процесс РРА
Рис. 14.2. Схема процессов выполнения проектов

462 Глава 14
Учебные цели главы 14
После изучения материала главы читатель должен уметь выполнять следующее:
■ описывать несколько различных способов, при реализации которых одно
действие в сети может зависеть от других действий;
■ идентифицировать новые действия и зависимости средствами группы
технического персонала с номинальным количеством участников;
■ объяснить стабилизирующую схему использованных зависимостей;
■ описать, по крайней мере, три различных вида зависимостей;
■ определять зависимости в контексте проектов;
■ описывать принцип недостоверности;
■ объяснить различие между "жесткой" и "мягкой" зависимостью.
Определение зависимости
Зависимости являются одной из форм ограничения для любого проекта. Помните
тройные ограничения, показанные на рис. 1.4? Здесь подразумевается то, что область
действия, график и затраты являются тройным ограничением для любого проекта.
Причем во всех трех частях происходит оценивание достигаемого уровня качества.
Строгие сроки сдачи работы и специфика минимально функциональных уровней
должны быть обдуманными ограничениями вашего плана.
В качестве зависимостей могут выступать любые взаимосвязи между действиями
проекта, которые могут влиять на составление графика работ. На самом деле в
программный проект могут включаться множество подобных зависимостей. Если
работа была полностью линейной, то каждое действие будет зависеть от другого
действия (за исключением действия "начало работы"), а проект будет считаться полностью
завершенным (сумма всех продолжительностей действий, которая была оценена в
главах 10 и 11). Если зависимости отсутствуют, все может начинаться в одно и то же
время, проект может выполняться столько, сколько выполняется одно действие.
Однако на практике ни один из этих вариантов не реализуется. Хотя в то же время они
иллюстрируют экстремальные значения, между которыми находится реальный график.
После того как ориентированная на продукт структура пооперационного перечня
работ определена, часто определяются зависимости между отделами. Однако
структура пооперационного перечня работ не предназначена для отображения
зависимостей. Пооперационный перечень работ демонстрирует иерархическую взаимосвязь, а
не построенные в перекрестном порядке зависимости. Наилучшим образом
представление зависимостей реализуется с помощью сетевой диаграммы. В главе 15 будет
показано, каким образом построить диаграмму, а теперь достаточно просто
предположить, что существует зависимость между двумя действиями, представленными
прямыми линиями со стрелкой, указывающей по направлению к зависимому действию.
Это означает, что второе (зависимое) действие зависит от первого действия. Две
простые зависимости действий, показанные на рис. 14.3, представляют собой панели
действий диаграммы Ганта.
Вы и ваша команда должны найти как можно больше зависимостей,
связывающих действия из структуры WBS текущего проекта. Если результаты поиска будут
неудачными, действия будут выступать в виде взаимосвязи, заданной по умолчанию.

Учет зависимостей 463
При использовании большинства инструментов составления графика проекта
предполагается отсутствие взаимосвязи между действиями, при их первом вводе в рабочее
окно инструмента. Однако, вскоре после того, как действия будут введены,
допускается наличие полностью линейной взаимосвязи (пример изображен на рис. 14.3). И как
всегда, "реальность находится где-то посередине".
Типы зависимостей, возникающих
при разработке ПО
Как упоминалось ранее, зависимости могут быть классифицированы несколькими
способами. Один способ предполагает разделение на внутренние и внешние
зависимости. При использовании другого способа зависимости рассматриваются как
ограниченные действиями или ресурсами. К тому же во втором случае внимание обращено на
сильные стороны зависимости. Зависимости могут быть не столь чистыми, как можно
ожидать, они могут порождать в графике некоторые особенности. Тем не менее, все
они должны быть определены и изучены с целью создания реального графика проекта.
Внешние и внутренние зависимости
Внешние зависимости программного проекта могут включать любые подключения
по отношению к программным продуктам других проектов. Они могут представлять
собой проекты высшего уровня (глава 8), включающие зависимости, установленные
по отношению к рабочим продуктам либо поставляемым продуктам проекта.
Примером может служить структура пооперационного перечня работ высшего уровня,
описывающая финальное решение полностью готовой программной системы, которая
включает аппаратное обеспечение (настраиваемое либо монтируемое), ПО (за
разработку которого вы несете ответственность), а также действия по установке и
тестированию (вы можете нести либо не нести ответственность за выполнение каждого из
этих действий).
Другим источником внешних
зависимостей могут выступать организаторы
совместного дела. В роли организатора
совместного дела может выступать любой человек, „ « - -
' Действие Б зависит от действия А
заинтересованный в проекте и
оказывающий на его ход выполнения положительное Рис. 14.3. Простая взаимосвязь зависимостей
либо отрицательное влияние.
Организаторы совместного дела выбираются на ранней стадии планирования проекта, а план,
задающий взаимоотношения с ними, определяется в ходе выполнения проекта.
Благодаря этому минимизируется вероятность того, что "злоумышленник" заведет
проект "в тупик", начиная с того момента, когда управление ожиданиями и мониторинг
требуемых изменений будут представлять значительную часть работы по управлению
программным проектом.
Как правило, в число организаторов совместного дела включены следующие
субъекты: команда разработчиков проекта, спонсор, функциональный менеджер(ы),
заказчики), а также пользователь(и). Также иногда в этом качестве рассматриваются
вторичный заказчик первичного заказчика либо вторичный пользователь первичного
пользователя. Управление организаторами совместного дела может происходить на
ранних стадиях либо на всем протяжении этого же проекта. При этом осуществляется
ДействиеА
Действие Б

464 Глава 14
взаимодействие с организаторами совместного дела, а также учитываются их запросы
относительно обычного и календарного планирования не только на этапе анализа
требований, но и на протяжении всего проекта. Зачастую рекомендуется передавать
руководящие полномочия участникам команды разработчиков проекта с целью
осуществления руководства организаторами совместного дела на однозначной основе.
С одной стороны это действие не должно отнимать много времени, но, с другой
стороны, могут возникать неприятные "сюрпризы" в случае, если члены команды в ходе
выполнения проекта предпримут какие-либо неожиданные действия (например,
отсылка случайных электронных сообщений, непродолжительные повторные визиты
либо телефонные звонки, занимающие линию). В этом случае мы имеем дело с
менеджментом взаимосвязей, который является столь же важным для успеха проекта,
как и техническая часть. Это происходит из-за того, что при осуществлении бизнес-
проектов немаловажную роль играет не только обработка транзакций, а также и
поддержка взаимосвязей. Цель менеджмента относительно организаторов совместного
дела заключается в том, чтобы заставить последних реализовывать цели и планы в
рамках данного проекта. Индивидуальный подход к организаторам совместного дела
может быть подобран с учетом одного из следующих критериев:
■ существующие социальные связи с организаторами совместного дела — ранее
приобретенные знакомства;
■ общее поле деятельности — наличие общих талантов гуру в области разработки баз
данных либо способностей эксперта в области разработки графических
интерфейсов пользователей, которые были обнаружены в ходе посещения
тематических конференций;
■ ожидание совместной работы в дальнейшем — возможно, в качестве тестера,
специалиста по установке или пользователя бета-версий разрабатываемого продукта;
■ общее местонахождение или язык— использование одного и того же рабочего
места, проживание в одном кампусе, городе, стране.
Примерами зависимостей для организаторов совместного дела, которые являются
весьма важными при выполнении различных программных проектов, являются
бизнес-события, имеющие большое значение для первичных либо вторичных
заказчиков. Если вы разрабатываете программную систему для клиентов, которые
занимаются перепродажей на специализированном клиентском рынке, маркетинговая группа
заказчика может предпринимать такие рекламные акции, как демонстрация
возможностей ранних версий ПО (чаще всего демонстрируются бета-версии). Эту важную
зависимость следует учитывать в графике проекта, поскольку она предполагает
необходимость подготовки к определенному (жестко заданному сроку) некоторой рабочей
версии. Из-за этого команда разработчиков проекта, пытающаяся разработать
реальный продукт с целью его внедрения в опытную эксплуатацию в дальнейшем, будет
испытывать некоторые неудобства. Все это будет трактоваться как жесткие
ограничения проекта (сторона график ограниченного с трех сторон треугольника). Опыт
подсказывает, подобный тип событий может быть недооценен на этапах
планирования жизненного цикла проекта, поскольку они могут не приниматься во
внимание непосредственным пользователем, от которого вы получаете большую часть
необходимой информации.
Другим основным источником внешних зависимостей являются поставщики. Их
также можно отнести к организаторам совместного дела, но они обычно принимают

Учет зависимостей 465
большее участие в выполнении проекта, чем другие внешние организаторы совместного
дела. Чаще всего они вступают в специфические ограниченные взаимосвязи, диктующие
жесткие ограничения проекта. Примером зависимости поставщика может быть интер
фейс для системы, разработанной сторонними производителями, с которой будет
взаимодействовать ваше ПО. Вы можете зависеть от другого графика проекта для другого
отдела, компании или местоположения, по отношению к которому с вашей стороны либо
отсутствует контроль, либо его величина является весьма небольшой. Из-за этого
возникнут ограничения для текущего проекта, что, в свою очередь, приведет к необходимости
выполнения планирования на случай возникновения чрезвычайных обстоятельств.
Внутренние зависимости довольно сильно связаны с программным проектом,
поскольку существует высокая степень связности между модулями, компонентами и
процессами. Большинство из этих объектов представляют собой прямой результат
реализации взаимосвязей компонентов в структуре WBS, ориентированной на
продукты. Например, завершенная версия системы зависит от кода компонентов,
который был скомпилирован и подготовлен для дальнейшего использования. В состав
программного проекта включено также множество интегральных зависимостей
процесса. В их число могут входить менеджмент конфигурации, управление проектом, а
также обеспечение качества ПО. Эти зависимости, как правило, специфичны для
проекта, хотя и можно привести некоторые общие примеры зависимостей:
■ утверждения плана вывода проекта из системы;
■ утверждения и требования вывода из системы;
■ внутреннее и внешнее управление циклами обзора;
■ идентификация элемента конфигурации;
■ аудит качества ПО.
Рекомендуется, чтобы эти зависимости представляли собой своего рода стадии в плане
программного проекта. Зачастую существует более одного действия, которое должно бьпъ
завершено с целью его распознания. Благодаря отображению внешних зависимостей в
качестве явных стадий можно показать, что ваш проект зависит от входных данных,
которые невозможно проконтролировать. В связи с этим необходима частая визуализация и
усиленный контроль, поскольку "кумулятивный эффект" ошибок может сказываться на
всех остальных планах проекта. Описание стадий проекта можно найти в главе 8.
Зависимости, связанные с ресурсами и действиями
Разбиение зависимостей на типы может происходить по принципу их разбиения
на управляемые ресурсами и управляемые действиями. Большинство типов графиков
могут быть созданы с помощью метода критического контура (СРМ, описывается в
главе 15), а также представлено в виде диаграмм Ганта. Диаграммы Ганта
предназначены лишь для отображения зависимостей между действиями проекта, и управляются
с помощью действий. Они не могут применяться для отображения базовых
ограничений ресурсов. Именно по этой причине вызов алгоритма выравнивания ресурсов для
обработки ограничений, для осуществления которого используется такой инструмент
составления графиков управления проектами, как Microsoft Project, создает
видимость "неразберихи" со всеми датами осуществления действий. Конечным итогом
может быть дальнейшее откладывание даты завершения проекта.
Единожды отобразив на график наличные ресурсы, можно получить график,
ограниченный ресурсами. При использовании графика подобного типа некоторые

466 Глава 14
действия не могут выполняться до тех пор, пока не будут завершены предыдущие
действия. Это связано с тем, что для выполнения новых действий потребуется
освобождение ресурсов, используемых прежними действиями. Например, даже, несмотря на
то, что интеграционные и регрессионные тесты могут планироваться таким
образом, что будут выполняться непосредственно после завершения кодирования и
тестирования модуля, тестеры не смогут получить к ним доступ. В результате действия
в рамках тестирования будут "заморожены" до тех пор, пока не освободятся
ресурсы, необходимые для выполнения тестирования. Подобный тип зависимости
относительно доступа к ресурсам становится серьезным ограничивающим фактором
при работе с некоторыми видами аппаратных средств (специальная тестовая
оболочка), либо при разработке новых устройств. Зависимости, связанные с
ограничениями на ресурсы, могут также иметь место при наличии календарных "окон"
доступности, таких как запланированное время тестирования функционирующей сети
либо графики отпусков основных членов проектной команды. Другая управляемая
ресурсами зависимость может быть ориентированной на затраты (например,
необходимость в ожидании более благоприятного времени, обеспечивающего
сокращение издержек на осуществление доступа). Примером подобного вида ограничения
ресурса, управляемого затратами, может служить возможность проведения
телеконференций, избегая "час пик". В главе 15 говорится о том, каким образом следует
настраивать график, управляемый действиями, с целью получения представления
относительно доступности ресурсов.
Л теперь будут проанализированы некоторые технические взаимосвязи между
действиями, позволяющие осознать, каким образом могут быть связаны различные
действия по разработке ПО, рассмотренные в главе 9.
Возможные взаимосвязи между зависимостями
Одним из наиболее распространенных методов классификации зависимости
является моделирование отношений "старт-финиш". Также может применяться
классификация по категории и по источникам зависимостей. Сначала рассмотрим
взаимосвязи типа "финиш-старт".
Финиш-старт (ФС)
При реализации взаимосвязи "финиш-старт" (ФС) действие начинает
выполняться только после того, как будет завершено предыдущее действие. Этот тип
зависимости действий является наиболее распространенным. В данном случае также
реализуется взаимосвязь, заданная по умолчанию, для
связанных действий в большинстве
инструментов календарного планирования
менеджмента проектов. Взаимосвязь "финиш-старт"
проиллюстрирована на рис. 14.4.
Действие Б не может выполняться до тех пор, г _ г г г ...
поканебудетзавесшенодействиеА В качестве примера зависимости финиш-
старт" может рассматриваться действие "най-
Рис. 14.4. Взаимосвязь зависимостей "фи- ти причину", которое должно быть завершено
нишгстарт до того, как начнет выполняться действие
"устранить проблему", поскольку невозможно
устранить проблему до того, как вы ее не изучите. На других иллюстрациях показано
что "построение тестов" должно быть завершено до начала "выполнения тестов", а
"установка ПО" должна быть завершена до начала "выполнения программы".
Действие А
ФС
Действие Б

Учет зависимостей 467
Старт-старт (СС)
Зависимость "старт-старт" определяет, что одно действие может выполняться
только при условии выполнения другого действия. При разработке программных
проектов общим типом взаимосвязи подобного типа является одновременный запуск
нескольких действий, основываясь на событии триггера. В качестве примера может
служить запуск на выполнение действий "выполнения планирования проекта",
"выполнения оценивания риска", а также "выполнения менеджмента конфигурации".
Взаимосвязь действий "старт-старт" показана на рис. 14.5.
Финиш-финиш (ФФ)
Взаимосвязь типа "финиш-финиш" (ФФ) подобна взаимосвязи типа "старт-старт" в
том, что одно действие связано с другим, однако в этом случае действия должны
завершаться одновременно. Это означает, что одно действие не может быть завершено
до тех пор, пока выполняется второе действие. Примером такой взаимосвязи может
служить то, что действие "управление проектом" не может быть завершено до тех
пор, пока выполняется действие "получить одобрение завершения проекта". Эта
взаимосвязь отображена на рис. 14.6.
СС
Действие А
Действие А
Действие Б
Действие Б
ФФ
Действие Б запускается при запуске действия А
Рис. 14.5. Взаимосвязь зависимостей
"старт-старт "
Действие Б не может быть завершено до тех пор,
пока не будет завершено действие А
Рис. 14.6. Взаимосвязь зависимостей
"финиш-финиш "
Старт-финиш (СФ)
Наиболее редкой является взаимосвязь "старт-финиш" (СФ). При такого рода
взаимосвязи определяется, что первое действие не может быть завершено до того,
как начнет выполняться следующее действие. Эта взаимосвязь напоминает
общеизвестную взаимозависимость типа "финиш-старт", но в данном случае зависимости
обращаются. Часто используется связь рабочего действия со стадией (действие события
с нулевой продолжительностью часто связана с несколькими различными действиями
завершения), поэтому действие не может быть завершено до момента достижения
стадии (все остальные действия будут завершены). В качестве примера можно
рассматривать действие "поддержка заказчика", которое не может быть завершено до
того, как будет пройдена стадия "завершение контракта". Взаимосвязь "старт-финиш"
продемонстрирована на рис. 14.7.
Специальные типы взаимосвязей
Воздействие на непосредственные начальные и завершающие взаимосвязи
оказывают запаздывающие и опережающие, твердые и мягкие взаимосвязи, а также
принципы неопределенности.

468 Глава 14
СФ
Действие Б
Действие А
Действие Б не может быть завершено до тех пор, пока не запущено действие А
Рис. 14.7. Взаимосвязь зависимостей "старт-финиш"
Запаздывающие и опережающие взаимосвязи
Полезными модификаторами зависимостей являются запаздывающие и
опережающие типы взаимосвязей, которые могут иметь отношение к любым другим
описанным выше типам зависимостей. Как правило, запуск или завершение
выполнения того или иного типа зависимости становится причиной ухудшения
(отставания) или улучшения (опережения) в рамках определенного временного
периода. На отставание обычно указывает число положительное, а на опережение —
отрицательное, добавленное во время запуска либо завершения связанных
действий. Часто используемой является взаимосвязь для операций с фиксированным
периодом соединения с некоторыми другими действиями. В частности, можно всегда
выполнить действие "покрыть вторым слоем краски" на два дня позже после
действия "покрыть первым слоем краски" с целью высыхания первого слоя краски.
Пример на рис. 14.8 демонстрирует действие В, которое выполняется через 10 дней
после завершения действия А несмотря на то, что действие Б может начать
выполняться немедленно.
Жесткие и мягкие зависимости
Еще один метод изучения зависимостей заключается в сравнении силы
соединения. Некоторые соединения являются физическими, поэтому в этом случае
физические законы будут препятствовать тому, чтобы действие Б начинало выполняться до
того, как завершилось действие А. Например, действие "разрешить рисование по
сухому" не может выполняться до того, как начнет выполняться действие "начать
рисование". А сила гравитации препятствует выполнению операции "возведение крыши"
до завершения действия "возведение стен".
Действие А
ФС
ФС+10-днеЕ
+10
наяз
адержка
Действие Б взаимно связано с действием А согласно схеме "финиш-старт",
однако действие В не может быть запущено до того,
как пройдет 10 дней после завершения действия А A0-дневная задержка)
Рис. 14.8. Запаздывающая взаимосвязь

Учет зависимостей 469
Аналогичным образом, невозможно достичь стадии "код скомпилирован" до
завершения действия "написание кода", и невозможно запустить на выполнение действие "обзор
спецификации разработки проекта" до тех пор, пока, по крайней мере, не начнет
выполняться действие "спецификация эскизного проекта". Говорят, что эти соединения должны
быть "жестко логическими" либо представлять собой "обязательные зависимости". Они не
могут быть разорваны, поэтому приведенные операции должны быть последовательны
увеличены на величину, эквивалентную продолжительности всего проекта.
Однако некоторые зависимости являются дискреционными и могут допускать
частичное перекрытие действий. В качестве примера можно рассматривать случай, когда
указания "нарисовать общую комнату" и "спальня для рисования" могут встречаться
одновременно. Часто дискреционный характер зависимости не очевиден. В
частности, людям, профессия которых не связана со строительством, понятия "постройка
фундамента", "постройка стен" и "сооружение камина" представляют собой образец
последовательных действий с жесткой логикой. Тем не менее, для большинства
строителей очевидно, что сооружение стен может начинаться в то же время, что и
сооружение фундамента, непосредственно после кладки плит перекрытия. Затем,
когда заготовлено достаточное количество бетонных плит перекрытия, они могут
устанавливать заранее сооруженные стены на плиты и закреплять углы вместе.
Программные проекты полны дискреционных зависимостей. Например, "спецификация
эскизного проекта" не нуждается в ожидании запуска до завершения "заполнения
документа, содержащего описания требований". Все может начаться одновременно,
либо спустя некоторое время, допуская, таким образом, некоторое сжатие графика.
Эти так называемые зависимости "мягкой логики" являются ключевыми для
менеджера проекта при построении агрессивного, но вместе с тем реалистичного графика.
Сводка по жестким и мягким зависимостям приводится в примечании 14.1.
Примечание 14.1. Зависимости, определяемые силой соединения
Тип
Дополнительные признаки Описание
Жесткая
логика
Мягкая
логика
Обязательные зависимости
Логические зависимости
Дискреционные зависимости
Представленная логика
Предпочитаемая логика
Сильное соединение, при реализации которого
действие не может быть запущено на
выполнение до тех пор, пока не будет завершено
предыдущее действие
Слабое соединение между действиями, которое
определяется проектной командной в соотиет-
ствии с наилучшей практикой либо нормами
Принцип неопределенности
До сих пор зависимости рассматривались таким образом, как будто бы все, что
касается взаимосвязей, заранее известно. К сожалению, всякому планированию всегда
предшествует предварительная работа, ибо никому не дано искусство точного
предсказания будущего. График проекта основан на предварительной информации о том,
как все должно происходить, если учтены все взаимосвязи и предположения. Этот
метод не намного лучше, чем любой другой прогноз, но поскольку персонал,
реализующий проект на практике, принимает участие в составлении графика, достигается
оптимальная точность прогноза. Иногда в ходе планирования выдвигаются неточные

470 Глава 14
предположения относительно имеющихся зависимостей. В этом случае возможно
более точное предположение при наличии доступных фактов, что, в свою очередь,
позволит составить новый план.
Можно также явно допускать некую неопределенность в будущем с помощью
буферов возможностей либо резервирования менеджмента. Как правило, на диаграмме
Ганга, соответствующей графику в виде отдельной панели активности (которая
предшествует стадии). Но это действие не будет отображено в структуре WBS до тех
по]}, пока оно не будет представлено на рассмотрение. Конечно, что бы ни планиро-
B.Liocb, весь проект — это всего лишь одно продолжительное действие (большое
предположение).
Дополнительные методы обработки неопределенностей при разработке любого
программного проекта будут рассмотрены в главах 15 (методики составления
графиков) и 18 (определение рисков, связанных с выполняемым проектом).
"Мозговой штурм" при поиске зависимостей
и действий
В главе 9 уже рассматривались методы идентификации действий и задач, которые
могут понадобиться при разработке программных проектов. Особо примечательным
является то, что 65 действий из 17 процессов программного инжиниринга,
описанных в документе IEEE 1074, могут быть распределены в соответствии со специфичной
моделью жизненного цикла, используемой при формировании прикладной структуры
пооперационного перечня работ. Возможность применения действий, описанных в
документе 1074, обеспечивается благодаря тому, что разрабатываемый проект доста-
ючпо хорошо описывается существующей моделью жизненного цикла. Благодаря
:>|и.му обеспечивается возможность повторного применения большинства действий.
Но что делать в том случае, когда отсутствует шаблон для разрабатываемого проекта?
Ь.с ш ранее не была определена модель жизненного цикла?
В этом случае придется разработать действия самостоятельно методом "мозгового
имл'рма", предпринимаемого усилиями команды разработчиков проекта. Затем по-
i ребуетея сгруппировать действия, распределить их в виде структуры WBS и найти
нес зависимости, воспользовавшись сведениями, представленными ранее в этой
главе. Разработка новых действий облегчается с помощью номинальной групповой
техники, описанной в следующем разделе. Эта техника проста в применении и
чрезвычайно полезна при сборе сбалансированных входных данных и идей, генерируемых
командой разработчиков проекта. Затем можно вести команду на пути поиска
зависимостей среди действий, описанных в разделе "Процесс, применяемый при
определении новых зависимостей".
Номинальная групповая техника
Лндрэ Дельбек (Andre Delbecq) и Эндрю Ван де-Вен (Andrew Van de Ven),
основываясь на исследованиях, проводимых Висконсинским университетом, а также Депар-
имептом здравоохранения, образования и благотворительной деятельности (HEW,
СЛИЛ) в 1968 году разработали так называемую "номинальную групповую технику".
.-.Нот технический прием обеспечивает наилучший путь достижения
сбалансированного участия в большинстве попыток, предпринимаемых для сбора данных. Это ме-
юд весьма целесообразен для следующих случаев:

Учет зависимостей 471
■ решения проблемы — поиск основных причин возникновения проблем либо
методов, используемых при их разрешении;
■ принятия творческих решений — для реализации оценок и жестких альтернатив;
■ ситуации, приводящих к генерации идей— появляется необходимость наличия
полностью обновленных входных данных.
Основание для использования данной техники состоит в том, что в данном случае
каждый член команды разработчиков может ранжировать элементы, не поддаваясь
влиянию других людей. Это особенно важно для тех команд, где несколько наиболее
влиятельных личностей задают тон, а остальное большинство молча придерживается
предложенной тактики. Этот процесс демонстрируется в примечании 14.2.
Примечание 14.2. Процесс, использующий номинальную групповую технику
1. Каждый участник команды в частном порядке разрабатывает перечень входных
к данных (действия прс^кта^редназначенные*длй:достижения Целей с помощью
; подходящих методов действий, рассмотренных'* главе 9; такие как глагол или
: имя существительное, маркеры языка, и т.д.). — ' -"•'
2; Круговая система, когда каждый участник проекта! поддерживает одну новую
позицию, включаемую в общий список (каждый становится В очередь). При этом не
допускаются дискуссии, и перечень позиций обозначается буквами, но Не цифрами.
3. Группа обсуждает позиции (если это необходимо) после заполнения списка с
целью исключения дублирования и похожие по значению слов и т.д.
4. Каждый сотрудник в частном порядке ранжирует количество наиболее важных
позиций, равное п. . „
■ ,"■ .- • ■ 1 < • ■ -v. ■ ;*' *ti %; >* -4
5. Используя результаты анонимного голосования,, руководитель учитьщает
порядковый номер, выставленный командой*дл^ каждой позиции.
6. Группа обсуждает результаты ранжир^ва^ив,|1азди|щые отклонения и т.д.
7. ПЬвт орите шаги 4, б и 6<до того, каюбудетЯОстий!уто''с0г#1асие, Обычно больше
двух;или трех проходов не бывает. ."^rfC-'ri-.4, -''* * ' "''
Целью этих упражнений является генерирование перечня действий, которые, по
мнению членов команды, удовлетворяют целям проекта (определяются в проектном
договоре). Это замена применяется в случае отсутствия шаблона WBS, соответствующего
жизненному циклу. К числу полезных привычек относится запись информации о
каждом действии на самоклеющихся бумажных листках (например, на листках Post-it от
фирмы ЗМ, которые в общем случае называются "стакерами"), а затем наклеивать их на
большую белую доску либо стену для всеобщего обозрения. Как правило, для получения
перечня действий, используемых при заполнении структуры WBS, потребуется лишь
несколько раундов. После этого начинает выполняться процесс построения структуры
WBS, основанный на использовании указанных на стикерах действий.
Процесс, применяемый при определении
новых зависимостей
При составлении перечня действий и размещении их на стикерах посредством
номинальной групповой техники проявляется затруднение, заключающееся в
наличии различного уровня детализации. В итоге в случае определения длительности

472 Глава 14
выполнения действий получаются результаты, ранжирующиеся от часа-двух (как в
случае с выполнением компиляции) до недель либо месяцев (как в случае с
"дизайнерской производственной системой"). Решение этой проблемы заключается в
группировании позиций в иерархическом порядке (как в случае со структурой WBS),
используя метод диаграмм связности. При реализации этого метода на практике все
стикеры, содержащие описание действий с общими позициями, помещаются на
одной стороне белой доски. В случае стикеров с описаниями другого рода действий
устанавливается четкая граница. В целях достижения общности можно попытаться
воспользоваться несколькими различными идеями. Иногда благодаря
переписыванию нескольких действий можно добиться лучшего их совпадения. В этом случае
используется общее правило "большого пальца", когда детали одного уровня
помещаются ниже уровня в случае наличия ежедневного менеджмента.
На следующем этапе выполняется ранжирование стикеров в виде структуры
пооперационного перечня работ, ориентированного на продукты. При этом
используются руководящие указания, описанные в главе 8. При ранжировании используется
логическое группирование (от действий высшего уровня до действий нижнего
уровня). Как только будет получено хорошее представление, которое одобряется членами
команды, начертите его на бумаге (не трогая при этом стикеры). При этом будет
получена полезная структура WBS, служащая источником новых зависимостей.
Затем можно определить все зависимости между различными действиями путем
внимательного рассмотрения каждого действия и повторного ранжирования
стикеров на белой доске. При этом применяются сведения, изложенные в данной главе.
Лучше всего начинать работу с целью создания поставляемого продукта, а
завершать-— путем создания готового проекта. При этом полезно задавать себе вопрос:
"Какова последняя вещь, выполняемая проектом?" Пусть белая доска будет
финальной позицией, закрывающей проект. Затем работа последовательно выполняется в
направлении от последней позиции. При этом возникает логический вопрос: "Что
надо сделать для завершения...?". Благодаря этому предотвращается включение
действий, которые напрямую не связаны с продуцированием поставляемых продуктов,
сводя тем самым затраты к минимуму.
Используя стираемые маркеры (необходимость их применения диктуется тем, что
приходится многократно выполнять изменения), нарисуйте линии, соединяющие
стикеры (как рассматривалось ранее). При работе с проектом, подобным
рассматриваемому, устанавливаются зависимости, характерные для данной задачи. Убедитесь в
том. что не были установлены какие-либо "зависшие цепи", как показано на рис. 14.9.
Эти цепи свидетельствуют о наличии действий, которые ничего не продуцируют.
Результирующая карта зависимостей практически всегда представляет собой сетевую
диаграмму, как показано в нижней части рис. 15.10. Создание сетевых диаграмм более
подробно рассматривается в главе 15, посвященной составлению графика.
Подытоживая сказанное, опишем несколько шагов, используемых при реализации
процесса на практике.
1. Методика "мозгового штурма" при составлении списка действий—
используйте номинальную групповую технику для построения перечня возможных
действий проекта, применяя при этом стикеры.
2. Найдите коллекции связности— логически "сгруппируйте" действия путем
идентификации операции, которые должны или будут выполнены вместе.
Уровень деталирования и количество позиций высшего уровня будут определяться

Учет зависимостей 473
особенностями проекта. На этом этапе не учитывайте продолжительность во
времени и ресурсы.
Идентифицируйте наивысшие уровни структуры WBS— подведите итоги по
группированию, выполняемому с помощью вывода рабочих продуктов с целью
получения высших уровней структуры WBS.
Создайте представление структуры WBS— записывайте на бумаге сведения о
структуре WBS. Эти сведения станут частью плана проекта.
Найдите зависимости — отработайте с конца до начала, ранжируйте в
логическом порядке стикеры на белой доске. Используя маркеры, изобразите
взаимосвязи между действиями (проявите аккуратность и рассмотрите все
взаимозависимости).
ФС
ФС
ФС
Действие -
'
ФС
Действие
Действие
ФС
ФС
Действие
Действие
ФС
Нет "зависших цепей" ?
Действие
ФС
Действие
ФС
Действие
Рис. 14.9. Наблюдайте за "зависшими цепями"
Резюме
В главе были описаны зависимости с учетом различных аспектов. Было установлено,
что зависимости бывают внешними и внутренними, ограниченные действиями либо
ресурсами, связанные в большей или меньшей степени. Были проверены способы
взаимной связи между различными действиями (например, связи ФС, СС, ФФ и СФ).
Эти зависимости становятся весьма важными при конструировании сети на
основе структуры WBS, ориентированной на продукты. Техника календарного
планирования, описанная в главе 15, интенсивно использует взаимосвязи между зависимостями,
созданные при построении плана проекта.
Контрольные вопросы
1. С какими из наиболее сложных задач сталкиваются менеджеры программных
проектов при рассмотрении взаимосвязей зависимостей и почему последние
оказывают столь сильный эффект на графики проектов?
2. Опишите ситуацию, при возникновении которой требуется использование
запаздывания времени в жизненном цикле разработки ПО.

474 Глава 14
Практическое занятие
Вы были выбраны для проведения недельной "школы молодого бойца",
направленной на адаптацию новых менеджеров компании. Хотя вы исполняли функции
менеджера проекта годами, до сих пор вам не приходилось принимать участие в
учебных курсах по менеджменту в составе компании. По вашему мнению, проект ARRS не
(\ -акционирует вот уже на протяжении 5 дней в учебном центре Аризоны. Но дело не
толь о в том, что вас не будет в течение следующей недели, а в том, что существует
предварительная работа, которая должна быть завершена и представлена в
воскресенье вечером в начале совещания. Ваше задание заключается в том, чтобы
проанализировать все внешние влияния, которые воздействуют на наиболее уязвимый проект.
В данном случае идет речь о проекте ARRS. Вы должны создать диаграмму
зависимостей всех факторов, влияющих на проект.
Литература
Berg Cindy и Kim Colenso. "Work Breakdown Structure Practice Standard Project — WBS vs. Activi-
l\cs." PM Network, 2000.
Kcrznei' Harold. Project Management- A Systems Approach to Planning, Scheduling, and Controlling, 6-е
издание. NY: John Wiley & Sons, Inc., 1998.
Lewis James P. Project Planning, Scheduling, and Control: A Hands-On Guide to Bringing Projects in on Time and
on Budget, повторное издание. New York, NY: McGraw-Hill, 1995.
l'aulk Mark О и другие. The Capability Maturity Model: Guidelines for Improving the Software Process. NY: Ad-
tlisoi, Wesley, 1994.
Piessman Roger S. Software Engineering: A Practitioner's Approach, 5-е издание. NY: McGraw-Hill, 2001.
Дополнительные сведения в Internet
www.ee.ed.ac.uhf'gerard/Management/ariS.html Gerard M. Blair, "Planning a Project."
wwxv.pmi.org/puhlictn/pmboktoc.htm. Основы знаний в области управления проектами Института PMI
(РМВОК® Guide), глава 6.

Формирование
рабочего графика
Рабочий график формируется на основании структуры WBS и содержит
информацию о продолжительности работы, ее основных стадиях, сведения о конечных
результатах, а также информацию, поступившую от ответственных за выполнение
соответствующих задач. Обычно рабочий график представляют в виде диафаммы Ганта
(Gantt), но часто используется и табличное представление, В любом случае реальный
график составляется на основании оценки общего объема работ и структуры WBS.
Процесс составления рабочего графика требует знания определенных методик, а с
художественной точки зрения подобен процессу разработки структуры WBS. Но
начинается построение всегда с определения области действия проекта (см. главы 7 и 14).
В данной главе будет рассмотрен процесс составления рабочего фафика для
реального профаммного проекта.
Стадии жизненного цикла
разработки продукта
Как показано на рис. 15.1, мы все еще находимся в начале жизненного цикла
разработки ПО, т.е. на стадии планирования проекта. В частности, мы все еще
планируем, как будем разрабатывать проект (главы 7, 8, 9, 10, 11, 12 и 13). Мы уже почти
подошли к окончанию этапа как, и теперь, кроме плана управления программным
проектом (software project management plan, SPMP), нам осталось лишь составить
рабочий график. Порядок действий при его составлении представлен на рис. 15.2.
Связь главы 15 с 34 компетенциями
Упражнения по составлению рабочего графика развивают умение правильно
оценивать альтернативные способы разработки программного продукта, особенно в случае
этапов, выполняемых субподрядчиками. Навыки по управлению проектом
заключаются в построении структуры WBS и в составлении рабочего графика. Большая часть

Глава 15
I Исследование
| концепции
• Формули-'1
рование

потребности
Исследование
системы
■ Спецификация'
интерфейса
системы
^Идентификация
■ циклов SLC
Циклы SLC
Выбор
модели
• Модель SLC
Угтановка
, соответствия

междузадачами и циклами
: SLC с помощью
i IEEE 1074
•SIX
определение
ресурсов
Бюджет
Требования
' Спецификация
требований
к ПО
Разработка
проекта
' Описание

разработки ПО
Внедрение
■ План

тации/верификации ПО
Выбор модели
жизненного цикла
разработки ПО
Установка
■Отчет об

тестации/верификации ПО
Эксплуатация
иподдержка
'
Пользовательская
документация
Сопровождение
■ Документация''
посопровож'
дению
Вывод из
эксплуатации
• Архивный
отчет
Рис. 15.1. Схема процесса разработки программного продукта
Почему ?
Коэффициент
КОИ
Что?
Техническое
задание
(на проект)
Составление
графика
Как?
ПланвРМР
Выполнение
Жиэнеь
цикл
1НЫЙ
Сделано
Процесс РРА
Рис. 15.2. Схема процессов, характерных для разработки этапов проекта

Формирование рабочего графика 477
действий, связанных с менеджментом рисков, выполняется именно при составлении
графика, так как план рисков всегда формируется на основании выбранного рабочего
графика. Необходимо также хорошо ориентироваться в способах выбора
подходящего графика и в специальных средствах составления графиков, которые используются
при управлении проектами. Как и при любом другом планировании, для составления
рабочего графика необходимо умение управлять людьми, что подразумевает ведение
переговоров, правильное руководство и грамотное проведение встреч.
Методики разработки продукта
1. Оценка альтернативных процессов— оценка различных подходов,
применяемых в ходе выполнения проекта.
2. Управление субподрядчиками — планирование, управление и осуществление
контроля деятельности субподрядчиков.
3. Навыки менеджмента проектов
4. Создание структуры пооперационного перечня работ— создание структуры
WBS для выполняемого проекта.
5. Документирование планов — идентификация ключевых компонентов для
данного плана.
6. Менеджмент рисков — идентификация, определение степени воздействия и
устранение рисков, связанных с выполняемым проектом.
7. Составление графика — формирование графика и определение ключевых стадий
выполняемого проекта.
8. Отбор инструментов менеджмента проектов — методика, используемая при
выборе инструментов управления проектами.
9. Навыки менеджмента персонала
10. Организация эффективных встреч— планирование и проведение
эффективных встреч, имеющих отношение к выполняемому проекту.
11. Взаимодействие и общение— взаимодействие с разработчиками, высшим
руководством и другими командами, имеющими отношение к данному проекту.
12. Лидерство — обучение команд разработчиков проекта для получения
оптимальных результатов.
13. Успешное ведение переговоров— разрешение конфликтов и успешное ведение
переговоров.
14. Эффективное представление — эффективное использование письменных и
устных навыков для популяризации выполняемого проекта.
15. Создание команды — формирование, руководство и поддержка эффективной
команды разработчиков проекта.
Учебные цели главы 15
После изучения материала главы читатель должен уметь выполнять следующее:
■ уметь составлять рабочий график работ для реальных проектов, используя метод
критического пути;
■ знать, что такое критическая цепь и чем она отличается от критического пути;

478 Глава 15
■ уметь описывать несколько различных представлений рабочего графика;
■ уметь объяснить, каким образом неопределенность влияет на процесс составления
рабочего графика;
■ знать два способа отображения рабочего графика в виде сетевой диаграммы;
■ уметь объяснить необходимость перераспределения ресурсов;
■ уметь описать различия между рабочим графиком, сформированным при
ограничениях деятельности, и рабочим графиком, разработанным в условиях
ограничений ресурсов.
Зачем нужен график?
Хороший вопрос! Действительно, зачем углубляться во все подробности проекта,
пытаясь определить реальную дату его окончания, если эта дата все равно, в конце
концов, окажется нереальной и будет скорректирована? С этой проблемой сегодня
сталкиваются многие менеджеры программных проектов. Они думают следующим образом:
"Почему бы не выбрать дату окончания проекта наугад и просто начать работу?"
Подобное отношение является результатом недостаточного понимания
пользователями, спонсорами и менеджерами того, чем на самом деле является рабочий
график. Общая картина проекта содержится в плане разработки программного продукта,
который описывает способы достижения целей, поставленных перед проектом.
Рабочий график является только одним из элементов этого плана и отображает
взаимоотношения между всеми производственными процессами, непосредственно связан
с реальным календарем и помогает правильно организовать работу проектировщи-
кон. С его помощью можно избежать неопределенности и продуктивно распределить
pai -чее время. Обычно рабочий график (чаще всего изображается в виде диаграммы
Гаи га) является лишь приложением к плану SPMP, так как в процессе работы над
проектом он чисто обновляется. Любые документы, которые могут обновляться, для
облегчения сопровождения проекта включаются в приложение.
Игра
Недостаточное понимание истинной сути графика работ и способов его
построения приводит к тому, что менеджеры относятся к нему как к "китайской грамоте".
При таком взгляде график представляется набором непонятных требований, в
котором производятся какие-то "фокусы" с формулами и указателями на функции,
непонятно откуда "всплывают" даты и каким-то образом определяются потребности в ре-
еурсах (стоимость = деньги). Существует три вида ограничений (область
определения, рабочий график и затраты). Несомненно, процесс разработки ПО требует
немалых человеческих усилий. В связи с этим менеджеры и заказчики часто играют в
своеобразную "игру", в которой даты и стоимость подбираются таким образом, чтобы
проект был максимально дешевым и разрабатывался как можно быстрее. В результате
получаемый от проектировщиков проект имеет оптимальную стоимость и
подходящий рабочий график. Зная об этом, многие менеджеры проектов, учитывая
вероятность занижения требований, специально расширяют допуски на результаты оценок
н планы. Таким образом, в эту "игру" играют обе стороны (менеджеры и
проектировщики), расширяя и урезая до тех пор, пока не будет достигнуто согласие или одна из
сторон не уступит другой.

Формирование рабочего графика 479
Мы рекомендуем не играть в подобные "игры", а доверять профессионализму
проектировщиков. Они хорошо знакомы со средствами проектирования и с предметной
областью, благодаря чему могут составить реальный рабочий график. При этом
можно быть уверенным в надежности оценки (главы 10 и 11) и правильности выбранных
методов составления графика (главы 8, 9, 12, 13, 14 и 15). Следует помнить о том, что
рабочий график должен быть не только "агрессивным" и соответствовать нормам
организации труда, но и реальным. Ни один человек за длительный период не
отрабатывает все 100% своего рабочего времени. Если уплывать отпуска, болезни, отгулы,
обеденные перерывы, обучение, перемены в работе и другие подобные причины, то
продуктивное время разработчика в любом проекте составляет в среднем 60-70%
общего времени работы в течение года. Для тех, кто работает с 8 часов утра до 5 часов
вечера D0 часов в неделю 52 недели в год) общее рабочее время в течение года
составляет D0 х 52 ") 2080 часов. 60% от этого времени составляют 1248 часов, а 70% —
1456 часов, что соответствует 24 и 28 часам в неделю. Если кто-то работает больше — это
прекрасно. В этом случае работа над проектом может быть завершена досрочно или
могут появиться дополнительные функции конечного продукта. Но если количество часов
продуктивной работы для одного из разработчиков будет меньше указанного выше, то
для своевременного завершения проекта на остальных членов команды ляжет
дополнительная нагрузка. Это приведет к прессингу, сверхурочной работе, дисгармонии
отношений и, возможно, даже к низкому качеству разрабатываемого продукта.
Неопределенность при составлении
рабочего графика
Составляя любой рабочий график, следует всегда учитывать принцип
неопределенности (см. главу 14). Спланированный рабочий график— это всего лишь
предположение о будущих действиях разработчиков при оптимальных условиях.
Возможными последствиями неопределенностями можно управлять с помощью
предусмотренных в графике временных резервов, которые являются аналогами финансовых
резервов, применяемых при построении бизнес-планов. Никто из проектировщиков
не может точно предсказать будущее. Если руководитель или заказчик считает, что он
может это сделать, непредвиденные обстоятельства в рабочем графике можно не
учитывать, но впоследствии может быть потеряно больше, чем сэкономлено. Если
кто-то считает, что он лучше других предсказывает будущие события, то, возможно,
ему следует уволиться со своей теперешней работы и попробовать свои силы в
торговле акциями или на товарной бирже.
Помните о том, что проект должен быть окончен к определенной дате (это то. что
интересует заказчика в первую очередь) с возможностью некоторой задержки. После
разработки структуры WBS, оценки продолжительности всех производственных
этапов и составления рабочего графика необходимо предусмотреть достаточное
количество буферов непредвиденных обстоятельств с целью учета возможных
неопределенностей. При этом уровень достоверности завершения проекта по отношению к
установленной дате необходимо принять равным примерно 95%. Распределение
рассматриваемой 95-процентной вероятности графически представлено на рис. 15.3.
Понижение уровня достоверности до 5% не принесет какого-либо реального
выигрыша ни для проектировщика, ни для руководства, ни для заказчика. Любой бизнес
полон риска, поэтому при объявлении предполагаемой даты завершения проекта

480 Глава 15
■ivmiik: указывать еще и вероятность успеха. Например, можно сказать так: "Наш анализ
выполняемой работы показал, что проект может быть завершен за 19500 часов {объем)
при условии наличия 15 эквивалентов полной занятости (стоимость) к 15 ноября
(/нггмтий график) с ti5-процентной вероятностью". При управлении разработкой
программных проектов управление ожиданиями осуществляется, главным образом, с
применением подходов и технологий, принятых в данной отрасли. Поэтому не пы-
т.нпесь "'играть" в расширение и урезание. Не сводите методы оценки к простому
занижению стоимости проекта. Оценка не должна быть предметом переговоров. Лучше
доверьтесь техническому заключению специалистов и внесите в рабочий график дос-
т.почпо большие буферы непредвиденных обстоятельств, в результате чего стано-
I1H г<. я возможным учет неопределенности оценки (обычно это делают при завершении
(н ионных этапов). Если руководство или заказчик говорит, что дата завершения
проекта неприемлема, то узнайте подходящую дату и используйте ее в качестве ограничения.
i lot лс этого в ходе планирования можно учесть необходимые ресурсы и, возможно, по-
и( к.iri> дополнительные слабые зависимости для того, чтобы перекрыть большее
количество производственных этапов и попытаться достичь более высокого уровня досто-
I'.ej и |оети для требуемой даты завершения проекта. Если урезать набор функциональных
< войегв программного продукта (сократить объем работ), то можно устранить соответ-
«■■I пуимцую часть оценочных расчетов. Все вышесказанное означает, что необходимо
< i .ip.i гься завершить все запланированные работы до установленной даты.
Распределение вероятности
времени выполнения действия
Действие 1
Действие 2
Действие 3
Действие 4
Действие 5
Деисшиеб
Распределение вероятности для даты завершения проекта
г-
i
5% вероятно J 95% вероятно
Оценка даты завершения проекта
Рис.15.3. Неопределенность даты завершения проекта
Психология оценивания
В главах 10 и 11 рассматривается несколько прекрасных методов и средств оценки
программных продуктов и трудозатрат, понесенных при выполнении определенных
действий. Давайте кратко рассмотрим ход мыслей среднего программиста,
принимающего окончательное решение. В тот момент, когда возникает необходимость оценить
дештвие, размышления специалиста по оценке выглядят примерно так:

Формирование рабочего графика 481
"На основании проведенного анализа в соответствии с моделью СОСОМО на
разработку этого компонента уйдет примерно три недели.
Но существует также множество неопределенностей, поэтому я удваиваю
полученную оценку временных затрат.
Кроме того, я не смогу полностью сосредоточиться только на этой работе,
поскольку принимаю участие еще в двух проектах.
Таким образом, я укажу в отчете, что для завершения данного действия мне
понадобится 10 недель."
Этот процесс проиллюстрирован на рис. 15.4. В данном случае оценщик
увеличивает допуски оценки для того, чтобы учесть возможную неопределенность. Он не
хочет брать на себя ответственность и указывать трехнедельный срок завершения
работы, так как правдоподобность такой оценки составляет всего 50 %. Вместо этого
оценщик предпочитает избрать срок с 99 % вероятностью завершения работ, и
потому использует хорошо известный трюк под названием "удвой и добавь еще немного".
По существу, около 65 % общего времени, отведенного на выполнение работы,
соответствуют буферу непредвиденных обстоятельств. Оценщик просто использует этот
буфер для того, чтобы не выставить себя в невыгодном свете, если работа не будет
выполнена вовремя.
Оценка времени, необходимого
для выполнения действия
После учета неопределенностей
После учета необходимости выполнения других задач
Оценка сроков выполнения действия,
которая указывается в отчете
Рис. 15.4. Еще один подход к распределению неопределенности
Такое поведение при составлении рабочего графика Элияху Голдрат (Eliyahu
Goldratt) назвал "студенческим синдромом". Люди умышленно откладывают сроки
завершения запланированной работы для того, чтобы завершить уже начатую работу
над каким-либо другим проектом, которая не терпит отлагательства. В этом случае
при планировании неопределенность учитывается для каждого действия, благодаря
чему реальная работа начинается по прошествии примерно 65 % времени,
отведенного для этапа. Такой подход приемлем, если начальная оценка по методу СОСОМО
(или SLIM) была выполнена правильно. Если же оценка была выполнена неверно, то
завершить работу к указанной дате будет очень проблематично. Голдрат назвал это
www. goldratt. com/. Критическая цепь.

482 Глава 15
явление "студенческим синдромом", потому что студенты склонны откладывать
выполнение курсовой работы на последнюю ночь перед ее сдачей.
Если такой подход применять для каждого действия в структуре WBS, то это
соответствующим образом отразится и на рабочем графике. Если контроль над непредвиденными
обстоятельствами в графике возложить не на всю команду в целом, а на отдельных
проектировщиков, и при этом все они будут подвержены "студенческому синдрому", то это
приведет к тому, что к моменту завершения работы над проектом возникнет внутреннее
напряжение. Вот почему разработка большинства программных проектов начинается с
некоторым запаздыванием и завершается немного раньше установленного срока.
Для того чтобы эффективно управлять неопределенностью, лучше всего
использовать в плане начальные оценки длительности производственных этапов. В этом
случае вероятность своевременного завершения каждого этапа будет составлять
только 50%. Это так называемое агрессивное оценивание. Теперь некоторую
неопределенность можно внести в буферы завершающего действия, что при
непосредственной работе над проектом позволит управлять неопределенностью сразу для всех
действий (см. главу 25). На рис. 15.5. проиллюстрировано уменьшение времени выполнения
отдельных действий и перенос времени неопределенности в буфер, отведенный для
всего проекта в целом. Такой подход позволяет управлять непредвиденными
обстоятельствами более эффективным образом.
Перенос менеджмента неопределенности
Название задачи
Фаза 1 - ПОДГОТОВКА
ha пять консультантов Андре Сторкал
Разместить центр данных
Разместить филиалы
Перенести центр продаж и обслуживании
Активизировать ISDN и службу Frame Relay
Фаза 2-РАЗВИТИЕ
Установить службы VAN
УввличитьзцкумцЙИ , .. -;;-;','-1". *;•;
Перенести центры управления запасами
Фаза 3 - УСТАНОВКА СВЯЗИ
Сократить офисы региональных торговых
представительств
Открыть офисы для продавцов
Фаза 4 - СЕЗОННЫЙ ПЕРСОНАЛ
Организовать работу сезонных офисов
Открыть дополнительные офисы
для продавцов
Завершить проект Service 21

Использование
»»»»
####
0.0
####
йОДГ
0.0
в»»»
0.0
0.0
Ресурсы
JOFFF
NH30F
JVTMP
JVTMP
MVTM
RVFMP
mvtm
mvtm
с уровня действия на уровень проекта
1996 | 1998 | 2000 | 2002
Янв Июл Янв Июл Янв Июл Янв Июл Янв Июл Янв Июл Янв Июл
1
■
■
■
■

*
1
"■».
Ч
Мини
%
мальн
юк зав
ч
ч
7ВОЗМ
ершен
ч \
ч\
эжный
ия
Дат
котор
ч
> Ч
V ч
С
J
а заве
аяназ
ч
ч
эшени
ывает
\
*
дпрое
:я зак
\
\
аа,
зчику
\
1 1 '
^
J
Наиболее агрессивный
график работ
Буфер
неопределенности
Рис. 15.5. Перенос неопределенности действия в буфер, отведенный для всего проекта в целом
Вероятность своевременного завершения каждого действия составляет только
50%, поэтому некоторые из них будут завершены позже установленного срока. Все
разницы в сроках завершения должны быть вычтены из буфера непредвиденных
обстоятельств последнего действия или всего проекта в целом. Однако некоторые
этапы могут быть завершены досрочно, поэтому выигрыш во времени также должен
быть добавлен к буферу неопределенности проекта. Это означает, что размер буфера
будет оставаться практически неизменным. В любом случае контроль над размером

Формирование рабочего графика 483
буфера неопределенности в процессе разработки проекта осуществляется всей
командой проектировщиков, что позволяет предпринимать эффективные меры для
поддержания 95 % уровня достоверности и завершить работу в установленный срок.
Более подробно этот вопрос будет рассмотрен в главе 25, когда речь пойдет о
наблюдении и контроле за выполнением проекта.
Основы формирования рабочих графиков
Существует несколько способов представления рабочих графиков. Мы рассмотрим
три самые распространенные формы: таблица, диаграмма Ганта и сетевая диаграмма.
Таблица
Это— самая простая форма представления рабочего графика. Она не относится к
графическим видам и представляет собой простой перечень действий с указанием даты
их начала и завершения. При необходимости в таблицу может быть включена и другая
информация. Подобный метод представления графиков весьма удобен при работе с
очень длинными перечнями действий проекта. Графические методы представления
при работе с очень большими проектами не используются из-за своей громоздкости.
Пример таблицы, представляющей рабочий график, представлен на рис 15.6.
Название задачи
Доставка пищи
Начальный этап
Мытье стола
Установка стола
Завершение подготовки
Действие по приготовлению пищи
Действие по составлению меню
Просмотр последнего меню
Составление нового меню
Действие по закупке продуктов
Составление списка необходимых продуктов
Закупка всех ингредиентов
Действие по приготовлению пищи
Изготовление закусок
Подготовка ингредиентов
Приготовление пищи
Пища готова
Действие по доставке пищи
Перемещение пищи на стол
Объявление о том, что стол накрыт
Пища доставлена
Структура WBS
0
1
1.1
1.2
1.3
2
2.1
2.1.1
2.1.2
2.2
2.2.1
2.2.2
2.3
2.3.1
2.3.2
2.3.3
2.4
3
3.1
3.2
3.3
Длительность
300,3 минуты
30 минут
20 минут
10 минут
0 минут
296,3 минуты
20 минут
5 минут
15 минут
130 минут
10 минут
2 часа
146,3 минуты
30 минут
45,3 минуты
70 минут
0 дней
5 минут
4 минуты
1 минута
Одней
Начало
9/18
9/18
9/18
S/19
9/19
9/18
9/18
9/18
9/1S
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
Завершение
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
9/19
Рис. 15.6. Пример графика, представленного в виде таблицы

484 Глава 15
Диаграмма Ганта
Чаще всего для представления графика работ используется диаграмма Ганта,
которую еще иногда называют гистограммой. Она была изобретена Генри Гантом
(Henry L. Gantt) во время Первой мировой войны и первоначально использовалась
для составления графиков отправки солдат и техники из тыла на побережье США,
откуда они должны были переправляться в Европу.
Фактически этот вид диаграмм хорошо известен даже тем, кто никогда не
сталкивался с разработкой каких-либо проектов.
На простой диаграмме Ганта, представленной на рис. 15.7, слева перечислены
производственные действия, а справа— указаны полоски, длина которых
соответствует длительности выполнения каждого этапа в соответствии с временной шкалой.
В настоящих диаграммах Ганта взаимосвязи не используются, однако многие
средства формирования рабочих графиков позволяют изображать между полосками
этапов связующие линии. Подобные диаграммы Ганта называются диаграммами
стадий. На подобных диаграммах некоторые действия могут быть пропущены, а
вместо них — изображены соответствующие стадии.
Визуально диаграмма Ганта представляет собой последовательность действий,
выполняемых в рамках данного проекта. Эта последовательность может быть
отсортирована по дате начала (как показано на рис. 15.6) или по какому-нибудь другому
параметру (например, коду WBS или уровню).
Название задачи
Фаза 1 - ПОДГОТОВКА
Нанять консультантов Андре Сторка
Разместить центр данных ( ''"'*
Разместить филиалы
Перенести центр продаж и обслуживания
Активизировать ISDN и службу Frame Relay
Фаза 2 - РАЗВИТИЕ
Установить службы VAN
Перенести центры управления запасами
Фаза 3 - УСТАНОВКА СВЯЗИ
Сократить офисы региональных торговых
представительств
Открыть офисы для продавцов
Фаза 4 - СЕЗОННЫЙ ПЕРСОНАЛ
Организовать работу сезонных офисов
Открыть дополнительные офисы
для продавцов
Завершить проект Service 21

Использование
glili
0.0
0.0
0.0
Ресурсы
111!
mvtm
mvtm
mvtm
1996 | 1S98 | 2000 | 2002
-в "в -в -в -а -в -в
1
■
■
■
■
■
4
►
Рис. 15.7. Пример диаграммы Ганта
При выполнении больших проектов, содержащих множество действий и другой
отображаемой информации, диаграммы Ганта могут быть очень громоздкими.
Иногда рабочие графики бывают настолько большими, что для их печати уходят целые
рулоны бумаги, которыми затем менеджеры проектов завешивают стены своих
офисов. Это действительно позволяет увидеть "общую картину", однако ориентироваться
в подобных графиках очень сложно.

Формирование рабочего графика 485
Сетевая диаграмма
Сетевые диаграммы еще называют логическими диаграммами и PERT-диаграммами.
Они содержат упорядоченный набор условных графических обозначений (обычно
прямоугольников и окружностей), содержащих название действия и его приоритет.
Также в условные обозначения часто заносится дополнительная информация,
например, продолжительность, дата начала, дата завершения и уровень
ответственности. Существует несколько различных методов построения сетевых диаграмм.
■ GERT — метод графической оценки и обзора;
■ PERT — метод программной оценки и обзора;
■ СРМ — метод критического пути;
■ PDM — метод предшествования;
■ ADM — метод стрелочных диаграмм.
Первые три метода имеют отношению к анализу, а последние два — это просто
методы построения диаграмм. Методы PERT и СРМ были изобретены почти
одновременно в 1950-х годах, поэтому их названия иногда объединяют в одно: PERT/CPM.
При этом под методом PERT/CPM подразумевается общий процесс анализа с
использованием сетевых диаграмм. Метод GERT также связан с анализом, однако он более
сложен, так как позволяет совершать как условную, так и вероятностную оценку
приоритета и продолжительности действий. Метод PERT позволяет производить только
вероятностную оценку продолжительности действий, и в нем вместо одноточечного
оценивания применяется трехточечное. При этом предполагается, что сетевая
логика фиксирована. Метод СРМ более простой, так как в нем предполагается, что
фиксирована как продолжительность действий, так и логика определения приоритетов.
Следует также отметить, что в методах PERT и СРМ используется один и тот же
подход к построению сетевых диаграмм.
Существует два основных способа представления действий в сети. В общем виде
сетевая диаграмма представляет собой набор узлов и стрелок. В ней содержится
следующая информация:
■ название действия или идентификатор узла (при этом часто используется код WBS);
■ время наискорейшего начала производственного этапа, которое определяется на
основании времени завершения предыдущего действия или какого-либо другого
ограничения (например, даты, фиксированной в проекте);
■ время быстрейшего завершения действия;
■ продолжительность этапа (количество временных периодов, необходимых для
выполнения работы);
■ максимально возможный срок, когда действие может быть начато, не затронув
стадию следующего действия;
■ максимально возможный срок, когда действие может быть завершено, не затронув
стадию следующего действия.
В одном из представлений сетевой диаграммы информация о производственном
этапе указывается в самом узле (рис. 15.8). Такое представление называется AON
(activity-on-node). В еще одном представлении, которое называется АОА (activity-on-
arow), информация о действии помещается на стрелке между двумя узлами (рис. 15.9).

486 Глава 15
В представлении АОА могут использоваться фиктивные стрелки, соответствующие
"этапам", для которых не отведены ресурсы или время. Они обычно изображаются в
виде пунктирной линии и отображают приоритет узлов при наличии более одного
этапа. По причине наличия подобных фиктивных этапов усложняется чтение АОА-
диаграмм. В методе PDM используется представление AON, а в методе ADM —
представление АОА.
Сеть АОА представлена на рис. 15.11, а две сети AON — на рис. 15.10. АОА-диаграммы
в паши дни используются редко, но какое бы представление не применялось,
принцип построения остается неизменным. В схеме AON есть начальный узел, который
обычно располагают слева, и конечный узел, находящийся справа. Все узлы,
распределенные между начальным и конечным узлами, соответствуют действиям в структуре
WBS проекта, причем каждом узлу соответствует только одно действие. Узлы можно
изображать в виде любой геометрической фигуры, однако, мы будем изображать их в
виде окружности (рис. 15.8).
Время наискорейшего начала _^^-@,10)
Время наискорейшего завершения
Идентификатор узла
Запас времени
Максимально возможный срок начала
Максимально возможный срок завершения t^/-jq go)
Рис. 15.8. Представление сведений
относительно действия AON
Идентификатор узла „
Время наискорейшего начала
Время наискорейшего завершения
А @,10)
Запас времени
/
10 A0,20)
Максимально возможный срок завершения
Максимально возможный срок начала
Рис. 15.9. Представление сведений относительно действия АОА
Обратите внимание на то, что на всех сетевых диаграммах хорошо
прослеживается старшинство узлов. В этом и заключается их основное преимущество. Можно легко
проследить порядок следования действий слева направо и увидеть взаимосвязь между
различными последовательностями узлов. Подобные диаграммы широко
используются при разработке проектных планов "с нуля", когда отсутствует даже шаблон
структуры WBS. Недостаток этих диаграмм аналогичен недостатку диаграмм Ганта и других
графических представлений: в больших проектах с огромным количеством действий
они становятся очень громоздкими и неудобочитаемыми. Тем не менее, сетевые
диаграммы очень удобны на начальном этапе планирования, а также при разработке
структуры WBS.

Формирование рабочего графика 487
@,10)
B0,50)
E0,60)
(80,80)
FS
FS
w
FS
Действие
#3
Действие
#6
FS
FS
Действие
#1
Действие
#4
#12
Действие
#7
FS
FS
FS
Действие
#2
#11
Действие
#5
Действие
#8
FS
FS
#10
Рис. 15.10. Примеры сетевых диаграмм AON
Построение рабочих графиков
с применением методов PERT и СРМ
Эти два метода анализа графиков известны с 1950-х годов. Они заложили
основание современных методик построения графиков. Метод СРМ (Critical Path Method,
метод критического пути) был разработан Дюпоном (DuPont) в 1958-59 годах. В нем
используется оценивание с фиксированным временем для каждого действия. Метод
PERT (Program Evaluation and Review Technique, оценка программы и техника
просмотра) был применен в ходе проектировании ракетной подводной лодки "Полярис"
специалистами департамента специальных проектов Военно-морских сил США Бузом
(Booz), Алленом (Allen) и Гамильтоном (Hamilton).
В обоих методах для отображения приоритета действий используются сетевые
диаграммы. В наши дни при построении рабочих графиков в большинстве случаев
используется метод СРМ. Вначале мы рассмотрим основные различия между
методами PERT и СРМ, а затем — использование сетевых диаграмм в СРМ-анализе.

488 Глава 15
Рис. 15.11. Пример сетевой диаграммы АО А
Метод PERT
При временном оценивании по методу PERT используется вероятностное бета
распределение (рис. 15.12). При этом производится три вида оценки
продолжительности действия: оптимистическая, наиболее вероятная и пессимистическая.
Выше
Ниже
Короне Возможная продолжительность Длиннее
Рис. 15.12. Бета-распределение PERT
Бета-распределение было выбрано для метода PERT вместо нормального
распределения по той причине, что оно наиболее точно описывает поведение людей
при выполнении оценивания. Мы по природе оптимисты и "склоняемся" к левой
части кривой распределения. Некоторые называют бета-распределение
"распределением закона Мерфи". Обратите внимание на то, что концы кривой
распределения не параллельны оси X, а пересекают ее. Это означает, что
продолжительность работы не может равняться нулю или быть бесконечной. Если фактическая
Средневзвешенная величина PERT=
(оптимистическая+4 х наиболее вероятная+пессимистическая)
Наиболее вероятная

Формирование рабочего графика 489
продолжительность меньше наиболее вероятной, то она будет только немного
короче (смещение влево), но если она длиннее, то может быть значительно длиннее
(смещение вправо). Другими словами, если что-то делается плохо, то оно делается
не просто плохо, а очень плохо. Фактически в методе PERT используется
оценивание только в трех точках, поэтому кривую распределения можно представить в
виде треугольника (рис. 15.13).
Выше
ЗС h-
х се
8 а
5 m
Середина
Бета-распределение
Треугольное распределение
Ниже
Короче Возможная продолжительность
Рис. 15.13. Треугольное и бета-распределение
Длиннее
Средневзвешенная величина PERT фактически соответствует середине
треугольного распределения, которое используется в качестве аппроксимации для бета-
распределения. Формула для вычисления средневзвешенной величины была
получена экспериментально, так как в 1950-х годах мощностей компьютеров для решения
такой задачи было недостаточно:
средневзвешенная величина PERT = (оптимистическая + 4х(наиболее вероятная) +
+ пессимистическая) / 6
При формировании рабочего графика, включающего множество действий,
оценивание по трем значениям занимает много времени. Кроме того, распространено
мнение, что оценивание по трем значениям не намного превосходит по точности
оценивание по одном значению. Исходя из этого, многие менеджеры программных
проектов при составлении графика работ используют метод СРМ. В результате все
сводится к обычным полоскам фиксированной длины, которые используются для
обозначения продолжительности действий в большинстве диаграмм Ганта.
Конечно же, при составлении плана проекта можно вычислить три величины для каждого
действия, а затем включить их в диаграмму Ганта, но в этом случае при каждом
изменении продолжительности все расчеты придется выполнять заново. Для
большинства рабочих графиков подобный подход неприемлем. Тем не менее, для
вычисления трех величин продолжительности действий можно воспользоваться
специальным инструментальным средством компании Palisade Corporation под
названием @Risk .
www.palisade, com/html/risk_^for_project.html. Инструмент@Risk

490 Глава 15
Метод СРМ
В ходе применения метода критического пути с целью прогнозирования общей
продолжительности проекта производится анализ приоритета действий. Основное
внимание при этом уделяется так называемому запасу времени (float) между двумя
действиями. Для определения этого понятия также используются термины "резерв
времени" (slack), "свободный запас времени" (free float) и "запас пути" (path float). Метод
СРМ заключается в определении последовательности действий (путь в сети), которая
обладает наименьшей гибкостью в составе рабочего графика (flexibility). Путь с
нулевой гибкостью называется критическим, потому что имеет нулевой запас времени
между всеми своими действиями.
Анализ по метод)' СРМ начинается со структуры WBS, в которой для каждого
действия существует только одна величина оценки. Затем используется метод PDM для
установки соотношений в соответствии с приоритетами действий в сети. После построения
сети по ней выполняется двунаправленный проход с анализом действий и вычислением
оценочных значений для каждого узла. В результате будет выявлен критический путь.
Для сети, изображенной в верхней части рис. 15.10 (с узлами в виде окружностей),
критическим будет путь B-C-D-F, а для сети, изображенной на рис. 15.11, — путь B-D-H-I. Для
сети, изображенной в нижней части рис. 15.10, критический путь определить
невозможно, так как в ее узлах не указана продолжительность действий.
При двунаправленном анализе сначала выполняется прямой проход по сети от
начального узла, для которого время наискорейшего начала и время наискорейшего
завершения равно нулю (на рис. 15.11 они обозначены в виде пары чисел над узлом).
В узле А время наискорейшего начала равно нулю, а время наискорейшего
завершения — ноль плюс продолжительность этапа А (в данном случае, 0 + 10 = 10). Следуя по
стрелке, переходим к узлу С, для которого время наискорейшего начала определить
пока что невозможно, так как неизвестны данные об узле В. Возвращаемся в
начальный узел и выполняем аналогичные вычисления для узла В. В данном случае время
наискорейшего начала для узла В равно нулю, а время наискорейшего завершения —
20 @ + 20 = 20). Теперь можно определить время наискорейшего начала для узла С.
Для этого выбирается большее из значений времени наискорейшего завершения для
узлов А A0) и В B0). В данном случае время наискорейшего начала для узла С
равно 20. Прибавляем к этому значению продолжительность действия С C0) и в
результате получаем время наискорейшего завершения для узла С: 20 + 30 = 50. Продолжаем
этот процесс вычисления времени наискорейшего начала и наискорейшего
завершения для узлов D и F. Убедитесь в том, что были проверены все возможные пути в сети
к узлу, для которого производится вычисление, так как это необходимо для
корректного определения времени наискорейшего начала. Время наискорейшего завершения
для конечного узла равно общей длине самого длинного пути в схеме. Именно эта
величина определяет продолжительность работы над проектом (в примере на
рис. 15.10 она равна 80).
После завершения прямого прохода можно сделать обратный проход. Он
начинается в конечном узле, после чего вычисляется максимально возможный срок начала и
максимально возможный срок завершения для каждого узла в сети до тех пор, пока не
будет достигнут начальный узел. На этот раз определяются пары чисел, которые
расположены под узлами. Для конченого узла в сети, представленной на рис. 15.10, это
пара значений (80. 80). Для узла F максимально возможное время начала равно
известному времени завершения 80 минус продолжительность узла F B0), то есть 80 - 20 = 60.

Формирование рабочего графика 491
Таким образом, парой значений для узла F будет F0, 80). Для узла D производятся
аналогичные вычисления. При этом максимально возможное время завершения будет
с отгадать с максимально возможным временем начала для узла F F0) минус
продолжительность узла D A0), то есть 50. Для узла Е из максимально возможного времени
начала для узла F F0) вычитается продолжительность узла Е C0), в результате чего
максимально возможное время начала для узла Е получается равным 30. Этот процесс
продолжается до тех пор, пока не будет достигнут начальный узел и не будут
определены все пары чисел. Для начального узла должны получиться значения @, 0).
Обратите внимание на то, что при прямом проходе:
■ процесс начинается с начального узла;
■ вычисления производятся для пары чисел, указанных над узлом;
■ продолжительность всегда прибавляется ко времени наискорейшего завершения
для подключенного узла.
При обратном проходе:
■ процесс начинается с конечного узла;
■ вычисления производятся для пары чисел, указанных подузлом;
■ продолжительность прохождения узла всегда вычитается из времени
наискорейшего начала для подключенного узла.
По окончании вычислений каждый узел содержит информацию о запасе времени,
как разницу между временем наискорейшего начала и максимально возможным
сроком начала (или временем наискорейшего завершения и максимально возможным
сроком завершения). Какая бы пара не была выбрана (начала или завершения),
результат будет тем же, так как в обоих случаях для вычисления использовалось одно и
то же значение продолжительности. Запас времени говорит о том, что действие
может быть начато на этапе где-то между временем наискорейшего начала и
максимально возможным сроком начала, причем это никак не повлияет на общую длину сети
(общее время работы над проектом).
Критический путь соединяет узлы с нулевым запасом времени. На рис. 15.10 и
рис. 15.11 критические пути выделены жирными линиями. На рис. 15.10 это — B-C-D-F, а
на рис. 15.11 — B-D-H-I. Смысл критического пути заключается в том, что при
увеличении продолжительности для любого из его узлов увеличивается время
завершения всего проекта. И наоборот, при сокращении продолжительности любого узла
критического пути уменьшается и общее время завершения проекта. Но есть одно
большое "но"! Любые изменения продолжительности любого узла могут привести к
изменению критического пути, поэтому после каждого такого изменения необходимо
выполнять перерасчет. Надеюсь, теперь понятно, почему этот процесс лучше
доверять компьютерам?
Обратите внимание на то, что во всех вычислениях при определении запаса
времени и критического пути не рассматривалось наличие каких-либо ресурсов,
необходимых для фактического выполнения работ. Это необходимо учитывать для
большинства организаций, так как наличие ресурсов обычно накладывает ограничения на
график работ. Это является большим недостатком метода СРМ. При его
использовании в графиках работ присутствуют ограничения для действий. Для построения
более реальных графиков необходимо отображать данные о доступных ресурсах, в
результате чего ограничения будут накладываться именно на ресурсы.

492 Глава 15
Перераспределение ресурсов
После того как все ресурсы (см. главу 12 для получения дополнительных сведений)
распределены между взаимосвязанными действиями из структуры WBS (см. главу 8
для получения дополнительных сведений) и подготовлен рабочий график, может
быть обнаружена ресурсная перегрузка. Обычно при первом просмотре рабочего
графика распределение ресурсов оказывается неравномерным (рис. 15.12), так как
они не учитываются в алгоритме СРМ.
150
100
Время
Рис. 15.14. Неравномерное потребление ресурсов
Ресурсы желательно распределить равномерно на протяжении всего проекта, чтобы
свести к минимуму простои между пиками потребления. Перераспределение нагрузки
заключается в перепланировании тех задач, для которых есть резерв времени. Благодаря
этому достигается более сбалансированное распределение потребления ресурсов.
Существует два основных типа алгоритмов перераспределения. Алгоритмы
первого типа основаны на методах линейного программирования, а алгоритмы второго
типа — на методах дискретной математики.
Большинство средств построения рабочих графиков производят
перераспределение ресурсов автоматически, однако они не обеспечивают оптимальных решений.
Для перераспределения можно применить:
■ сдвиг действий — смещение дат начала/завершения вперед или назад для
избежания назначения ресурсов;
■ разбиение действий на несколько этапов с целью оптимизации потребления ресурсов;
ш "растягивание действий" — увеличение продолжительности действий, за счет чего
уменьшается ресурсная нагрузка;
ш замещение ресурсов — замена ресурсов с целью повышения производительности,
эффективности и т.п.;
м назначение сверхурочных часов — приспособление к перегрузке;
■ истощение ресурсов — назначение ресурса, использующего неравномерное
распределение нагрузки.
При перераспределении ресурсов менеджер проекта должен учитывать
фиксированные даты (т.е. даты, при наступлении которых работа обязательно должна быть
начата или завершена). Они накладывают на проект ограничения и затрудняют
работу с графиком, уменьшая степень его гибкости. Конечно же, некоторые даты не могут

Формирование рабочего графика 493
быть нефиксированными. Это относится, например, к датам платежей для всех
проектов, связанных с "проблемой 2000 года". В общем случае при перераспределении
ресурсов в графике работ дата завершения проекта смещается вперед (рис. 15.15).
150i
100
Время
Рис. 15.15. Равномерное потребление ресурсов
Большинство современных инструментальных средств построения рабочих
графиков (например, Microsoft Project) выполняют всю работу автоматически, и потому
производство сетевых вычислений вручную маловероятно даже для небольших
проектов. Тем не менее, важно понимать те процессы, которые используются при
использовании этих инструментальных средств для построения графиков.
Привязка рабочего графика к реальному
календарю
Для большинства неопытных менеджеров проектов разработка удобного рабочего
графика является трудновыполнимой задачей. Они уже знают, что для представления
графика нужно использовать диаграмму Ганта и потому начинают работать со
структурами WBS с помощью специальных инструментальных средств типа Microsoft Project.
При этом иногда даже не производится декомпозиция работ, и построение графика
выполняется "с нуля" — с пустой диаграммы Ганта. После этого датированные действия
отмечаются в структуре WBS или непосредственно в диаграмме Ганта, и над ними
производятся некоторые манипуляции до тех пор, пока даты не станут "подходящими".
Затем добавляются и немного подгоняются некоторые взаимосвязи. И наконец,
выполняется добавление и перераспределение ресурсов, после чего к своему разочарованию
менеджеры проектов обнаруживают, что в аккуратно составленной диаграмме Ганта
некоторые действия сместились, а другие были разбиты на несколько частей. Поэтому
рабочий график возвращается в состояние, бывшее перед перераспределением
ресурсов, в результате чего он превращается в простой перечень дат начала и завершения
основных действий. Подобный график работ является не реальным, а интуитивным.
При таком подходе к построению рабочих графиков допускается, как минимум,
две ошибки.
1. В деятельность по подготовке плана не вовлекаются непосредственные
разработчики проекта.
2. Менеджеры проекта не знают, какую информацию нужно использовать для того,
чтобы график работ стал реальным, а не интуитивным.

494 Глава 15
Представление с помощью диаграмм Ганта (или любое другое представление)
только отражает основную информацию, извлеченную из структуры WBS,
приоритетность действий, распределение ресурсов и усредненную фиксированную оценку
работ. Для составления реального рабочего графика полученное представление
необходимо наложить на реальный календарь рабочего времени. С целью подгонки
реального рабочего графика не требуется изменять даты начала и завершения
действий, а нужно лишь модифицировать базовые элементы.
Для того чтобы понять, как выполняется привязка рабочего графика к реальному
календарю, рассмотрим взаимосвязь между четырьмя основными компонентами
любого действия, включенного в рабочий график:
■ работа — временные затраты персонала;
■ единицы — количество ресурсов, необходимое для завершения выполняемого
действия;
■ продолжительность — рабочее время, необходимое для завершения выполняемого
действия;
■ даты — календарное время, необходимое для завершения выполняемого действия.
С этими компонентами связаны три вида ограничений, накладываемых на объем
работ, рабочий график и стоимость. Работа— это общие трудозатраты персонала.
Процесс оценки данного параметра описан в главах 10 и 11. Результат оценки в
данном случае может выглядеть следующим образом:
Работа — "Разработка графического интерфейса: 48 штатных дней ".
Единицы— это количество ресурсов, необходимых для выполнения работы. Для
данного примера они могут быть описаны следующим образом:
Единицы — "Эту работу выполнят Эйбл, Бейкер, Чарли и Дон".
Продолжительность— это фактическое количество рабочих дней, необходимых для
выполнения работы при наличии указанных ресурсов:
Продолжительность — 8 штатных дней / 4 человека = 12рабочих дней на
выполнение задачи ".
Теперь календарные даты для 12 рабочих дней определяются по фактическому
календарю. При этом предполагается, что все работают полное рабочее время при
обычной 40-часовой рабочей неделе, длящейся с понедельника по пятницу.
Даты — "Для разработки графического интерфейса нам нужно 2 недели и 2 рабочих дня"
Первые три элемента изменяются незначительно, независимо от того, когда была
завершена работа. Последний элемент напрямую зависит от календаря и потому
привязан к конкретным рабочим дням. Если в течение рабочего периода какие-либо
ресурсные единицы будут недоступны, то предполагаемая дата завершения работы
соответствующим образом будет смещена.
Подобная взаимосвязь весьма напоминает связь между расстоянием, временем и
скоростью.
Примечание 15.1. Взаимосвязь между расстоянием, временем и скоростью
Расстояние / Скорость *■ Время . .
Если я выеду на машине из Нью-Йорка и буду ехать без остановки со средней
скоростью 100 км/час, то доберусь до Лос-Анджелеса за 50 часов. Но я не смогу ехать без
остановок все 24 часа в сутки. Если же я буду ехать только 8 часов в день, то на путь из

Формирование рабочего графика 495
Нью-Йорка в Лос-Анджелес мне понадобится 6,25 суток. Для того чтобы ускорить
переезд, мне нужно либо ехать быстрее, либо затратить на дорогу больше времени в
течение одного дня. То же самое относится к параметрам ограничений. Если я хочу
"разработать графический интерфейс" и на это для четырех человек отводится 48
штатных часов, то работа будет завершена за 12 дней. Если работу нужно сделать
быстрее, то придется либо уменьшить ее объем (например, ограничить возможности
графического интерфейса), либо увеличить рабочее время (сверхурочные часы),
либо использовать больше людей. Количество людей нужно увеличивать очень
осторожно, так как это снижает эффективность взаимодействия и распределения работы.
Построение рабочих графиков
с применением метода критической цепи
До сих пор шла речь о классических методах построения рабочих графиков,
применяемых при управлении проектами (PERT, CPM, PDM и т.д.). Теперь обратимся к
результатам некоторых современных исследований в этой сфере. Начиная с 1950-х
годов, когда были разработаны методы PERT и СРМ, принципиально новых подходов
к разработке рабочих графиков не было вплоть до 1997 года. В этом году доктор
Элияху Голдрат применил теорию ограничений (Theory Of Constraints, TOC) к
процессу управления проектами, что было описано в книге под названием "Критическая
цепь"(Critical Chain).
Теория ограничений разрешает проблемы (подобно TQM) и применима
практически в любой дисциплине. Она основана на теории систем, согласно которой все
системы содержат внутри себя нужные ограничения. Задача состоит в том, чтобы
определить эти ограничения и извлечь из них максимальную пользу посредством
правильной организации системы. Таким образом будет улучшена работа всей системы в
целом. Метод фиксации ограничений Голдрата состоит из пяти этапов:
1. определение ограничений системы;
2. принятие решения относительно максимально эффективного использования
ограничений системы;
3. организация всей системы в соответствии с принятым решением;
4. улучшение ограничений системы;
5. если какое-либо ограничение было снято, осуществляется переход на этап 1.
Основная идея заключается в увеличении производительности всей системы
посредством сокращения незавершенного производства (work-in-process, WIP) и снижения
эксплуатационных расходов (стоимость запуска системы). Голдрат придает большое
значение тому факту, что большинство из нас уделяет основное внимание оптимизации
отдельных частей системы, а не самой системы в целом. Он считает неправильным
бухгалтерское соглашение, согласно которому материально-производственные запасы
(WIP) относят к активам, так как они, по сути приводят к значительному снижению
производительности системы. Это было отражено в 1980-х годах на примере концепции
повышения эффективности производства посредством выпуска продукции строго в
соответствии с графиком. Кроме того, Голдрат выступает против многих методов
оптимизации, подобно планированию требований к производству (MRP) и обеспечению
ритмичности производственного процесса, так как это фокусирует все внимание на
локальной оптимизации за счет снижения общей производительности системы.

496 Глава 15
Теория ограничений Голдрата впервые была представлена в 1984 году в книге под
названием "Цель" (The Goal), где она была применена в условиях заводского
производства. Эта книга имела успех, так как была написана в виде художественного
романа, а не учебника или научного доклада. В 1990 году Голдрат написал книгу "Теория
ограничений" (Theory of Constraints), в которой более подробно представил принципы
своей теории.
В 1997 году увидела свет еще одна книга Голдрата— "Критическая цепь". В ней
теория ограничений была применена к управлению проектами и построению
рабочих графиков. На ее основе Роберт Ньюболд (Robert Newbold) написал в 1998 году
книгу под названием "Управление проектами с применением метода кратчайшего пути -
применение теории ограничений" (Project Management in the Fast Line: Applying the
Theory of Constraints).
В книге "Критическая цепь"Голдрат сравнивает рабочий график с заводом.
Единственное различие между ними состоит только в том, что в графике вся работа разбита
на действия, а на заводе — продукт обрабатывается последовательными действиями
машин. В книге описаны некоторые распространенные проблемы построения
рабочих графиков, с которыми сталкиваются специалисты в последние годы. К ним
относятся "студенческий синдром" и одновременное выполнение слишком большого
количества задач, что усложняет оптимизацию производства.
Голдрат уделяет особое внимание обработке неопределенностей в проектных
планах, что просто необходимо при управлении рисками, а также поддерживает
размещение буферов непредвиденных обстоятельств в стратегических местах графика работ.
Одним из основных вопросов, рассматриваемых в книге "Критическая цепь",
является обработка ограниченных ресурсов. Голдрат указывает на то, что любая
организация является системой, и, как любая система, она имеет ограничения. Без
сомнения, все организации, занимающиеся разработкой ПО, имеют несколько "узких
мест", которые могут быть связаны как с отдельными техническими специалистами,
играющими ключевую роль в большинстве активных проектов, так и с целыми
подгруппами. В любом проекте такие ключевые ограничения находятся на критическом
пути. Если эти "узкие места" немного "расширить", то будет повышена
производительность всей организации.
Для описания ключевых ограничений ресурсов Голдрат использовал слово
"Гсрби" ("Herbies"), по имени самого медленного бойскаута, о котором упоминается в
книге "Цель". Определение таких ресурсов и соответствующее размещение действий и
буферов приведет к лучшим результатам, чем простое последовательное внесение
всех действий в график (в большинстве современных инструментальных средств
построения рабочих графиков используются условия, заданные по умолчанию).
Подход Голдрата заключается в построении рабочего графика с конца, когда в
процессе последовательного продвижения к началу проекта основное внимание
уделяется максимально эффективному использованию ресурсов "Герби". При этом
некоторые члены организации могут бездействовать, и Голдрат доказывает, что для них
лучше бездействовать до тех пор, пока ресурсы "Герби" не будут подготовлены, чем
выполнять действия, которые является частью критического пути. Цепь из действий,
на которых используются "Герби", Голдрат назвал критической цепью. При этом он
указал, что нет ничего страшного в том, что некоторые агрегаты на заводской линии
будут простаивать, так как агрегаты, накладывающие ограничения, продолжают
работать в оптимальном темпе.

Формирование рабочего графика 497
На рис. 15.16 показан пример графика с критической цепью. В данном проекте
критическая цепь выделена жирной линией, проходящей через несколько действий и
оканчивающейся на отметке "Дата наискорейшего завершения" (буфер проекта не
затрагивается). Некоторые из представленных этапов были определены как критические
в процессе анализа по методу СРМ, а другие являются критическими из-за недостатка
ресурсов. Например, для действий IB, 2B и ЗВ используется один и тот же ресурс,
поэтому они не могут выполняться одновременно. В результате анализа по методу СРМ
эти этапы не были включены в критический путь. Вместо этого они изображаются
последовательно с размещением перед ними специальных буферов. Эти "буферы
снабжения" предназначены для защиты действий в составе критической цепи от пересечения с
предыдущими действиями AС, 2А и ЗА) в результате проявления "студенческого
синдрома" или возникновения неопределенности. Буферы снабжения поглощают часть
времени действия критической цепи, в противном случае смещение некритического
действия может привести к смещению всего графика работ.
Рис. 15.16. Формирование графика методом критической цепи
Очень важно понимать, что критический путь и критическая цепь — это не одно и
то же. Критический путь — это самый длинный путь в схеме, когда учитываются
только действия, а критическая цепь — это самый длинный путь в схеме, когда
учитываются как действия, так и ресурсы.
При построении рабочих графиков с критическими цепями очень важно
правильно выбрать размер буферов. Насколько большим должен быть буфер? В общем
случае, размер буфера выбирается равным половине общего времени всех действий,
выполнение которых предшествует этому буферу, при условии, что вероятность
своевременного завершения работ для всех выполняемых действий равна 50%. Если
была выполнена консервативная оценка для 95-процентной вероятности, то размер
буфера снижается до 5% от общей длины предшествующих действий. Помните, что
целью буферов является поглощение неизбежных неопределенностей запланированных

498 Глава 15
будущих событий. Чем больше буферов используется на уровнях снабжения и
проекта, тем проще осуществлять контроль за датами завершения работ. Использование
буферов при наблюдении и управлении проектом будет рассмотрено в главе 25.
Методика Голдрата отнюдь не нова, однако представленный в ней взгляд на
характерные для нашего времени проблемы открывает новый подход к построению
рабочих графиков. Согласно этому подходу, для оптимизации производительности
проекта основное внимание уделяется не ограничениям выполняемых действий, а
ресурсным ограничениям и управлению неопределенностями (размещение буферов).
К сожалению, большинство современных средств управления проектами не
учитывают неопределенности в достаточной степени. Так, метод PERT основан на
распределении вероятности своевременного выполнения каждой задачи, однако, в
больших графиках подобные вычисления очень сложны, и потому в средствах
управления проектами обычно применяется метод СРМ (фиксированная оценка задач).
Кроме того, как в методе PERT, так и в методе СРМ фактически не используются
ресурсные ограничения и управление буферами для учета неопределенностей. Только в
нескольких средствах уделяется внимание критическим цепям и управлению
буферами. Их можно найти на Web-узлах, перечисленных в конце главы 14.
Тем не менее, неопределенность в графике работ можно обрабатывать явно при
помощи включения в стратегических пунктах буферов, представленных в виде
действий. В примере, представленном на рис. 15.17, буферы были включены в конце
основных стадий работ.
0
1
2
_а_
Выбиваются буферы
неопределенности
очнчтьных действий
7
6
Собираются
е буфера* на уровне
стадии и проекта
_12_
13
14
15
16
и
16
19
О
., Название задачи -^^"чо '
е Вполненме проекта
Определение требований
Требования утверждены
V;
О \
О
Стадия Assy A
р» Проектирование Assy A
•*■ Разработка Assy A
Непредвиденные обстоятельства на данной стадии
jT Стадия Assy А завершена
Стадия Assy В
Проектирование Assy В
Разработка Assy В
Непредвиденные обстоятельства на данной стадии
Стадия Assy В завершена
Стадия объединения
Объединение Assy А и В
Проверка на соответствие требованиям
Непредвиденные обстоятельства на данной стадии
г Интеграция завершена
Непредвиденные обстоятельства проекта
Готовность поставляемого продукта

Продолжительность
34 дня
Здня
1 день
17 дней
6 дней
7 дней
4 дня
ОднеЙ
12 дней
Здня
6 дней
Здня
ОднеЙ
10 дней
7 дней
1 день
2 дня
ОднеЙ
10 дней
Одней
■■•$#ш,яъят<т
■Ьштълщш
<К '
и
и
1/25
i i I
i |
нАЖЩ-i
-ШшЛ*
-L.
ч.
mmmi-i=
ШШтЬМЁ
ti2'22
ik-b-v
fc**IUT* fc*l>
Vot
Рис. 15.17. Построение рабочего графика с помощью метода критической цепи
Завершение построения реального
рабочего графика
Подводя итог, представляем описание полного процесса построения рабочих
графиков с применением метода СРМ от концепции через определение критического
пути до финальной подгонки графика и подготовки документации.
1. Разработка структуры пооперационного перечня работ (WBS).

Формирование рабочего графика 499
а) Какие работы должны быть выполнены?
б) Кто будет выполнять каждый вид работ?
в) Какие требуются материалы и оборудование?
г) Какая стоимость выполнения каждого действия?
2. Определение взаимосвязей между действиями.
а) Что должно быть сделано в первую очередь?
б) Что будет сделано в дальнейшем?
в) Что будет выполняться параллельно?
3. Разработка сетевой диаграммы (PDM) на основании структуры WBS и
информации о взаимосвязях.
4. Анализ по методу СРМ.
а) Прямой проход для определения времени наискорейшего начала и завершения.
б) Обратный проход для определения максимально возможного срока начала
и завершения.
в) Приемлема ли общая продолжительность?
5. Определение и анализ действий, включенных в состав критического пути.
а) Можно ли сократить какие-нибудь из них?
б) Если да, то изменится ли при этом критический путь?
6. Распределение ресурсов.
а) Перераспределение ресурсов.
б) Приемлема ли общая продолжительность?
7. Преобразование сети в диаграмму Ганта .
8. Разработка ценовой базы и определение кривых затрат.
Резюме
Эта глава была посвящена вопросам построения рабочего графика проекта на
основании структуры пооперационного перечня работ, включающего
определенные зависимости. Было рассмотрено несколько различных подходов, применяемых
при конструировании рабочего графика, включая методы критического пути и
критической цепи.
Также были изучены различные способы представления рабочего графика и
несколько различных подходов к построению сетевых диаграмм. Кроме того, были
затронуты вопросы влияния на процесс проектного планирования психологии и
теории вероятности.
Контрольные вопросы
1. В чем заключаются основные сложности при использовании метода PERT?
Каковы пути их преодоления?
2. Как вы думаете, почему методы СРМ до сих пор используются в большинстве
программных средств построения графиков работ, несмотря на то, что современные

500 Глава 15
вычислительные возможности намного превосходят возможности 1950-х годов?
Как вы думаете, можно ли в этих средствах использовать так же и метод PERT или
метода СРМ вполне достаточно?
3. Как вы думаете, отличается ли методика критической цепи от той методики,
которая описана в РМВОК? Объясните ваш ответ.
4. Как вы думаете, что является лучшим средством определения
производительности проекта: буферы EVA или СРМ? Объясните ваш ответ.
Практическое занятие
Мисс Пайтель получила утвержденный вами проектный план и анализ всех задач, а
комплекс работ был утвержден доктором Чжоу. Вы чувствуете, что, несмотря на
реорганизацию, все же организационная форма была выбрана правильно. Теперь
необходимо составить завершающий график работ. Информация какого типа вам
понадобится? Мисс Пайтель приступила к завершающему этапу разработки бюджета на
следующий финансовый год и ожидает от вас точные данные о проекте ARRS.
Разработайте рабочий график для ARRS.
Литература
Kerzner Harold. Project Management A Systems Approach to Planning, Scheduling and Controlling, 6-е
издание. NY: John Wiley & Sons, Inc., 1998.
Lewis James P. Project Planning, Scheduling, and Control- A Hands-On Guide to Bringing Projects in on Time and
on Budget, переработанное издание. NY: McGraw-Hill. 1995.
Model" Joseph J., et al. Project Management with CPM, PERT, and Precedence Diagramming, 3-е издание. NY:
Van Nostrand, 1983.
O'Brien James J. Scheduling Handbook. NY: McGraw-Hill, 1969.
Paulk Mark C., et al. The Capability Maturity Model: Guidelines for Improving the Software Process. NY: Addi-
son-Weslcy, 1994.
Pressman Roger S. Software Engineering: A Practitioners Approach, 5-е издание. New York, NY: McGraw-
Hill. 2001.
Дополнительные сведения в Internet
stsc.hill.af .mill/crosstalk/1995/mar/metrics.asp. Инструментальные измерительные
средства: трудозатраты и график, Дэвид Р. Эриксон (David R. Erickson) и А. Тодд Стидман (A Todd
S(eadinan), STSC.
www.pmi.org/publictn/pmboktoc.htm. Институт PMI. Руководство Основы знаний в области
управления проектами (РМВОК® Guide), глава 6.

Формулирование
требований
За последние 20 лет все специалисты, вовлеченные в разработку ПО и управление
программными проектами, хорошо усвоили важность формирования набора
требований. Мы достаточно редко слышим истории о точно подобранном наборе технических
условий, но зато часто слышим высказывания о проблемах, связанных с недостатками
четко определенных требований. Как разработчики и менеджеры мы должны знать о
той огромной цене, которая будет заплачена в случае недостаточно хорошо
определенных или некорректных требований. Подобные ошибки приводят к значительным
затратам и приносят наибольший вред отношениям с заказчиками. Нечетко
сформулированные требования не имеют смысла, а неточные искажают смысл проекта. Если при
определении требований допустить большую неточность, то конечная система может
полностью отличаться от первоначально задуманной. Может произойти выход за рамки
условий, указанных в договоре. Даже если на первом этапе работ все будет сделано
правильно, изменчивость требований может нарушить самые лучшие планы. Необходимо
точно определить суть решаемой проблемы, даже при наличии нескольких заказчиков с
несопоставимыми требованиями. Каждый участник проекта имеет собственную точку
зрения на требования и собственный стиль обучения и общения. Если мы не будем
эффективно слушать и общаться, то "правильные" требования будут обнаружены слишком
поздно (если вообще будут обнаружены). Существуют различные методы определения
требований, хотя ни один из них не является полностью научным. Считается, что
требования закладывают основание программного продукта, поэтому имеет смысл
рассмотреть как можно больше подходов к этому наиболее проблематичному и в то же
время важному этапу процесса разработки программного продукта.
Стадии жизненного цикла
разработки продукта
На рис. 16.1 показано, что требования определяются в самом начале
жизненного цикла разработки ПО, т.е. в процессе исследования концепции, исследования

502 Глава 16
системы и анализа требований. Фактически определение требований никогда не
прекращается, поскольку большинство современных проектов проходят
повторяющийся жизненный цикл разработки до тех пор, пока не станут достаточно
качественными. Определение требований, предъявляемых к программному
продукту, можно начинать сразу же после выяснения системных требований. Затем
требования оформляются в виде официального документа под названием
"Спецификация требований к ПО" (Software Requirements Specification, SRS). После
этого требования передаются заказчику и используются как основание для
программного моделирования.
Связь главы 16 с 34 компетенциями
Определение требований является очень важным этапом в разработке продукта и
связано со многими компетенциями (рис. 16.2).
Методики разработки продукта
I. Определение продукта— идентификация клиентской среды и требований,
выдвигаемых по отношению к продукту.
2- Управление требованиями — мониторинг изменений требований.
3. Управление субподрядчиками— планирование, управление и осуществление
контроля над формулированием и выполнением требований.
4. Выполнение начальной оценки— оценка степени трудности, рисков, затрат и
формирование рабочего графика.
5. Отбор методов и инструментов — определение процессов отбора применяемых
методов и инструментальных средств.
Навыки менеджмента проектов
6. Создание структуры пооперационного перечня работ— разработка структуры
WBS для проекта.
7. Менеджмент рисков — идентификация, определение воздействия и обработка
рисков.
8. Выбор метрических показателей — выбор и использование требуемых
метрических показателей.
Навыки менеджмента персонала
9. Организация эффективных встреч — планирование и проведение
эффективных встреч.
10. Взаимодействие и общение— взаимодействие с разработчиками, высшим
руководством и другими командами.
II. Успешное ведение переговоров— разрешение конфликтов и успешное ведение
переговоров.
12. Эффективное представление— эффективное использование письменных и
устных навыков для представления проекта.

Формулирование требований 503
Исследование
концепции
•
Формулирование

потребности
Исследование
системы
' Спецификация'
интерфейса
системы
Идентификация
циклов SLC
• Циклы SLC
Выбор
модели
' Модель SLC
Установка
соответствия
между
задачами и циклами
SLC с помощью
IEEE 1074
•SLC
Распределение
ресурсов
• Бюджет
Требования
■ Спецификация
требований
к ПО
проекта
■ Описание

разработки ПО
Внедрение
• План

тации/верификации ПО
Выбор модели
жизненного цикла
разработки ПО
Установка
•Отчетов

тестации/верификации ПО
Эксплуатация
и поддержка
■
Пользовательская
документация
Сопровождение
' Документация''
по
сопровождению
Вывод из
эксплуатации
• Архивный
отчет
Рис. 16.1. Определение требований выполняется в начале зкизненного цикла разработки ПО
ПО
Программный продукт
1. Процессы оценки
2. Осведомленность
о стандартах процесса
3. Определение продукта
4. Оценка альтернативных процессов
5. Управление требованиями
6. Управление субподрядчиками
7. Выполнение начальной оценки
8. Выбор методов и средств
9. Подгонка процессов
10. Отслеживание качества продукта
11. Понимание действий по разработке
Проект
Проект
12. Разработка пооперационного
перечня работ
13. Документирование планов
14. Оценка стоимости
15. Оценка трудозатрат
16. Управление рисками
17. Отслеживание процесса разработки
18. Составление графика работ
19. Выбор метрических показателей
20. Выбор средств управления проектом
21. Отслеживание процесса
22. Отслеживание хода
выполнения проекта
Менеджмент
Персонал
23. Оценка производительности
24. Вопросы интеллектуальной
собственности
25. Проведение эффективных встреч
26. Взаимодействие и общение
27. Лидерство
28. Управление изменениями
29. Успешное ведение переговоров
30. Планирование карьерного роста
31. Эффективное представление
32. Набор персонала
33. Отбор команды
34. Создание команды
Рис. 16.2. Связь процесса определения требований с 34 компетенциями

504 Глава 16
Учебные цели главы 16
После изучения материала главы читатель должен уметь выполнять следующее:
■ описывать местоположение процесса определения требований в жизненном
цикле разработки ПО;
■ перечислять компетенции из документа SQI ВОК, необходимые для успешного
определения требований;
■ описывать процесс определения требований как в общем смысле, так и в
соответствии с моделью SEI СММ;
■ определять факторы, критичные для достижения успеха, и их применимость к
требованиям, предъявляемым к программным продуктам;
■ определять критичность точности определения требований, важных для
успешной разработки программного продукта;
■ характеризовать требования (например, примитивные, тестируемые и т.д.);
■ знать перечень типов требований, предъявляемых к программным продуктам;
■ знать несколько методов, которые используются для определения требований;
■ уметь описывать и применять такие методы определения требований, как опрос,
"мозговой штурм", составление схемы процесса мышления, FAST и JAD;
■ знать о проблемах определения требований, предъявляемых к программным
продуктам.
Основы управления требованиями
По вопросу определения требований было написано несколько прекрасных
руководств. Мы не будем пересказывать их, а просто опишем достоинства каждой из этих
книг. Джеральд Вайнберг (Gerald Weinberg) , Роджер Прессман (Roger Pressman) и
Барри Боэм (Barry Boehm)' описывают этапы процесса определения требований,
предъявляемых к программным продуктам, а также этапы подготовки их в
спецификации SRS (этот вопрос обсуждается в главе 17). Мы не претендуем на знание лучших
подходов, а просто хотим представить практическое описание и общую
информации), имеющую отношение к хорошо известным методикам.
В данной главе будут изучены этапы "Сбор" и "Анализ", описанные Вайнбергом
(рис. 16.3). Кроме того, будут рассмотрены несколько моделей высокого уровня,
которые могут пригодиться при сборе и анализе требований. Основная часть действий
по моделированию выполняется на стадиях анализа и разработки проекта (глава 22).
Этапы разработки требований согласно Прессману представлены на рис. 16.4.
В данной главе будут рассмотрены лишь процессы определения требований (пони-
Gausc Donald С и Gerald M. Weinberg. Exploring Requirements: Quality Before Design. Dorset
House. P. 95, 1989
Pressman Roger S. Software Engineering: A Practioner's Approach, 5-е издание. Boston, MA:
McGraw-Hill, 2001.
Boehm Barry и др. Developing Multimedia Applications with the Win Win Spiral Model.
Proieedings. ESEC/FSE 97 and ACM Software Engineering Notes, November. New York, NY: Association
for Computing Machinery, 1997.

Формулирование требований 505
мание того, что хочет заказчик), анализа и обсуждения (анализ потребностей и их
обсуждение для принятия приемлемого решения). Этап определения спецификации
требований рассматривается в главе 17, а этап системного моделирования — в главе 22.
Рис. 16.3. Этапы анализа требований Рис. 16.4. Этапы формулирования требований
по Вайнбергу по Прессману
Источник: Donald С. Gause и Gerald M.
Weinberg. Exploring Requirements: Quality Before Design.
NY: Dorset House, 1989.
Этапы формулирования требований:
■ определение требований — уяснение того, что хочет заказчик;
■ анализ и обсуждение требований — анализ потребностей и их обсуждение для
принятия приемлемого решения;
■ спецификация требований — спецификация однозначного решения;
■ системное моделирование;
■ аттестация требований — проверка спецификации;
■ управление требованиями.
Согласно модели Боэма (рис. 16.5), процесс определения приоритетности
требований и подготовки к составлению спецификации состоит из выяснения
выигрышных условий, обсуждения, а также достижения взаимного согласия и компромиссов.
Требования определяют структуру программной системы. Они используются при
проектировании системы, так как определяют ее назначение и внешнее поведение.
Процесс формулирования требований считается одним из самых важных при
построении программной системы и содержит все работы, связанные с требованиями.
Этот процесс состоит из четырех этапов: определение, анализ, спецификация и
аттестация требований.

506 Глава 16
Рис 16.5. Этапы формулирования требований по Боэму
Источник: Barry W. Boehm и др. Software Requirements as Negotiated Win Conditions.
Proceedings oflCRE, pp. 74-83, 1994.
Управление требованиями и модель SEI CMM
Управление требованиями — это ключевая область процесса (key process area,
КРА) для второго уровня модели SEI CMM (повторяемый уровень). Цель
применяемого в этом случае процесса — "установить общее понимание между заказчиком и
программным проектом на основании требований заказчика, предъявляемых к
программному проекту" . В роли заказчика может выступать организатор или внешний
пользователь (например, группа системного проектирования, группа исследования
рынка или какое-либо другое внутреннее подразделение). С точки зрения СММ дан-
пая область КРА является областью управления уже собранными системными требо-
1 Paulk Mark С, Charles V. Weber, Bill Curtis и Mary Beth Chrissis. The Capability Maturity Model:
Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley SEI Series in Software
Engineering. P. 126, 1994.

Формулирование требований 507
ваниями, которые предъявляются отдельно к аппаратному и отдельно к ПО. Часто
эти требования, предъявляемые к ПО, являются только "схемой", и в дальнейшем
будут дополняться заказчиком.
Ниже перечислены цели, выдвигаемые при управлении требованиями области
КРА, а также соответствующие им действия.
Цели
Цель 1. Системные требования используются для формирования базовой линии
при проектировании программного продукта, а также для управления.
Цель 2. Программные планы, продукты и производственные этапы должны быть
совместимы с системными требованиями, предъявляемыми к программному продукту.
Выполняемые действия
Действие 1: Группа по разработке ПО рассматривает требования до того, как они
будут реализованы в проекте.
1. Определяются неполные и неверные требования.
2. Предъявленные требования рассматриваются относительно:
- их реальности и пригодности для реализации в программном продукте;
- четкости и корректности формулировок;
- взаимной совместимости;
- возможности тестирования.
3. Предполагается, что все предъявляемые требования имеют потенциальные
ошибки, а потому производится их изучение совместно с группой аналитиков. В
случае необходимости вносятся коррективы. При анализе также учитываются и
системные требования.
4. Выводы относительно предъявляемых требований обсуждаются со всеми
задействованными группами.
Действие 2. Группа по разработке ПО использует предъявляемые требования в
качестве основы для планов, рабочих продуктов и производственных этапов.
Действие 3. Изменения, внесенные в предъявляемые требования, сначала
рассматриваются, а затем вносятся в программный проект.
Критические факторы успеха
Требования часто представляют в виде набора критических факторов успеха
(Critical success factors, CSF) программного продукта. Эти факторы определяют:
■ то ограниченное количество областей, где "все должно быть правильно";
■ те административные или производственные области, которым постоянно
уделяется особое внимание для обеспечения высокой производительности;
■ предположительную ценность проекта;
■ события и обстоятельства, которым менеджеры уделяют особое внимание;
■ те области, в которых обязательно требуется успех, чтобы каждый основной
участник проекта имел больше всего шансов для успешного достижения целей;
■ достижение высокого качества.

508 Глава 16
Следует отметить, что всегда существует соблазн разработать факторы CSF с
упрощенными характеристиками типа "найти решение определенной проблемы".
Однако не следует поддаваться подобному соблазну, поскольку при подобном
определении задачи возникает слишком много неопределенности. Для того чтобы составить
спецификацию и начать моделирование, необходимо определить специфичные
требования, на основании которых завершенный проект будет удовлетворять
пользователей и разработчиков.
Когда факторы CSF явно определены в виде критических требований, их можно
протестировать и измерить, а также использовать при анализе изменений в объемах
работ. Конечно же, аналитик не может игнорировать все остальные требования,
однако основное внимание уделяется все-таки тем требованиям, которые на этапе сбора
информации о требованиях были определены как самые важные и критические.
Факторы CSF наиболее эффективны при работе со средствами быстрого прототипирова-
ния (rapid prototyping), средствами быстрой разработки приложений (RAD) и
спиральными моделями, которые используются в быстро изменяющейся среде
жизненных циклов разработки ПО.
Следует также отметить, что факторы CSF напрямую связаны с целями и задачами,
определенными в стратегических и бизнес-планах. Каждому фактору, критичному
относительно успеха, соответствует ключевой показатель, обеспечивающий
возможность измерения и разработки стандарта производительности или возможность
отклонения от запланированной производительности. Для программных проектов
факторы CSF обычно представляются в виде отметок этапов или других ключевых
показателей, позволяющих определить производительность. На этом мы
остановимся в рассмотрении вопроса о факторах CSF программного продукта и в дальнейшем
просто будем помнить о том, что одни требования могут быть важнее других. В
дальнейшем факторы CSF будут использоваться для упрощения идентификации
требований. Это очень удобно в тех случаях, когда некоторые функции при определении
приоритетности вычеркиваются из планов или откладываются.
Определение требований к ПО
Требование к ПО — это возможность, которую кто-либо ожидает от данного ПО. Это
может быть один компонент из нового приложения, новая функция уже существующего
приложения (модернизация) или запрос на исправление текущего недостатка.
В стандарте IEEE требование определено как (а) условие или возможность,
необходимая пользователю для решения проблемы или достижения цели; (б) условие или
возможность, которой должна обладать система или компонент системы, соответст-
нхющие договору, стандарту, спецификации или другому официальному документу;
(в) документированное представление условия или возможности подобно
описанному в определениях (а) и (б)'.
Типы требований к ПО
Требование может быть осознанным (известным, высказанным) или
неосознанным (забытым, невысказанным). Осознанное требование иногда выдвигается самим
разработчиком проекта, а неосознанное упускается по той причине, что на данный
IEEE. 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. Software
ingntmnig Standards Collection. NY: Institute of Electrical and Electronics Engineers, 1990.

i
i
I
I Формулирование требований 509
момент оно не требуется или неизвестно данному разработчику. Кроме того,
неосознанное требование может удовлетворяться каким-либо уже существующим
процессом. Ваинберг и другие специалисты предполагают также наличие невообразимых
требований (неизвестных, невысказанных). Это такие требования, о наличии
которых организатор даже и не предполагает.
Осознанные, забытые и неизвестные требования могут быть функциональными
или нефункциональными. Функциональные требования определяют, что должен
выполнять программный продукт. Они основаны на специфических источниках, часто
используются в бизнес-правилах и имеют еще одно распространенное название —
"свойства продукта".
Нефункциональные требования, как правило, имеют отношение к качеству и
оговаривают то, насколько программный продукт правильно делает то, что он должен
делать. Нефункциональные требования, важные для пользователей, включают
спецификации требуемой производительности, работоспособности, надежности,
простоты использования и гибкости. Нефункциональные требования, важные для
разработчиков и обслуживающего персонала, включают в себя спецификации требуемой
способности к конфигурированию и интегрируемости программной системы, а также
удобство сопровождения, переносимости и тестирования. В качестве
нефункциональных требований могут также выступать неявные требования к изменчивости,
возможности повторного использования и способности к взаимодействию.
Некоторые функциональные и нефункциональные требования не могут быть
удовлетворены при помощи одного системного компонента (или даже небольшого
набора системных компонентов), поскольку зависят от остальных частей системы.
Такие требования рассматриваются в масштабе всей системы совместно со всем
набором требований, предъявляемых к качеству программного продукта.
Некоторые требования являются архитектурными. К ним, например, относится
совместимость названий компонентов и интерфейсов, а также возможность
расширения и наращивания систем.
Также могут быть ограничивающие требования. К ним относятся ограничения
при проектировании систем, соответствие стандартов, а также юридические и
организационные вопросы. Ограничения могут поступать как от пользователей, так и от
организаций, и могут быть как функциональными, так и нефункциональными.
Определение "хорошего" требования к ПО
В главе 17 описывается преобразование требований к ПО в программные
спецификации. В данной главе, посвященной определению требований, нас
интересует не столько формат требований, сколько процесс их формирования. В данном
случае акцент делятся на определении производственных этапов, необходимых для
удовлетворения всех требований, поступивших от всех организаторов. На этапе
сбора требований могут применяться одновременно несколько точек зрения, которые
определяют, как должны выглядеть спецификации программного продукта.
Никогда не помешает поразмыслить о будущем и немного упростить выполнение
следующего этапа.
Существует несколько атрибутов качества, которые должны использоваться в
требованиях. В главе 30 эти атрибуты, впервые предложенные Мак Коллом (McCall) в
1970-х годах, позволяют отличить просто "хорошие" требования от первоклассных.
Вайгерс (Weigers) указывал на существование характеристик, которые должны быть

510 Глава 16
присущи каждому требованию в отдельности, и желательных характеристик для всего
SRS-документа в целом . Наша цель — достижение обоих типов. Согласно Боэму,
одним из самых лучших показателей "качества" требования является его тестируемость.
Если можно создать средство для тестирования требования, то оно определено
однозначно и может быть измерено. При этом самым важным фактором является
возможность определения того момента, когда требование будет удовлетворено.
При сборе информации о требованиях к ПО учитываются следующие атрибуты,
позволяющие достичь запланированного уровня качества.
■ Корректность — может быть подтверждена только заказчиком или пользователем.
■ Пригодность— требует знания среды на стороне разработчика. При этом для
удовлетворения окончательно сформулированных требований должны быть в
наличии соответствующие средства, методы, человеческие ресурсы и бюджетные
средства.
■ Необходимость — необходимый уровень качества может быть определен во время
обсуждения между разработчиками и организаторами. В программном продукте
можно реализовать множество различных возможностей, но при разработке и
реализации первой версии программного продукта достаточно использовать
только самые необходимые требования.
■ Приоритетность — может быть определена как разработчиками, так и
организаторами совместного дела во время проведения интервью или сеанса выработки
требований. В конце данной главы будет рассмотрена идея Фон Майерхаузера (von
Mayerhauser) о четырех уровнях приоритетности: очень важный; абсолютно
необходимый для реализации в следующей версии; важный, но не обязательный для
реализации в следующей версии (условный); и необязательный (реализация
зависит от наличных ресурсов и рабочего графика) .
■ Однозначность — согласно стандарту IEEE определяется наличие только одной
интерпретации. Определяет простоту чтения и понимания.
■ Лаконичность — содержание в требовании только той информации, которая
необходима для выполнения текущего этапа разработки. Связанная с требованием
информация об истории, стоимости и рабочем графике размещается отдельно.
■ Возможность проверки (тестируемость, измеримость) — говорит о том, что
соответствие программного продукта требованию может быть проверено человеком
или компьютером.
В дополнение к признакам отдельного требования, можно рассмотреть признаки
всей спецификации SRS в целом.
■ Завершенность— определяется после обзора, проведенного организатором
проекта, и говорит о том, что учтены все важные требования (функциональные
свойства, производительность, внешние факторы и т.д.).
■ Соответствие — определяется разработчиками при сопоставлении с внутренними
документами.
■ Изменяемость — изменение требований является вполне логичным процессом.
'* Wegers, Karl E. A999). Software Requirements. Redmond, WA: Microsoft Press.
' Von Mayrhauser, Annelise. Software Engineering: Methods and Management. Boston, MA: Academic
Press, 1990

Формулирование требований 511
■ Трассируемость — определяется совместно организатором проекта и
разработчиком и говорит о том, что требование может явно указывать на свой источник в
составленном ранее документе (например, документе, полученном в процессе
совместного проектирования приложения (Joint Application Design, JAD). Кроме
того, требование должно прослеживаться в будущем в SRS, а затем — на этапе
разработки проекта и создания программного кода.
Гоз (Gause) и Вайнберг упоминают о важности ясности изложения требований.
Они приводят известный пример того, как простое на первый взгляд утверждение
приобретает несколько различных интерпретаций. Рассмотрим известное детское
стихотворение.
У Мэри одна овечка была.
Ее шерсть была как снег бела.
И куда бы Мэри ни шла,
Овечка следом за нею брела.
При расстановке акцентов на разных словах меняется смысл фразы.
Акцент на словах "у Мэри" говорит о том, что овечка была именно у Мэри, а не у
Тома, Дика или Гарри.
Акцент на слове "одна" обращает особое внимание на то, что у Мэри была только
одна овечка, а не целое стадо.
Акцепт на слове "овечка" наводит на вопрос о том, почему у Мэри не было
какого-нибудь другого домашнего животного, например, собаки, кота, коровы, козы или
попугая.
Акцент на слове "была" наталкивает на мысль о том, что у Мэри в данный момент
уже пет овечки.
Примем для слова "была" определение "обман"; для слова "овечка" — "человек,
которого можно легко обмануть, особенно в вопросах коммерции"; для слова "шерсть" —
"отнять деньги или имущество, полученное в результате обмана или вымогательства" ;
а для слова "снег" — "жаргонное выражение, означающее обман, принуждение или
многоречивое убеждение"". На основании этих определений Гоз и Вайнберг
представили рассмотренное выше стихотворение в следующем виде.
... Красноречивая мошенница по имени Мэри обманула маленького,
беспомощного, доверчивого торговца акциями, присвоив себе все его имущество в результате лжи
и вымогательства. Теперь становится понятным, почему "куда бы Мэри ни шла,
овечка следом за нею брела".
Что же еще оставалось делать бедной овечке после того, как ее остригли?
Таким образом, это стихотворение является пародией на современный мир бизнеса...
Это всего лишь наивное стихотворение о невинной девочке, у которой есть
верный домашний любимец. Однако в реальной жизни все бывает гораздо серьезней,
когда серьезные взрослые дяди и тети выбрасывают несколько строк из документа с
перечнем требований, а затем начинают разрабатывать программный продукт на
основании единственной неверной интерпретации.
www. т-ги. com/cgi-bin/'dictionary.
www.ycurdictionary.com/cgi-bin/mw.cgi.
"См. сноску 1.

512 Глава 16 I
Методы определения требований
Теперь нам предстоит рассмотреть интервью, "мозговой штурм" (brainstorming),
схемы мышления (mind mapping), метод упрощенной спецификации приложения
(Facilitated Application Specification Technique, FAST) и совместную разработку
приложений (Joint Application Design, JAD), кроме того, мы определим требования
к ПО при помощи сценариев выбора (case scenario). Приведем несколько общих
положений.
■ В процессе сбора требований должны принимать участие фактические
пользователи, а не посторонние люди.
■ Все организаторы проекта должны быть идентифицированы, при этом в процессе
сбора требований должны принимать участие представители каждого типа.
■ Неоднозначные требования должны быть идентифицированы для выполнения
прототипирования.
■ Заказчики и спонсоры необязательно применяют разрабатываемое приложение,
однако, работу по сбору требований и разработке конечной системы оплачивают
именно они.
■ До этапов разработки необходимо идентифицировать ограничения предметной
области, что отразится на ограничении функциональных свойств и
производительности системы или программного продукта.
■ Каждый организатор проекта несколько необъективен, особенно при оценке
степени пользы для своей организации.
■ Группы сосредоточения не входят в методологию, поскольку их члены не
принимают участие в принятии решений.
■ Если разрабатывается только программный продукт, то должна быть
определена техническая среда, в которой будет эксплуатироваться этот продукт
(например, архитектура компьютеров, операционная система, средства
телекоммуникации).
■ Если разрабатывается целая система (программная и аппаратная часть), то
системные требования должны быть определены до уровня требований к ПО.
■ Входные данные для методов определения требований включают определение
понятий, деловые цели высокого уровня, определение потребностей и
пригодности, определение объема работ и проектный план.
■ Выходные данные для методов определения требований включают
сформированный согласно приоритетам и функциям перечень требований, ограничения
предметной области, набор сценариев выбора и прототипы.
■ Для каждого требования должно указываться обоснование.
■ Сценарии выбора и схемы мышления могут использоваться в отдельности или как
вложенные методы при интервью, "мозговом штурме", FAST или JAD.
■ Методы определения требований применяются только при наличии всех
необходимых участников.
Теперь рассмотрим некоторые из перечисленных ранее методов.

Формулирование требований 513
Интервью
При сборе требований почти всегда используется опрос. Даже если применяется
метод "мозгового штурма", составления схемы мышления, FAST или JAD, то при
исследовании концепции обычно требуется более высокая степень детализации, для
чего опрашиваются хотя бы некоторые из организаторов.
В прошлом для сбора информации о требованиях аналитики просто собирали
представителей организаторов проекта и проводили с ними беседу. К сожалению, при
использовании только такого метода остается достаточно много невыявленных
требований. Для выяснения всех возможных мнений и пожеланий очень сложно встретиться
лицом к лицу с достаточным количеством организаторов проекта, так как в условиях
глобального экономического пространства они разбросаны по всему миру. Тем не
менее, опрос очень полезен на первом этапе для получения общего описания требований
к ПО. Считается, что 50 % всей основной информации поступает именно от людей.
Мы рекомендуем прочитать несколько книг, посвященных исключительно
проведению интервью. В качестве примера такой книги можно назвать "Basic Interviewing
Techniques" ("Основные методы проведения интервью") Бруно Ванассе (Bruno Va-
nasse). Можно также ознакомиться со статьями по вопросу сбора требований к ПО
(например, статьей Гоза и Вайнберга "Исследование требований: качество до
проектирования"). В данной главе будут рассмотрены только несколько самых важных основных
этапов проведения интервью.
Этапы проведения интервью
Процесс проведения интервью состоит из следующих этапов: разработка
вопросов, выбор опрашиваемых пользователей, планирование контактов,
непосредственное проведение интервью, завершение встречи, определение последующих действий.
Разработка вопросов
Интервью начинается с одного или нескольких вопросов, позволяющих наилучшим
образом выяснить истинные требования (то есть, те, которые действительно нужны, а
не те, которые желательны или нужны исходя лишь из предположений). Для создания
шаблона вопросов можно использовать некоторые показатели из исходного запроса на
обслуживание, из документации по исследованию концепции, а также на основе плана
управления программным проектом (Software project management plan, SPMP).
Выбор участников интервью
Целесообразнее опрашивать организаторов проекта, поскольку они всегда
предоставляют самую важную и ценную информацию. Лично всех орагнизаторов,
скорее всего, опросить будет невозможно, поэтому выбираются их представители.
Они должны хорошо знать предметную область, быть легкими в общении и уметь
давать ясные и достоверные ответы на поставленные вопросы.
Рассмотрим несколько групп, составляющих иерархию участников интервью.
Персонал начального уровня — не имеет большого опыта работы, поэтому не
может предоставить много информации. Тем не менее, этих людей также следует
опрашивать, поскольку им присущ свежий взгляд. Кроме того, на этом уровне можно
неожиданно получить очень ценную информацию.
Организаторы проекта среднего уровня — учитывая опыт работы, организаторы этого
уровня хорошо знакомы с рабочей и технической сторонами предметной области и
потому могут дать ее подробное описание. Всегда опрашивайте менеджеров проекта.

514 Глава 16
Менеджеры и другие заказчики особого рода— генеральные директоры и вице-
президенты, которые хорошо знают предметную область и предназначение проекта,
составляют отдельную группу опрашиваемых организаторов. Если есть такая
возможность, всегда опрашивайте генерального спонсора.
Научные сотрудники — если среди них есть организаторы проекта, то они помогут
взглянуть на все с другой точки зрения.
Обычные пользователи системы — эта группа, может быть, самая важная, так как
пользователи проводят больше времени во взаимодействии с системой, чем кто-либо
еще. Они могут иметь революционный способ мышления. Это хорошо, однако, не
следует забывать и о возможной предвзятости к уже существующим системам.
"Восходящие звезды" — если они присутствуют в организации, заказавшей
программный продукт, то мнение этих будущих лидеров будет очень ценным и
современным.
Чем больше категорий людей будет опрошено, тем более надежной будет
собранная информация.
Планирование контактов
Если позволяет время, узнайте немного о том человеке, с которым нужно
побеседовать, и о его взгляде на данный проект. В чем заключается его вклад как
организатора проекта? Все люди заняты, поэтому ограничьте интервью только тем, чтобы
узнать, что опрашиваемый ожидает от разрабатываемого программного продукта.
Точки зрения остальных организаторов проекта можно будет узнать в процессе
"мозгового штурма" или опросов по методам FAST или JAD.
Первый контакт часто происходит по телефону или по электронной почте.
Представим некоторые советы на этот случай:
■ большинство людей более склонны к интервью во вторник, среду или четверг, так
как в эти дни они, скорее всего, наименее загружены работой;
■ во время телефонного разговора не забывайте о вежливой интонации;
■ представляйтесь четко;
■ объясните цель звонка или электронного сообщения;
■ объясните, каким образом данный организатор проекта попал в перечень
участников интервью;
■ подчеркните, что он является именно тем человеком, который может дать
правильные ответы, и что вопросы будут сугубо официальными;
■ укажите предположительную продолжительность интервью;
■ если необходимо и есть такая возможность, предложите компенсировать какую-то
часть расходов на поездку и затраченное время;
■ назначьте время и место для встречи или время следующего контакта;
■ определите способ обмена информацией и механизм обратной связи;
■ попросите разрешение на изучение материалов, иллюстрирующих способ ведения
данным организатором проекта своего бизнеса;
■ мотивируйте важность личной встречи;
■ если с назначением встречи возникают проблемы, оставьте свой контактный
телефонный номер на тот случай, если кандидат передумает.

Формулирование требований 515
Непосредственное проведение интервью
Интервью можно провести по телефону, персонально или с помощью Internet
(видеоконференция, чат, электронная почта), однако лучшим способом осуществления
интервью является непосредственное общение, "лицом к лицу". Самым важным
фактором для получения информации при опросе является правильно "сформированная"
атмосфера, которая обеспечивает одновременно комфорт и конфиденциальность.
1. Создайте нужную атмосферу. Если будет установлена атмосфера доверия и
взаимопонимания, то это позволит задавать как общие, так и более глубокие
вопросы. Для создания такой атмосферы:
- спросите разрешение на ведение записей в процессе проведения интервью;
- демонстрируйте искренний интерес относительно вклада данного человека в
дело разработки ПО;
- слушайте, это самая лучшая мотивация для опрашиваемого — полное внимание
опрашивающего;
- начинайте с незначительных вещей, а затем переходите к более сложным
вопросам;
- будьте откровенны и честны;
- будьте сдержанны, никто не хочет разговаривать с тем, кто "все знает";
- придерживайтесь темы разговора, кроме тех случаев, когда необходимо
рассмотреть общие представления, необходимые для лучшего понимания сути
требований;
- попросите взглянуть на ту среду, в которой будет применяться данный
программный продукт;
- предложите помощь в составлении отчета о проекте, дайте понять, что обмен
информацией является двунаправленным.
2. Задавайте вопросы. Вопросы должны быть простыми, краткими и состоять
только из одной части. Два или три вопроса, заданные одновременно, могут
привести к сложным формулировкам требований, что осложнит их
интерпретацию и тестирование.
Используйте сопоставления. Пример: "В каком диапазоне находится доход
компании ABC от продажи компонентов: от 15 до 30 миллионов долларов, или от 30
до 60 миллионов долларов?".
Импровизируйте. Вопросы, без сомнения, необходимо подготовить заранее,
однако не нужно читать их, не отрываясь от листка. Они должны выполнять
просто роль плана, который используется для направления хода беседы.
Слушайте собеседника и переводите разговор в то направление, которое наиболее
соответствует заготовленным вопросам. Некоторые опрашиваемые могут быть
экспертами в своей области. В этом случае будет полезно задавать вопросы типа
"для чего?" и "что будет, если?", так как это позволит получить дополнительную
важную информацию.
Задавайте вопросы, не имеющие непосредственное отношение к бизнесу,
процессу или программному продукту. Гоз и Вайнберг приводят возможный перечень
таких вопросов.
- Может ли эта система причинять какие-либо проблемы?

516 Глава 16
- Существует ли необходимость решения тех проблем, которые могут не быть
очевидными?
- Какую вы бы хотели видеть степень детализации?
- Опишите среду, в которой будет функционировать система.
- Каким образом данная система изменит характер вашей работы?
- Каким образом данная система повысит эффективность Вашей работы?
- Есть ли какие-либо данные или функции, общие для различных подразделений
в вашей организации?
- Может ли кто-то еще решить поставленную задачу?
- Какие существующие проблемы может решить данная система?
- Какие данные, необходимые вам, находятся в других системах?
- Какую новую информацию будет предоставлять новая система?
- Какова бизнес-цель для данной системы является самой важной?
- Каковы требования к производительности (и есть ли они вообще)?
- Какие проблемы должна решать эта система?
- Какие программные пакеты используются в настоящее время?
- Что будет делать новая система (функциональные свойства) из того, что в
данный момент недостижимо при помощи существующих ручных или
автоматизированных систем?
- Кто является пользователем данного продукта?
3. Если опрос зашел в тупик...
Возможно, опрашиваемый не обладает интересующей информацией или не имеет
доступа к ней. В этом случае поблагодарите за потраченное время и создайте
хорошее впечатление о своем визите, оставив контактный телефонный номер на
тот случай, если у этого человека появится какая-нибудь новая информация.
Бывает так, что опрашиваемый не имеет желания предоставлять информацию.
В этом случае для преодоления возникшего препятствия можно особо
подчеркнуть высокую компетентность этого человека и то положительное влияние,
которое он может оказать на конечную систему.
Иногда, для того чтобы направить интервью в другое русло, необходимо задать
конкретные вопросы, предоставив примеры возможных ответов. Также можно
использовать вопросы, для ответа на которые требуется провести анализ.
Завершение встречи
Не забывайте постоянно мотивировать опрашиваемого, так как в будущем,
возможно, опять понадобится его помощь. Кроме того, если у этого человека останется
хорошее впечатление от проведенной беседы, то в дальнейшем он может
предоставлять новую информацию уже по собственной инициативе. Используйте следующие
рекомендации:
■ спросите, есть ли у опрашиваемого какие-нибудь вопросы к вам;
■ спросите, существуют ли вопросы, которые еще не были рассмотрены;
■ предложите тему для еще одной беседы в будущем;

Формулирование требований 517
■ предложите предоставить в дальнейшем документы с описанием требований и
спецификации требований к ПО (SRS);
■ укажите способ связи на тот случай, если появится какая-либо дополнительная
информация;
■ запросите о возможности связи с опрашиваемым на тот случай, если понадобится
рассмотреть еще какой-либо вопрос;
■ спросите, есть ли кто-либо еще, кого можно опросить по данному вопросу,
■ спросите, существует ли какой-либо материал по данному вопросу в бумажном или
электронном виде, которым можно было бы воспользоваться;
■ задайте несколько вопросов об эффективности процесса.
Определите, что делать дальше, и сделайте следующее:
■ свяжитесь с тем, кого вы опрашивали, и поблагодарите его;
■ зафиксируйте информацию, полученную в результате опроса;
■ подготовьте исходные данные для следующего этапа определения требований —
"мозгового штурма", FAST, JAD — или перейдите непосредственно к составлению
спецификации требований.
Сеансы "мозгового штурма"
Ни одна идея не может быть настолько нелепой, чтобы она не могла быть
рассмотрена пристальным и в то же время непоколебимым взглядом.
Уинстон Черчилль.
"Мозговой штурм"- это метод проведения собраний, при котором группа людей
пытается найти решение специфической проблемы посредством накопления всех
спонтанно возникающих идей.
Проще обработать совершенно "дикую" идею, чем придумать новую.
Алекс Осборн.
Концепция "мозгового штурма" описана во множестве книг и статей. В данной
главе мы просто обобщим некоторые роли и правила "мозгового штурма"
применительно к определению требований, предъявляемых к программным проектам.
"Профессиональные" сборщики требований могут изучить книги по этому вопросу в
оригинале, попрактиковаться с каким-нибудь другим специалистом в этой сфере, а
затем приобрести специализированные обучающие программные средства. В то же
время, кому-то будет достаточно той информации, которая содержится в данной
главе. Важным моментом в процессе определения требований является то, что
"мозговой штурм" является прекрасным основанием для сеансов JAD и использования
сценариев выбора, что описано в этой главе несколько позже.
По существу, при "мозговом штурме" для решения проблем используется
групповой эффект. Он заключается в быстром генерировании идей без каких-либо оценок и
преобразований, при этом некоторые идеи могут выглядеть "дикими", "безумными"
или просто непрактичными. В дальнейшем каждая сгенерированная идея
оценивается, и те из них, которые заслуживают внимания, развиваются далее.

518 Глава 16
Определение "мозгового штурма"
"Мозговой штурм" — это групповой метод, который используется в процессе сбора
требований для выявления творческих идей. Он облегчает определение "проблемы",
которая должна быть решена в течение последующего жизненного цикла. Сюда
иходит написание спецификаций требований к ПО, анализ и моделирование
требований, а также проектирование программного продукта.
Метод "мозгового штурма" используется во многих бизнес-приложениях как
способ быстрого генерирования новых идей. В данном конкретном случае мы пытаемся
удовлетворить запросы организаторов проекта для того, чтобы избежать
неожиданных сюрпризов позднее при разработке проекта. Чем больше требований будет
представлено, тем лучше. Возможно, не все из них будут реализованы в первой версии
продукта (или вообще не будут реализованы), но зато они будут зафиксированы. Если
новому поколению пользователей потребуется какая-нибудь функция, которую ранее
отложили пли удалили, то будет сэкономлено время и силы, которые ушли бы на
новые интервью, "мозговые штурмы" и составление документов FAST и JAD. В этом
случае идея уже будет зафиксированной, но не реализованной.
"Мозговой штурм" приводит к генерированию множества идей, хотя и не все
из них будут использованы. Согласно теории, лучше иметь длинный список
требований, из которого можно что-то выбрать, чем начинать с "чистого листа".
Элементы длинного списка можно разбивать по категориям и приоритетам, а также
выбрасывать.
Центральная концепция "мозгового штурма" была сформулирована Алексом Ос-
борном (Alex Osborn) . В 1941 году, являясь руководителем рекламного агентства, он
искал способ стимулирования новых идей вместо того, чтобы сдерживать их развитие
па обычных собраниях. Он посоветовал группам работников "придумывать" идеи в
групповом процессе, когда никакая идея не отвергается и не критикуется. Таким
образом быстро возникает большое количество идей, даже несмотря на то, что
некоторые из них являются "дикими" и преувеличенными. Теория Осборна звучит
следующим образом: чем больше оригинальных идей, тем больше полезных идей. Сам по
себе человек редко может придумать такое же количество творческих идей, как при
"мозговом штурме" даже в составе небольшой группы.
Осборн обнаружил, что при уменьшении степени подавления люди намного
охотнее высказывают полезные идеи, которые при других условиях им показались бы
незначительными. Фактически, иногда бывает так, что самые "авангардные" и странные
идеи, приводят к возникновению совершенно новых подходов.
Введение этой оригинальной методики произвела настоящую "революцию", и
теперь метод "мозгового штурма" используются почти во всех крупнейших компаниях
мира, став синонимом "творческого мышления" в большинстве толковых словарей.
Во время сеанса "мозгового штурма" люди свободны от ограничений,
накладываемых на высказывание мнения, что позволяет сгенерировать максимально возможное
количество идей. В результате на поверхность выходят по-настоящему оригинальные
замыслы. Все участники такого сеанса могут высказывать любые идеи, которые
приходят им в голову, независимо от того, значительные они или нет. Ни одна идея не
подвергается критике, даже если она выглядит ужасно глупой, так как в обязанности
каждого участника входит не исследование точек зрения, а их генерирование.
Osborn Alex F. Ар/ЛШ Imagination. Buffalo, NY: Creative Education Foundation, 1983.

Формулирование требований 519
Согласно словарям, во время "мозгового штурма" люди могут переживать
внезапное вдохновение; получать интересные идеи; испытывать сильный взрыв эмоций,
причиной которого часто становится резкое повышение умственной активности, а
также внезапные психические расстройства. Различные современные авторы
характеризуют "мозговой штурм" как:
■ часть процесса принятия решения, во время которой создаются новые идеи по-
средством подавления критических суждений;
ш метод, позволяющий максимально увеличить способности человека по
генерированию новых идей;
■ процесс генерирования большого количества идей, независимо от их начального
достоинства;
■ метод, разработанный специально для получения максимально возможного
количества идей, имеющих отношение к специфической сфере деятельности;
■ создание такого состояния мышления, которое оптимально подходит для
генерирования новых идей;
■ процесс свободного обмена различными идеями для формирования новых идей
или концепций;
■ процесс, во время которого группа людей может отбросить ограничения и
правила, накладываемые на высказывание мнений, для генерирования новых идей и
решений.
Теперь давайте рассмотрим некоторые "правила" проведения сеансов "мозгового
штурма".
Роли во время сеансов "мозгового штурма"
Каждый участник сеанса "мозгового штурма" исполняет одну из трех ролей: лидер,
секретарь, им член команды.
Лидер
Лидера также еще называют арбитром или председателем. Являясь хорошим
слушателем, лидер отвечает за направление процесса "мозгового штурма" в правильное
русло. В его обязанности входит ободрение участников, обеспечение
индивидуального и группового порядка, а также помощь секретарю в записи идей. Лидер следует
объявленному распорядку и начитает процесс генерирования идей сначала в том
случае, если что-то не получается. Лидер должен принимать не только те идеи, которые
громко выкрикиваются, но и те, которые записываются участниками на бумаге.
Секретарь
Секретарь записывает все идеи таким образом, чтобы каждый человек,
находящийся в комнате, мог видеть эти записи. Для этого можно использовать
лекционные плакаты и маркеры, белые доски или проекторы. Также можно использовать
проецирование информации с экрана компьютера. В случае использования
лекционных плакатов отрывайте каждый заполненный лист и прикрепляйте его на стену
так, чтобы каждый мог его видеть. В малых группах обязанности секретаря может
выполнять лидер, однако направлять собрание и одновременно правильно
записывать все идеи достаточно сложно. В больших группах может понадобиться два или
три секретаря.

520 Глава 16
Участники
При разработке ПО обычно выступают несколько организаторов проекта,
имеющих различные точки зрения. Сеанс "мозгового штурма"— это прекрасная
возможность научиться соглашаться с точкой зрения другого человека. Различия во мнениях
способствуют творческому формированию оригинальных идей. Существует
опасность того, что участники начнут доказывать правильность своей точки зрения для
успеха проекта. Размер групп может колебаться от четырех до тридцати человек,
однако опытные лидеры рекомендуют формировать группы от пяти до десяти человек
(идеальный размер— шесть или семь человек). Многие люди охотно пользуются
возможностью высказать различные мнения, однако, это может привести их к нервному
срыву в том случае, если они не смогут выразить все идеи. Главная ответственность
участников заключается в генерировании идей и мнений (в данном случае —
требований), а также в стимулировании к высказыванию своих мыслей других людей.
Правила проведения сеансов "мозгового штурма"
В книгах правила проведения сеансов "мозгового штурма" описываются по-
разному. При этом часто одни описания пересекаются с другими. Мы решили
сэкономить время читателей и объединить правила, взятые из различных изданий, в один
всеобъемлющий список.
Правила для лидеров
■ Идеи должны высказываться устно (предпочтительно) или в виде записок.
■ В случае необходимости допускайте молчание.
■ Получите как можно больше идей от всех участников. При этом до окончания
генерирования идей не должно быть никакой критики или осуждения.
■ Объявите участникам основные правила сеанса.
■ Не допускайте критики, обсуждений и споров.
■ Не позволяйте высказывать серьезные или иронические комментарии.
■ Поощряйте "дикие" или нелепые идеи.
■ Определите цель или тему.
■ Большую часть времени поддерживайте высокий темп с целью уменьшения
задержек и вероятности проведения оценок.
■ Помогайте участникам изменять и комбинировать идеи.
■ Помогайте участникам генерировать идеи.
■ Установите ограничения по времени.
■ Используйте все отведенное время.
Правила для секретарей
■ Не описывайте идеи подробно, а лишь кратко указывайте их суть.
■ Если необходимо, попросите о коротком пояснении.
■ Используйте собственные слова того, кто высказывает идею.
■ Записывайте каждую идею в виде нескольких слов или коротких фраз.
■ Записывайте идеи таким образом, чтобы все участники могли их видеть.

Формулирование требований 521
Правила для участников
■ Дополняйте и расширяйте идеи других участников.
■ Полностью погрузитесь в процесс генерирования идей и мыслите свободно.
■ Рассматривайте все с различных точек зрения.
■ Проявляйте творческий подход.
■ Будьте открыты для новых оригинальных идей.
■ Будьте терпеливы в молчании.
■ Не бойтесь рисковать.
■ Высказывайте только одну идею за раз.
■ Придумывайте усовершенствования и вариации записанных идей.
■ Не отвлекайтесь на объяснения.
■ Не оценивайте идеи других, не критикуйте и не осуждайте.
■ Не используйте жестов, которые могут быть истолкованы как критика или осуждение.
■ Не прерывайте других докладчиков.
■ Не уделяйте слишком большого внимания только одной идее.
■ Генерируйте столько идей, сколько возможно за короткий промежуток времени.
Сейчас главное — количество. Качество будет исследовано потом.
■ Высказывайте каждую идею кратко.
■ Подключайте воображение.
■ Размышлять будете после.
■ Высказывайте идеи по очереди.
■ Думайте быстро.
■ Записывайте свои идеи и передавайте их секретарю.
Общие правила проведения сеансов "мозгового штурма"
■ Принимаются любые идеи. Такого понятия, как "неправильная", "глупая",
"странная" идея, не существует.
■ Идея принадлежит всей группе, а не только тому человеку, который ее высказал.
■ Ценной является каждая точка зрения.
■ Проводите сеансы в группах правильной величины.
■ Набирайте в группы тех людей, которые действительно могут быть полезными.
■ Обсуждение идей происходит после завершения "мозговой атаки".
Детализация некоторых самых важных правил проведения
сеансов "мозгового штурма"
Воздерживайтесь от осуждения идей. В процессе сеанса "мозгового штурма" идеи
могут обсуждаться, но не осуждаться. Никто не должен высказываться о том, что
какая-то идея не сработает или может иметь негативное побочное действие. Все идеи
потенциально хороши (даже если вначале они так и не выглядят, то впоследствии их
можно модифицировать и извлечь большую пользу). Не забывайте о том, что любая

522 Глава 16
дискуссия обычно приводит либо к критике, либо к одобрению. Оценка отбирает
время и силы, которые должны быть полностью отданы на создание идей.
Поощряйте "дикие" и преувеличенные идеи. Проще привести в нормальный вид
"дикую" идею, чем придумать новую. Странные и на первый взгляд
неработоспособные идеи после применения новых моделей мышления могут привести к
возникновению новых подходов. Высказывание "странных" и "абсурдных" идей снимает
ограничения в разуме других участников.
Сейчас важно количество, а не качество. Проще сократить длинный список идей
или сформировать одну хорошую идею на основании множества мелких идей, чем
попытаться придумать хотя бы что-то незначительное "с нуля". Чем длиннее список,
тем больше шансов создания хорошей идеи. Лидер должен постоянно помогать
участникам генерировать все новые и новые идеи.
Дорабатывайте чужие идеи. Большинство творческих людей являются хорошими
слушателями. Лидеры должны поощрять запись идей и их дополнение новыми мыслями. Уже
высказанные идеи можно усовершенствовать и использовать в качестве основы для новых
оригинальных идей. В каждой идее заключен полезный принцип или концепция.
Все участники и высказываемые ими идеи одинаково ценны. Точки зрения могут
быть (и должны быть) разными, однако все они должны приниматься. Уникальные
подходы к ситуациям позволяют сформировать различные решения.
Советы по проведению сеансов "мозгового штурма"
В дополнение к перечню ролей и правил проведения сеансов "мозгового штурма",
рассмотрим некоторые технические приемы, повышающие шанс на успех.
■ Позвольте группе определить продолжительность коротких перерывов. Если
люди будут свободны в том, чтобы в нужный момент прерывать и возобновлять
сеанс, то это снимет напряжение. Отдых полезен.
■ Перед началом сеанса проведите небольшую "разминку" на какой-либо несложной
теме, не связанной с основной. Это поможет участникам настроиться и
почувствовать себя более комфортно тем, кто еще никогда не участвовал в подобных
мероприятиях. В результате на самом сеансе будет проявляться больше творчества и
мышление участников не будет связано ограничениями.
■ Учитывайте то, что многие работники боятся допускать ошибки в работе. Они
боятся своих менеджеров, боятся потерять работу или пойти на понижение и потому
очень нерешительны в высказывании "диких" идей, которые могут не сработать.
Создайте для таких людей безопасную атмосферу, и тогда они смогут проявить
творчество. Если все организовано правильно, то "мозговой штурм" — это
идеальная возможность раскрыться, так как все участники принимаются без осуждения.
Фактически поощряются любые "ненормальные" идеи.
■ Используйте в сеансах "мозгового штурма" концепцию схемы мышления
(рассматривается и следующем разделе данной главы).
■ Не доверяйте первому впечатлению. В любой самой "непривлекательной" идее,
несомненно, есть полезные "семена".
■ Если поток идей начинает "иссякать", попросите малые группы собраться вокруг
различных лекционных плакатов и обсудить изображенные на них идеи. Можно
также попросить каждого человека записать некоторые идеи на листе бумаги и
обсудить их с кем-нибудь еще. Используйте различные варианты. Заминка в
мышлении — это еще не остановка мышления.

Формулирование требований 523
■ Хорошо, если все участники сядут за столом по кругу. Также эффективны столы в
виде буквы "П".
■ Пытайтесь увидеть полезное даже в простых вещах. Используйте ассоциативное
мышление.
■ Используйте перерывы, однако, ограничьте их время.
■ Разместите лекционные плакаты и маркеры таким образом, чтобы к ним мог легко
дотянуться каждый участник. Снабдите всех блокнотами и ручками для записи
личных идей. Это даст гарантию того, что ни одна идея не будет потеряна.
■ Положите перед участниками те предметы, которые помогут стимулировать
мыслительный процесс. К примеру, можно использовать цветные карандаши и бумагу
или цветной пластилин.
■ Обеспечьте каждого участника удобным стулом.
■ Поддерживайте в комнате визуальное разнообразие, что позволит участникам
рассматривать какой-либо предмет во время высказывания идеи. Если все смотрят
в лицо рассказчику, то это может его смутить.
■ Если кому-то для того, чтобы быть услышанным, требуется микрофон, то группа
слишком большая для проведения сеанса "мозгового штурма".
■ Используйте достаточно большую комнату, чтобы каждый участник мог свободно
перемешаться, не мешая другим. Однако комната не должна быть слишком
большой, чтобы группа по сравнению с ней не казалась маленькой.
■ Время сеанса "мозгового штурма" не должно превышать двух часов. Разбейте весь
период времени на обсуждения, длящиеся не более, чем по 15-минут.
■ По окончании сеанса "мозгового штурма" вернитесь к зафиксированным идеям и
поразмышляйте над ними. Возможно, некоторые из них можно будет объединить
или расширить.
■ Очень маленькая группа должна располагаться за столом, покрытым небольшими
листами бумаги для свободной записи. Участники не должны сидеть слишком
далеко друг от друга.
■ Лидер может быть одним из членов группы и принимать участие в генерировании
идей наравне с остальными.
■ Перед возобновлением сеанса после перерыва попросите людей поменяться
местами и познакомиться со своими новыми соседями.
■ При обращении к группе не называйте участников по именам, а используйте слово
"мы". Это объединит группу и укрепит взаимную поддержку и ответственность.
Распорядок сеанса "мозгового штурма"
Ниже представлен пример распорядка сеанса "мозгового штурма", согласованный
с различными источниками.
1. Вступление. Укажите тему сеанса, обсудите правила и представьте участников.
2. "Разминка" (от 5 до 10 минут), которая позволит создать атмосферу
уверенности и готовности к генерированию идей. Тема "разминки" должна быть
нейтральной и понятной для всех участников и никак не связаной с основной темой

524 Глава 16
сеанса (например, изобретение новых кухонных принадлежностей или
автомобильных аксессуаров). Для поощрения творчества лидер может обсудить правила
и попросить группу внести какие-либо дополнения или изменения для того,
чтобы сеанс был максимально эффективным.
3. "Мозговой штурм". Попросите высказывать рациональные идеи, радикальные
идеи, необычные идеи и любые другие идеи, которые приходят на ум. Активно
работайте в течение 10-15 минут, а затем сделайте перерыв. Останавливайтесь до
того, как утихнет энтузиазм. Если на группу "снизошло вдохновение", то можно
продлить период активности еще на 5 минут. После перерыва продолжайте
работу. При этом всегда следуйте правилам. Не принуждайте участников делать
перерыв и также не принуждайте их заканчивать перерыв. Если поток идей
"истощается", рассмотрите и уточните уже записанные идеи. Убедитесь в том, что
идеи понятны каждому участнику. Объедините подобные идеи по категориям и
удалите дубликаты. Определите критерий оценки.
4. Достижение единодушного мнения. Попросите группу проголосовать за
небольшую часть идей (первые 10-15 идей или около 1/3 доработанного списка).
Каждый участник должен оценивать одну и ту же часть списка идей. Отведите для
"голосования" достаточное количество времени, а затем попросите каждого
участника анонимно предоставить его решение.
5. Завершение сеанса. Поблагодарите участников за участие в сеансе, позвольте им
завершить те записи, которые еще не завершены, и попросите заполнить форму
оценки. Укажите день, когда оцененные идеи будут возвращены им обратно.
Ищите скрытые идеи.
Подготовка к сеансу "мозгового штурма"
Как и в любом проекте, планирование и подготовка значительно повышает
вероятность успеха сеанса "мозгового штурма". Выполните следующее.
■ Определите и пригласите участников, секретаря и лидера. Предоставьте им
информацию о месте и времени проведения сеанса, а также о его
предположительной продолжительности.
■ Определите, каким образом разрабатываются специальные программные системы
или подсистемы, и подготовьте для всех членов группы соответствующую
документацию (сводка по исследованию концепции, сводка по проведенным
интервью, цели планирования проекта).
■ Определите правила и роли сеансов "мозгового штурма", которые используются в
вашей организации и предоставьте их каждому участнику.
■ Убедитесь, что в комнате есть удобные стулья, правильно размещенные столы
необходимой формы, лекционные плакаты, белые доски, проекционные
компьютерные мониторы, прохладительные напитки и "игрушки" (пластилин,
карандаши, калейдоскоп и т.п.).
Обработка результатов сеанса "мозгового штурма"
Обычно редактированием идей по завершению сеанса "мозгового штурма"
занимается лидер. Мы рекомендуем привлекать к этому еще одного или двух человек,
которые будут в дальнейшем заниматься разработкой приложения.

Формулирование требований 525
Во-первых, отбросьте те идеи, которые не могут быть использованы или не
завершены. Не нужно выбрасывать их совсем, а просто зафиксировать и устранить из
списка идей, предлагаемых на рассмотрение. Для отказа от идей используйте
надежные критерии и будьте внимательны, чтобы не удалить чего-либо преждевременно.
Если некоторые идеи дублируются, то удалите дубликаты. Если группа составила
короткий список анонимно рекомендованных идей, то дубликаты уже удалены. Все идеи
должны быть занесены в односекционный список в каком-либо компьютерном
формате (например, Excel).
Распределите оставшиеся идеи на три категории.
Реальные. Настоящие требования, которые могут быть оттестированы.
Возможные. Могут использоваться в качестве требований.
Маловероятные. Скорее всего, не являются "разумными" требованиями.
Зафиксируйте результаты для дальнейшего использования при составлении
спецификации требований к ПО. Они не только пригодятся при переносе требований в
спецификации, но и при определении тех спецификаций, которые будут реализованы
в первой версии программного продукта. Процесс определения приоритетности
будет рассмотрен несколько позже.
Составление схемы мышления
Схема мышления — это концепция, которая может быть использована либо
совместно с "мозговым штурмом", либо независимо от него. Идея состоит в использовании
ключевых слов, рисунков, символов и цветов для отображения умственного
восприятия рассматриваемого вопроса. Многим людям (особенно тем, у кого хорошо
развита зрительная память) проще запоминать подробности в нелинейном виде, что
особенно полезно при быстром конспектировании. Сторонники применения
мыслительных образов утверждают, что при восстановлении в памяти содержимого текста
90 % записанных слов не используются, а образы мышления предоставляют
высокоэффективные визуальные подсказки. Авторами этой фундаментальной идеи
считаются Тони Бузан (Tony Buzan) и Джозеф Новак (Joseph Novak) .
Ниже представлены и некоторые обшие определения.
■ Схема мышления — это эскиз или набросок, на котором центральная и побочные
идеи представлены в виде рисунков (значков, картинок) и ключевых слов,
записанных на линиях (дуги, векторы), соединяющих рисунки.
■ Каждая схема мышления является уникальной по своей форме и содержимому. Это
особенно важно при восстановлении информации.
■ Ключевые слова хорошо различимы благодаря соединяющим их линиям.
■ Схемы мышления позволяют преобразовывать сложные разветвленные области
знаний в легко управляемые структуры.
■ Центральная идея четко представлена в центральной части схемы. Относительная
важность каждой идеи очевидна по размещению: более важные идеи находятся
ближе к центру, а менее важные — ближе к границам.
■ Суть схемы мышления состоит в объединении разнотипной информации вокруг
центрального вопроса в цельной структуре.
" Buzan Tony и Barry Buzan. The Mind Map Book: How to Use Radiant Thinking to Maximize Your
Brain's Untapped Potential NY: Penguin Putnam, 1996.

526 Глава 16
■ Прозрачность и открытость схем мышления облегчает генерирование новых идей
с использованием записанных творческих представлений.
■ Подобные конструкции позволяют легко запоминать информационной
содержимое, а также повышают эффективность восстановления информации.
■ Структуры такого типа позволяют с легкостью удалять и добавлять новую
информацию без снижения удобочитаемости.
Для составления схемы мышления при определении требований необходимо
следующее.
1. Выбрать хорошо запоминаемые ключевые слова.
2. Соединить ключевые слова, записав их на линиях, а затем соединить эти линии.
3. Определить структуру схемы мышления отдельно от линейной структуры,
записанной на бумаге. В линейной структуре просмотр начинается с первого элемента
и продолжается последовательно предложение за предложением сверху вниз. В
отличие от этого, анализ схемы мышления начинается с центра эскиза и
расходится в разные стороны от основного вопроса.
Составление схемы мышления в группе (например, во время сеанса "мозгового
штурма") подразумевает создание набора проиллюстрированных основных идей,
изображения которых прикрепляются на стену и составляют своеобразную
"художественную галерею" идей. Затем участники подходят к каждому рисунку и
добавляют свои в виде соединенных слов и набросков. В конце концов, вопрос будет
зафиксирован в таком виде, который позволяет быстро и легко восстановить в памяти
выводы, решения и требования.
Метод упрощенной спецификации приложения (FAST)
Метод FAST является завершающим для элементов "мозгового штурма" и метода
JAD, и потому будет рассмотрен в данной главе лишь поверхностно. Тем не менее, это
ни в коей мере не приуменьшает важность этого метода, так как он является важной
частью процесса управления программными проектами и был разработан специально
для сбора требований к ПО. Мы представим только общее резюме по методу FAST, a
подробно с этим вопросом можно ознакомиться в других книгах (например, "Software
Engineering"Прессмана').
Основные правила для метода FAST подобны правилам проведения сеанса
"мозгового штурма".
■ Проведите на нейтральной территории встречу разработчиков и заказчиков.
■ Установите правила для подготовки и участия.
■ Объявите неофициальный распорядок.
■ Пригласите арбитра для управления встречей.
■ Подготовьте подсобные материалы: листы бумаги, лекционные плакаты, клейкие
листочки и т.п.
■ Участники должны согласиться с тем, чтобы не критиковать друг друга и не
вступать в споры.
■ Определите цель:
См. сноску 2.

Формулирование требований 527
1. сформулируйте описание проблемы;
2. предложите элементы решения;
3. обсудите различные подходы;
4. определите предварительный набор требований к решению.
Подготовка к сеансу FAST может включать в себя следующее.
■ Составление списка объектов, которые:
1. являются частью среды, окружающей систему,
2. производятся системой;
3. используются системой.
■ Составление списка служб (процессов и функций), которые манипулируют
объектами или взаимодействуют с ними.
■ Составление списка ограничений и критериев производительности.
В течение сеанса FAST обычно происходит следующее.
■ Представление подготовленных списков объектов, служб, ограничений и
критериев производительности с последующим проведением дискуссии. В результате
некоторые элементы списков могут быть перемещены, объединены и т.д.
■ Создание объединенного списка, в котором лишние элементы исключаются, и
добавляются новые идеи.
■ Достижение согласия между участниками относительно списка при помощи
арбитра.
■ Разбивка на команды для работы над "мини-спецификациями" или отдельными
частями известных программных требований:
1. обсуждение мини-спецификаций;
2. определение внешних объектов данных;
3. оценка плотности и содержимого информационного потока;
4. определение и совершенствование программных функциональных свойств;
5. осмысление "поведения" программного продукта;
6. определение характеристик интерфейса;
7. определение ограничений проекта.
■ Составление перечня вопросов, которые будут рассмотрены позже.
■ Создание критериев проверки.
■ Подготовка к выполнению следующего этапа— составления спецификации SRS
(см. главу 17).
Совместная разработка приложений
Кроме интервью, сеансов "мозгового штурма", опросов в малых группах, сеансов
FAST (как с использованием схем мышления, так и без них), существует еще один тип
чрезвычайно эффективного метода проведения встреч: метод совместной разработки
приложений (Joint application design, JAD). Как и все остальные методы определения
требований, метод JAD описан во множестве различных книг. Одну такую книгу, попу-

528 Глава 16
лярную и по сей день, написали Вуд (Wood) и Сильвер (Silver) в 1989 году . В данной
главе представлен обзор процесса JAD, а в приложении G бегло рассматривается
реальный JAD-процесс для двух недавно объединившихся крупных компаний в США.
Определение метода JAD
Метод совместной разработки приложений (JAD) — это зарегистрированный
товарный знак, относящийся к компании IBM. Он представляет собой групповой подход к
определению требований, при реализации которого особое внимание уделяется
усовершенствованию группового процесса и правильному подбору людей, вовлеченных в работу над
проектом. Начало концепции JAD было положено в 1977 году специалистами из компании
IBM Тоби Кроуфордом (Toby Crawford) и Чаком Моррисом (Chuck Morris). Объединив
методологию IBM, подходы к планированию бизнес-систем и собственные новаторские
методы, они создали новое соглашение для профессионалов в области информационных
систем и конечных пользователей относительно требований и спецификаций проекта.
Начиная с 1977 года, метод JAD стал самым популярным средством формулирования
требований к ПО. Он может также использоваться для составления других планов, проектов
и стратегий па протяжении жизненного цикла разработки программного продукта.
Организации, которые занимаются разработкой ПО, теперь понимают, что методики с
высокой степенью взаимодействия с пользователем (включая моделирование и средства
быстрой разработки приложений) позволяют создавать высококачественные продукты.
Сеансы JAD аналогичны сеансам "мозгового штурма", однако не во всем. Сеансы
"'мозгового штурма" длятся около двух часов, а сеансы JAD— до трех дней. На сеансах
"мозгового штурма" происходит быстрое генерирование идей, а на сеансах JAD —
высокоуровневые специфические программные модели функций, данных и линий поведения.
Сеанс JAD имеет определенную структуру, на нем придерживаются определенной
дисциплины, и он проходит под руководством арбитра. В его основе лежит обмен
информацией с использованием документации, фиксированных требований и правил
работы. С момента появления методики JAD на сеансах используются CASE-
инструменты и другие программные средства, предназначенные для построения
диаграмм потока данных (Data flow diagram, DFD), диаграмм взаимосвязей между
сущностями (Entity relationship diagrams, ERD), диаграмм смены состояний и других
объектно-ориентированных диаграмм.
В 1989 году Каперс Джонс (Capers Jones) провел исследование 60 проектов. В
результате было обнаружено, что без применения JAD в процессе формулирования
требований было упущено 35 % функциональных свойств, а с применением JAD —
меньше 10 %. Еще лучшие показатели были выявлены для тех проектов, в которых метод
JAD использовался совместно с моделированием .
Роли в сеансах JAD
Разработчики
В задачу разработчика входит оказание помощи организаторам в формулировании их
потребностей, которые обычно являются решением существующих проблем. Таким
образом, определение требований к ПО происходит совместно с организаторами проекта.
Wood Jane и Denise Silver. Joint Application Design: How to Design Quality Systems in 40% Less Time.
NY: John Wiley & Sons, 1989.
www. thebeenet. com/bluebird/jaddoc.htm. Billjennerich. Joint Application Design:
Business Requirements Analysis for Successful Re-engineering. Berwyn, PA: Bluebird Enterprises, 1999.

Формулирование требований 529
Участники
Также как и в сеансах "мозгового штурма", организаторам проекта отводится
самая важная роль в сеансе JAD. Для успешного проведения сеанса ключевым
требованием является высокий уровень квалификации приглашенных. Правильный подбор
людей позволит быстро принимать решения и разрабатывать правильные модели,
даже если они не будут завершены.
Арбитр/консультант
Также как и в сеансе "мозгового штурма", ходом сеанса JAD управляет арбитр. Он
должен сводить к минимуму проявление непродуктивных человеческих эмоций,
наподобие агрессивности или самозащиты. Арбитр не является хозяином ни процесса,
ни программного продукта. Он присутствует только для того, чтобы помогать
организаторам проекта разрабатывать программный продукт.
Секретарь
Также как и в сеансе "мозгового штурма", секретарь сеанса JAD документирует
идеи и помогает следить за временем.
Сеансы JAD
Согласно Вуду (Wood), сеанс JAD— это своеобразная "мастерская", работающая в
максимально напряженном режиме, где решения принимаются совместно всеми
участниками. При этом участники являются крупными специалистами в
рассматриваемом вопросе. Рекомендуется процесс исследования проекта разбивать на следующие
этапы: поиск фактов и сбор информации, подготовка сеанса JAD, проведение самого
сеанса JAD и проверка собранной информации. Также как и в случае с сеансом
"мозгового штурма", комната для проведения сеанса JAD должна быть
соответствующим образом оборудована. Должен быть предоставлен свободный доступ к белым
доскам, лекционным плакатам, маркерам, правильно расставленным столам
подходящей формы, проекторам, плакатам, столам с напитками и т.д.
Основные правила и рекомендации по проведению сеансов JAD являются
зеркальным отображением правил и рекомендаций проведения сеансов "мозгового
штурма":
■ "глупых" вопросов не существует;
■ все участники находятся в равном положении;
■ молчание является знаком согласия даже в том случае, если вы отсутствуете;
■ каждый член команды может свободно перемещаться по комнате и получать явное
согласие по данному вопросу от любого присутствующего;
■ никакие "выступления" не допускаются;
■ побочные разговоры не допускаются;
■ все члены команды задействованы на протяжении всего сеанса (рекомендуется
три дня на сеанс);
■ за один раз должен рассматриваться только один пользовательский сценарий;
■ при "мозговом штурме" главное не качество, а количество;
■ определитесь с терминологией и используйте при записи трехбуквенные
аббревиатуры;

530 Глава 16
■ все члены команды должны быть открыты для генерирования идей;
■ все члены команды поддерживают и обучают друг друга, а также помогают
расслабиться и немного повеселиться.
Результаты проведения сеанса JAD
Имеет смысл позволить двум группам (разработчикам и организаторам
совместного дела) владеть всеми результатами совместного творчества во время сеанса JAD.
В их состав могут входить:
■ диаграмма контекста данных (рис. 16.6);
■ диаграмма потока данных первого уровня;
■ диаграмма потока данных нулевого уровня;
■ глобальная модель данных — диаграмма взаимосвязей между сущностями (рис. 16.7);
Рис. 16.6. Пример неполной диаграммы контекста данных (DCD)
■ перечень первичных объектов;
■ объектная модель высокого уровня (рис. 16.8);
■ обязанности кандидатов и сотрудников для каждого объекта;
■ перечень первичных процессов/сценарии выбора;

Формулирование требований 531
■ другие диаграммы потока данных, диаграммы состояния, деревья альтернатив,
таблицы решений;
■ требования, предъявляемые к данным для каждого процесса;
■ перечень допущений;
■ документация по анализу или назначению открытых вопросов.
Результаты сеанса JAD используются в процессе определения требований для
организации следующего этапа — создания спецификации SRS.
Атрибут -
Атрибут -
Атрибут -
Объект
Данные, информация
: Ъ?
Объект
Данные, информация
Атрибут •*
Атрибут
Объект
Данные, информация
п
■ Атрибут
- Атрибут
- Атрибут
Атрибут
Рис. 16.7. Пример глобальной модели данных
Объект
Атрибут
Служба
\1/
'
Объект
Атрибут
Служба
Объект
Атрибут
Служба
Рис. 16.8. Пример объектной модели высокого уровня
Проблемы, которые могут возникнуть во время сеанса JAD
Ни один метод не является совершенным. Несмотря на то, что метод JAD с
успехом применяется уже на протяжении нескольких десятилетий, он имеет ряд
"уязвимых мест".
Например, участники передают свои идеи арбитру и/или секретарю. Во
избежание неверной интерпретации собранных данных, необходимо принять некоторые
меры предосторожности. Использование во время сеанса автоматизированных
инструментальных средств и проверка результатов всеми участниками уменьшит риск.
На сеансах JAD рассматриваются преимущественно информационные системы, в
которых особое внимание уделяется элементам данных и проекту интерфейса. Есть
мало информации об использовании метода JAD для определения требований,
предъявляемых к системам реального времени.
На проведение трехдневного сеанса JAD с представителями всех групп
организаторов проекта, каждая из которых состоит из квалифицированных специалистов,

532 Глава 16
уходит немало средств. Три дня— это средняя продолжительность. Для анализа
сложных вложенных систем реального времени и систем, от которых зависит
человеческая жизнь, часто требуется больше времени. Если сеанс длится "до тех пор, пока
не устанем", то усталость может наступить уже в тот момент, когда будут определены
только сценарии выбора.
Пользовательский сценарий и сеансы разработки
схем выбора
Многие практические методики являются объектно-ориентированными. Они
очень обширны, поэтому те из них, которые представлены в данной книге,
рассматриваются вссь.ма поверхностно. Мы описываем только основы того, что должны
знать менеджеры для грамотного управления программными проектами, а также
указываем ссылки на литературу для углубленного изучения каждого представленного
вопроса. Теперь настало время кратко рассмотреть такой метод определения
требовании, как схемы выбора. Объектная модель будет рассмотрена в главе 22.
В процессе определения требований для представления исследуемой системы,
отображения несовместимости, ошибок, упущений и неопределенностей
используются как текстовые, так и графические модели. Текст и рисунки позволяют лучше
попять требования, а также компенсируют недостатки языка и словарного запаса.
Многие менеджеры программных проектов твердо уверены в том, что сценарии выбора и
диаграммы в процессе сеанса сбора требований (JAD, FAST) являются ключевыми
элементами для создания определений, организации взаимодействия между
пользователем и системой, а также базисом для проверки.
Определение схемы выбора
Схема выбора описывает на высоком уровне, что (а не как) должна делать система.
При этом анализ выполняется с точки зрения пользователя относительно области
применения приложения и его структуры. В схемах выбора задается специальная
цепочка записанных высказываний. Часто думают, что термины "схема выбора" (use
case), "сценарий выбора" (use case scenario) и "диаграмма выбора" (use case diagram) — это
одно и то же, однако, на самом деле это не так. Схема выбора— это
структурированным шаблон, описывающий пользовательские требования при помощи
структурированного языка (например, русского языка). Сценарий выбора— это
неструктурированное описание пользовательских требований. Ни один из этих двух методов не
ограничен объектно-ориентированной моделью, однако они обычно рассматриваются
именно в этом направлении. Диаграмма выбора— это графическое представление,
к< ггорое может быть разбито на дополнительные уровни абстракции. Рассмотрим для
начала компоненты этих методов.
Действующие лица
Действующее лицо или внешний агент находится вне системной модели, однако
некоторым образом взаимодействует с ней. Действующим лицом может быть
человек, машина или информационная система, внешняя для системной модели.
Действующее лицо не является частью самой системы. В роли действующих лиц могут
также выступать заказчики, клиентские приложения, внешние системы (например,
правовые или бухгалтерские), а также внешние устройства (например, мониторы
неисправностей).

Формулирование требований 533
Схема выбора
Схема выбора— это текстовое повествовательное описание последовательности
событий со стороны действующего лица, которое использует систему. Это— набор
"рассказов" о том, как используется система, в котором проиллюстрированы и
выражены требования. Можно также сказать, что схема выбора— это набор транзакций
(маленьких наборов действий), которые имеют определенное значение для
действующего лица. Она содержит описание хода событий, которые происходят в системе.
Схема выбора — это статическая функциональная модель со статическими
взаимосвязями и постоянными последовательностями.
Диаграмма выбора
Диаграмма выбора — это визуальное представление процесса взаимодействия
действующего лица с системой. Система отображается в виде прямоугольника, в
котором указывается название системы (или подсистемы), а действующее лицо — в виде
условных фигурок (не обязательно человеческих). Схемы выбора изображаются в
виде овалов, в которых указывается название, а взаимосвязи — в виде линий или
стрелок, соединяющих действующие лица и схемы выбора. Действующие лица
располагаются вне прямоугольника, так как по отношению к системе они являются
внешними. Схемы выбора располагаются внутри прямоугольника и обеспечивают
требуемые функциональные свойства. Взаимосвязям или ассоциациям
соответствуют сплошные линии, соединяющие действующие лица и схемы выбора. Участие
может быть в любом виде, и не обязательно какое-либо действующее лицо должно
инициализировать функциональность схемы выбора. Пример диаграммы выбора
представлен на рис. 16.9.
Сельскохозяйственный
рабочий
Хранилище данных
Аналитик
Существующая система
Рис. 16.9. Пример диаграммы выбора

534 Глава 16
Согласно Рихтеру (Richter), система, построенная с применением схем выбора,
функционирует на основании того, каким образом действующие лица используют эту
систем)'. В такой модели представлены те функции, которые имеют смысл для
действующих лиц. Необходимо только выяснить, к каким функциям обращается действующее
лицо, и к каким действующим лицам обращается система. Каждая схема выбора состоит
из одного или нескольких абзацев текста, который также известен под названием
"спецификация". Сначала необходимо идентифицировать действующие лица системы и
схемы выбора, а затем объединить полученную информацию в диаграмме выбора. В
результате получится статическая функциональная модель со статическими
взаимосвязями и постоянными последовательностями. В ней нет информации о динамике работы
представленных функций. Этот недостаток устраняется при помощи диаграмм
действий, описанных в книге Рихтера "DesigningFlexible Object-Oriented Systems with UML" .
Преимущества схем выбора
Схемы выбора могут быть ключевым средством для понимания требований в
бизнесе. Кроме того, они помогают удостовериться в том, что все пользователи системы
имеют одно и то же представление о выбранной модели. В следующем списке
перечислены некоторые преимущества схем выбора.
■ Использование устойчивых названий для различных схем выбора облегчает обмен
информацией и позволяет избежать ошибок, вызванных путаницей в обращениях
различных людей или групп людей к элементам системы.
■ Диаграммы выбора обеспечивают документированную модель, которая точно
описывает существующий процесс и разрабатываемую систему.
■ Схемы выбора понятны менеджерам, пользователям и разработчикам и не
требуют специальной подготовки.
■ Схемы выбора и сценарии выбора обеспечивают возможность проверки и
тестирования системы.
■ Схемы выбора могут быть использованы для формирования бизнес-правил.
■ Схемы выбора определяют процесс взаимодействия заказчика с группой.
■ Схемы выбора могут быть легко преобразованы в объектные модели.
■ Схемы выбора позволяют контролировать работу функций.
■ Схемы выбора предоставляют основную информацию, необходимую для создания
моделей.
■ Схемы выбора снижают вероятность появления функций, которые не
соответствуют целям системы.
■ Схемы выбора демонстрируют ход обрабатываемых событий.
Советы по созданию схем выбора
Рассмотрим некоторые советы по созданию схем выбора в процессе определения
требований.
■ Пусть каждая схема выбора содержит рассказ о том, как пользователь
взаимодействует с системой на этапе разработки. Это позволит достигать конкретных целей
(абстрактный диалог).
" Richter Charles. Designing Flexible Object-Oriented Systems with UML Indianapolis, IN: Macmillan
Technical Publishing, 1989.

Формулирование требований 535
■ Назначьте "защитников" проекта, которые являются обычными пользователями
для каждого пользовательского класса. Они послужат в качестве первого
интерфейса между пользователями и разработчиками.
■ Избегайте на данном этапе устанавливать стратегии проекта, включая разработку
пользовательского интерфейса.
■ Избегайте в схемах выбора дублирования.
■ Избегайте слишком быстрого создания слишком большого количества схем выбора.
■ Не записывайте в схемах выбора определений данных, так как признаки данных
включаются в диаграммы классов, логические модели данных и словари данных проекта.
■ Записывайте следующую информацию о каждой схеме выбора:
1. уникальный идентификационный номер;
2. краткое название;
3. историю создания — автор, дата создания, кто обновил, дата последнего
обновления;
4. действующие лица;
5. краткое описание;
6. пред- и постусловия;
7. приоритетность;
8. частота использования;
9. подробное описание действий пользователя и ответов системы в обычных
условиях;
10. альтернативные направления;
11. условия возникновения ошибок и реакция системы;
12. включения (другие схемы выбора, которые могут быть вызваны);
13. специальные требования;
14. допущения;
15. комментарии.
■ Функциональных требований должно быть больше, чем схем выбора.
Во время проведения сеанса FAST или JAD руководитель для начала процесса
определения схемы выбора может выполнить следующие действия (рис. 16.10).
1. Определить, кто будет использовать систему непосредственно. Например, в роли
действующих лиц могут выступать нажатые клавиши клавиатуры.
2. Выбрать одно из действующих лиц.
3. Определить, что данное действующее лицо требует от системы. Каждое действие
заносится в схем)' выбора.
4. Определить и описать для каждой схемы выбора "основное направление",
которое используется при обычных обстоятельствах.
5. Описать направление в следующей форме: "Действующее лицо делает то-то,
система делает то-то; действующее лицо делает то-то, система делает то-то..." При
этом все описания должны придерживаться высокого уровня. Это — не время для

536 Глава 16
обсуждения пользовательского интерфейса. Необходимо только описать
системные функции, которые будут известны действующему лицу, и те действия
действующего лица, которые будут известны системе.
6. После описания основного направления необходимо рассмотреть альтернативы
(они будут добавлены в диаграмму в виде дополнительных схем выбора, достаточно
хорошо описанных во всех книгах по объектно-ориентированным технологиям).
7. Просмотреть описание всех схем выбора. В случае обнаружения общих элементов
во избежание дублирования зафиксировать только одну схему выбора.
8. Повторить действия со 2 по 7 для каждого действующего лица.
И последний совет — не усложняйте схемы выбора.
гшюашщплявр
С
1. Определить; too будрг
непосредственно,
использовать систему
/Ч^ЖЧ-М'ШИИЖ
ЧЕ
2. Выоратьодйо ' -. :
из действующих лиц
х .•тшти.гу^т^мштщ
3. определить, чтоденнов/L
лицо требуете* окшчш. -*,-. чс■:■•-■ \'
Каждое действие заносится в схему at
5, ОписатьЧюновж»-'
.направление,,,-^„^jfl
Рис. 16.10. Этапы создания схемы выбора
Советы по определению требований
к качеству ПО
Требования, которые обычно собираются с помощью нескольких рааличных
средств, затем сжимаются и форматируются в соответствии с шаблоном SRS и
преобразуются в спецификации. На этом этапе нужно придерживаться ясности формулировок
для того, чтобы не осложнять работу в будущем. При составлении спецификаций
требуется больше четкости, чем при простом определении требований. Представленные
ниже советы помогут сделать правильное преобразование требований в спецификации.

Формулирование требований 537
■ Определите термин "требования" в контексте проекта, потому что для разных
людей он может иметь разное значения. Требования — это высказанные
организаторами утверждения о функциональности и качестве системы, но они еще не
являются "спецификациями". Требования могут включать в себя функциональные,
поведенческие и информационные модели высокого уровня (диаграммы потоков
данных, модели отношения логических объектов, объектные модели, модели
управления), однако они не содержат подробностей о структуре пользовательского
интерфейса, необходимых при разработке системы.
■ Помните о существовании различных типов требований (функциональные,
нефункциональные, предъявляемые к качеству, предъявляемые к
производительности, пользовательские, ограничения и т.д.).
■ Учитывайте международные стандарты.
■ Определите функции, критичные по времени.
■ Учитывайте вопросы безопасности и защиты.
■ Записывайте требования, которые могут быть прослежены в спецификациях
(укажите источник для обратной трассировки спецификаций).
■ Проследите требования к ПО в обратном направлении вплоть до системных
требований, схем выбора или документации по определению требований.
■ Создайте схему идентификации требований (для прямой и обратной трассировки).
■ Если на этом этапе можно определить возможные сообщения об ошибках, то
зафиксируйте их.
■ Постоянно обменивайтесь информацией. Решения о принятии требований
разработчики должны принимать совместно с организаторами проекта. Однако
часто бывает так, что при возникновении сложного вопроса, для решения
которого отведено очень мало времени, разработчик пытается заполнить "пробел"
собственными силами без уточнения необходимой информации. Не
выбрасывайте никаких "пользовательских классов". Качественные программные
продукты могут содержать пользовательские классы, использующие входные данные
членов классов.
■ Старайтесь как можно быстрее уменьшить неоднозначность требований.
Неоднозначное требование может иметь две или более противоречивые интерпретации.
Кроме того, оно может быть составным, то есть иметь внутри себя несколько
независимых требований. Признаками составных требований обычно являются
слова "и" и "с". Однозначные требования "примитивны", понятны, кратки и
тестируемы. Примитивные требования можно соединить друг с другом. Они
отображают одну (и только одну) мысль.
■ Определите необходимость использования вторичных и условных требований.
Вторичное требование соответствует необходимому или предшествующему
условию другого требования. Условное требование — это требование, для которого
определены другие (вторичные) требования как необходимые или
предшествующие условия. Примером условного требования является функция, которая не
может быть реализована до тех пор, пока не будет установлена определенная версия
операционной системы. Еще одним примером условного требования является
обратная совместимость с другими системными компонентами.

538 Глава 16
■ Старайтесь при написании требований не использовать внутренне субъективных
и двусмысленных слов. Особенно опасными являются такие термины, как "всегда",
"иногда", "часто", "минимизировать", "максимизировать", "оптимизировать",
"быстрый", "дружественный к пользователю", "легко", "простой", "обычный", "нормальный",
"большой", "интуитивный", "сильный", "современный", "усовершенствованный",
"эффективный", "поддержка" и "гибкость". Большинство из этих терминов не поддаются
проверке.
■ Спроектируйте тесты для проверки функциональных требований.
■ Учитывайте разработку моделей.
■ Создайте словарь данных.
■ Предложения и абзацы должны быт краткими, а требования должны находиться
на одном уровне детализации (используется один тест функциональности).
■ Избегайте при написании требований многословности.
Если соблюдать эти советы и часто обращаться к организаторам, то в результате
будет заложено хорошее основание для создания спецификации SRS.
Проблемы, возникающие при определении
требований
Самой сложной задачей при создании программной системы является точное
определение того, что требуется создать. Ни одна абстрактная задача не вызывает
столько трудностей, как определение подробных технических требований, предъявляемых к
интерфейсам с людьми, машинами и другими программными системами. Ни одна
задача не приносит такого же вреда конечной системе в случае ошибки. Нет ни одной
задачи настолько же сложной в исправлении последствий. Поэтому многократное
извлечение и уточнение требований, предъявляемых к продукту,- это самая важная часть
взаимодействия разработчика с клиентом
Фред Брукс.
Брукс (Brooks) в своих исследованиях показал, что во избежание проблем следует
быть осторожным в следующих случаях.
■ Согласование корректных изменений, внесенных в требования.
■ Достижение завершенности требований при отсутствии системного проекта с
определенными ограничениями.
■ Недостаточное понимание предметной области, когда пользователь и аналитик
"говорят на разных языках".
■ Изменение требований с течением времени.
■ Наличие конфликтных точек зрения на необходимые требования.
■ Изучение факторов среды (например, достоверности интерфейсов с другими
системами).
Brooks Frederick P. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE
Computer, 20D):10-19, 1986.

Формулирование требований 539
■ Разработка не очень дорогостоящих моделей, являющихся частью методики
определения требований, компоненты которых не поддаются реализации.
■ Пропуск "очевидной" информации.
■ Акцентирование внимания на вычислительных аспектах системы, а не на ее
влиянии на производственный процесс.
■ Выражение требований в форме, позволяющей разработчикам определить их
реализуемость и тестируемость.
■ Определение экспертов в предметной области (применение и разработка).
■ Определение аналогичных систем, из которых можно позаимствовать требования.
■ Определение границ применимости системы.
■ Недостаточное понимание организаторами совместного дела вычислительных
возможностей и ограничений.
■ Недостаточное понимание пользователями их потребностей.
■ Привлечение к работе всех основных групп организаторов совместного дела
(заказчики, спонсоры, пользователи, разработчики, инженеры по качеству, аналитики).
■ Повторное исследование требований вследствие поступления новой информации.
■ Хранение информации в электронном виде, когда производится ее постоянное
обновление. Если во время сеанса "мозгового штурма" использовался бумажный
лекционный плакат, то его содержимое должно быть включено в электронный
документ, электронную таблицу или базу данных и быть предоставлено всем
организаторам совместного дела.
■ Акцентирование внимания не на методике, а на методологии. Ориентироваться на
какую-либо методику опасно, так как это может привести к искажению условий
задачи. Вместо этого лучше ориентироваться не на задачу, а на пользователя.
■ Использование требований на уровне вопроса "какие?", когда решение вопроса
"как?" откладывается до этапа разработки (Какие данные производит и потребляет
система? Какие функции должна выполнять система? Какие нужны интерфейсы?
Какие применять ограничения?).
■ Недостаточное понимание назначения системы внутри организации, в которой
эта система будет использоваться.
■ Достижение "завершенности" посредством решения заранее намеченных вопросов.
■ Управление конфликтными целями, точками зрения и интересами.
■ Моделирование большого количества данных.
■ Получение санкций.
■ Получение перечней желаемых требований от организаторов с различными
уровнями полномочий (то есть менеджеры не должны влиять на пользователей).
■ Разбиение системы на подсистемы для уменьшения сложности.
■ Сопротивление разработке новой системы со стороны персонала (причиной
этому может быть, к примеру, страх потерять работу вследствие автоматизации
некоторых функций).
■ Выяснение приоритетности требований и определение критичных функций.

540 Глава 16
■ Формирования количества информации, достаточного для переноса в SRS и начала
разработки, однако, не слишком большого, как этого требуют некоторые методологии.
■ Сохранение лишней на данный момент информации, полученной от
организаторов, до наступления соответствующего этапа разработки.
■ Организаторы совместного дела (проекта) могут иметь совершенно различную
квалификацию, поэтому язык требований бывает сложным для понимания.
■ Желание вложиться в рамки стоимости и графика работ, предложенного спонсором.
■ Адаптация методов определения требований к тем, которые подходят для данного
проекта. Внесение в методологию гибкости.
■ Прямое и обратное прослеживание требований.
■ Выяснение проектных ограничений.
■ Выяснение требований для больших и/или сложных систем.
■ Проверка требований на их соответствие целям проекта.
■ Работа внутри каскадной модели жизненного цикла, когда этап проектирования
может пересекаться с этапом сбора требований. Дело в том, что определение
требований редко заканчивается на этапе требований.
Ни для одной из перечисленных ситуаций не существует частичного ответа или
простого решения, однако рассмотренные методы помогут в некоторой степени
преодолеть возникающие трудности. Менеджер должен тщательно исследовать
проблемы, характерные для данного программного проекта, преобразовать их в риски,
зафиксировать, а затем производить постоянный контроль.
Требования и внедрение функций
определения качества
Внедрение функций развертывания качества (Quality function deployment, QFD) —
.*uj процесс фиксации требований заказчика и их преобразования в требования,
которые могут быть использованы специалистами по проектированию, разработке и
сопровождению программных средств. Как и по многим другим вопросам, которые
рассматривались в данной главе, вопросу QFD посвящено множество книг, статей,
консультационных служб, программ и Web-узлов. Процесс внедрения функций раз-
ж'ртыпания качества будет также рассмотрен в главе 30. Он заслуживает внимания в
контексте определения требований по той причине, что самым первым этапом в QFD
чнляется "определение самых важных требований заказчика к продукту и их
преобразование в проектные требования". На данном этапе жизненного цикла разработки
ПО мы еще не готовы к преобразованию требований заказчика в проектные
требования. Это будет сделано позднее, после создания спецификации SRS и аналитического
моделирования. На данный момент нас в первую очередь интересуют методы
определения и фиксации требований организаторами проекта.
Процесс QFD включается в систему таких методов как "мозговой штурм ", FAST
u f AD, При этом информация используется совместно членами смешанной
команды состоящей из представителей различных групп организаторов. В эту команду
)''-:одяг специалисты по следующим вопросам: маркетинг, продажа, обслуживание,
р.и цространение, разработка проекта продукта, проектирование процесса, постав-
1.1 и производство. И конечно же, в состав команды входят конечные пользователи

Формулирование требований 541
программной системы. Второй особенностью процесса QFD при определении
требований является необходимость фиксации информации в одном месте и в
компактной форме. И наконец, метод QFD (как и другие методы определения
требований) поддерживает согласование и принятие решений. Особенно это касается тех
случаев, когда требуется найти оптимальное решение при наличии сложных
взаимосвязей и компромиссов.
Метод QFD начинает выполняться с представленных ниже действий, которые
явно взаимосвязаны с процессом определения требований.
1. Определяются группы, взаимодействующие с данной системой (например,
заказчики, пользователи и разработчики). Также выясняются все указанные
заказчиком начальные ограничения, оказывающие влияние на процесс
определения требований.
2. Создаются требования заказчика на высоком уровне. При этом учитываются
различные точки зрения. Требования — это выражения, описывающие то, что
система должна делать. Они должны быть понятны заказчику и иметь для него
значение. Потребности чаще всего выражаются на языке заказчика, поэтому
разработчикам часто приходится корректировать их для того, чтобы они были
тестируемы и измеримы.
3. Определяется степень важности каждого требования. Относительно заказчика
требование может быть очень важным E баллов); важным D балла); не важным,
но желательным C балла); не важным B балла) и незначительным A балл).
Некоторые цели процесса QFD перекликаются с целями процесса определения
требований.
■ В обоих случаях происходит попытка указать руководству на важность этапа
определения требований и на преимущества обмена информацией, выполняемого па
данном этапе.
■ В обоих случаях происходит попытка зафиксировать потребности заказчика с
последующей разработкой соответствующих решений. Точки зрения пользователей
могут быть зафиксированы при помощи экспериментальных моделей, а также во
время сеансов "мозговой атаки", FAST и JAD.
■ В обоих случаях члены группы поддержки совместно работают над достижением
общей цели — получения качественных требований.
Использование метода QFD при определении требований имеет следующие
преимущества.
■ Межфункциональный обмен информацией и работа в команде приводят к
получению более удобного продукта.
■ Приоритетные требования позволяют определить те элементы, которые имеют
более высокий приоритет и должны быть выполнены в первую очередь. Это
оптимизирует распределение ресурсов во время разработки.
■ Нужная информация сохраняется в документация QFD, благодаря чему в
дальнейшем она может быть использована повторно. Это, в конце концов, сокращает
время разработки.
■ Все работы сфокусированы на заказчике, в результате чего он будет более
удовлетворен качеством конечного продукта.

542 Глава 16
Внедрение функций качества напоминает о том, что кроме функциональных и
нефункциональных существуют также "обычные" требования, удовлетворяющие
ожидания заказчика; "ожидаемые" требования, которые заказчиком могут быть явно
не высказаны, однако их отсутствие приведет к значительному неудовлетворению; а
также "восхитительные" требования, которые превышают все ожидания заказчика и
очень ему понравятся. На рис. 16.11 представлен диапазон требований от
высказанных, которые в случае своего присутствия удовлетворяют заказчика, до
невысказанных, которые в случае своего отсутствия огорчат заказчика.
Тем не менее, специалистам по определению требований не позволяют
"расслабляться", и через некоторое время "удовлетворяющие" требования становятся
"ожидаемыми". При этом заказчик остается неудовлетворенным, если такие требования
отсутствуют, независимо от того, были они высказаны или нет (рис. 16.12).
Требование
Высказанное
Невысказанное
(Функциональное)
Невысказанное (неожиданное)
Если присутствует
...; ^казчикдовълей». *г
Заказчик ожидает
увидеть его и потому
считает его вполне
обоснованным
а*£«
Если отсутствует
Заказчик никак
не реагирует
Рис. 16.11. Высказанные и невысказанные требования заказчика
Заказчикдоволен
Степень
активности
ЗаказчикнеД-»»**
Рис. 16.12. Удовлетворение требований заказчика

Формулирование требований 543
Приоритетность требований
На протяжении всей этой книги постоянно высказывается одна мысль, которая
особенно подчеркивается в главах 10 и 11, посвященных определению размера и
проведению оценки программного продукта. Эта мысль заключается в том, что при
планировании и разработке программного продукта существует только определенное
количество степеней свободы. Можно зафиксировать качество, график работ или
стоимость, однако невозможно зафиксировать сразу все эти показатели. В
большинстве случаев чем-то приходится жертвовать. Ни менеджеры, ни заказчики не
соглашаются с увеличением срооков работ или повышением стоимости, поэтому
часто достижение результатов планируется последовательно нарастающим. При этом
в первую очередь реализуются те функции, которые являются самыми важными.
Конечно, можно было бы пожертвовать и качеством, однако на это редко кто
соглашается. Тот момент в цикле разработки продукта, когда собраны все необходимые
требования, является идеальным для установки приоритетности. После этого можно
удалять требования с низким приоритетом без страха испортить весь продукт.
Разработка ПО в изменчивой среде требований всегда связана с издержками, однако, хуже
всего то, что, в конце концов, не осуществляются ожидания организаторов.
После того, как определены все классы организаторов проекта, цели проекта
могут измениться и даже стать несовместимыми с теми целями, которые были раньше.
Частый обмен информацией с заказчиком и определение приоритетности
требований уменьшает проектный риск. Самые важные функции (то есть настолько
критичные по своему назначению, что не могут быть изменены) разрабатываются в первую
очередь. Согласованные даты реализации всех остальных функций заносятся в
график работ, а схема приоритетов передается всем организаторам. Такой подход
снижает опасность срыва проекта.
Приоритетность требований можно с успехом использовать во многих
организациях, ориентирующих свою работу на распределение средств в текущем финансовом
году. В том случае, если покупка оптимальной версии не укладывается в ограничения
бюджета, остаток средств можно использовать на приобретение уменьшенной версии
продукта. Диалог между организаторами и разработчиками должен останавливаться
на определении самых важных требований. Он должен продолжаться для
исследования всех возможных вариантов. Если свойства продукта смогут быть оценены для
стоимости и графика работ, то организаторы получат дополнительную информацию
для принятия правильного решения.
У организаторов проекта имеется собственный уникальный набор "критериев",
определяющих "важность" или ценность требований. Он основан на анализе
стоимости/выгодности проекта и набора требований под названием "набор свойств". При
анализе требований важно также учитывать качество и ограничения.
Сначала системная функциональность группируется в наборы свойств, которые
будут содержать в себе логически связанные требования. Затем организаторы
оценивают каждое требование внутри каждого набора свойств на предмет его значимости.
При этом часто используется простая схема:
3 = ответственная задача (очень важная, абсолютно необходимая)
2 = важная, но не абсолютно необходимая
1 = желательная, но не обязательная

544 Глава 16
На третьем этапе разработчики и организаторы проекта совместно
определяют для каждого требования возможность его немедленной реализации;
возможность и причину отсрочки его реализации; а также возможность отказа от его
рассмотрения.
Процесс оценки не всегда бывает простым. Если какое-либо свойство кому-
нибудь не нравится, то оно, скорее всего, не будет в списке на первом месте.
В большинстве случаев для требований, полученных при помощи схем мышления,
метода JAD или группы фокусировки и выражающих осознанные и неосознанные
потребности и желания организаторов, необходимо определить приоритетность.
Приоритетность требований дает как неосязаемые преимущества (например,
повышение доброжелательности заказчика), так и осязаемые (например, увеличение
объема продаж).
При определении приоритетности могут пригодиться схемы выбора, с помощью
которых можно выяснить ожидаемую частоту использования, удовлетворяющую
большинство привилегированных пользовательских классов; реализацию
центрального бизнес-процесса; функции, требуемые по закону, и т.д. Можно также воспользо-
ваться факторами, критичными к успеху, чтобы определить те функции приложения,
которые должны работать надлежащим образом.
В табл. 16.1 представлен простой подход к документированию соглашений о
том, как и когда будут реализованы приоритетные требования. Этот пример был
специально упрощен, однако такой формат можно использовать для любого
количества уровней приоритетности (в данном случае их три) и для любого количества
набора свойств (в данном случае их также три). После того, как требования будут
расставлены согласно степени важности, они группируются в связанные наборы
свойств. Комбинации из двух наборов могут быть реализованы в различных
версиях программного продукта.
Таблица 16.1. Пример распределения наборов свойств в соответствии
с версиями продукта
Наборы Набор свойств 1 Набор свойств 2 Набор свойств 3
свойств
} 1омер
Персии
1 Реализуются все
требования с
приоритетом 3
2 Сохраняются все
требования с
приоритетом 3
3 Сохраняются все
требования с
приоритетом 3
Реализуются все
требования с
приоритетом 3
Сохраняются все
требования с
приоритетом 3
Сохраняются все
требования с
приоритетом 3; реализуются все
требования с
приоритетом 2
Реализуются все
требования с
приоритетом 3
Сохраняются все
требования с
приоритетом 3; реализуются все
требования с
приоритетом 2
Сохраняются все
требования с
приоритетом 3 и 2

Минимальная
версия

Формулирование требований 545
Окончание табл. 16.1
Наборы Набор свойств 1
свойств
Набор свойств 2
Набор свойств 3
Сохраняются все
требования с
приоритетом 3; реализуются все
требования с
приоритетом 2
Сохраняются все
требования с
приоритетом 3 и 2
Сохраняются все
требования с
приоритетом 3 и 2
Сохраняются все
требования с
приоритетом 3 и 2; реализуются
все требования с
приоритетом 1
Сохраняются все
требования с
приоритетом 3 и 2
Сохраняются все
требования с
приоритетом 3 и 2
Сохраняются все
требования с
приоритетом 3 и 2; реализуются
все требования с
приоритетом 1
Сохраняются все
требования с
приоритетом 3 и 2; реализуются
все требования с
приоритетом 1
Сохраняются все
требования с
приоритетом 3 и 2
Сохраняются все
требования с
приоритетом 3 и 2; реализуются
все требования с
приоритетом 1
Сохраняются все
требования с
приоритетом 3 и 2; реализуются
все требования с
приоритетом 1
Сохраняются все
требования с
приоритетом 3 и 2; реализуются
все требования с
приоритетом 1
Макси-
версия
Резюме
Определение требований — это самый сложный и в то же время самый важный
процесс во время разработки программного продукта. Определение требований
может происходить на протяжении всего жизненного цикла продукта, хотя, чем больше
будет сделано до написания спецификации, тем лучше. Процесс сбора требований
затрагивает почти все из 34 компетенций, которым должны соответствовать
менеджеры программных проектов. Этот процесс настолько фундаментальный для развития
организаций, что институт SEI отнес его к области ключевых процессов уровня 2.
Требования сложно определять по различным причинам, включая тот факт, что мы
можем просто не знать, чего хотим до тех пор, пока не столкнемся с этим. Почти у всех
программных систем независимо от их размера есть множество организаторов и
классов организаторов (например, спонсоры, заказчики, пользователи, разработчики и
оценщики качества). В работе над программными продуктами принимает участие так
много людей с такими разнообразными точками зрения, что конфликт целей просто
неизбежен. В этой ситуации крайне важно установить нормальные партнерские
взаимоотношения между заказчиками и разработчиками в вопросах определения
требований и менеджмента. Менеджеры проектов при сборе требований могут использовать
ряд проверенных методов. В частности, можно определить факторы системы,
критичные к успеху, что подразумевает обмен информацией со всеми классами организаторов.
Необходимо также знать типы требований к ПО, характеристики хорошо написанных
требований и методы проведения эффективных встреч для достижения общего мнения
(опрос, "мозговой штурм", составление схемы мышления, FAST, JAD и схемы выбора).

546 Глава 16
В процессе работы над этой главой мы обращались за советом к нескольким
крупным специалистам в области разработки ПО. Так, Вайнберг, Прессман и Боэм
предоставили несколько полезных наборов действий; дали критерии определения
"хороших" требований (краткость, однозначность, тестируемость); дали понимание
проблемы, возникающей при создании аналитической модели, и способы ее
решения; помогли понять важность трассируемости и моделирования данных, функций и
моделей поведения; а также напомнили о том, что все сразу сделать невозможно.
Исходя из этой предпосылки, для требований необходимо определить приоритетность.
Контрольные вопросы
1. Просмотрите следующие утверждения, включающие требования, и определите,
насколько они "хороши".
Сводное окно должно отображать время поступления каждого заказа и
количество заказанных элементов.
Сводное окно должно отображать идентификатор покупателя.
В окне заказа пользователь должен иметь возможность сохранять, добавлять или
редактировать отдельный заказ.
В окне заказа пользователь должен обязательно указывать протокол заказа.
Объем имеющихся дефектов не должен превышать заданного ограничения.
Окно счетов должно отображать счета заказчика, где сначала указывается номер
счета, а затем — имя заказчика.
Интерфейс по отношению к пользователю должен быть дружественным.
Пользователь при внесении информации о заказе в форме должен использовать
минимальное количество нажатий клавиш.
Сообщения об ошибках должны отображаться в окне сразу же после ввода
пользователем некорректной информации.
Дата должна быть в стандартном формате.
Пользователю должна быть предоставлена возможность исправления ошибок
ввода.
Установка должна быть завершена за 45 минут.
Сообщения об ошибках должны использоваться для обработки эксплуатационных
ошибок, а также отображения состояния системного процесса и сбоев в программе.
Система должна иметь обширный набор функциональных свойств.
Эксплуатационные ошибки должны иметь возможность коррекции.
Для отображения сообщений об ошибках должно использоваться диалоговое
окно с описанием ошибки.
Определенные сообщения об эксплуатационных ошибках должны
сопровождаться инструкциями по диагностике.
Сообщения об ошибках должны содержать инструкции по восстановлению и
описание процедур.
2. Изучите диаграмму, представленную на рис. 16.6. Оцените эту диаграмму в
контексте представленного примера. Является ли она корректной и завершенной?,.

Формулирование требований 547
Практическое занятие
Мистер Ли, являющийся торговым представителем вашей корпорации в Китае,
обратился к мисс Пайтель, чтобы обсудить план продаж и структуру своих
комиссионных и квоты на следующий финансовый год. Ему было поручено продать
совершенно новую систему радио-, пейджинговой и сотовой связи одному из китайских
министерств. Так как один из его родственников работал в Министерстве по
радиовещанию, то он избрал именно эту организацию. В нашей корпорации используется
такой подход, что торговый представитель с наибольшими открытыми
предложениями имеет собственный счет. Господин Ли попросил мисс Пайтель, чтобы она не
использовала этот счет и не связывалась ни с кем, кроме него. Но сначала ему нужно
встретиться с мистером Лу и выяснить всю необходимую информацию.
У вас есть четыре недели для завершения этапа сбора требований. Этот этап
предположительно начнется через три дня, когда вы приедете в Пекин, чтобы встретиться с мисс
Пайтель и собрать требования при помощи мистера Лу и его команды.
Разработайте новый план сбора требований для данной ситуации.
Литература
Akao Y., ed. Quality Function Deployment. Cambridge, MA: Productivity Press, 1990.
BuzanTony. Use Both Sides of Your Brain, 3rd ed. NY: Penguin Putnam, 1991.
Buzan Tony, Tony Dottino, and Richard Israel. The Brainsmart Leader. Burlington, VT: Gower Pub,
1999.
Dorfman M., and R.H. Thayer, eds. Software Engineering. Los Alamitos, CA: IEEE Computer Society
Press, 1997.
Doyle Michael, and David Straus. How to Make Meetings Work: The New Interaction Method. NY: Penguin
Putnam, 1982.
Gorden Raymond L. Basic Interviewing Skills. Prospect Heights, IL: Waveland Press, 1998.
Guinta Lawrence R., and Nancy С Praizler. The QFDBook. NY: Amacom Books, 1993.
Haag Stephen, M.K. Raja, and L.L. Schkade. Quality Function Deployment Usage in Software
Development. Communications ofthe ACM, 39(l}:41-49, 1996.
Hammer Theodore F., Leonore L. Huffman, and Linda H. Rosenberg. Doing Requirements Right the
First Time. Crosstalk, Journal of Defence Software Engineering. December, 1998.
Hauser John R., and Don Clausing. The House of Quality. The Harvard Business Review, May-
JuneC):63-73. 1988.
Hunter Michael R., and Richard D. Van Landingham. Listening to the Customer Using QFD. Quality
Progress. 27D):55-59, 1994.
IEEE 1233. Guide for Developing System Requirements Specifications. Software Engineering Standards
Collection. NY: Institute of Electrical and Electronics Engineers, 1998.
IEEE 830-1998. IEEE Recommended Practice for Software Requirements Specifications. Software
Engineering Standards (jiuection. NY: Institute of Electrical and Electronics Engineers, 1998.
Jacobson Ivar, et al. Object-Oriented Software Engineering: A Use Case Driven Approach. Reading, MA: Addi-
son-Wesley, 1992.
Jazayeri A. Ran, and F. van der Linden. Software Architecture for Prodcut Families. Reading, MA: Addison-
Wesley, 2000.
Keil Mark, and Erran Carmel. Customer-Developer Links in Software Development. Communications of
ACM, 38E):33-44, 1995.
Koltzblatt Karen, and Hugh R. Beyer. Requirements Gathering: The Human Factor. Communications of
ACM, 38E):30-32, 1995.

548 Глава 16
Marqulies Nancy. Mapping Inner Space: Learning and Teaching Mind Mapping. Tuscon, AZ: Zephyr
Press, 1991.
Metzler Ken. Creative Interviewing: The Writer's Guide to Gathering Information by Asking Questions. NY: Allyn
& Bacon, Pearson Education, 1996.
Ogren Ingmar. Requirements Management as a Matter of Communication. Crosstalk, Journal of Defense
Software Engineering 13D), 2000.
Playle Greg, and Charles Schroeder. Software Requirements Elicitation: Problems, Tools, and
Techniques. Crosstalk, Journal of Defense Software Engineering 9A2), 1996.
Plsek Paul E. Creativity, Innovation, and Quality. NY: McGraw-Hill, 1997.
Ruinbaugh James. Getting Started: Using Use Cases to Capture Requirements. Journal of Object-Oriented
Programming, September, 1994.
Somerville Ian, and Gerald Kotonya. Requirements Engineering: Processes and Techniques. NY: John Wiley &
Sons, 1997.
Su'ehlo Kevin. Catching Up with the Joneses and 'Requirement' Creep. InfoWorld, July 29,1996.
Thayer Richard H., Merlin Dorfman, and Sidney C. Bailin, eds. Software Requirements Engineering 2nd ed.
Los Alamiios, CA: IEEE Computer Society Press, 1997.
Thayer Richard H., ed. Software Engineering Project Management. Los Alamitos, CA: IEEE Computer
Society Press, 1997.
Walters Stan B. Principles ofKinesic Interview and Interrogation. Boca Raton, FL: CRC Press, 1995.
Wiegers Karl E. Writing Good Requirements. Software Development, May, 1999.
Wycoff Joyce. Mindmapping: Your Personal Guide to Exploring Creativity and ProblemSolving. NY: Berkley
Books, 1991.
Дополнительные сведения в Internet
edweb.sdsu.eda/triton/gaides/Brainstorming.html.
members.ozemail.com.au/-caveman/Creative/Techniques/brainstorm.htm.
www.acq-ref.navy.mil/wcp/qfd.html. QFD
www.brainstorming, со. ик. Infinite Innovations Ltd. "Мозговой штурм ".
www.brainstorming.org.ик/tutorials/usenewpeople.html.
www. dhutton. com/samples/sampqfd.html. QFD.
www.directedcreativity.com. "Мозговой штурм".
www.humansource. com/trendspotting/19990201.htm. Интервью.
www. inspiration. com/. Схемы мышления.
www.mcli.dist.maricopa.edu/authoring/studio/guidebook/brain.html. "Мозговойштурм".
www.methods-tools.com/.
www.raindjet.com/. Схемы мышления.
www. nauticom. net/www/qfdi/. Институт QFD.
www.ozemaii.com.au/~caveman/Creative/Miridmap/. Особенности выбора узлов, имеющих
отношение к составлению схем мышления.
www. qfdi . org/. Институт QFD.
www.sdmagazine.com/documents/s=758/sdm9905c/9905c.htm.
www.zoo.co.uk/~z0001039/PracCuides/pg_use_cases.htm. Схемы выбора, Эдвард Кену-
орти (Edward Kenworthy).

Спецификация
требований к ПО
Определение корректных требований — это, наверное, самый ответственный этап
программного проекта. Очень важно, чтобы формат проекта соответствовал
требованиям к ПО, собранным командой разработчиков, в противном случае эти
требования не смогут быть поддержаны и представлены в программном продукте. Глава
посвящена описанию процесса составления спецификации требований к ПО (Software
Requirements Specification, SRS), используемого для текущего сопровождения и
представления требований, сформулированных по отношению к программному проекту.
Спецификация SRS имеет ключевое значение для всего жизненного цикла разработки
программного продукта. Это не только производный документ, в котором
определены спецификации программного проекта, но и основной документ, применяемый с
целью проведения аттестационных и приемочных испытаний. Аттестация — это
оценка качества работы менеджеров проекта. Она определяет степень соответствия
программного продукта установленным требованиям. Спецификация SRS выступает в
роли некоего механизма фиксирования системных требований, которые
используются в качестве критериев при аттестации.
Барри Боэм (Barry Boehm) впервые применил экономическую теорию в сфере
разработки ПО в 1981 году". На рис. 17.1 показано, что чем дальше продвигается
жизненный цикл проекта, тем дороже обходится устранение ошибок. Причиной
появления большинства ошибок на завершающих этапах жизненного цикла являются
нечетко сформулированные или пропущенные требования. Мы не можем изменить
экономическую теорию, но мы можем уменьшить количество ошибок на фазе жизненного
цикла, соответствующей определению требований, разработав подробную
спецификацию SRS. В главе приводятся рекомендуемые подходы к составлению
спецификации требований к ПО.
1 Boehm Barry W. Software Engineering Economics, Englewood Cliffs, NJ: Prentice-Hall, 1981.

550 Глава 17
Большие программные проекты
Фаза, на котором был обнаружен и устранен сбой
Рис. 17.1. Чем позже в жизненном цикле разработки ПО
обнаруживаются ошибки, тем дороже обходится их устранение
Стадии жизненного цикла
разработки продукта
Исследование концепции и системы уже завершено. Теперь необходимо
определить то, в какой степени конечный продукт будет подходить для работы в системной
среде. Этот момент является весьма важным, так как любой программный продукт
всегда функционирует в какой-то системной среде. На данный момент мы находимся
на этапе определения требований (рис. 17.2). При выходе за пределы этого этапа
будет получена спецификация требований к ПО.
Связь главы 17 с 34 компетенциями
Для менеджеров проекта при составлении качественных спецификаций SRS
крайне важно уметь обращаться с требованиями и правильно составлять документацию.
На данном этапе жизненного цикла разработки программного продукта основными
задачами менеджера проекта являются оценка временных затрат и разработка
графика работ на основании полученных требований.

Спецификация требований к ПО 551
V
Исследование
концепции
41
рование

потребности
11
ч
Исследование
системы
.
• Спецификация'
интерфейса
системы
ч
Требования
■ Спецификация •
требований
к ПО
^
<'
\
Разработка
проекта
„
• описание ■

разработки ПО
■ Пли
i <
\
Внедрение
тации/вери-
фикацииПО
<'
\
Установка
• Отчет об ат- '
тестации/ве-
рификации ПО
' Г
N
Эксплуатация
и поддержка
•
Пользовательская
документация
1'
,
v
Сопровождение
..... J .
■ До сументация'
по
сопровождению
i'
v
Вывод из
эксплуатации
t ....
■ Архивный
отчет
Рис. 17.2. Место процесса разработки спецификации требований к ПО в жизненном цикле
разработки продукта
В данной главе речь пойдет о следующих компетенциях.
Методики разработки продукта
1. Управление требованиями — отслеживание изменяющихся требований.
Навыки менеджмента проектов
2. Документирование планов — идентификация ключевых компонентов.
3. Оценка трудозатрат — оценка трудозатрат, требуемых для завершения проекта.
Навыки менеджмента персонала
4. Организация эффективных встреч — планирование и проведение эффективных
встреч.
5. Эффективное представление — эффективное использование письменных и
устных навыков.

i
i
552 Глава 17
Кроме того, почти во всякой работе, при которой наблюдается взаимодействие с
заказчиком, требуются следующие компетенции, имеющие отношение к управлению
персоналом: 26 — взаимодействие и общение; 27 — лидерство; 28 — управление
изменениями; 29 — успешное ведение переговоров; и 34 — создание команды.
Учебные цели главы 17
После изучения материала главы читатель должен уметь выполнять следующее:
■ разрабатывать подробную спецификацию SRS для программного проекта;
■ оценивать SRS относительно факторов, критичных по качеству;
■ планировать и оценивать процесс разработки SRS, который является частью
проектного этапа определения требований;
■ создавать базу для аттестационных и приемочных испытаний.
Вопросы, решаемые с помощью
спецификаций SRS
Основной вопрос, который решается с использованием спецификации SRS,— это
определение предметной области программного продукта. Как показано на рис. 17.3,
все программные продукты можно рассматривать относительно данных, процесса
и поведения.
Когда предметная область рассматривается в связи с данными, определяются
первичные объекты данных, которые будут обрабатываться программной системой. При
этом определяется не только сам объект, но и его расположение. Кроме того,
устанавливаются взаимосвязи между объектами и процессами, оперирующими этими
объектами. Например, для торговых автоматов важной частью данных является личный
идентификационный номер (PIN) покупателя.
Данные, передаваемые внутри программной системы,
/\ претерпевают множество преобразований. Именно на этих
/ \ преобразованиях и концентрируется внимание при рассмот-
&fb X\* рении предметной области в контексте процесса. В
специфику Предметная \& кации SRS фиксируются бизнес-требования, соответствующие
/ область \ процессу преобразования входных данных в выходной ре-
/ I \ зультат. Что касается нашего примера с торговым автоматом,
*■ * ^ этому процессу соответствует проверка PIN-номера.
поведение При рассмотрении аспекта поведения системы основное
Рис. 17.3. Три аспекта внимание уделяется состояниям, в которых эта система мо-
рассмотрения програм- жет находиться. После ввода PIN-номера в торговый автомат
много продукта он переходит в режим проверки введенного номера. После
этого запускается соответствующий процесс, и происходит
преобразование данных, однако, пользователь увидит только сообщение о результате
проверки PIN-номера.
Именно на этапе разработки спецификации SRS происходит переход от
распознавания и определения предметной области проекта к области решения. Затем трем
аспектам рассмотрения ставятся в соответствие три модели требований,
отображающие характеристики данных, процесса и поведения (рис. 17.4). К рассмотрению этих

Спецификация требований к ПО 553
моделей мы вернемся несколько позже. Таким образом, спецификация SRS
предоставляет каркас, обеспечивающий поддержку моделей.
При изучении программной системы в различных аспектах возникают вопросы,
которые приводят к понятию совокупности требований. Эти вопросы касаются
качества и способов проверки завершенной спецификации SRS. Компанией Construx
Software был предложен ряд контрольных списков (www.construx.com),
обеспечивающих контроль над процессом разработки ПО. Кроме того, стандарт IEEE 830-1998
содержит набор характеристик качества, которым должна соответствовать
спецификация SRS. Ниже приводится соответствующий краткий перечень:
1. корректность;
2. однозначность;
3. завершенность;
4. согласованность;
5. упорядочение элементов согласно их важности и/или устойчивости;
6. возможность верификации;
7. способность к изменению;
8. Возможность трассировки.
Рис. 17.4. Триада "процесс, данные, поведение"
На основании моделей контрольных списков и стандарта при помощи
спецификации SRS можно ответить на следующие вопросы, имеющие отношение к ключевым
характеристикам.

554 Глава 17
1. Корректность.
A. Определено ли ожидаемое время ответа для всех требуемых операций с точки
зрения пользователя?
B. Установлены ли какие-либо другие соглашения о времени, например, время
обработки данных, время передачи данных или пропускная способность системы?
C. Определены ли все задачи, необходимые пользователю?
D. Для всех ли задач определены входные и выходные данные?
E. Указан ли уровень защиты?
F. Обеспечивается ли необходимая надежность системы? В частности, определены
ли последствия программных сбоев, организована ли защита ключевой
информации от сбоев, организована ли система обнаружения и обработки ошибок?
G. Найдены ли компромиссные решения для согласования конкурирующих
свойств (например, запас прочности и корректность)?
Н. Определены ли внешние каналы общения с людьми, а также другими
программными и аппаратными системами?
I. Существует ли определение того, что считается успешным
функционированием, а что — сбоем?
2. Однозначность.
A. Достаточно ли ясны требования для того, чтобы быть выделенными в
независимую группу с целью их реализации на практике, и после этого все еще
оставаться понятными?
B. Отделены ли функциональные требования от нефункциональных?
3. Завершенность.
A. Все ли входные данные заданы для системы с указанием их источника,
точности, диапазона значений и частоты повторяемости?
B. Все ли выходные данные заданы для системы с указанием их направления,
точности, диапазона значений, частоты повторяемости и формата?
C. Были ли заданы все интерфейсы обмена данными с указанием средств
взаимодействия, проверки ошибок и коммуникационных протоколов?
D. Какая информация являлась недоступна на момент начала разработки?
Определены ли области незавершенности?
E. Полностью ли определены требования? Если продукт будет удовлетворять
всем требованиям, будет ли он принят?
F. Осталось ли чувство беспокойства относительно каких-либо требований?
Существуют ли такие требования, которые невозможно реализовать, и которые
включены только для того, чтобы удовлетворить заказчика или начальника?
G. Был ли выполнен полный анализ рисков с особым акцентом на пропущенных
требованиях?
4. Согласованность.
A. Указываются ли в составе требований детали разработки проекта?
B. Был ли выбран достаточный уровень согласованности для требований? Могут
ли какие-либо требования определяться более подробно? Можно ли для
описания каких-либо требований использовать меньше подробностей?

Спецификация требований к ПО 555
5. Упорядочение элементов согласно их важности и/или устойчивости.
А. Каждый ли элемент имеет отношение к проблеме и ее решению?
6. Возможность верификации.
т
A. Понятен ли пользователю язык, на котором излагаются требования? Согласны
ли пользователи с этими требованиями?
B. Все ли требования можно протестировать? Возможна ли независимая
проверка возможности удовлетворения всех требований?
7. Способность к изменению.
A. Определены ли возможные изменения требований, включая вероятность
изменения для каждого из них?
B. Определена ли эксплуатационная надежность системы, включая способность
отвечать на изменения операционной среды, интерфейсы с другими
программными системами, точность, производительность и другие расчетные
характеристики?
8. Возможность трассировки.
A. Не конфликтуют ли требования друг с другом?
B. Можно ли проследить каждый элемент до своего исходного состояния в
предметной среде?
Преимущества спецификации SRS
Использование документа SRS обеспечивает разработку однозначных
спецификаций, образующих завершенный документ. Подобные спецификации обеспечивают
взаимодействие менеджеров с организаторами проектов, благодаря чему и те, и
другие могут быть уверены в том, что:
1. заказчики программного продукта точно описали желаемый результат;
2. производители программного продукта осознают желания заказчиков;
3. персонал занимается:
а) разработкой SRS-схемы для проекта и организации;
б) определением формата и содержимого специфических требований к ПО;
в) разработкой дополнительных локальных пособий, подобно использованию
контрольного списка качества SRS или справочника лучших методов
организации производственных работ.
Корректно разработанная спецификация SRS предоставляет организаторам
проекта следующие специфические преимущества.
■ На основании SRS достигается согласие между заказчиками и производителями
программного продукта. В спецификации SRS полностью описаны функции,
которые должен выполнять разрабатываемый программный продукт. Это позволяет
потенциальным пользователям определить степень соответствия продукта их
потребностям, а также пути модификации продукта для того, чтобы он был
максимально полезен в решении их задач.

556 Глава 17
■ Снижаются временные затраты на разработку. В подготовке спецификации SRS
задействованы различные группы в организации заказчика. Они тщательно
исследуют все требования еще до того, как начнется непосредственная разработка
проекта. Это снижает вероятность последующей повторной разработки проекта,
кодирования и тестирования.
■ При тщательном изучении требований, представленных в спецификации SRS,
можно обнаружить недосмотры, недоразумения и противоречия еще на ранних
этапах цикла разработки, когда проблемы устранять гораздо легче, чем на более
поздних этапах.
■ Спецификация SRS становится основой для оценки стоимости и составления
графика работ. Описание продукта — это реальный базис для оценки стоимости
проекта. В среде, где существует понятие формального предложения, SRS используют
для утверждения оценки предложения или цены.
■ С помощью правильно составленных спецификаций SRS на уровне организации
могут разрабатывать намного более продуктивные планы аттестаций и проверок.
Являясь частью договора на разработку, SRS обеспечивает точку отсчета для
оценки соответствия техническим условиям.
■ Благодаря спецификации SRS облегчается передача программного продукта
новым пользователям, а также его установка на других компьютерах. Таким образом,
заказчикам становится проще переносить программный продукт в другие
подразделения организации, а разработчикам — передавать другим заказчикам.
■ Спецификация SRS служит основой для модернизации. В этом документе
рассматривается сам продукт, а не процесс разработки проекта, поэтому на ее основании
можно производить расширение завершенного продукта.
Разработка документа SRS
Определение требований является важнейшей частью проекта, а спецификация
SRS реализует механизм фиксации и хранения требований, имеющих отношение к
проекту. Некорректные, неточные или избыточные определения требований
приведут к задержкам при выполнении рабочего графика, перерасходу ресурсов или
неудовлетворенности заказчика. Применяемые методы анализа требований зависят от
специфики определенного типа проектных работ. Для многих областей
промышленности существуют испытанные специфические методики получения полных и точных
определений требований. При этом иногда составляется схематическое руководство
пользователя. Методы могут быть различными, однако принципы остаются
неизменными для проектов любого типа и размера. Анализ требований должен охватывать
весь объем проектных работ, а также быть исчерпывающим, всесторонним и
учитывать интересы всех организаторов проекта.
Если сократить анализ или пренебречь ясностью и строгостью, то полученные
определения требований будут неоднозначными. Перед тем как работа будет
продолжена, результаты проведенного анализа требований следует проверить и
утвердить со стороны заказчика или спонсора проекта. В больших проектах первой
формальной оценкой фактически является оценка требований.
Спецификация SRS может принимать любую форму, пригодную для
специфических нужд выполняемого проекта. Здесь же требуется рассматривать характеристики,

Спецификация требований к ПО 557
имеющие отношение к качеству. Представленный ниже шаблон базируется на
стандарте IEEE 830-1998 с некоторыми модификациями, основанными на практическом
опыте определения требований программных проектов. В этой базовой схеме SRS
учитываются все три точки аспекта изучения предметной области проекта. Она
служит для фиксации и поддержки требований, предъявляемых к проекту.
Титульный лист
Титульный лист определяет документ в виде спецификации требований к ПО.
Здесь же указываются авторы проекта и его название. Контрольный список вер
сий/переработок помещают либо на титульном, либо на следующем листе. Здесь
находятся сведения по версиям SRS и другие комментарии, имеющие отношение к
процессу менеджмента конфигурации.
Оглавление
Для создания оглавления используйте автоматизированный генератор, входящий
в состав средств проектного документирования.
Раздел 1. Введение
Следующие подразделы должны содержать обзор всего документа SRS. Сам по
себе раздел 1 может использоваться независимо в качестве резюме управляющего
(executive summary).
1.1. Назначение
Определите назначение данной спецификации SRS и перечислите специалистов,
для которых она предположительно предназначена. Укажите причину ее "появления
на свет" на данном этапе жизненного цикла продукта.
1.2- Область действия
1. Укажите название производимого программного продукта и кратко опишите его
функции.
2. С целью достижения максимальной определенности объясните, какие операции
программный продукт будет выполнять, а какие — нет.
3. Опишите области применения данного программного продукта, для чего необходимо:
а) как можно более точно описать преимущества и цели;
б) придерживаться согласованности с аналогичными утверждениями в
спецификациях более высокого уровня (если они существуют).
1.3. Допущения и зависимости
Перечислите и опишите все факторы, влияющие на требования, указанные в SRS.
Эти факторы не являются проектными ограничениями программного продукта,
причем любые их изменения могут повлиять на формулирование требований. Очень
важно, чтобы они были перечислены в первой части спецификации SRS. Часто
менеджеры и руководители ограничиваются прочтением только одного введения
(резюме управляющего), так как их работа заключается в содействии успешному
завершению проекта. Если они будут знать все допущения и зависимости, то смогут
лучше справиться со своей задачей.

558 Глава 17
Одно из допущений может заключаться в том, что аппаратное обеспечение, на
базе которого функционирует программный продукт, работает под управлением
специфической операционной системы. При этом в случае, если подобная операционная
система не используется, происходит изменение спецификации SRS. Подобные
основные зависимости должны быть в центре внимания руководства.
1.4. Обзор SRS
Опишите остальную часть спецификации SRS и ее структуру.
Раздел 2. Общее описание
Укажите общие факторы, влияющие на продукт и предъявляемые к нему требования.
Здесь не описываются специфические требования. Каждый из пяти подразделов
облегчает понимание требований, но они не содержат описания деталей проектирования или
каких-либо специфических требований. Подобные детали описываются в разделе 3.
2.1. Описание продукта
В этом разделе спецификации SRS описывается отношение данного продукта к
другим продуктам или проектам.
1. Если продукт независим и полностью автономен, то это необходимо указать в
данном разделе.
2. Если данный продукт определен в спецификации SRS как компонент большой
системы или проекта, необходимо выполнить следующие действия:
а) опишите функции каждого компонента большой системы или проекта, а также
определите интерфейсы;
б) не вдаваясь в подробности, определите основные внешние интерфейсы
данного программного продукта;
в) опишите аппаратные средства компьютера и периферийные устройства,
совместно с которыми будет использоваться программный продукт (здесь
уместен лишь беглый обзор).
С целью получения лучшего представления о среде, в которой будет функционировать
данный продукт, желательно нарисовать структурную схему основных компонентов
большой системы или проекта, указать взаимосвязи между ними и внешние интерфейсы.
2.2. Функции программного продукта
Здесь требуется кратко описать функции, выполняемые программным продуктом.
Иногда такое описание может заимствоваться прямо из раздела системной
спецификации, в котором указаны все функции программного продукта. Перечень функций
можно организовать в форме, удобной для понимания всех желающих. Здесь также
желательно использовать структурные схемы, изображающие взаимосвязи между
различными функциями.
2.3. Характеристики пользователей
Следует привести описание общих характеристик конечных пользователей
продукта, которые будут влиять на специфические требования. Большинство людей
взаимодействует с программными системами на этапах эксплуатации и
сопровождения. К ним относятся пользователи, операторы и обслуживающий персонал.
Некоторые характеристики этих людей (например, уровень образования, опыт работы и

Спецификация требований к ПО 559
техническая компетентность) накладывают на эксплуатационную среду системы
значительные ограничения. Именно для этих людей предназначены руководства
пользователей приложения. Никогда не бывает "слишком рано" для того, чтобы начать
составление документации для конечного пользователя. На момент завершения
спецификации SRS следует понимать способы взаимодействия пользователя с системой.
Если к этому времени руководство пользователя не будет написано, то послужит
явным сигналом того, что некоторые требования были пропущены.
2.4. Общие ограничения
Выполните общее описание всех элементов, ограничивающих действия на
разработчиков системы. Это описание может содержать:
1. регуляторную политику;
2. аппаратные ограничения (например, для требований относительно длительности
сигнала);
3. интерфейсы с другими приложениями;
4. параллельную работу;
5. функции аудита;
6. функции контроля;
7. требования к языку более высокого порядка;
8. протоколы установки связи;
9. критичность приложения;
10. учет безопасности и надежности.
Раздел 3. Специфические требования
В этом разделе мы ознакомим читателей с важнейшими подробностями,
необходимыми для разработки проекта. Обычно это самая большая и важная часть
документа SRS. В этом разделе описываются три точки зрения на предметную область
(см. рис. 17.3), а также содержатся диаграммы и модели требований.
1. Подробности должны определяться в виде отдельных специфических
требований. При этом следует учитывать характеристики качества (корректность,
однозначность, завершенность, согласованность, упорядочение элементов согласно
их важности и/или устойчивости, возможность проверки, способность к
изменению и возможность трассировки).
2. Специфические требования должны быть представлены в последовательной и
ясной форме.
3. Каждое требование должно формулироваться в такой форме, чтобы его
реализация могла быть объективно проверена одним из общепринятых методов.
4. Должны определяться источники требований, поскольку это облегчит понимание
источников проблем.
Ъ: Специфические требования необходимо классифицировать следующим образом:
а) функциональные требования;
б) требования, предъявляемые к производительности;

560 Глава 17
в) ограничения, связанные с выполняемым проектом;
г) признаки;
д) требования, предъявляемые к внешнему интерфейсу.
Есть четыре основных типа организации данного раздела. Конкретный выбор
зависит от имеющейся прикладной области и сути программного продукта.
1. На рис. 17.5 представлены функциональные требования, после которых следуют
четыре типа интерфейсных и других требований.
2. На рис. 17.6 представлены четыре типа требований к интерфейсам, привязанные
к отдельным функциональным требованиям. После этого приводится
спецификация остальных требований.
3. На рис. 17.7 проиллюстрированы все вопросы, затрагиваемые функциональными
требованиями, а после них следуют все остальные требования. Такой образец
применяется повторно для всех классификаций требований, предъявляемых к
внешнему интерфейсу.
4. На рис. 17.8 интерфейсные и все остальные требования определены в связи с
функциональными требованиями.
3. Специфические требования
3.1 Функциональные требования
3.1.1 Функциональное требование 1
3.1.1.1 Введение
3.1.1.2 Входныеданные
3.1.1.3 Обработка
3.1.1.4 Выходные данные
3.1.2 Специфические требования 2
3.1.п Специфические требования п
3.2 Требования, предъявляемые ко внешнему интерфейсу
3.2.1 Пользовательские интерфейсы
3.2.2 Аппаратные интерфейсы
3.2.3 Программные интерфейсы
3.2.4 Коммуникационные интерфейсы
3.3 Требования, предъявляемые к производительности
3.4 Ограничения при разработке проекта
3.4.1 Соответствие стандартам
3.4.2 Аппаратные ограничения
3.5 Характеристики качества
3.5.1
3.6 Другие требования
3.6.1 База данных
3.6.2 Эксплуатация
3.6.3 Адаптация при установке
Рис. 17.5. Изначально указываются все
функциональные требования

Спецификация требований к ПО 561
Выбор организации данного раздела SRS должен быть обусловлен корректностью
описания требований в наиболее приемлемом виде. Последующая схема шаблона
использует структуру, подобную представленной на рис. 17.5.
3.1. Функциональные требования
В этом разделе документа описывается, что именно продукт будет выполнять, до
какого уровня или требования он будет это делать, какие входные данные должны быть
преобразованы в выходные (методы этого преобразования не указываются) и какие для этого
требуются операции. Если логическое обоснование требования не является очевидным,
то укажите его явно. Перечислите все задачи, которые должны решаться на этом этапе.
3. Специфические требования
3.1 Функциональные требования
3.1.1 Функциональное требование 1
3.1.1.1 Спецификация
3.1.1.1.1 Введение
3.1.1.1.2 Входные данные
3.1.1.1.3 Обработка
3.1.1.1.4 Выходные данные
3.1.1.2 External Interlaces
3.1.1.2.1 Пользовательские интерфейсы
3.1.1.2.2 Аппаратные интерфейсы
3.1.1.2.3 Программные интерфейсы
3.1.1.2.4 Коммуникационные интерфейсы
3.1.2 Специфическое требование 2
3.1.п Специфическое требование п
3.2 Требования, предъявляемые к производительности
3.3 Ограничения при разработке проекта
3.4 Характеристики качества
3.4.1
3.5 Другие требования
3.5.1 База данных
3.5.2 Эксплуатация
3.5.3 Адаптация при установке
Рис. 17.6. Все требования, предъявляемые к интерфейсу,
привязаны к функциональным требованиям
Для каждой функции определите требования, предъявляемые к входным данным,
методам обработки и выходным данным. Обычно такие требования оформляются в
виде четырех подчиненных абзацев.
1. Назначение функции: логическое обоснование назначения функции.
2. Входные данные: источники, корректные диапазоны значений, временные
соглашения, операционные требования, специальные интерфейсы.
3. Выполняемые операции: проверка корректности, реакции на
непредусмотренные условия, виды методов обработки данных.

562 Глава 17
4. Выходные данные: назначение, корректные диапазоны значений, временные
соглашения, обработка некорректных значений, сообщения об ошибках, требуемые
интерфейсы.
3. Специфические требования
3.1 Функциональные требования
3.1.1 Функциональные требования
3.1.1.1 Введение
3.1.1.2 Входные данные
3.1.1.3 Обработка
3.1.1.4 Выходные данные
3.1.1.5 Требования, предъявляемые к производительности
3.1.1.6 Ограничения при разработке проекта
3.1.1.6.1 Соответствие стандартам
3.1.1.6.2 Аппаратные ограничения
3.1.1.7 Атрибуты
3.1.1.7.1 Защита
3.1.1.7.2 Возможность сопровождения
3.1.1.8 Другие требования
3.1.1.8.1 База данных
3.1.1.8.2 Эксплуатация
3.1.1.8.3 Адаптация при установке
3.1.2 Функциональное требование 2
3.1.п Функциональное требование п
3.2 Требования, предъявляемые ко внешнему интерфейсу
3.2.1 Пользовательские интерфейсы
3.2.1.1 Требования, предъявляемые к производительности
3.2.1.2 Ограничения при разработке проекта
3.2.1.2.1 Соответствие стандартам
3.2.1.2.2 Аппаратные ограничения
3.2.1.3 Характеристики качества
3.2.1.3.1
3.2.1.4 Другие требования
3.2.1.4.1 База данных
3.2.1.4.2 Эксплуатация
3.2.1.4.3 Адаптация при установке
3.2.2 Аппаратные интерфейсы
3.2.3 Программные интерфейсы
3.2.4 Коммуникационные интерфейсы
Рис. 17.7. После функциональных требований
указываются остальные требования, и в самом конце — требования,
предъявляемые к интерфейсу '
3.2. Требования, предъявляемые к внешнему интерфейсу
Этот раздел спецификации SRS содержит всю информацию, необходимую дл"я
правильной разработки интерфейсов с объектами, внешними по отношению к
данному программному продукту. Особенно важно задать требования для процесса взаи-

Спецификация требований к ПО 563
модействия конечного пользователя с программной системой. Если это требуется, в
данном подразделе описываются специфические интерфейсы с аппаратными
средствами, другими приложениями и коммуникационными системами.
3. Специфические требования
3.1 Функциональное требование 1
3.1.1 Введение
3.1.2 Входные данные
3.1.3 Обработка
3.1.4 Выходные данные
3.1.5 Внешние интерфейсы
3.1.5.1 Пользовательские интерфейсы
3.1.5.2 Аппаратные интерфейсы
3.1.5.3 Программные интерфейсы
3.1.5.4 Коммуникационные интерфейсы
3.1.6 Требования, предъявляемые к производительности
3.1.7 Ограничения при разработке проекта
3.1.8 Характеристики качества
3.1.8.1
3.1.9 Другие требования
3.1.9.1 База данных
3.1.9.2 Эксплуатация
3.1.9.3 Адаптация при установке
3.2 Функциональное требование 2
З.п Функциональное требование п
Рис. 17.8. После функциональных требований следуют
требования, выдвигаемые к интерфейсу, а затем — все
остальные требования
3.2.1. Пользовательские интерфейсы
Здесь указываются следующие сведения.
1. Характеристики всех интерфейсов, посредством которых пользователь
взаимодействует с программным продуктом. Например, если пользователь работает с
системой через дисплейный терминал, то указывается следующая информация:
а) требуемые форматы изображений на экране;
б) макет страницы и содержимое всех отчетов или меню;
в) сравнение времени ввода и вывода данных;
г) возможность использования программируемых функциональных клавиш.
2. Все аспекты оптимизации интерфейса. Это может быть просто список с
описанием визуальных элементов системы.
3.2.2. Аппаратные интерфейсы
Укажите логические характеристики всех интерфейсов между программным
продуктом и аппаратными компонентами системы. Опишите типы поддерживаемых
устройств, способ их поддержки, а также перечень применяемых протоколов. Здесь
также следует изобразить структурную схему взаимосвязей между аппаратными
блоками и связанными с ними программными функциями.

i
564 Глава 17 |
3.2.3. Программные интерфейсы
Укажите, какие должны использоваться программные продукты (например,
системы управления данными, операционные системы или математические пакеты), а
также интерфейсы с другими прикладными системами.
Для каждого программного продукта должна быть указана следующая информация:
1. название;
2. мнемосхема;
3. номер спецификации;
4. номер версии;
5. производитель.
Для каждого интерфейса:
1. описание назначения интерфейсного ПО относительно данного программного
продукта;
2. описание интерфейса в терминах содержимого сообщений и формата (интер
фейсы, снабженные документацией, подробно описывать не обязательно, —
достаточно указать только ссылки на определяющие их документы).
3.2.4. Коммуникационные интерфейсы
Укажите несколько коммуникационных интерфейсов, например, применяемые
протоколы локальной сети.
3.3. Требования, предъявляемые к производительности
В этом подразделе указываются как статические, так и динамические
количественные требования, предъявляемые к программному продукту или к процессу
взаимодействия человека с этим продуктом в целом.
1. Статические количественные требования могут включать в себя:
а) допустимое количество терминалов;
б) максимальное количество одновременно работающих пользователей;
в) допустимое количество одновременно обрабатываемых файлов и записей;
г) максимально возможные размеры таблиц и файлов.
2. Динамические количественные требования могу включать, например,
допустимое количество активных транзакций и задач, а также объем данных, который
может быть обработан за определенный период времени в обычных
обстоятельствах или в момент пиковой нагрузки.
Все эти требования должны указываться с применением измеримых терминов.
Например, правильным требованием будет: "95% транзакций должны быть
обработаны меньше, чем за 1 секунду", а не "оператор не должен ожидать завершения
транзакции".
Примечание. Количественные ограничения, накладываемые на определенную
функцию, обычно указываются в соответствующем пункте в разделе, посвященном ее
описанию.

Спецификация требований к ПО 565
3.4. Ограничения, связанные с выполняемым проектом
Ограничения проекта могут обуславливаться другими стандартами, аппаратными
ограничениями и особенностями операционной среды.
3.4.1. Соответствие стандартам
Укажите требования, обусловленные существующими стандартами или
инструкциями. Они могут включать:
1. форматы отчетов;
2. правила присвоения имен элементам данных;
3. процедуры учета;
4. аудиторское отслеживание.
Последний пункт предполагает необходимость отслеживания процесса
обработки данных. Такие трассировки необходимы для некоторых приложений, в
результате чего минимизируются затраты на управление. В подобных требованиях
может быть указано, что все изменения в базе данных платежей должны быть
записаны в файл трассировки. При этом сохраняются значения, которые были как до
внесения изменений, так и после них.
3.4.2. Аппаратные ограничения
Определите требования, предъявляемые к программному продукту,
обусловленные его функционированием в среде различных аппаратных ограничений.
3.5. Характеристики качества
К разрабатываемому ПО можно применять несколько характеристик качества.
Определите самые важные из них для данного продукта и создайте в
спецификации раздел для каждой из них. Определение характеристик качества
представлено на рис. 17.9.
3.5.1. Эффективность
Дайте логическое обоснование включению характеристики эффективности в
спецификацию для данного продукта.
Опишите, как можно определить присутствие, отсутствие или уровень этой
характеристики. Определите способы проверки этой характеристики после того, как
разработка продукта будет завершена.
3.5.п. Простота использования
В инструкциях отмечаются, что каждая характеристика качества должна быть
описана в отдельном подразделе. В номере данного раздела указан суффикс "п". Это
указывает на наличие более одной характеристики данного типа.
Опишите, как можно определить присутствие, отсутствие или уровень этой
характеристики. Определите способы проверки этой характеристики после того, как
разработка продукта будет завершена.
3.6. Другие требования
Некоторые требования могут быть обусловлены назначением программного
продукта, особенностями организации пользователей и т.п. Каждое такое требование
рассматривается в отдельном разделе.

566 Глава 17
3.6.1. База данных
В этом разделе указываются требования, предъявляемые к базе данных, которая
входит г) состав программного продукта;
1. типы информации;
2. частота использования;
3. права доступа;
4. описание элементов данных и файлов;
5. взаимосвязи между элементами данных, записями и файлами;
6. описание статической и динамической организации;
7. способы хранения требований, предъявляемых к данным.
Если используется какой-либо существующий пакет баз данных, то его название
должно быть указано в разделе 3.2.3, "Программные интерфейсы", а в текущем
разделе описываются подробности его использования.
Рис. 17.9. Характеристики качества
3.6.2. Операции
Этот раздел иногда включают в раздел "Пользовательские интерфейсы". В нем
\'казываются необходимые пользователю обычные и специальные операции,
например:

Спецификация требований к ПО 567
1. различные режимы осуществления операций в организации пользователя
(операции, инициатором которых является пользователь);
2. периоды диалоговых операций и периоды автоматических операций;
3. вспомогательные функции обработки данных;
4. операции резервного копирования и восстановления данных.
3.6.3. Требования, предъявляемые к адаптации при установке
Этот раздел содержит:
1. описание требований, предъявляемых ко всем специфическим для данного
расположения, предназначения или операционного режима данным и начальным
последовательностям (например, ограничения системы безопасности);
2. описание свойств, которые должны быть изменены для адаптации программного
продукта к установке.
Раздел 4. Информация о поддержке
Данный раздел спецификации SRS является неотъемлемой частью всех
формальных спецификаций требований. Спецификация SRS постоянно используется на
протяжении всего жизненного цикла продукта, а не только на этапе разработки.
Информация, которая содержится в этой спецификации, используется при обновлении вер
сий. Кроме того, она является очень важным элементом при аттестационных
испытаниях и последующих возвратных тестах.
4.1. Определения, сокращения и аббревиатуры
В этом разделе перечисляются все термины, сокращения и аббревиатуры,
необходимые для правильной интерпретации SRS. Сюда могут также быть включены ссылки
на приложения или какие-либо другие документы.
4.2. Ссылки
В этот подраздел включите следующую информацию.
1. Представьте полный перечень всех ссылок на документы, которые встречаются в SRS.
2. Для каждого документа укажите заголовок, номер отчета (если это возможно),
дату и издателя.
3. Укажите источники, из которых были получены эти ссылки.
4. Используйте как можно больше Web-ссылок.
5. Включите матрицу трассировки.
Матрица трассировки — это один из ключевых элементов на выходе из этапа
определения требований. Она используется на протяжении всего жизненного цикла
разработки ПО. Здесь находится информация, относящаяся к эволюции схемы нумерации для
раздела требований SRS, а также описывает топологию используемой структуры.
Пример матрицы трассировки требований представлен в табл. 17.1. В данном
случае требования рассматриваются относительно аппаратных модулей. Матрицы
трассировки могут отображать любые информационные измерения. Чаще всего
они используются при:
1. разработке пользовательского интерфейса;

568 Глава 17
2. аттестационных испытаниях;
3. приемочных испытаниях;
4. определении элементов соответствия договору;
5. в процессе обучения;
6. проектировании модулей;
7. в процессе написании исходного кода;
8. при документировании;
9. в процессе выявления внешних зависимостей;
10. при определении факторов качества;
11. в ходе обнаружения ошибок.
Таблица 17.1. Матрица трассировки требований
3.1
3.1.1
3.1.1.1
3.1.1.2
3.1.1.3
3.1.1.4
3.1.2
3.1.2.1
3.1.2.2
3.1.2.3
3 1.2.4
3.1.U
3.1.П.1
3.1.П.2
3.1.П..З
3.1.п.4
3.2
3.2.1
3.2.2
Номер требования и его описание
Функциональные требования
Функциональное требование 1
Введение
Входные данные
Обработка
Выходные данные
Функциональное требование 2
Введение
Входные данные
Обработка
Выходные данные
Функциональное требование п
Введение
Входные данные
Обработка
Выходные данные
Требования, предъявляемые к внешнему
интерфейсу
Пользовательские интерфейсы
Аппаратные интерфейсы
^
модуль
Аппаратный
X
X
X
X
X
(N
модуль
Аппаратный
X
X
X
X
X
X
т
модуль
Аппаратный
X
X
X
X
Ч"
модуль
Аппаратный
X
X
X
Л
модуль
Аппаратный
Ю
модуль
Аппаратный
г^
модуль
Аппаратный
X *
X

Спецификация требований к ПО 569
Окончание табл. 17.1
X X J3 X X X Л
к к к ч ч ч ч
£, 5; 5; 3v ?. ?, 3.
ч п п п ч ч п
б е> ег 3 о & о
s s a s s s s
,. ,, в >а « « в « я
Номер требования и его описание 2 2 3 3 2 3 3
г ISSIBEE
— ■*■* -* Л л rt л
а. а. о. о.
! ! f I i i I
3.2.3
3.2.4
3.3
3.4
3.4.1
3.4.2
3.5
3.5.1
3.5.2
3.5.3
3.5.4
3.5.5
3.5.6
3.5.7
3.5.8
3.6
3.6.1
3.6.2
3.6.3
Программные интерфейсы
Коммуникационные интерфейсы
Требования, предъявляемые к
производительности
Проектные ограничения
Соответствие стандартам
Аппаратные ограничения
Характеристики качества
Корректность
Однозначность
Завершенность
Согласованность
Упорядочение элементов согласно их
важности и/или устойчивости
Возможность верификации
Способность к изменению
Возможность трассировки
Другие требования
База данных
Операции
Адаптация при установке
X
X
X
X
X
X
X
X
X
4.3. Приложения
Приложения являются неотъемлемой частью реальных спецификаций
требований, хотя в некоторых из них и нет большой необходимости. Они могут содержать
следующее:
1. образцы форматов ввода/вывода, описания результатов анализа стоимости,
результаты других исследований;
2. вспомогательную или справочную информацию, полезную для работы с SRS;
3. описание проблем, решаемых данным программным продуктом;
4. историческую справку, происхождение, опыт использования и операционные
характеристики организации продукта;

570 Глава 17
5. упорядоченный список перекрестных ссылок на те незавершенные требования к
ПО, которые будут завершены на указанных промежуточных этапах;
6. специальные инструкции по упаковке программного кода, а также требования,
предъявляемые к средствам обеспечения безопасности, экспортированию,
начальной загрузке и т.д.
4.1. Предметный указатель
'1 икже как и оглавление, предметный указатель для спецификации SRS можно
сгенерировать автоматически.
Оценка спецификации SRS для проекта
В процессе построения спецификации SRS менеджер проекта всегда должен
помнить о характеристиках качества: корректность, однозначность, завершенность,
согласованность, упорядочение элементов согласно их важности и/или устойчивости,
возможность проверки, способность к изменению и возможность трассировки. Эти
характеристики оцениваются после завершения построения спецификации SRS.
Корректность
Спецификация SRS считается корректной только в том случае, если программный
продукт соответствует всем указанным в ней требованиям. Для проверки
корректности не существует каких-либо специальных средств или процедур. Разработанная
спецификация SRS может быть сопоставлена с какой-нибудь подходящей спецификацией
более высокого уровня (например, спецификацией системных требований), с другой
проектной документацией, а также с другими стандартами. Кроме того, корректность
может быть установлена на основании соответствия SRS фактическим потребностям
заказчика или пользователя.
Однозначность
Спецификация SRS считается однозначной только в том случае, если все
указанные в пен требования имеют только одну интерпретацию. Это, как минимум,
означает, что каждая характеристика конечного продукта должна быть описана с помощью
отдельного уникального выражения. В тех случаях, когда используемый термин
может иметь несколько трактовок, он помещается в глоссарий и описывается более
подробно. Спецификация SRS — это важная часть процесса определения требований
и составе жизненного цикла разработки ПО. Она используется при разработке
проекта, внедрении, наблюдении за ходом выполнения проекта, проверке и аттестации, а
также в а процессе обучения (как описано в стандарте IEEE 1074-1997).
Спецификации SRS должна быть однозначной как для своих разработчиков, так и для тех, кто
будет ею пользоваться в дальнейшем. Тем не менее, эти две группы людей часто имеют
разные уровни квалификации, а потому и к описанию требований к ПО могут
подходить по-разному. Способ представления спецификации требований, который
приемлем для разработчика, может быть сложен для восприятия пользователей и наоборот.
Для того чтобы избежать неоднозначности, обращайте внимание на следующие
специфические вопросы.
1. Недостатки естественного языка — требования часто записываются на естественном
человеческом языке (например, английском), который является изначально неодно-

Спецификация требований к ПО 571
значным. Спецификация SRS, написанная на таком языке, должна проверяться
независимым лицом с целью определения и устранения языковой неоднозначности.
2. Язык составления спецификаций требований — одним из способов, позволяющих
избежать неоднозначности естественного языка, является запись SRS с помощью
одного из специализированных языков составления спецификаций требований.
Соответствующие языковые процессоры автоматически обнаруживают многие
лексические, синтаксические и семантические ошибки. Одним из недостатков
использования подобных языков является трудность их освоения. Кроме того,
они непонятны многим пользователям, не являющимся хорошими специалистами
в технических вопросах. Более того, подобные языки больше подходят для
выражения только определенных типов требований для определенных типов систем.
Таким образом, их влияние на требования может быть практически незаметным.
3. Средства представления — методы определения требований,
специализированные языки, а также поддерживающие их средства можно разбить на три основные
категории: объектные, процессные и поведенческие. В случае применения
объектно-ориентированных подходов требования организуются в терминах объектов
реального мира, признаков этих объектов и служб, предоставляемых этими
объектами. В случае использования подходов, связанных с применением процессов,
термины организуются в виде иерархий функций, которые обмениваются
информацией посредством потоков данных. Поведенческие подходы описывают
внешнее поведение системы в терминах абстрактных представлений (например,
исчисления предикатов), математических функций или конечных автоматов.
Полезность подобных средств и методов при подготовке SRS зависит от размера и
сложности программы. В случае применения подобного подхода желательно
также составлять описания на естественном языке. Это позволит работать с SRS тем
заказчикам, которые не знакомы с условными обозначениями.
Завершенность
Спецификация SRS считается завершенной только в том случае, если она
содержит следующие элементы.
1. Все значимые требования, имеющие отношение к функциональным, свойствам,
проектным ограничениям, признакам и внешним интерфейсам. В частности
должны быть указаны и учтены все внешние требования, обусловленные
системной спецификацией.
2. Описание реакций программного продукта на все доступные тины входных
данных во всех возможных ситуациях. Обратите внимание на то, что должны быть
указаны реакции, как на корректные, так и на некорректные входные значения.
3. Метки и ссылки на все рисунки, таблицы и диаграммы в SRS, а также определение
всех терминов и единиц измерения.
4. Не должно быть ни одной метки "подлежит определению" (То Be Determined,
TBD). Если в каком-либо разделе есть метка TBD, то он должен также содержать
описание причин использования TBD (например, почему неизвестен ответ на
некоторый вопрос), чтобы данная ситуация могла быть разрешена в дальнейшем;
описание действий, необходимых для устранения TBD; а также перечень
ответственных и время устранения TBD.

572 Глава 17
Согласованность
В рассматриваемом случае имеется в виду внутренняя согласованность. Если
спецификация SRS не соответствует каким-либо документам более высокого уровня
(например, спецификации системных требований), то она либо несогласованна, либо
некорректна. Спецификация SRS считается согласованной внутренним образом только
и том случае, если ни одно из подмножеств отдельных требований не конфликтует ни с
одним другим подмножеством. Существует три вида вероятных конфликтов в SRS.
1. Конфликт между характеристиками объектов реального мира.
- Формат выходных отчетов может быть описан в одном требовании в виде
таблиц, а в другом — в виде обычного текста.
- В одном требовании может быть указано, что все лампочки должны быть
зеленого цвета, а в другом — синего.
2. Логический или временной конфликт между двумя действиями.
- В одном требовании может быть указано, что программа складывает два числа,
а в другом — что программа их перемножает.
- В одном требовании может быть указано, что "Б" всегда следует только после
"А", а в другом — что эти две буквы могут встречаться одновременно.
3. Два требования или большее их количество в различных выражениях могут
описывать один и тот же объект реального мира. Например, программный запрос на
ввод информации пользователем в одном требовании может быть назван
"приглашением", а в другом "сигналом". Для обеспечения согласованности лучше
использовать стандартную терминологию.
Упорядочивание элементов согласно их важности
и/или устойчивости
Спецификация SRS считается упорядоченной согласно важности и/или
устойчивости элементов только в том случае, если в ней для каждого требования
используются идентификаторы важности или устойчивости. Обычно требования,
предъявляемые к программному продукту, имеют различную важность. Некоторые из них могут
быть крайне важными (особенно в приложениях, от которых зависит жизнь людей), а
другие — только желательными. Для каждого требования, указанного в SRS, данное
различие должно быть проведено четко и очевидно.
Подобное определение требований помогает: ч
1. заказчикам более внимательно относиться к каждому требованию и выявлять
скрытые допущения:
2. разработчикам принимать корректные проектные решения и правильно
распределять усилия по разработке отдельных частей программного продукта.
Степень устойчивости
Один из методов определения требований использует величину устойчивости.
Устойчивость можно определить как количество ожидаемых изменений требования на
основании практического опыта работы или знания будущих событий, которые
повлияют на организацию, функции и людей, обслуживающих программную систему.

Спецификация требований к ПО 573
Степень необходимости
Еще одним способом упорядочивания требований является их подразделение на
необходимые, условные и необязательные.
1. Необходимые —программный продукт не сможет работать до тех пор, пока
соответствующим образом не будут реализованы эти требования.
2. Условные — могут улучшить программный продукт, однако, он будет работать
даже в случае их отсутствия.
3. Необязательные — имеют отношение к функциям, которые в одних случаях могут
быть полезными, а в других — нет. Такие требования дают разработчику
возможность предлагать функциональность, выходящую за рамки SRS.
Возможность верификации
Спецификация SRS считается подлежащей верификации только в том случае, если
каждое указанное в ней требование является верифицируемым. Требование
считается верифицируемым только в том случае, если существует какой-либо ограниченный
процесс, в течение которого человек или компьютер могут установить соответствие
продукта данному требованию. В общем случае все неоднозначные требования
являются неверифицируемыми. Неверифицируемые требования обычно определяются
словесными формами "работает хорошо", "хороший пользовательский интерфейс" и
"обычно происходит". Подобные требования не могут быть верифицированы, потому
что невозможно дать четкое определение терминам "хороший", "хорошо" или
"обычно". Требование типа "программа никогда не должна попадать в бесконечный
цикл" также является неверифицируемым, так как не существует теоретической
возможности проверки его качества.
Приведем пример верифицируемого требования.
"Выходные данные программы должны быть получены в течение 20 секунд,
отведенных на обработку события, умноженных на 60% общего времени или в течение 30
секунд, отведенных на обработку события, умноженных на 100% общего времени".
Подобное утверждение можно верифицировать, потому что в нем используются
конкретные термины и измеримые величины. Если для верификации соответствия
программного продукта какому-либо требованию невозможно воспользоваться каким-
либо методом, то такое требование должно быть удалено либо пересмотрено.
Способность к изменению
Спецификация SRS считается изменяемой только в том случае, если ее структура и
стиль позволяют легко внести любые изменения в требования, не нарушая при этом
самой структуры и стиля.
Способность к изменению обычно подразумевает:
1. наличие логически последовательной и простой в использовании структуры SRS с
оглавлением, предметным указателем и подробными перекрестными ссылками;
2. отсутствие избыточности (это означает, что одно и то же требование не повторяется);
3. независимое определение каждого требования, не смешанное с определениями
других требований.

574 Глава 17
Избыточность, сама по себе, не является ошибкой, но она может легко привести к
возникновению ошибок. Иногда избыточность приводит к лучшей восприимчивости
спецификации SRS, однако, в процессе модификации такого документа могут
возникнуть проблемы. Например, требование может быть изменено только в одном месте, а
в другом остаться неизменным. В этом случае спецификация SRS становится
несогласованной. Если необходимо внести избыточность, то в SRS должны быть также
включены подробные перекрестные ссылки. Это позволит в дальнейшем выполнять
корректную модификацию таких требований.
Возможность трассировки
Спецификация SRS считается трассируемой в том случае, если в ней явно
прослеживается происхождение каждого требования и если она позволяет быстро найти
любое требование для дальнейшего использования при разработке продукта или
доработке документации.
Рекомендуется использовать следующие два вида трассировки.
1. Возможность обратной трассировки (направлена в сторону предыдущих этапов
разработки). Она зависит от ссылок на источники требований в более ранних
документах.
2. Возможность прямой трассировки (применяется ко всем документам, созданным
в процессе построения SRS). Она зависит от того, имеет ли каждое требование
в SRS уникальное имя или ссылочный номер.
Возможность прямой трассировки SRS особенно важна на этапах эксплуатации и
обслуживания программного продукта. В случае изменения исходного кода и
проектное документации должна быть предусмотрена возможность установки полного
набора требований, на которые могут повлиять внесенные модификации.
Полезные советы
1. Избегайте избыточности, иначе, например, раздел 2 будет пересекаться с
разделом 3. Избыточность усложняет сопровождение документа.
2. Нумеруйте каждый раздел. Это упростит трассировку и создание трассировочных
таблиц.
3. Лучше один раз увидеть, чем сто раз услышать. Если требование сложно
объяснить в текстовом виде, то в этой ситуации может помочь диаграмма.
4. Диалоговые окна лучше не описывать в тексте, а нарисовать. Для представления
элементов пользовательского интерфейса также используйте графику.
Резюме
Получение корректных требований — это самая важная задача в процессе
разработки программного продукта. Когда разработчики начинают сбор требований,
относящихся к проекту, очень важно, чтобы проект имел согласованный формат для
обработки и представления этих требований. В данной главе рассматривалась
структура спецификации требований к ПО (Software Requirements Specification,
SRS), которая используется для обработки и представления требований, формули-

Спецификация требований к ПО 575
руемых по отношению к проекту. Спецификация SRS имеет значение на
протяжении всего жизненного цикла разработки ПО. Это не просто производный
документ, содержащий проектные спецификации, а основа для проведения
аттестационных и приемочных испытаний. В ходе проведения аттестации оценивается
качество работы менеджеров проекта. Она определяет степень соответствия
программного продукта установленным требованиям. Спецификация SRS — это
механизм фиксирования системных требований, которые используются в качестве
критериев при аттестации.
В процессе разработки спецификации SRS менеджер проекта всегда должен
помнить о характеристиках качества SRS: корректность, однозначность, завершенность,
согласованность, упорядочение элементов согласно их важности и/или
устойчивости, возможность проверки, способность к изменению и возможность трассировки.
Эти характеристики всегда оцениваются после завершения построения SRS.
Контрольные вопросы
1. В стандарте IEEE определен полезный набор спецификаций, которые могут быть
преобразованы в шаблоны для фиксации и обработки требований к ПО. Найдите
в Internet другие шаблоны, предоставляемые другими международными
организациями по стандартам.
2. Каким образом проектная схема WBS связана со спецификацией SRS? Какие
можно внести изменения в WBS на основании того, что было изучено относительно
структуры SRS?
3. Влияет ли структура SRS на процессы жизненного цикла?
4. Как незавершенная спецификация SRS влияет на оценку графика работ и
стоимости проекта?
Практическое занятие
Все задержки, внесенные в план выполнения проекта, уже утверждены, поэтому у
пас есть только два дня на разработку шаблона SRS, после чего потребуется
приступать к сбору требований. Вы ошибочно интерпретировали 5-й уровень возможностей
модели СММ для BSD, указав, что разрабатываемая система может "сохранять любые
рабочие графики программного проекта". Теперь нужно каким-то образом исправить
положение. Завтра начнет отмечаться День независимости Индии, и все учреждения
будут закрыты в течение четырех дней. Каким образом вы собираетесь исправить
шаблон для сбора требований, необходимый мисс Пайтель и мистеру Лу? Какие
средства будут использованы и как вы объясните необходимость их использования? Не
забывайте, что мисс Пайтель не в восторге от стандартов IEEE.
Литература
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications. IEEE
Computer Society.
Pressman Roger S. Software Engineering: a Practitioner's Approach, 5th ed. NY: NcGraw-Hill, 2001.

576 Глава 17
Дополнительные сведения в Internet
sel .gsfc.nasa.gov/website/documents/contents.html. Аннотированная библиография
лаборатории Software Engineering Laboratory (SEL); ноябрь 1998. Национальная администрация
аэронавтики и исследования космоса (NASA), Центр подготовки космонавтов им. Годдарда (Goddard
Space Flight Center (GSFQ), Green belt, MD.
www.atlsysguild.com/GuildSite/Robs/Template.html. Описываемый здесь шаблон
спецификации требований используется в качестве основы для разработки спецификаций. Он
содержит разделы для всех типов требований, соответствующих современным программным системам. На
этом Web-узле находится PDF-версия шаблона, которой можно воспользоваться в процессе сбора
требований. Данный шаблон может применяться при работе с такими популярными средствами
сбора требований, как Requisite, DOORS и Caliber RM.
www.construx.com/. Компания Construx Software занимается разработкой программных
средств, предназначенных для управления производством, консультирования, обучения, а также
разработкой ПО на заказ. Программные продукты позволяют составлять контрольные списки,
создавать шаблоны и производить оценку требований.
www. imappl .org/crest/requizement.html. В основе работы группы CREST лежат
партнерство и практический опыт. Онн входят в состав департамента системных и компьютерных наук
Говардского университета и занимаются опытным исследованием и оценкой средств, методов и
ресурсов, которые используются при разработке ПО.

Определение рисков,
связанных
с выполнением проекта
Управление рисками, связанными с разработкой ПО, представляет собой
формальный процесс, позволяющий систематически идентифицировать, оценивать и
смягчать факторы возможного риска. В процессе управления проектом основное
внимание уделяется вопросам идентификации рисков в проекте, имеющих как
внутренние, так и внутренние причины. В документе РМВОК риск определяется как
совокупность элементов в управлении проектом, включающих процессы идентификации,
анализа и ответных реакций на риски, возникающие в проекте. Эти элементы
охватывают "идентификацию рисков, их количественную оценку, разработку откликов на
риск и контроль откликов на риск" . Предназначенная в помощь менеджеру проекта в
процессе определения и управлениями рисками, эта глава позволит получить ответы
на следующие вопросы.
■ Что такое риск, связанный с управлением проектами?
■ Каковы некоторые модели, отражающие особенности риска менеджмента?
■ Каким образом выполняется идентификация рисков?
■ Как анализируются и количественно оцениваются риски?
■ Какова методика совершенствования откликов на риск и каким образом
реализуется управление рисками?
■ Какие шаги способствуют разработке плана по управлению рисками?
Управление рисками представляет основную проблему и в других областях,
связанных с управлением проектом. На рис. 18.1 приводится обзор документа
РМВОК, где отмечено, каким образом управление рисками применяется в других
областях знаний.
PMI Standards Committee, William R. Duncan, Director of Standards. A Guide to the Project
Management body of Knowledge. Newtown Square, PA: Project Management Institute, 1996.

578 Глава 18
ОБЛАСТЬ
ДЕЙСТВИЯ
Выполнимость
ожиданий
КОЛИЧЕСТВО
ИНТЕГРАЦИЯ
В ПРОЦЕССЕ МП
Т
Жизненный
цикл и переменные
среды
_i_
ОБЩЕНИЕ
~7
Идеи, директивы
и точность, достигаемая
при обмене данными
Стандарты
РИСК
Возможная
ПЕРСОНАЛ
требований продуктивность
Временные целевые Стоимостные „„„ .Р£Ш!?!11»f,?™„„■
ограничения целевые ограничения при выборе материалов,
ограничения целевые ограничения првдПрИЯТИйи служб
ВРЕМЯ
ЦЕНА
КОНТРАКТЫ
Рис. 18.1. Интегрирование областей знаний, определенных в РМВОК,
и управление рисками
Стадии жизненного цикла
разработки продукта
Управление рисками начинается с исследования понятий, способствующих
одобрению программного проекта. Хороший менеджер проекта должен хорошо
справляться с оценкой и управлением рисками, возникающими при разработке программ.
Управление рисками охватывает весь жизненный цикл разработки, вплоть до сдачи
проекта. Анализ возникающих рисков и непрерывное планирование ведется
постоянно на всех стадиях жизненного цикла разработки ПО. Риски анализируются,
определяются их приоритеты с учетом недельного графика работ, причем текущий список
рисков из "первой десятки" оглашается на еженедельном собрании, на котором
рассматривается текущее состояние проекта. Единственная возможность по смягчению
степени влияния рисков заключается в их обработке участниками команды
разработчиков проекта. На рис. 18.2 показано, какое место занимает управление рисками в
жизненном цикле разработки ПО.
Связь главы 18 с 34 компетенциями
В главе основное внимание уделяется изучению методов оценки риска со стороны
менеджера проекта. При этом ключевое значение имеет компетенция под номером
16, описывающая управление рисками. Умение обрабатывать риски является
основным в деятельности любого менеджера. Для менеджеров программных проектов
именно эти навыки представляются наиважнейшими, поскольку порой упущения в
этой сфере "сводят на нет" усилия, направленные на выполнение проекта. Следует
учитывать, что программные проекты постоянно усложняются, вследствие чего
весьма затруднительно рассматривать продукт как единое целое. Вследствие этого
затрудняется процесс тестирования и доступ к программному продукту.

Определение рисков, связанных с выполнением проекта 579
Исследование
концепции
•Формули-'1
рование

потребности
Исследование
системы
■ Спецификация''
интерфейса
системы
Требования
■ Спецификация
требований
к ПО
Разработка
проекта
• Описание

разработки ПО
Внедрение
■ План

тации/верификации ПО
Установка
■Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
■
Пользовательская
документация
Сопровождение
' Документация
по
сопровождению
Выводиз
эксплуатации
Анализ проектов
- План уменьшения рисков
■ Архивный
отчет
Мониторинг и контроль проектов
Выполнение планирования случайностей
■ Планирование случайных факторов
Управление проектом
• Отчеты об управлении проектом
Ведение журнала
• Хронологические записи о проекте
Реализация методов отчета о трудностях
■ Отчет о разрешенных проблемах
• Отчет об основных расширениях проблем
■ Проанализированный отчет о проблемах
Рис 18.2. Роль управления рисками в жизненном цикле разработки программного продукта
Чтобы эффективно управлять рисками, менеджер проекта должен иметь
достаточно высокий уровень подготовки по следующим компетенциям: выполнение
начальных оценок, составление графика, проведение эффективных собраний и
презентаций. Определение рисков осуществляется в ходе начального оценивания. Профиль
уточненных рисков оказывает влияние на оценивание и выполнение произвольных
графиков. Основной задачей менеджера проекта при проведении интервью и собра-

580 Глава 18
нпй является определение рисков. Собрания и презентации представляют наиболее
распространенные коммуникационные возможности менеджера проекта. Наряду с
другими задачами менеджмента проекта на определение рисков оказывают влияние
некоторые из рассматриваемых нами 34 компетенций.
Учебные цели главы 18
После изучения материала главы читатель должен уметь выполнять следующее:
■ описывать источники возникновения рисков при разработке любых программных
проектов;
■ формировать таблицу категорий рисков при разработке любых программных
проектов;
■ определять вероятность проявления основных рисков, связанных с разработкой ПО.
Определение управления рисками
Управление рисками включает ясное понимание внутренних и внешних причин,
влияющих на проект, которые могут привести к его срыву. Анализ рисков
выполняется после формирования плана проекта. В результате начального анализа риска
создастся план рисков, который должен регулярно просматриваться и корректироваться.
Главной целью управления рисками является идентификация и контроль за редко
встречающимися факторами, которые приводят к вариациям проекта. Подобный подход
отражается в формальном процессе, когда факторы риска систематически
идентифицируются, оцениваются и поддерживаются.
Что касается определения программы, то определение SEI довольно точно
передает суть проблемы: "Риск отражает возможные существенные потери" . При
разработке программного проекта потери определяют негативное влияние на проект. Это
влияние может привести к ухудшению качественных показателей конечного
продукта, к увеличению затрат, смещению сроков или же к полному срыву проекта. Риски
i п-ражают неопределенность или же недостаточный объем знаний, касающихся
спектра всех возможных будущих событий. Эти события можно разделить на
благоприятные и неблагоприятные для выполнения проекта в будущем.
Вообще говоря, риск подразумевает лишь возможность появления существенных
потерь или ущерба. Можно выделить следующие категории риска:
■ внутренний, который находится в сфере влияния менеджера проекта;
■ внешний, находящийся вне сферы влияния менеджера проекта.
План разработки программного проекта представляет лишь прекрасно
подготовленный прогноз относительно запланированных событий. На протяжении
жизненного цикла проекта может происходить большое число событий, не внесенных в этот
план. Эти события и составляют вариацию. Умелый менеджер проекта в состоянии ее
минимизировать. На рис. 18.3 показаны возможные проявления риска в проекте,
приведена классификация рисков, а также особенности проекта, идентифицирующие
риски и определяющие смягчение их влияния.
и mi >. set. <mu. edu/programms/sepm/risk/.

Определение рисков, связанных с выполнением проекта 581
Менеджер проекта имеет дело с рисками, которые можно классифицировать
следующим образом.
1. Известное в известном. Эти риски известны команде разработчиков проекта
наравне с тем, что определена категория риска, а также реальные оценки рисков для
данного проекта. В качестве примера подобного риска можно указать отсутствие
исполнительного спонсора для крупных разделов проекта. Если исполнительный
спонсор отсутствует, проявляющийся в этом случае риск относится к известному
типу, а относительно его наличия в данном проекте также можно сделать
определенные выводы. Риск, относящийся к категории "известное в известном", также
может связываться с риском той категории, который можно смягчить в данном
проекте. Эти риски указываются и описываются в плане по менеджменту проекта.
2. Известное в неизвестном. Эти риски известны команде разработчиков проектов,
знакома категория риска, но неизвестны его реальные проявления для данного
проекта. Например, отсутствие связи с конечным пользователем приводит к
риску, связанному с отсутствием корректности при идентификации требований. Если
для данного проекта неизвестно, будет ли обеспечен доступ к конечному
пользователю, речь идет об известном типе риска. Однако неизвестно, существует ли
вообще риск для данного проекта. Подобные риски описываются в плане
менеджмента рисков, где определяется их приоритетность, а также еженедельно
обновляются сведения о рисках.
3. Неизвестное в неизвестном. Эти риски известны команде разработчиков проекта,
знакома категория риска, но неизвестны его реальные перспективы для данного
проекта. Несмотря на то, что менеджеры проекта используют при классификации
рисков довольно обширные категории, в технологической области может иногда
проявляться "неизвестное в неизвестном". Подобный пример проявляется в том случае,
если проект использует специфическое технологическое решение, которое
формулируется в терминах контракта для данного проекта. И хотя подобное положение
вещей само по себе таит определенный риск, при отсутствии опыта работы с
инструментом менеджер проекта не может знать всех потенциальных рисков, которые
может повлечь за собой применение инструмента. Для учета этих потенциальных
рисков можно предложить только наиболее общий подход, предполагающий
определение бюджета для преодоления возможных случайных последствий.
Финансирование
возникающих План План
случайностей управления рисками менеджмента проекта
Рис. 18.3. Спектр неопределенности рисков

582 Глава 18
Используя планы управления проектом и рисками, менеджер проекта приступает
к идентификации бюджетных средств, направленных на преодоление случайностей.
На рис. 18.4 показано соотношение риска и стоимости проекта (в долларах) на
протяжении жизненного цикла. Отображаясь на фазы жизненного цикла разработки
продукта и проекта, определенные в стандарте IEEE 1074, инвестиции в проект
постепенно растут вплоть до завершения фазы формулирования требований. Наряду с
учетом требований, исследование концепций и системы представляют первые три
фазы жизненного цикла. В течение этих фаз планирование проекта оказывает
наибольшее влияние на процедуру смягчения рисков. Присущий изначально проектный
риск имеет наибольше влияние именно в этот период времени, на этапе выполнения
проекта влияние ослабевает.
На фазах разработки проекта, внедрения и установки резко возрастает
редукционный потенциал риска, связанного с выполнением проекта. Если предположить, что
менеджеры проекта имеют большой опыт работы, а проекты ведут себя вполне
предсказуемо, степень риска продолжает уменьшатся, а объем инвестиций в проект
плавно возрастает. Последние три фазы — эксплуатация и поддержка, сопровождение и
вывод из эксплуатации отличаются наименьшими значениями риска, связанного с
разработкой ПО. Эти фазы также отличаются наибольшими значениями инвестиций.
Однако именно на протяжении этих трех фаз наибольшее влияние приобретает риск,
связанный с выходом на рынок программного обеспечения.
Часть рисунка, отмеченная как "Область наибольшего влияния на процесс
смягчения риска" касается требований, разработки проекта, внедрения и частично процесса
установки. Именно в этой области менеджер проекта может оказать наибольшее
влияние на процесс уменьшения рисков. По мере того, как риски уточняются и их
влияние смягчается, вероятность проявления риска плавно уменьшается, а
инвестиции, направленные в проект, приобретают прогнозируемый характер. Если же риски
не идентифицированы и их влияние не смягчено, стоимость проекта быстро растет.
~
пен
1—
О
Исследование
концепции
Исследование
системы
'■'^Xth ;
- -'. ;' ''.'■£
?:Щ2$
i;v-?V*J«4
шт
*-.-■->:эй;
^4£-4vV
W-Q;t*
тф-
шт
>&%*'.<■*
-Ш-&
3 "эффёсттШ^^^Щш
,.--•, ^ ~
Требования
Наибольшая степень
влияния п
ланироваж
w проекта
"ШЙйШ
Разработка I Ви.лп.и1И
проекта | Внв«|енив
т
щ
fit
■•'4
и
т
'ш£ —.
п
Наибольшая степень
влияния
зыполнения
проекта
Эксплуатация
и поддержка

Сопровождение
Г
3
*
епа (в
!
хэ
^
Вывод из
эксплуатации
Преобладание
про
дукта на ры
нке
Рис. 18.4. Проектные риски, проявляющиеся во время жизненного цикла
разработки ПО

Определение рисков, связанных с выполнением проекта 583
После того как менеджеры проекта идентифицируют риски в пределах
жизненного цикла разработки ПО, а также уточнят тактики по смягчению их влияния,
возникает необходимость в идентификации уровня толерантности риска. В зависимости от
личных пристрастий и требований организации, уровни толерантности варьируются
от оценочных откликов до действий, предполагающих использование
альтернативных подходов. На рис. 18.5 демонстрируются разнообразные подходы. Прямая,
проходящая из начала координат под углом 45 градусов вправо и вверх, представляет так
называемый нейтральный риск. Эта прямая состоит из точек балансирования между
объемом финансовых инвестиций и вероятностями события, связанного с
проявлением риска. Отдельные программисты и команды разработчиков, любящие риск,
могут воспользоваться верхней кривой. При этом возрастают потенциальные потери
вследствие возможного наступления события, связанного с проявлением риска. Те
же, кто предпочитает избегать рискованных ситуаций, воспользуются параметрами
области, расположенной ниже нейтральной прямой. И хотя риска можно избежать,
возможные значения прибыли окажутся меньшими, чем в случае выбора точек
нейтральной прямой. И чем больше финансовых средств инвестируется во избежание
появления рискованной ситуации, которая так ли иначе случается, тем больший
объем средств теряется для инвестиций с другими целями. Причем упускается
возможность инвестирования этих средств и получения отдачи от их использования. Все это
и определяет возможные издержки.
$$
__^
ПРЕМИЯ
размер ставки
Г)
Авантюрист _-- • i
-- * '
**' '
' 1
У i
У 1
/ ^ /
/ У S
! '
} '
i *
1 ~ ,~' Любитель
1 S „*«•' СПОКОЙНОЙ ЖИЗНИ
1 ' -—-
1.0
РИСК
(вероятность наступления рискового события)
Рис. 18.5. Отклонения в толерантности риска
Деловые риски следует отделять от проектной идеи "чистого риска". Деловой или
присущий изначально риск позволяет оценить шанс, состоящий в получении дохода или
убытка в связи с любой деловой деятельностью. Чистый риск или страховой риск
описывает возможность потерь. Примерами подобных потерь служат непосредственная
утрата имущества, значительные косвенные потери, персональный ущерб и
юридическая ответственность. Непосредственная утрата имущества включает затраты на
страхование имущества, ущерб от автомобильных аварий, пожаров и краж.
Примером значительных косвенных потерь может служить защита участников контракта от
непрямых потерь, которые можно понести по вине третьей стороны; устранение

584 Глава 18
недоработок и замена оборудования. Юридическая ответственность предполагает
защит)' от правовых действий в случае возникновения ошибок в ходе проектирования,
при формировании ложного общественного мнения и при нарушениях хода
выполнения проекта. Наконец, примерами чистого персонального риска являются факторы
i una компенсаций рабочим и затрат на замену служащих.
Среди тех понятий, которые входят в сферу изучения при обращении к
управлению рисками, входит определение количественной степени риска. В этом случае
используются следующие понятия:
■ рисковое событие: формальное описание тех событий, которые могут произойти
и иметь какое-либо отношение к проекту;
■ вероятность риска: оценка возможности рискового события;
■ объем средств, "поставленных на карту": оценка потерь в случае
неудовлетворительного результата;
■ выявление риска: потенциал полной ответственности за имеющийся риск;
формула оценки степени риска представлена на рис. 18.11.
Модели управления рисками
Институтами управления проектами и программного инжиниринга была
проведена идентификация нескольких моделей управления рисками, подготовленных
менеджерами проектов. При рассмотрении этих моделей также использовалась работа
Ьарри Боэма (Barry Boehm), содержащая парадоксальные выводы относительно
процесса разработки ПО.
На рис. 18.6 демонстрируется, что управление рисками, связанными с проектом,
предполагает наличие следующих элементов.
■ Идентификация риска— определение источников возникновения риска,
идентификация потенциальных рисковых событий и симптоматики риска.
■ Определение количественных показателей риска— применение качественного и
количественного анализа, определение вероятностных значений для
благоприятных и неблагоприятных возможностей. Также определяются значения для
возможностей, позволяющих игнорировать определенные события, и
неблагоприятных обстоятельств, которые лучше не допускать.
■ Планирование откликов— управление рисками и планирование случайностей,
идентификация резервов, выраженных как в денежном эквиваленте, так и в
человеко-часах, а также определение методики смягчения влияния рисков с
использованием оговоренных в контракте средств.
■ Отслеживание и контроль— разработка планов корректирующих мероприятий и
просмотр результатов внедрения как части всестороннего внедрения плана
управления рисками.
Процесс управления рисками, описанный Барри Боэмом, первоначально изла-
!ался в справочнике "Software Risk Management", изданном IEEE Computer Society
Pi ess в 1989 году'. На рис. 18.7 показано графическое представление данной модели.
Huelini Barry W. Tutorial: Software Risk Management. Los Alamitos, CA: IEEE Computer Society

Определение рисков, связанных с выполнением проекта 585
Управление рисками включает два аспекта — оценивание риска и контроль.
Процесс оценивания риска подразделяется на процедуры идентификации риска,
анализа и установки приоритетов.
Идентификация рисков выполняется с помощью методик контрольных списков,
анализа принимаемых решений и устранения проблем. Если используются
предметные области, заранее известные менеджеру проекта и команде разработчиков,
можно воспользоваться контрольными списками. Тогда можно гарантировать, что
все ранее проявившиеся риски из категории "известное в известном" будут
идентифицированы для данного проекта. Если же проекты разрабатываются с учетом
новой предметной области или же применяется новая методика, мало известная
команде разработчиков проекта, обращаются к анализу принимаемых решений и
процедуре устранения проблем.
»" айййз: ■'■
'■ 'jrt, „.-.Чу,«,',; ;
Количественный
^Лайадйз" '
•- ->" ■■■■—-•< -
Планирование
!i откликов
Отслеживание
* «контроль,*
Рис. 18.6. Модель рисков, разработанная
специалистами Института управления проектами
С помощью этих инструментов команда разработчиков сможет более четко
представлять особенности предметной области, с учетом которой разрабатывается
программное обеспечение, и сосредоточить внимание на особенностях общего плана уже
определенных классов риска.
Анализ идентифицированных рисков выполняется с использованием
моделирования производительности и размеров стоимости, анализа сетевых возможностей,
принимаемых решений и факторов, влияющих на качество. Моделирование
производительности и размеров стоимости позволяет менеджеру проекта на основе
переменных, отражающих особенности производительности и размеры затрат,
формировать сценарии по принципу "что, если". Значения этих переменных оцениваются на
основе представлений, присущих изначально предметной области, где исследуется
данная проблема. Можно добавить усовершенствованные статистические методики
типа метода Монте-Карло, что позволит в дальнейшем проводить дополнительный
анализ. Анализ сетевого и качественного факторов, а также фактора выбора решения
позволяет команде разработчиков проекта получить расширенные представления об
информации, которая разрабатывается в процессе анализа проблемы при
выполнении идентификации рисков.
Идентификация
риска

586 Глава 18
После идентификации и анализа рисков следует определить относительный
потенциал их проявления и влияния на проект. Уточнение приоритетов рисков позволяет
команде разработчиков проекта обратить пристальное внимание на несколько
критических факторов риска. Именно они наиболее опасны и могут послужить причиной
возникновения сбоев при выполнении проекта. Для каждого риска, имеющего высокий
уровень приоритета, должно проводиться вычисление его вероятности, описанное
далее и этой главе. Действие риска заключается в определении количественных
показателей, характеризующих проявление риска. Сначала вычисляется вероятность текущего
проявления риска (RE, risk exposure), а затем определяется это же значение RE после
выполнения действий по смягчению риска. Определяется стоимость затраченных
усилий но выполнению действий, направленных на смягчение риска. Вычитая
коэффициент RE, полученный после выполнения действий по смягчению риска, из значения RE,
вычисленного до выполнения этих действий, разделим полученный результат на
затраты, понесенные на этапе смягчения риска. Таким образом получим меру для
оценивания выгоды при относительных затратах. Редукция составного риска представляет
собой простое разложение многофакторных рисков на однофакторные компоненты, что
позволяет оценить приоритеты среди рисков.
Управление рисками включает планирование менеджмента рисков, определение и
мониторинг рисков. Наряду с оцениванием рисков эти три компонента
поддерживаются наборами инструментов и методик.
Управление
рисками
Оценка риска
Контроль риска
Идентификация риска
Анализ риска
Расстановка
приоритетов рисков
Планирование
управления рисками
Определение риска
Отслеживание риска
Контрольные списки
Анализ методом выбора решений
Декомпозиция
Производственные модели
Модели затрат
Сетевой анализ
Анвлиз методом принятия решений
Анализ с учетом фактора качества
Выявление риска
Воздействие риска
Уменьшение сложных рисков
Информация по закупкам
Избегание рисков
Передача риска
Уменьшение риска
Планирование элементов риска
Интеграция плана риска
Прототипы
Имитации
Этвлонные тесты
Набор анализов
Персонал
Отслеживание стадий проекта
Отслеживание "горячей десятки"
Повторная оценка риска
Корректирующее действие
Рис. 18.7. Модель проектного риска (поБоэму)
Источник: Boehm Barry W. Tutorial: Software Risk Management. Los Alamitos,
CA: IEEE Computer Society Press, 1989.

Определение рисков, связанных с выполнением проекта 587
Во время планирования менеджмента рисков используются инструменты по
покупке информации и методики, позволяющие избежать проявления рисков. Также
применяется передача, редукция, планирование элементов И интеграция
планирования. Информации о закупках является практической реализацией принципа
"Обратимся к экспертам!". В данном случае речь идет о подписании контрактов с
консультантами-экспертами по основополагающим вопросам, получении информации из
баз данных, содержащих интересующие вас вопросы, а также подписке на оказание
исследовательских услуг.
Меры, позволяющие избежать проявления рисков, представляют такие возможности по
реструктуризации проекта и продукта, которые помогают не допустить проявления
данного риска. Передача риска обычно предполагает заключение страхового договора,
покрывающего издержки этого риска. Происходит передача ответственности для
данной части проекта, с учетом присущего изначально риска, другой организации.
Планирование элементов риска и интегрирование плана рисков реализуются
одновременно при структурировании плана проекта. Путем разложения риска на
образующие части можно отдельно адресовать и определять каждый элемент риска. Эта
стратегия, известная под названием "разделяй и властвуй", применяется для
смягчения степени влияния риска. При интегрировании плана рисков рассматриваются его
отдельные элементы, которые затем объединяются в обобщающем проекте.
Определение риска выполняется с помощью прототипов, имитаций, показателей
производительности, анализа и привлечения персонала. Поэтому в модели риска
прослеживается явная связь с виртуальной моделью разработки ПО, созданной Боэмом.
Прототипы, имитации и показатели производительности обычно предлагают
дополнительные инструменты и возможности. Эти инструменты играют огромную роль при
уменьшении и смягчении рисков. Однако эти инструменты требуют инвестиций и для
реализации предоставляемых преимуществ необходима определенная тренировка.
Отслеживание стадий проекта, "горячей десятки" рисков, повторное оценивание
рисков и выполнение корригирующих действий позволяет поддерживать
инструменты, реализующие отслеживание рисков. Эти инструменты являются составной
частью тех шагов, которые предпринимает менеджер проекта для реализации
полномасштабного управления рисками. Эти меры обсуждаются в разделе, посвященном
разработке плана управления рисками.
Проектные риски и Институт SEI
Институт программного инжиниринга (SEI) (входящий в состав Университета
Карнегн-Мсллон) разработал модель оценки рисков при разработке программ,
основанную на цикле Шухарта-Деминга (Shewhart-Deming). Рассматриваемая модель
поддерживает информацию и получение откликов на нее как внутри, так и вне
проекта. Сведения имеют отношение к деятельности, связанной с рисками, текущим
рискам и эманации рисков. На рис. 18.8 демонстрируются процессы, нашедшие
отражение в модели:
■ идентификация — поиск и локализация рисков до того, как они превратятся в
проблемы;
■ анализ — преобразование в информацию, определяющую принятие решений, тех
данных, на которые влияет риск, оценивание влияния, вероятности и временных
рамок; классификация рисков и определение приоритетов;

588 Глава 18
■ планирование — преобразование информации, на которую влияет риск, в решения
и действия по смягчению влияния риска (как в настоящем, так и в будущем), а
также реализация этих действий на практике;
■ отслеживание — отслеживание значений индикаторов риска и действий по
смягчению его влияния;
■ контроль — корректировка отклонений от планов по смягчению риска.
В процессе реализации этих функций поддерживается связь с общими
характеристиками процесса, коими являются:
■ идентификация — уточнение сути рисков;
■ анализ и определение количественных показателей риска— сбор информации и
уточнение приоритетов рисков;
■ планирование с использование откликов— принятие решений на основе
информации о рисках;
■ отслеживание и поддержка связи — отслеживание рисков и контроль за
действиями при поддержке коммуникационного статуса.
Рис 18.8. Модель управления
рисками, разработанная
Институтом программного инжиниринга
Идентификация рисков
Процесс идентификации рисков реализуется с помощью тех же инструментов, что
и любой другой анализ. Его начало характеризуется подбором команды и
проведением совместно с заказчиком "мозгового штурма", предметом которого является
создание списков "известное в неизвестном". Воспользуйтесь контрольными списками, со-
с пшлепными в связи с проблемами, которые возникали в предыдущих проектах. Эти
списки можно восстановить из хранилища проекта или на основе базы знаний.
Проверяйте все требования проекта, включенные в его план, что упростит определение
риска. Обратите особое внимание на заманчивые предположения относительно
безотказного функционирования проекта. Обратитесь к опытным разработчикам по
поводу идентификации рисков и определения их количественных характеристик.
Внимательно изучите структуру сбоев и сетевые диаграммы, имеющие отношение
к плану управления проектами, и попытайтесь составить перечень "узких мест"
проекта. В результате применения подобного подхода выявляется круг задач, которые
должны быть завершены до того, как начинают выполняться необходимые задачи.
Именно этот момент часто служит камнем преткновения при проектировании
запланированной рабочей сети, а также чаще всего приводит к срыву рабочего графика.

Определение рисков, связанных с выполнением проекта 589
Иногда эскизный набросок рассматриваемого процесса помогает выявить зоны
риска. Если процесс является неизвестным для вас, сделайте набросок плана его
выполнения. Это позволит отметить все связи, способствующие успешной реализации.
Проверяйте источники информации при принятии в проекте ключевых решений.
Рассмотрите ключевые моменты, приводящие к решениям.
Л теперь рассмотрим риски различных типов:
■ технический;
■ операционный;
■ политический;
■ юридический;
■ управленческий;
■ рыночный;
■ социальный;
■ внутренний;
■ внешний.
После завершения первого этапа работы по идентификации проектного риска,
команда разработчиков проекта вынуждена сделать шаг назад и более внимательно
изучить все возможные источники рисков. На рис. 18.9 изображены три основные
области риска, которые проявляются при составлении графика и определении
затрат. В данном случае идет речь о поддержке, технической и программной областях.
Не забывайте о том, что уточнение затрат и составление графика имеют присущие им
собственные риски.
Технический аспект
Рис. 18.9. Источники риска
В табл. 18.1 приводятся показатели для трех основных источников риска. Риски
технического характера играют основную роль при разработке ПО с тех пор, как
создание программ ассоциируется с высокими технологиями. Программистские риски
возникают в том случае, если предпринимаются попытки управления программным
проектом. По мере того, как разработка программного продукта приближается к
завершению, все большее значение приобретают риски, связанные с поставкой ПО, его
установкой и методикой поддержки.

590 Глава 18
Таблица 18.1. Примеры оценки показателей внутри каждого источника риска
Технические источники
Источники, связанные
с программированием
Источники, связанные
с поддержкой
Физические свойства
Материальные свойства
Доступность материальных
ресурсов
Персональная доступность
Свойства, связанные с распро- Способности персонала
странением
Тестирование и
моделирование
Интеграция и интерфейс
Разработка ПО
Безопасность
Изменения требований
Безопасность
Надежность
Влияние среды
Проблемы коммуникации
Забастовки работников
Проверка на отсутствие сбоев Изменения требований
Операционная среда Политическая защита
Аксиоматическая или
основанная на доказательствах
технология
Стабильность требований,
определенных в контракте
Надежность и возможность
поддержки
Обучение и поддержка обу-
чения
Оборудование
Представление о
"человеческом факторе"
Безопасность системы
Технические данные
Представления о
возможностях
Представления о связях
между операциями
Переносимость
Поддержка вычислительных
ресурсов
Упаковка, обработка, сохран-
Системная сложность Основополагающий профиль
Уникальные или специальные Регулятивные изменения
ресурсы
Как можно заключить из рис. 18.9, размеры затрат и уточнение графика
подвержены влиянию не только трех начальных источников риска, а также оказывают
влияние друг на друга. Риск, связанный с размером затрат, может проявиться при
оценивании ошибок, при перераспределении накладных расходов, общих и
административных затрат. Можно составить более жесткий график, усиливая в проектном
задании степень конкуренции, увеличивая количество критических пунктов
маршрута и оценивая ошибки.
На рис. 18.10 иллюстрируется простой диаграммный метод для представления
классов и типов идентифицированных рисков. Риски можно легко сгруппировать в
кластеры на основе сферы действия, качества, графика и величины затрат. Также
можно использовать более грубое деление с учетом особенностей бизнеса,
технологии и среды. Уделяя внимание отображению кластеров и формированию категорий
для идентифицированных рисков, проектная команда может акцентировать
внимание на тех областях, где риски остаются, но не являются идентифицированными.
Такой подход помогает открывать "неизвестное в неизвестном".

Определение рисков, связанных с выполнением проекта 591
Сбои со стороны
подрядчика
Продукт
Бизнес
Технический аспект
Уменьшение объема
финансирования
Сбои при эксплуатации
Сетевые сбои
Новая технология
Недостаточный
уровень обучения
Рис. 18.10. Группирование рисков
Качественные и количественные
методики оценки риска
Обычно для анализа рисков применяют как известные, так и новые инструменты и
методики. Ранее обсуждались следующие инструменты, пригодные для анализа
идентифицированных рисков.
■ "Мозговой штурм".
1. Идеи по анализу рисков предлагаются без обсуждения или оценки.
2. Построения выполняются на основе предложенных идей.
3. Процесс повторяется до тех пор, пока не исчерпаются все идеи.
■ Метод Delphi.
1. Выделяется группа экспертов (изолированных друг от друга и незнакомых
между собой).
2. Подготавливается и распространяется перечень вопросов, относящихся к
рискам.
3. Опрос экспертов по поводу различных подходов к обработке рисков и других
соображений по этой теме.
4. Распределите среди членов группы отклики и статистические данные,
полученные при осуществлении обратной связи.
5. Повторяйте этот процесс до тех пор, пока эксперты не достигнут консенсуса.
Менеджеры проекта и команды могут применять при анализе рисков новые
методики анализа.
■ Анализ, базирующийся на чувствительности.
1. Выберите несколько переменных, играющих важную роль в
рассматриваемом плане.

592 Глава 18
2. Определите приемлемый диапазон вариации.
3. Оцепите эффект, возникающий в результирующем проекте при изменении
диапазона.
■ Вероятностный анализ.
1. Аналогичен анализу, базирующемуся на чувствительности.
2. Добавляет вероятностное распределение для каждой переменной, что обычно
уменьшает возможный оптимизм.
■ Имитация по методу Монте-Карло.
1. Аналогична вероятностному анализу.
2. Присваивает каждой переменной случайные значения.
3. Выполняйте имитацию несколько раз для получения вероятностного
распределения для результата.
4. Сформируйте диапазон вероятностных значений для результата.
■ Теория полезности.
1. Представляет отношение к риску разработчика решения.
2. Рассматривается в качестве теоретического направления.
3. Представлено на рис. 18.5.
■ Анализ решения с помощью дерева.
1. Графический метод.
2. Усиливает вероятностные представления для каждого результата.
3. Обычно применяется для оценивания величины затрат и промежутка времени.
Методики анализа тесно связаны с определением количества для риска.
Выполняется присваивание числового значения отдельному риску или же кластеру, классу
проектного риска. Менеджер проекта должен помнить об одном, наиболее важном
аспекте процесса определения количественной меры риска. Дело в том, что все
численные значения производны от наилучших оценок, которые известны как прогнозы.
Поскольку нет уверенности в том, что наступил момент, который описывается в
прогнозе для этих рисков, нельзя также заключить, оказывает ли риск какое-то реальное
влияние на данный проект. Задача состоит в том, чтобы количественно оценить
относительный риск, сравнивая один риск с Другими, и спрогнозировать влияние
данного риска па проект.
Процесс количественной оценки риска начинается с вычисления зависимости
проекта от идентифицированных рисков. При этом вычисляется фактор зависимости
от риска. На рис. 18.11 представлена формула зависимости от риска, которая
применяется в проекте для каждого риска, обладающего достаточно высоким приоритетом.
Эту формулу можно применять ко всем рискам, но на практике лишь риски с
наибольшим приоритетом требуют дополнительного внимания и количественного
определения зависимости от риска.
Благодаря применению теории вероятности, наравне с деревьями решений,
можно на основе множества альтернатив поддерживать механизм определения
количественных оценок для риска. Например, если установлен бонус в размере 100 000
долларов за выполнение опережающего графика (агрессивный график, только если шанс
на успех — не меньше 18%) и 250 000 долларов штрафа в случае невыполнения работы

Определение рисков, связанных с выполнением проекта 593
в срок в соответствии с каким-либо графиком (будем консервативны и установим 90%
вероятности своевременного или более раннего завершения работ), вы будете
стремиться работать по опережающему либо консервативному графику?
RE=
Вероятность риска (Р)
неудовлетворительный исход
для рискового события
X
количество ставок (L=потери)
~\
> RE=PxL
Рис. 18.11. Формула зависимости от риска
С помощью дерева решения из примера на рис. 18.12 можно заключить, что при
выборе опережающего графика потенциал для риска уменьшится на 180 000
долларов, в то же время использование консервативного расписания приводит к потере
только 25 000 долларов. В этой ситуации менеджер проекта должен стремиться к
уменьшению риска при работе согласно консервативному графику.
Вероятность (Р) х
Раннее
Решение
по поводу
графика
Выбор
агрессивного
графика
Выход (L)
+$100,000 +$20,000
-$250,000 -$200,000
Ожидаемое
значение
-$180,000
+$0
+$0
Выбор
консервативного
графика
-$250,000 -$25,000
-$25,000
Рис. 18.12. Пример дерева решения
Контроль рисков, проявляющихся
при разработке ПО
Ниже приводятся примеры ключевых рисков и угроз, проявляющихся при
разработке ПО.
1. Нереальный бюджет и график:
- проследите все оценки и реалии; оцените уровень профессионализма команды;
- получите ясное представление о том, чем заполнено рабочее время
разработчиков — в любой организации имеются резервы рабочего времени;
- не позволяйте клиенту уговаривать вас принять нереальные оценки для сроков
и объемов бюджета.
2. Недостатки имеющегося персонала:

594 Глава 18
- запланируйте обучение в тех областях, которые необходимы для выполнения
данного проекта;
- установите обучающий шаблон для разработчиков на время выполнения
проекта;
- культивируйте такие взаимоотношения в команде, которые способствуют
обучению персонала, приветствуйте разделение коллектива на группы по рабочим
интересам.
3. Внедрение ошибочных направлений:
- настаивайте на встрече с заказчиком;
- используйте прототип и демонстрируйте планируемые подходы.
Проект плана управления рисками содержит все идентифицированные риски и, в
случае необходимости, планы по их смягчению. При генерировании откликов на
риск идентифицированные риски могут обрабатываться тремя способами.
1. Принять — ничего не делать. Одобрение последствий как в активной, так и в
пассивной форме.
2. Передача. Перекладывайте потери на третьи организации как на контрактной
основе, так и с помощью санкций или приобретения страховки.
3. Смягчение. Уменьшайте влияние или вероятность с помощью непрерывного
планирования или используйте резерв, попытайтесь устранить причину, применяя
альтернативны стратегии разработки ПО.
Подготовьте соответствующие отклики по каждому пункту риска, отвечая на
следующие вопросы.
1. Кто несет ответственность за данное действие?
2. Когда действие должно произойти?
3. Какую систему исчисления использовать?
4. Каково метрическое значение триггера?
В табл. 18.2 иллюстрируются отклики на риски для десяти первых рисков проекта.
Каждый риск имеет идентификатор и дескриптор. Вместе с триггером показано и
наблюдаемый метрический показатель. Для каждого риска величина больше или равна
значению триггера. Подобные таблицы необходимо пересматривать не реже одного
раза в неделю.
Таблица 18.2. Таблица откликов на риск
Идеи- Пункт риска Триг- Значе Риск Возможный Кто Дата
тифи- гер ние ожидае- подход
катор мый
1 Слишком мало 10 12 630
инженеров-
экспертов
2 Плотная раз- 25 28 450
работка
графика
Уточните уело- МП 1/15
вия контракта
Выполните МП ведется
Delphi-оценки постоянно

Определение рисков, связанных с выполнением проекта 595


тификатор
3
4
5
6
7
8
9
10
Пункт риска
Недостаточно
эффективная
функция
отчетности
Слишком
разнообразный
интерфейс
Новые
требования
Угроза
"позолоты"
Просчеты в
качестве

Нестабильность в
замкнутости
Проблемы со
временем
Новые
технологические
риски

Триггер
20
10
5
15
3
10
5
5
Значе
ние
25
20
5
15
6
6
6
8
Риск

ожидаемый
180
150
150
120
60
60
30
10
Возможный
ПОДХОД
Экспертная
оценка с
заказчиком
Экспертная
оценка с
заказчиком
Экспертная
оценка затрат
Придерживайте
сь документа
требований
Обратиться ко
второму
поставщику
Исследовать
расположение
скобок
Имитация и
тестирование
Экспертная
оценка с
ответственным по
научной части
Окончание табл. 18.2
Кто

Руководитель
проекта

Руководитель
проекта
МП

Руководитель
проекта
ПМ
Инженер
Инженер

Руководитель
проекта
Дата
2/15
2/15
ведется
постоянно
ведется
постоянно
2/1
2/15
ведется
постоянно

периодически
Управление откликами на риск предполагает регулярную экспертную оценку всех
рисков с целью отражения происшедших изменений. Информация о десяти наиболее важных
рисках пересматривается, как минимум, еженедельно. Эти риски могут совпадать с
рисками из таблицы откликов, как показано в табл. 18.3. Отличие этих двух таблиц в том, что
вероятности и потери показаны в качестве компонентов зависимости от риска.
Таблица 18.3. "Горячая десятка" рисков, связанных
с программными проектами


тификатор
Пункт риска
Триг- Значе- Риск
гер иие
ожидаемый
Возможный
подход
Кто
Дата
Слишком мало 70
инженеров-
экспертов
Плотный гра- 50
фик
630 Уточните уело- МП
вия контракта
450 Выполните МП
Delphi-оценки
1/15
ведется
постоянно

596 Глава 18


тификатор
3
Л
5
(i
7
8
9
10
Пункт риска
Недостаточно
эффективная
функция
отчетности
Слишком
разнообразный
интерфейс
Новые
требования
Угроза
"позолоты"
Просчеты в
качестве

Нестабильность в
замкнутости
Проблемы со
временем
Новые
технологические
риски

Триггер
20
25
30
30
10
10
5
5

Значение
9
6
5
4
6
6
6
8
Рнск

ожидаемый
180
150
150
120
60
60
30
10
Возможный
подход
Экспертная
оценка с
заказчиком
Экспертная
оценка с
заказчиком
Постоянная
экспертная
оценка объемов
затрат
Придерживайте
сь документа
требований
Обратиться ко
второму
поставщику
Исследовать
расположение
скобок
Имитация и
тестирование
Экспертная
оценка с
ответственным по
научной части
Окончание табл. 18.3
Кто

Руководитель
проекта

Руководитель
проекта
МП

Руководитель
проекта
ПМ
Инженер
Инженер

Руководитель
проекта
Дата
2/15
2/15
ведется
постоянно
ведется
постоянно
2/1
2/15
ведется
постоянно
периодич
ески
Категории риска
План управления проектными рисками моделирует 12 категорий потенциального
риска для определенного проекта.
1. Задачи и цели. Каждый одобренный проект должен занимать соответствующее
место среди целей и задач организации. Те проекты, которые не соответствуют
реальным целям организации, создают напряжение, влияющее на все проекты.
Например, потребуем, чтобы существовала организация, в задачи которой
входила бы разработка программного обеспечения для внутреннего корпоративного
производства, а цель состоит в создании наиболее эффективного, заказного
программного обеспечения для предприятий организации. Если организация
приступит к выполнению проекта по созданию пакета ПО общей направленности и
на коммерческой основе, это будет рискованным мероприятием,
противоречащим текущим задачам и целям организации.

Определение рисков, связанных с выполнением проекта 597
2. Организационный менеджмент. Каждый из выбранных проектов должен
вписываться в текущую или планируемую организационную структуру. Если
организация не обладает подобной структурой или же еще не создана, трудно
рассчитывать на успешную реализацию программного проекта. Примером подобных
рискованных формирований являются торговые организации, прекращающие
разработку проектов без дотаций со стороны исполняющих организаций. Проект
"перебрасывается на поле" организации по разработке, поскольку нет
подходящей команды, и отсутствует процесс формирования типа системы торговли.
3. Заказчик. Все проекты должны иметь постоянную "обратную связь" с заказчиком.
Проект разработки программного обеспечения требует обширных вводных
данных, которые могут представить заказчики и конечные пользователи. Без
подобного ввода данных самый удачный процесс разработки приведет к формированию
только отлично функционирующей системы, не отвечающей реальным запросам
конечных пользователей. Сокрытый здесь риск состоит в привлечении в команду
неопытных сотрудников, не обладающих адекватным опытом по разрешению
проблем, связанных с предметной областью. Такие сотрудники не смогут
удовлетворять технические запросы разработчиков ПО.
4. Бюджет/стоимость. Именно данная категория обычно привлекает наиболее
пристальное внимание и оказывает влияние на все другие категории.
Менеджеры проектов сосредотачивают внимание на бюджете и объемах затрат,
поскольку именно эти рычаги позволяют задействовать широкий спектр
возможностей, приводящих проект к успешному завершению. Для уменьшения риска,
относящегося к этой категории, следует четко представлять размеры проекта,
располагать достоверной предысторией о работе над подобными проектами, а
также иметь достаточно полное представление о внешних влияниях, например,
о технологии.
5. График. Самый большой риск состоит в том, что команде разработчиков
навязываются слишком тесные временные рамки графика. Если разработчики не могут
оказывать влияния на формирование графика и даты ключевых этапов проекта,
довольно велика вероятность того, что график выполняться не будет. Команды
разработчиков ПО должны принимать участие в разработке проектных графиков
и иметь возможность вносить туда изменения.
6. Содержание проекта. Все проекты генерируют те или иные особенности,
которые дополняют проект и образуют промежуточные продукты. Одним из
основных компонентов является документация, содержащая требования, сведения о
проектировании и целевая программная система. Если эта информация
отсутствует, могут появиться ошибки, либо резко и непредсказуемо возрастет риск
потери сведений, содержащихся в проекте. Также может нарушиться график или
существенно пострадает содержимое продукта.
7. Выполнение. Эти факторы риска относятся к особому периоду, когда наступает
период практических испытаний разработанной системы. Однако именно эти
факторы риска являются ключевыми для критерия по разработке программного
обеспечения. Некоторые из основных областей риска относятся к
функционированию системы во время тестирования. Критическое значение имеет
возможность полного тестирования всех модулей и их интерфейсов. Неадекватное
тестирование ведет к сбоям при выполнении проекта.

598 Глава 18
8. Управление проектом. Эта категория относится как к процессам управления
проектом, так и к компетенции менеджера проекта. Риск существует не только из-за
недостатков, неадекватной трактовки, процессов менеджмента, но может быть
также следствием предыдущего опыта работы менеджера проекта. Менеджеры
проектов должны иметь опыт работы с предметной областью и иметь
представления о процессах проектного менеджмента.
9. Процессы разработки. Эта категория фокусируется на тех процессах, которые
уменьшают общий риск и улучшают качество производимого продукта. К
процессам разработки не относятся специфические инструменты, такие как языки
программирования, построители или генераторы кода. Рассматриваемые процессы
фокусируются на процессах конфигурационного менеджмента, практиках
страховки качества и анализе альтернатив.
10. Среда разработки. Данная категория сосредоточена на физической среде
возможностей, аппаратных платформах и инструментах по разработке
программного обеспечения. Риск возникает не только из-за недостатка адекватных
инструментов, а из-за отсутствия адекватных возможностей. Если команда не подобрана
специально для решения конкретной задачи, отсутствует адекватное
пространство для выработки соглашений, пространство для поддержки интервью с
заказчиком и рабочие комнаты, риск существенно возрастает.
11. Персонал. Эта категория является единственной, где существенное уменьшение
риска достигается за счет набора опытной и высокопроизводительной команды
разработчиков ПО. Разработчики, обладающие высокой рабочей
эффективностью, могут в 10 и даже в 25 раз продуктивнее работать, чем обычная команда.
Неуверенность в возможностях команды или в опытности ее членов в сочетании с
некоторыми особенностями проблемных предметных областей способствует
фиксации консервативного подхода к факторам риска из этой категории.
12. Поддержка. Эта заключительная категория позволяет количественно оценивать
риск, связанный с ПО, после поставки программного продукта. Команда
разработчиков проекта часто несет ответственность за поддержку программного
обеспечения в течение определенного периода после поставки продукта. Если же это
не так, а неопытные пользователи пытаются фиксировать ошибки в программном
обеспечении, проектный риск существенно возрастает. Инструменты,
применяемые для разработки, должны быть доступны и на этапе поддержки. Поддержка
поставщика после выпуска продукта характеризуется наличием риска выпуска,
если отсутствует план или бюджет для реализации инструментария непрерывной
поддержки.
Этапы разработки плана
по управлению рисками
Разработка плана управления рисками представляет собой несложный процесс,
состоящий из пяти этапов. Используя предварительно указанное разбиение на 12
категорий рисков, необходимо выполнить ранжирование и отсортировать риски таким
образом, чтобы ими можно было управлять. Затем рассматриваемый план появится в
результате процесса идентификации рисков, введения категорий и установления
приоритетов.

Определение рисков, связанных с выполнением проекта 599
Этап 1
Используя описанные категории рисков, создайте таблицу категорий. Команда
разработчиков может воспользоваться этой таблицей для обзора категорий рисков
данного проекта. Также команда получает информацию о наборе факторов для
изучения. Таблица категорий рисков содержит сведения о том, какие факторы рисков
более реальны и сколь они наглядны. Если организация располагает методами работы
с этими факторами, можно сравнить их рейтинги в данном проекте с рейтингами в
проектах, которые разрабатывались ранее. Можно использовать подход, основанный
на всеобъемлющем рейтинге, или фиксировать внимание на определенном
количестве рисков или же комбинировать количество рисков и степень их влияния,
прогнозируя успех или неудачу проекта. Данная таблица является отправной точкой при
идентификации определенных рисков в каждом проекте.
Этап 2
Ранжируем риски, связанные с выполнением проекта, по категориям:
■ факторы риска и области — в каждой категории в этом столбце перечисляются
факторы категории риска;
■ низкая очевидность риска (L) — этот столбец характеризует данный фактор
относительно невысокой вероятности риска для проекта;
■ средняя очевидность риска (М) — этот столбец характеризует данный фактор
относительно средней вероятности риска для проекта;
■ высокая очевидность риска (Н) — этот столбец характеризует данный фактор,
когда вероятность риска для проекта достаточно велика;
■ рейтинг — выделите уровень риска (например, Н, М, L или 3,2,1), применимый для
данного проекта;
■ комментарии — поддерживается информация об особенностях проекта, которая
позволяет соблюдать выбранный рейтинг.
Обратите внимание, что в некоторых случаях очевидное проявление риска в
одной категории может характеризоваться как высокое, а в другой - как низкое.
Например, поддержка целей организации или применение новых технологий может
предприниматься любым способом, в зависимости от ситуации.
В табл. 18.4 приводятся факторы риска и категории, для которых очевидность
риска характеризуется соответственно как низкая, средняя и высокая. Данная
таблица служит шаблоном, используемым в качестве отправной точки для разработки
любого проекта программного обеспечения. Категории, факторы и очевидность можно
легко обновлять для любого проекта в пределах рассматриваемой схемы проекта.
ЭтапЗ
Выполните сортировку таблицы рисков, располагая их в порядке убывания
очевидности. Тогда сначала перечисляются риски с самой высокой очевидностью.
Вычислите зависимость риска для "верхних" десяти рисков, а также для всех рисков,
отмеченных как "высокие", если их больше десяти. Именно эти риски и будут
ключевыми. Идентифицируйте средства для контроля над каждым ключевым риском,
устанавливая ответственного за эти действия и дату их выполнения. Интегрируйте
ключевые риски в план проекта и уточните их влияние на график и размер затрат.

QUALITY
SOFTWARE
МИНЕМ*
rKUJCb I
iiflHlCFIIFHT
If IflHH ULIf ILIII
Robert T. Futrell
Donald F. Shafer
Linda I. Shafer
Prentice Hall PTR
Upper Saddle River, NJ 07458
www.phptr.com

Научно-популярное издание
Дональд Ф. Шафер, Роберт Т. Фатрелл, Линда И. Шафер
Управление программными проектами: достилсение
оптимального качества при минимуме затрат
Литературный редактор С. Г. Татаренко
Верстка М-А. Удалое
Художественные редакторы Е- П. Дынник, А. А. Линник (мл.),
М.А. Удалое
Корректоры 3. В. Александрова, Л. А. Гордиенко,
Т. А. Корзун, Л. В. Коровкина,
О. В. Мишутина
Издательский дом "Вильяме".
101509, Москва, ул. Лесная, д. 43, стр. 1.
Изд. лиц. ЛР № 090230 от 23.06.99
Госкомитета РФ по печати.
Подписано в печать 27.01.2003. Формат 70X100/16.
Гарнитура Times. Печать офсетная.
Усл. печ. л. 91,59. Уч.-изд. л. 69,07.
Тираж 3000 экз. Заказ № 2424.
Отпечатано с диапозитивов в ФГУП "Печатный двор"
Министерства РФ по делам печати,
телерадиовещания и средств массовых коммуникаций.
197110, Санкт-Петербург, Чкаловский пр., 15.

Продолжение табл. 18.4
I
II
III
IV
VI
Соответствие
контрактным условиям
Определенные
преимущества
Контракт с заказчиком имеет
реальные сроки, связи с
командой хорошие
Преимущества четко
определены, меры
идентифицированы и четко выделены
основные из них
Факторы бюджет/затраты
Объем проекта
Ограничения по
аппаратному
обеспечению
Технология
Повторно
используемые компоненты
Компоненты
поддержки
Небольшой, несложный, его
легко разбить на части
Небольшие или же не
связанные с аппаратным
обеспечением, или наличие единой
платформы
Отработанная, имеющаяся в
наличии, опыт можно
использовать в домашних условиях
Компоненты доступны и
совместимы с применяющимся
подходом
Компоненты доступны и
непосредственно применимы
Контракт имеет некоторые
открытые вопросы, которые
могут прервать работу
команды
Остаются некоторые вопросы
о преимуществах или
вносятся изменения в основные
мероприятия, подвергаются
сомнению определенные меры
Средний, умеренной
сложности, можно разбить на части
Определенные ограничения,
связанные с аппаратным
обеспечением, несколько
платформ
Имеющийся в наличии,
определенный опыт работы в
домашних условиях
Перспектива для
компонентов, даты поставки указаны
неточно
Компоненты функционируют
при различных
обстоятельствах
Контракт имеет обременительные
задокументированные требования
или нуждается в дополнительной
работе по согласованию
Преимущества не определены,
основные мероприятия не
установлены, недостижимы или же имеют
неограниченный характер
Большой, высокой сложности, его
нельзя разбить на части
Важные ограничения, связанные с
аппаратным обеспечением,
наличие нескольких платформ
Новая технология или применение
нового пути, или разработка
небольших опытных домашних
заготовок
Компоненты проектируются, но
недоступны
Известно, что компоненты в
определенных случаях терпели сбои,
частенько запаздывали или же
были несовместимы с
определенными моментами подходами

Продолжение таб.1, IS. 4
I
II
III
IV
VI
Объем бюджета
Бюджетные
ограничения
Экономическое
подтверждение
Управление
объемами затрат
Факторы, связанные с
Передача поставок
График разработки
Состав проекта
Стабильность
требований
Полнота и четкость
требований
Возможности по
тестированию сие-
Достаточный по объему
распределенный бюджет
Фонды распределены без
ограничений
Полностью подтверждаются,
обоснована эффективность
затрат
Удачно установлены,
функционирует
графиком
Стабильные даты передачи
Проекты команды, указанные
в графике, выполняются,
график отражает реальное
положение
Небольшие изменения или же
изменения согласованного
набора
Все полностью уточнены и
четко выписаны
Требования к системе легко
тестируются, планы
разрабатываются
Спорный бюджет,
распределен
Определенные вопросы о
доступности фондов
Подтверждение под вопросом
или эффективность
установлена не полностью
Система в порядке,
недостатки в определенных областях
Некоторые
неопределенности с поставками
Команда обнаруживает часть
плана, которая повышает
интенсивность графика
Возможно внесение
изменений в согласованный набор
Определенные требования
остаются неполными или
нечетко выписаны
Части системы сложно
тестировать или же возможно
частичное планирование
Достаточным является
сомнительный бюджет
Распределение под сомнением или
же изменения происходят по
существу
Не подтверждается или
демонстрируется эффективность затрат
Системный недостаток или
отсутствует
Нестабильная, передача
нерегулярна
Команда проектирует, что
нежелательно пересечение двух или
большего количества частей графика
Быстро изменяются или не
согласованы по основным направлениям
Некоторые требования
содержатся только в голове заказчика
Большая часть системы трудна для
тестирования или же отсутствуют
планы по тестированию

ПрпИтжсни? табл IS 4
I
II
III
IV
VI
Затруднения,
возникающие при
разработке
Затруднения,
возникающие при
реализации
Зависимость от
системы
Удачно определенные
интерфейсы; разработка имеет
четкую структуру
Алгоритмы и разработка
вполне соответствуют задачам
по внедрению, стоящим перед
командой
Четко определенные
зависимости от программных усилий
и других частей системы
Неясности в способах
разработки или неопределенность
в аспектах разработки
Алгоритмы и/или разработка
имеет элементы,
представляющие для этой команды
определенные трудности при
внедрении
Некоторые элементы
системы хорошо структурированы
и включены в план, другие же
еще не подвергались осмыс-
Интерфейсы недостаточно
хорошо определены или организованы,
предмет разработки изменяется
Алгоритмы и/или разработка
имеет компоненты, которые
представляют большие затруднения при
внедрении этой командой
Отсутствует четкий план или
расписание, в соответствии с
которым будет функционировать вся
система
Стабильность
документов
Документы доступны вовремя
и содержат небольшое число
ошибок
Факторы, влияющие на выполнение проекта
Возможности по Модульная разработка позво-
тестированию ляет облегчить планирование
процессов тестирования и
выполнения
Ожидаемые усилия Доступны хорошие оценки,
по тестированию
Функциональные
возможности
вполне подготовлен и
соответствует системе процесс
доступа
Высокая функциональность,
отвечает всем требованиям
заказчика
Некоторые документы могут Небольшой шанс получения доку-
появиться с запаздыванием и ментов вовремя, ожидается боль-
содержать небольшие ошибки шое число исправлений и
изменений
Модульная разработка
предназначается для разработки
вспомогательных тестов,
объединяемых затем в единый тест
Приблизительная оценка
времени для тестирования
может быть «узким местом»
процесса
Хорошие функциональные
возможности, отвечающие
большинству запросов
заказчика
Отсутствует модульная разработка
или возможность легко определять
тестовое планирование
"Бедная" оценка или же отсутствие
оценок времени для тестирования,
определенный шанс столкнуться с
«узким местом»
Скудные функциональные
возможности, несоответствие с большим
количеством запросов заказчика

Продолжение табл. ISA
I
II
III
IV
VI
Внешнее аппаратное Необходима небольшая кор-
обеспечение или ин- рекция или же можно ее из-
терфейсы ПО бежать, нужны интерфейсы
Факторы управления проектами
Подход
Связи
Опыт менеджера
проекта
Планирование продукта и
процесса, мониторинг
проводится своевременно
Четко очерчены статус и цели
коммуникаций между
командой и оставшейся частью
организации
Менеджер проекта имеет
большой опыт работы над
аналогичными проектами
Отношение менед- Основательно настроен
жера проекта на успех
Влияние/поддержка Полная поддержка команды и
менеджера проекта менеджмента
Необходима определенная
интеграция или некоторые
интерфейсы
Планирование и мониторинг
по совершенствованию
заданий
Поддерживается связь между
некоторыми объемами
информации в течение
некоторого времени
Менеджер проекта имеет
скромный опыт работы или
опыт работы с проектами
других типов
Выполняет работу с желанием
сделать ее хорошо
Поддержка большинства из
команды, есть небольшие
группы, имеющие особое
Требуются расширенные
интерфейсы
Слабое планирование или
отсутствие планирования и мониторинга
Редкие плодотворные связи с
командой или с теми, кто желает
получить информацию о статусе
команды
Менеджер проекта не имеет опыта
работы с проектом подобного типа
или же является новичком в
проектном менеджменте
Отношение к проекту "с
прохладцей"
Отсутствует заметная поддержка,
менеджер существует только "на
бумаге"
Факторы, влияющие на процесс разработки
Анализ альтернатив Полный анализ альтернатив,
все учитывается, требования
подтверждаются
Полный анализ альтернатив,
некоторые требования
спорны или альтернативы не
полностью согласованы
Анализ не завершен, не учтены все
альтернативы или требования
потерпели сбой

Продолжение табл. IS.4
I
II
III
IV
VI
Подход к страховке
по качественным
показателям
Процесс передачи
Документация по
разработке
Использование
определенного
инженерного процесса
Ранняя
идентификация дефектов
Установлена система QA
(страховка по качеству),
постоянно отслеживается,
эффективен
Изменения в процессе
передачи незначительны,
содержимое расписание
пересматриваются и утверждаются всеми
привлеченными лицами
Корректная и доступная
Процедуры установлены,
однако, они недостаточно полно
соблюдаются, или они не
приводят к должной эффективности
Изменения в процессе
передачи доводятся до сведения
всех привлеченных
Отсутствует процесс QA или нет
установленных процедур
Изменения в способ передачи
выполняются без пересмотра или
команда не привлекается
Небольшой дефицит, доступна Не существует
Своевременная разработка Процесс установлен, но он не
процесса, основательная, эф- последователен или неэффек-
фективная, принимаемая всей тивен
командой
Экспертные оценки
встречаются повсюду
Изменение
управления над рабочими
продуктами
Отслеживание
дефектов
Формальное изменение
управления процессом
своевременно, последовательно,
эффективно
Определено отслеживание
дефектов, последовательное,
эффективное
Факторы среды разработки
Физические возмож- Небольшие или нет необхо-
ности димости в обновлении
Экспертные оценки
применяются спорадически
Изменения процессом
управления проходят
своевременно, непоследовательно или
неэффективно
Определен процесс
отслеживания дефектов, однако
непостоянно применяется
Необходимы определенные
модификации, некоторые из
них имеют место
Не используется формальный
процесс
Эксперты команды обнаруживают
все дефекты с помощью
тестирования
Не используется процесс
изменения контроля
Своевременно не используется
процесс для отслеживания
дефектов
Необходимы крупные обновления
или для этого отсутствуют
возможности

Продолжение табл. 18.4
II
III
IV
VI
Платформа
аппаратного обеспечения
Доступность
инструментов
Менеджмент
конфигурации
Безопасность
Стабильная, изменения
не ожидаются емкость
достаточна
Реализуемая,
документирована, подтверждена
Полностью контролируется
Поддержка
поставщиков
Все области учитывают
основные методики по
обеспечению безопасности, данные
резервируются, система
предупреждения опасности
своевременно реагирует,
процедуры отслеживаются
Полная поддержка по
согласованной цене, в
необходимых временных рамках
Факторы, связанные с персоналом
Доступность персо- По мере необходимости,
пенала редача некоторых функций
заместителю на оговоренных
условиях, наличие нескольких
"пожарных" случаев в работе
Объединение спо- Удачное объединение дисци-
собностей персонала плин
Знание продукта Большой опыт по разработке
продуктов подобного типа
Некоторые изменения
эволюционируют, но находятся
под контролем
Доступны, подтверждены,
необходимо выполнить
определенные разработки (или
минимальный объем документации)
Элементы управления по мере
необходимости
Некоторые своевременные
меры безопасности,
выполняется резервное копирование,
но процедуры недостаточны
или не отслеживаются
Платформа в процессе разработки
вместе с программным
обеспечением
Неподтвержденная, собственная
или требует большой доработки,
документация отсутствует
Отсутствуют уместные элементы
управления
Отсутствуют своевременные меры
безопасности, недостаточное
резервное копирование, не
рассматривается использование
предупреждений об опасности
Адекватная поддержка по
цене, оговоренной в контракте,
удобное время отклика
Доступен, возможна
частичная передача функций
заместителю на оговоренных
условиях, небольшое число
"пожарных" случаев
Некоторые дисциплины
представлены неадекватно
Небольшой опыт в разработке
продукта этого типа
Небольшая или же нет поддержки,
высокая стоимость и/или
незначительное время для отклика
Передача большого числа функций
заместителям, недоступность,
команда большую часть времени
тратит на устранение "пожарных"
ситуаций
Некоторые дисциплины вообще не
представлены
Отсутствует опыт в разработке
продукта этого типа

Окпнчаниг табл. 18.4
II
III
IV
Опыт разработки
ПО
Обучение команды
Взаимоотношения в
команде и настрой
команды
Производительность
работы команды
Расширение опытных знаний
при работе с проектом этого
типа
Уместный учебный план,
тренинг проходит непрерывно
Сильная настроенность на
успех проекта, дух кооперации
Факторы поддерйкхи
Сложность
Внедрение
изменений
Персональная
поддержка
Поддержка
поставщиков
Рассматриваются все
основные стадии, вовремя
выдаются готовые продукты, высокая
производительность
Структурно поддерживаемая
(невысока я сложность,
которую можно измерить или
запроектировать)
Команда своевременно
откликается на запросы
заказчиков
Своевременная, на высоком
уровне, достаточная по объему
Небольшой опыт в работе
с аналогичными проектами
Недоступен тренинг в
некоторых областях или тренинг
запланирован на будущее
Есть желание выполнить
необходимый объем работ для
удачного завершения дела
Встречаются основные стадии
моменты, некоторая задержка
с готовыми продуктами,
доступная производительность
Определенные аспекты
трудно поддерживать (средняя
сложность)
Опытность команды
недостаточна, но имеет место
доступность заказчика
Пропущены некоторые
экспертные области
Полная поддержка по огово- Адекватная поддержка по
ренной цене и в необходимых контрактной цене, вполне
временных рамках реальное время отклика
Небольшой или отсутствует опыт
работы с аналогичными проектами
Отсутствует учебный план или
тренинг не подготовлен в
доступной форме
Слабая заинтересованность или
отсутствие взаимозаменяемости,
команда не представляет единого
целого
Производительность низкая,
основные стадии не выделены,
отставание в подготовке продуктов
Очень сложно реализовать
поддержку (высокая сложность)
Команда неспособна отвечать на
запросы заказчиков
Важную роль играют
дисциплинарные вопросы или ошибки
экспертов
Небольшая поддержка или ее
отсутствие, высокая стоимость и/или
значительное время отклика

Определение рисков, связанных с выполнением проекта 609
Этап 4
Установите формат отчета для регулярного риска. Этот отчет заслушивается на
еженедельных встречах, где рассматривается состояние проекта. Как минимум,
показывайте состояние "верхней" десятки (табл. 18.3), изменения в ранжировании для каждого
риска за последнюю неделю и число недель в списке. Отобразите отчет откликов о
рисках (табл. 18.2) и отчет об изменениях в рисках. В табл. 18.5 показан этот отчет вместе с
изменениями в ранжировании и достижениями в вопросах определения.
Этап 5
На заключительном этапе следует удостовериться, что управление рисками
является непрерывным процессом в рамках управления проектами. Отслеживание и
контроль рисков, включенными в список, должен выполняться на регулярной основе.
Менеджер проекта и все члены команды должны обращать пристальное внимание на
поведение идентифицированных рисков, а также контролировать процессы их
определения. Новые риски должны идентифицироваться прежде всего, для них
определяются приоритеты, которые затем добавляться в план управления рисками. Риски с
высоким приоритетом следует обрабатывать в соответствии с общим планом проекта.
Таблица 18.5. Еженедельный отчет об изменениях рисков
Пункт риска
чсственным
характеристикам
11естабильность
защиты
Проблемы со
временем
Новые
технологические риски
Рейтинг на Последний Число не- Подход к определению
этой неделе рейтинг дель в списке
Контакт под вопросом
Выполнение
Delphi-оценок
При экспертной оценке
вопросов с заказчиком
При экспертной оценке
вопросов с заказчиком
Экспертная оценка
каждого нового требования
относительно затрат
Экспертная оценка
каждого этапа
Еще не обнаружен
второй поставщик
Соглашение по поводу
использования скобок
рассматривается
План по имитации
в марте
Экспертная оценка
требований
Слишком мало
экспертов по разработке
программ
Привязка разработки
к графику
Слабая функция
отчетности
Слишком различные
интерфейсы
Новые требования
Угроза "позолоты"
11еизвестность по ка-
1
2
3
4
5
6
7
1
2
5
4
3
6
8
2
2
3
3
4
4
3
9
10
10

610 Глава 18
Резюме
Управление рисками, связанными с разработкой ПО, является формальным
процессом, при котором факторы риска систематически идентифицируются,
оцениваются и смягчаются. Основная задача управления проектами состоит в определении
риска в проекте, возникшего вследствие либо внешних, либо внутренних причин.
Управление рисками включает идентификацию риска, определение его
количественной характеристики, разработку отклика на риск и управление за откликом на него.
Чтобы помочь менеджеру проекта в процессе определения риска и управления им,
в главе рассматриваются следующие вопросы.
■ Что такое управление рисками?
■ Каковы некоторые модели менеджмента рисков?
■ Как выполняется идентификация рисков?
■ Каким образом анализируются и идентифицируются риски?
■ Как разрабатываются отклики на риски и каким образом реализуется их контроль?
■ Какие шаги необходимы для разработки плана управления рисками?
Управление рисками является центральным моментом для всех областей
проектного менеджмента.
Контрольные вопросы
1. Менеджер проекта системы управления лифтами применял методику Delphi для
получения ответа на вопрос: "Следует ли использовать формальные методы для
доказательства адекватности возможностей по безопасности встроенной системы
управления"? Результаты пятого раунда показаны на рис. 18.13.
A. Что означают эти результаты для менеджера проекта?
B. Сколько раундов нужно реализовать в методе Delphi?
C. Можно ли переформулировать вопрос с целью достижения лучшего эффекта?
2. Следует ли в проекте по созданию системы управления лифтом затратить 500 000
долларов на оплату работы независимого аудитора программного обеспечения?
Аудитор обнаружит критические ошибки. Также нужно учесть, что начислен штраф
в размере 18 миллионов долларов, который следует заплатить, если критическая
ошибка будет выявлена заказчиком. Вероятность того, что критическая ошибка
будет найдена без привлечения аудита, составляет 0,3, вероятность того, что
критическая ошибка не будет обнаружена составляет 0,1, и того, что критических ошибок
нет — 0,6. С привлечением аудита вероятность обнаружения критической ошибки
возрастает до 0,36, а вероятность не обнаружить критическую ошибку снижается до
0,04. Постройте дерево решений для данных количественных характеристик риска.
3. Каким образом отображается распознавание технических, программистских и
поддерживаемых источников риска, если можно ожидать, что они
идентифицируются в рамках модели жизненного цикла IEEE 1074? Где они находятся в
спиральной модели жизненного цикла?
4. Каким образом методики Delphi и Монте-Карло применяются в приложении G
при идентификации рисков, связанных с задачей системы управления лифтом?

Определение рисков, связанных с выполнением проекта 611
Назначенная вероятность (%)
Желательность практически 100%
Высокая степень желательности
Очень хороший шанс
Возможно
Вероятно
Мы полагаем
Лучше, чем выравнивание
Мы полагаем
Невероятно
Нежелательно
Вероятность нулевая
Малые шансы
Практически нет шансов
Высокая степень нежелательности Г
1
9 О
О О
'
гг-
г~"
-±-
-н~-
г-Н
__]—i «
Г"
■
I
hr^
f i
t
i
k
T
!_..
-ь
~H
1
j
-h
-b
4i
T.t
i'i
r—•
,l
•
***
L__fi
"-fT
h-^H
—I—
f— i
f
-h
J..!
■
Шансы незначительны £
fuc. 18.13. Проблемная диаграмма пятого раунда Delphi
Практическое занятие
М-р Адаме прибыл на конференцию, которая проводилась группой по подготовке
правительственных заказов из вашей корпорации. Они сообщили об инструменте,
который поддерживается Рабочей сетью менеджеров ПО (Software Project Managers
Network) (www.spmn.com). Этот инструмент называется Risk Radar. Этот свободно
распространяемый инструмент является базой данных по управлению рисками,
помогающей менеджерам проектов в гибкой и удобной форме выполнять
идентификацию проектных рисков, определять приоритеты и устанавливать связи между ними.
Поддерживаются функции стандартных баз данных, позволяющие добавлять и
удалять риски, а также специализированные функции, с помощью которых можно
устанавливать приоритеты и выводить из эксплуатации проектные риски. Каждый риск
имеет определенный пользователем план управления и журнал регистрации.
М-р. Адаме убеждал д-ра Харита, что рассматриваемый инструмент работает с
материальным процессом и может служить дополнением к тем инструментам по
оцениванию и определению размеров, которые в настоящее время применяются в BSD.
Д-р Харита одобрительно воспринял совет и опробовал инструмент при работе над
небольшим проектом под своим руководством. Вы уже догадались? В данном случае
идет речь о ARRS!
Д-р Харита не смог получить доступ к Web-узлу через брандмауэр BSD и просит вас
загрузить его и выполнить первый этап разработки набора стандартных отчетов (как
коротких, так и длинных) для совместного использования ARRS-информации о риске
вместе с командой разработки. Об этом пойдет речь на телеконференции, которая

612 Глава 18
оудст проходить на следующей неделе. Когда вы вернетесь к матрице распределения
ответственности, то поймете, что именно вы несете ответственность за анализ
рисков для проекта ARRS.
Дополнительные сведения в Internet
wwu.baz.com/kjordan/swse625/intro.litnil. К. Джордан (K.Jordan). Введение в
программные риски и управление ними, 1997.
www.eaij.asu.edu/~riskmgmt/intro.html. Раймонд Миллер (Raymond Miller). Управление
качеством и рисками, 1997.
www. sei . cinu.edu/publications/documents/97. reports/97hb002/97hb002abstract.html.
bpaiiaii Галахер (Brian Gallagher), Кристофер Альберте (Christopher Alberts) и Ричард Барбор
(Kiihaid Barbour). Ключевая область процессов управления рисками для приобретаемого ПО
(КРЛ) - руководство, версия 1.0.
www.sei.cmu.edu/publications/documents/97.reports/97hb002/97hb002abstract.ht
. ■ I Джеймс С. Коллофелло (James S. Collofello). Управление рисками при разработке ПО.
Инструменты, обеспечивающие
управление рисками
Инструмент Risk Radar, — основанный на MS Access инструмент по отслеживанию рисков.
www. .spurn. com/rsktrkr. html.
Информационный дайджест по инструментам управления рисками, www. incose.org/tools/
1 uol tax/riskmgt_tools.html.
Модуль Risk+, дополнительный модуль к MS Project, www. cs-solutions. com/riskplus. htm.
Модуль ("/Risk, дополнительный модуль для Excel или MS Project, www.palisade.com/html/
r; ik.html.
Литература
Boelun Barry W. Tutorial: Software Risk Management. Los Alamitos, CA: IEEE Computer Society Press,
! •№.).
KaroLik. Dale. Software Engineering Risk Management Los Alamitos, CA: IEEE Computer Society Press,
1!><>(,.
Pi itchai d Carl. Risk Management. Arlington, VA:ESI International, 1997.

Введение
в программный
инжиниринг
Программный инжиниринг (разработка ПО) «^относится к компьютерным наукам в
полном смысле этого слова. Скорее он служит проводником идей в неких абстрактных
языках программирования. Впервые появившись в далеком 1968 году, разработка ПО с
полным правом может быть отнесена к самому современному виду инженерной
деятельности: "Название 'программный инжиниринг' было далеко не случайным, ибо оно
выражало потребность индустрии по производству ПО в теоретических основах и
практических дисциплинах, которые являются вполне устоявшимися в традиционном
инженерном деле". В своем выступлении на этой же конференции Фриц Бауэр (Fritz
Bauer) определил программный инжиниринг как "реализацию и применение четко
выработанных инженерных принципов с целью разработки экономичного ПО, которое
является надежным и может выполняться на реальных компьютерах" . На протяжении
этой главы вы встретите другие определения программного инжиниринга,
используемые практикующими менеджерами программных проектов.
В документе Основы знаний в области менеджмента проектов (Project
Management Body of Knowledge, PMBOK), изданном Институтом менеджмента проектов
(Project Management Institute) определяется пять групп процессов менеджмента
проектов: процессы планирования, выполнения, контроля, закрытия, а также начальные
процессы. Настоящая глава знакомит с основами процессов инжиниринга ПО в
проекте, в рамках которого выполняется его разработка. На данной стадии происходит
применение оцененных и запланированных ресурсов к процессу выполнения плана
проекта. На рис. 19.1 демонстрируется относительный объем трудозатрат,
понесенных при осуществлении каждого процесса. Процессы выполнения требуют
наибольшего объема бюджетных затрат, поскольку достаточно велик уровень и объем
действий, требуемых для разработки качественного ПО.
' Конференция Software Engineering Conference, проводимая под эгидой научного комитета
НАТО, под редакцией Питера Наура (Peter Naur), p. 13, 1968.
s Bauer Fritz L. "Software Engineering". Information Processing, 1972.

614 Глава 19
Процессы
выполнения
Начальная фаза Конечная фаза
Время *•
Рис. 19.1. Процессы, происходящие в ходе выполнения менеджмента проекта
В этой главе вы не найдете всеобъемлющего рассмотрения всех аспектов
программного инжиниринга. Дополнительные сведения по этой теме лучше поискать в
книге Роджера Прессмана (Roger Pressman) Software Engineering. A Practitioner's Approach .
Менеджеры программных проектов обязаны понимать суть описанных процессов,
что позволит им создавать высококачественное ПО. Описанию этих процессов и
посвящена настоящая глава.
Стадии жизненного цикла
разработки продукта
На данный момент завершены начальная фаза и фаза планирования. Также
завершена разработка первой версии спецификации требований к ПО. В
распоряжении менеджера проекта оказался прототип, при разработке которого
ставилась цель проверки на практике концепции или оценка степени выполнимости.
Начиная с этапа завершения всех моделей формирования требований, которые
включаются в план SRS, и вплоть до момента завершающей поставки и установки,
методы программного инжиниринга, методики и инструментарий направлены на
поддержку процессов выполнения проекта. Этот период времени
проиллюстрирован на рис. 19.2.
Совместными усилиями Общества компьютерных стандартов IEEE (IEEE
Computer Society) и Координационного комитета по вопросам программного
инжиниринга АСМ (АСМ Software Engineering Coordinating Committee) был разработан документ
Основы знаний в области программного инжиниринга (Software Engineering Body of
Knowledge) . В этом документе описываются процессы поддержки, происходящие на
протяжении всего жизненного цикла. Благодаря использованию подобного
документа можно ограничить жизненный цикл, изображенный на рис. 19.2, дисциплинами,
относящимися к программному инжинирингу.
Pressman Roger S. Software Engineering: A Practitioner's Approach, 5-е издание. McGraw-Hill, 2001.
1 www. SWEBOK. org.

Введение в программный инжиниринг 615
к
ч -' \
Исследование
концепции
™„„,.. ,
рование

потребности
1 .
1 Г
\
Исследование
системы
.
• Спецификация'
интерфейса
системы
, .
1
\
Процессы выполнения
V
Требования
,
■ Спецификация'
требований
к ПО
ч
< i
\
Разработка
проекта
_
•иписание •

разработки ПО
• Пл
1
11
\
Внедрение
тации/вери-
фикации ПО
i
Г
N
Установка
; ,
■ Отчет оо ат- '
тестации/ве-
рификации ПО
< <
\
Эксплуатация
и поддержка
•
Пользовательская
документация
i<
Сопровождение
V
_ , 1
■ До сументация *
по
сопровождению
i г
■ .
ч
Вывод из
эксплуатации
• Архивный
отчет
Рис. 19.2. Местонахождение процессов выполнения в жизненном цикле разработки ПО
Связь главы 19 с 34 компетенциями
Процессы программного инжиниринга тесно связаны со многими навыками по
менеджменту программных продуктов, а также с одним навыком, лежащим в
плоскости менеджмента проектов. Именно здесь находится та поворотная точка всего
процесса менеджмента проекта, где менеджер проекта осуществляет переход от стадии
планирования и начала работ в рамках проекта к стадии выполнения. Применяемые в
этом случае компетенции взаимодействуют с процессами по разработке ПО.
Методики разработки продукта
1. Процессы оценивания.
2. Оценка альтернативных процессов.
3. Отбор методов и инструментов.

616 Глава 19
4. Подгонка процессов.
Менеджмент проектов
5. Отслеживание процесса разработки.
Если менеджер проекта способен успешно применять методы программного
инжиниринга, соответствующие методики и инструменты, достижение целей проекта
гарантировано.
Учебные цели главы 19
После изучения материала главы читатель должен уметь выполнять следующее:
■ успешно принимать участие в дискуссиях, посвященных вопросам программного
инжиниринга в жизненном цикле разработки ПО;
■ объяснять, какие из 34 компетенций, связанных с конечным продуктом,
процессом и персоналом, имеют отношение к программному инжинирингу;
■ описывать, каким образом модель зрелости возможностей, разработанная
Институтом программного инжиниринга (Software Engineering Institute), связывает
программный инжиниринг с процессами обеспечения качества
разрабатываемого продукта;
■ определять суть программного инжиниринга.
Определение программного инжиниринга
в модели SEI СММ
Модель СММ имеет отношение к группе моделей программных процессов,
разработанных на широкой базе, поддерживаемой сообществом разработчиков ПО. По-
(кольку мы имеем дело с моделью, наблюдается упрощение реального процесса
инжиниринга. Представляя собой норматив, модель СММ идентифицирует
возможности организации, относящейся к категории той или иной степени зрелости.
Организации, применяющие эту модель в качестве механизма измерения и
совершенствования процессов, должны использовать приемлемую интерпретацию
областей знаний процесса в аспекте деловых целей. При использовании этой модели в
качестве средства оценки процессов и инструмента измерения, она становится своего
рода "дорожной картой", обеспечивающей успешное улучшение процесса. Вообще
говоря, модель СММ можно рассматривать в качестве совокупности четко
сформулированных концепций инжиниринга и менеджмента, основанных на проверенных
принципах обеспечения качества (например, концепции TQM, Деминга (Deming) и
Косой (Crosby)). В процессе разработки ПО, когда знания требуется должным
образом оценивать и защищать, следует уделять немалое внимание принципам
обеспечения качества (см. примечание 19.1).
Модель СММ не является сборником предписаний на все случаи жизни. Здесь не
сказывается, каким образом организация должна устанавливать атрибуты процесса.
Также ее применение не гарантирует немедленный успех. Процесс внедрения
улучшений требует времени и непрерывных усилий в масштабах всей организации. При
:-»том особое значение приобретает исполнительный менеджмент и выделенные сред-
с тал. Модель СММ трудно отнести к разряду универсальных методологий, когда

Введение в программный инжиниринг 617
"один размер пригоден на все случаи жизни". Первый шаг, который требуется сделать
па пути использования этой модели, заключается в настройке приложений уровней
зрелости в соответствии с конкретной организацией и имеющимся набором
проектов. Институтом SEI были разработаны другие модели зрелости возможностей,
которые применимы к персоналу организации, процессу приобретения ПО, инжинирингу
систем, интегрированному процессу разработки программного продукта, а также по
отношению к персональному программному процессу.
Примечание 19.1. ПО — материализованные знания
Источник: Howard, Baetjer, JrkiA997).f«$^^
Software Engineering. Los AlamltP^C^ ffiEE^roput^Sodety,'
Поскольку ПО, как и любой дрзтч>Й1Йп^^
зованных знаний, а также в сшитого, что знйи^из^ачал^ьно яйляются несистема-
тизированньши, неопрёд^ёмнымй Ш; по
программу можнб предотавйть й'й^'^рбцехсасс^ального обучения. Этот
процесс реализуется в* форме диалбга1, в;shpoi^cce^dqrafe
мые знания материализуются !ei виде готового; njiolfpa^Hbr^ При этом
осуществляется общЫиёГмеж)г| пользователями и разработчиками, реализуется
взаимодействие между пбльзЬватёляййй тр^буемыйи инструментами
(технология). Этот процесс является итеративным, причем используемые инструменты
образуют среду, в которой осуществляются коммуникации. Каждый новый раунд
диалога способствует получению все более полезных знаний со стороны
привлеченных специалистов. "* , ;,> .\-:ч.-. ->
Одним из основных применений модели СММ является определение того, что
означает процесс, достигший определенной степени зрелости. В применении к ПО
можно сказать, что зрелому процессу присущи следующие атрибуты:
■ определенный — указывается "способ, требуемый для выполнения дела";
■ документированный — разработан таким образом, что может быть известным и
используемым в дальнейшем;
■ изученный — обучение на основе документации;
■ практичный — может применяться на практике, а не откладываться в "долгий ящик";
■ поддерживаемый — доступный, пересмотренный и улучшенный;
■ контролируемый — изменения одобрены "участниками совместного дела";
■ верифицирован — процесс выполняется корректно;
■ проверен — выполняется именно тот процесс, который необходим;
■ измеренный — оцененная производительность применяется в качестве базиса для
контроля и улучшения процесса;
■ способность к улучшению — гибкость и способность к изменениям.
Преимущества зрелого процесса становятся очевидными в результате выполнения
некоторого анализа. Составленные графики и бюджеты основаны на исторических
сведениях, относящихся к оценкам производительности, и являются реалистичными.
Как правило, получаются ожидаемые результаты, связанные с затратами, графиком и
функциональными свойствами. Все, кто принимает участие в разработке, понимают

618 Глава 19
важность последовательного выполнения установленного процесса. Существующая
инфраструктура предназначена для поддержки процессов (программный
инжиниринг и его бизнес-аспекты), а менеджеры обязаны отслеживать качество
программных продуктов, а также процессы, в результате протекания которых создаются эти
продукты. При этом во главу угла ставится процесс, а не человек.
Инжиниринг программных продуктов относится к области ключевых процессов
для уровня 3, т.е. "определенного".
Назначение процесса инжиниринга программных продуктов заключается в
последовательном выполнении хорошо продуманного процесса инжиниринга, в результате чего
достигается интеграция всех соответствующих действий, направленных на быстрое и
эффективное получение корректных и совместимых программных продуктов.
Процесс программного инжиниринга включает выполнение инженерных задач, в
результате чего создается и поддерживается ПО. При этом используются
определенный программный процесс, а также подходящие методы и инструменты. В
процессе выполнения задач программного инжиниринга производится анализ
системных требований, сформулированных для данного ПО, разрабатывается сама
программа, происходит ее реализация в программном коде, интегрируются
программные компоненты, а также происходит тестирование ПО на предмет
соответствия указанным требованиям.
Полк Вебер, Куртис и Криссис (Paulk Weber, Curtis, Chrissis), The Capability Maturity
Model: Guidelines for Improving the Software Process .
Цели
Цель 1. Определяются, интегрируются и последовательно выполняются
задачи, связанные с процессом программного инжиниринга, в результате чего
разрабатывается ПО.
Цель 2. Поддерживается взаимная совместимость между программными продуктами.
Действия
Действие 1. Производится интеграция в определенный процесс программного
проекта уместных методов и инструментов программного инжиниринга.
Действие 2. Выполняется разработка, поддержка, документирование и
верификация требований к ПО на основе систематического анализа имеющихся требований в
соответствии с определенным программным процессом для данного проекта.
Действие 3. Производится разработка, поддержка, документирование и
верификация структуры программы в соответствии с определенным программным
процессом для данного проекта. При этом ставится цель аккомодации требований к ПО и
формирования каркаса, обеспечивающего создание программного кода.
Действие 4. Выполняется разработка, поддержка, документирование и
верификация программного кода согласно определенному программному процессу
проекта. При этом ставится цель реализации требований к ПО и программного
проекта в целом.
Действие 5. Тестирование ПО производится в соответствии с определенным
программным процессом проекта.
' См. сноску 1.

Введение в программный инжиниринг 619
Входы
Действие 6. Планируется и выполняется интегрированное тестирование,
соответствующее определенному программному процессу проекта.
Действие 7. Планируется и выполняется системное тестирование, а также
тестирование пригодности ПО. В результате проверяется степень соответствия ПО
сформулированным по отношению к нему требованиям.
Действие 8. Разрабатывается и поддерживается документация в соответствии с
определенным программным процессом проекта. Она используется на этапе
эксплуатации и поддержки ПО.
Действие 9. Производится сбор и анализ данных о дефектах, полученных в ходе
выполнения экспертных оценок и тестирования ПО. При этом руководствуются
определенным программным процессом для данного проекта.
Действие 10. Поддерживается совместимость для всех компонентов
производимых программных продуктов, включая планы выпуска ПО, описания процессов,
сформулированные требования, программные требования, программный проект,
код, планы и процедуры тестирования.
Процесс программного инжиниринга
представляет собой "применение систематического,
упорядоченного и исчисляемого подхода к
разработке, эксплуатации и поддержке ПО;
применение принципов инжиниринга по отношению
к процессу разработки ПО" . На рис. 19.3 вы
видите не модель жизненного цикла, которой
обязаны следовать инженеры-программисты, а
просто общепринятую традиционную модель
разработки ПО. Разработчики основываются на
незавершенном наборе требований, сформулированных на фазе "урезанных"
требований, и разрабатывают код с тем, чтобы получить удовлетворяющую запросы
пользователей программу. В данном случае мы имеем дело с системой замкнутого цикла,
обратные связи которой не выходят за пределы группы разработчиков.
ПО, инжиниринг и программный
инжиниринг
При определении понятия ПО используется некий исторический контекст. До
1968 года термин "программный инжиниринг" (см. примечания 19.2, 19.3 и 19.4)
вообще не применялся.
Примечание 19.2. Определение программного инжиниринга
Пока не выполнено,_
выполнять
Рис. 193. Не используйте этот
жизненный цикл
?* *""«*£•'»£?%
Источник: Boehro, Barry W, "ПрограмйнЫ^йнжи!
Программный инжиниринг представляет, ";"я'
ных знаний к процессу проектированиям
а также соответствующей ppttpe^^wj^i^
ции и поддержки программ. Этот процесс^гакж»;
производством программ. - ■*•
>Г'Ь
IEEEStd 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.

620 Глава 19
Примечание 19.3. Определение ПО
-1
Источник: Webster's College Dictionary. NY: Random HouseA19v92.„
software (ПО) (n, soft-ware) дата: 1960 год ■ ,. , ,. ,j»j-. •' .,«, ..r • .i .,«, .
1. Программы, процедуры и символические языки, «сонтролирую«цие.
функционирование аппаратного обеспечения и управляющие выполнени»
операций. ' j "'••,.'''« v"
Примечание 19.4. Определение инжиниринга
Источник: Webster's Dictionary of the English Language. i0: 'JjejSffch^^a^tis,JiS0.k
engineering (инжиниринг)  r :n/■;, , :v .jj'v^W1:^, ,;i ■;«-: "VV
1. Наука, изучающая способы применения 'знаний•TfeauoMtrmk-матерЧии^иэдрйр^йдных-!
источников энергии для решения практических Г1роблему всвникаюших в шадустрии. :
Кто же изобрел первую программу? Если руководствоваться определением ПО (IEEE
Standard 610) как совокупности объектов, которые "контролируют процесс
функционирования аппаратного обеспечения и управляют ходом выполнения операций" , то первой
программой, созданной в 1804 году, является устройство, автоматизирующее прядильный
процесс. Благодаря этому устройству стала возможной автоматизация прядильного
процесса на фабриках, когда управление работой оборудования начало осуществляться
силами одного оператора, работающего без ассистентов. Джакард (Jacquard) не получил
патента на свое устройство. Принадлежащий ему патент 1801 года, выданный на
улучшенный ткацкий станок, часто ошибочно трактуют как патент на устройство, управляемое
перфокартами, которое носит его имя. Работая в городе Лионе (Франция), Джакард
создал свою машин)' путем комбинирования двух идей, принадлежащих французским изобре-
тат елям: цепь перфокарт Джина Фалькона (Jean Falcon) и цилиндрический механизм
Жака Вакансона (Jacques Vaucanson). Устройство Джакарда монтировалось на верхней части
ткацкого станка с ножным приводом. Именно здесь мы видим первый пример
использования перфокарт с целью управления производственным процессом .
В примечании 19.5 содержится краткая справка по истории развития
вычислительных механизмов и ПО.
Примечание 19.5. История развития программного инжиниринга
Источник: worldhKtorysite com/culttech.html Thistlerose Publications, copyright 2000.
Вычисления и компьютеры: исторические даты > . ,
1617 г. Джон Непер (John Napier) продемонстрировал выполнение операций ум-
ножения и деления с помощью счетов. ^ -Г^^ЖШ'^РШ^' *М ^
1642г.БлезПаскаль.(BlaisePascal) изс>бретаетарифмометр, .--у».*-,. >««i. t>
1671 г. Готфрид Вильгельм Лейбциц (ОЖ X^ibrr|if^c4p^eTaer^ифмометрл-^иаЫ
u "f % iV>TTbaJ*i*eV. ♦3'» »■ Ч * ' * « , - * >
женный редукторным механизмом. , t -%ч ';«-,&ТХ**^Л »£*bV"^-f ti l. \
См. сноску 6.
"history.acusd. edu/деп/recording/notes. html. Steve Schoenherr. Recording Technology
Hnion, 2001.

Введение в программный инжиниринг 621
1801 г. Джозеф Джакард (Joseph Jacquard) изобрёл ткацкий прядильный станок,
управляемый с помощью перфокарт.
1820 г. Чарльз Томас (Charles X. Thomas) изобрел коммерческую
вычислительную машину.
1835 г. Чарльз Бэббидж (Charles Babibage) изобрел "Аналитический механизм",
предвестник появления компьютеров.
1959 г. Джордж Буль (George Boole) опубликовал научный труд, посвященный
основам двоичной алгебры.
1897 г. Чарльз Сандерс Пирс (Charles Sanders Peirce) применил булеву логику к
анализу электрических схем.
1872 г. Лорд Кельвин (Kelvin) разработай^ агеалогошлй компьютер, используемый
для расчета приливов и отливов. j ,, " ' „ч
1886 г. Герман Холерит (Herman НоиепШ);П]реддожил ишользовать перфокарты
при вычислениях. v ", ', '
1890 г. Идеи Холерита были успешно реализованы в ходе проведения переписи
населения в США. , , ■' - .,-
1911 г. Усилиями Холерита была-создана компания, которая позднее получила
название IBM. * * '* '
1937 г. Джордж Стибиц (George Stibitz) создал электрическую схему, в которой
были применены законы булевой алгебры.
1939 г. Специалисты из фирмы IBM и Говард Айкен (Howard Aiken) из
Гарвардского университета начали работу по созданию компьютера Mark I.
1943 г. Компьютер, разработанный Аланом Тьюрингом (Colossus), сумел разгадать
немецкий секретный код Enigma.
1946 г. Был создан компьютер Electronic Numerical Integrator and Calculator (ENIAC).
1946 г. Группа ученых. Фон Нейман (Von "Neumann), Колдштайн (Coldstine) и
Бурке (Burks) опубликовали труд.-в котором обосновали основные концепции,
связанные с применением компьютеров;
1949 г. В университете штата Иллинойс на основе принципов Фон Неймана был
разработан компьютер ILLIAC.
1951 г. В бюро переписи США был установлен компьютер UNIVAC.
1956 г. Компьютер победил человека в игре в шахматы,;
1957 г. Усилиями сотрудников фирмы IBM был разработан язык
программирования FORTRAN. '; и *\\ а, * "
1959 г. Джек Санта-Клер Килби (Jack St. Clair Kilby),,специалист из фирмы Texas
Instruments, разработал первую микросхему^
1960 г. В исследовательской лаборатории Liyerroore Advanced Research Computer
(LARC) был создан транзистор. •» , % • ;
1969 г. В Министерстве обороны США была разработана компьютерная сеть
ARPANET.
1971 г. Инженеры из фирмы Intel изобрели первый микропроцессор.
1972 г. Нолан Бушнель (Nolan Bushnell) разработал первую видеоигру ("Pong").

622 Глава 19
1972 г. Рэй Томлинсон
почтой, воспользовавшись
1974 г. Появились первые персональные комльк^геры.*^*^.^&Й^,,» -мйгта^.
1974 г..В супермаркетах появились первые сканерьг,штрих-код6в* Г^Д.*& *" -^%sJL
1977 г. Запатентовано у< тройство в виде перчатш^ладегчарщё^^взаимодеиствие^с
компьютером. --ч< <£*« *-*"*V< ц^^мг^/^ ^ ^J**1 *
1977 г. Компьютерные эффекты, примененные Джорджем Лукасом*'(George Lucas)
при создании фильма "Звездные войны", произвели настоящую революцию в
режиссерском деле. '
1979 г. В Японии была продана первая видеоигра (Рас-Май^
1980 г. Дэн Бриклин (Dan Bncklin) и Дэн Фли< " ~~
ный код для электронной таблицы VforCalc*
1981 г. Фирма IBM представила персональны^
лением операционной системы Microsoft.*, i
1982 г. Службы француз» кой почта 5$телеграф§Г
1983 г. На основе ARPANET возникла йвь^рос _
произошло окончательное разделени^междиражд^н'йй
1984 г. Фирма Apple Computer анонсировала*^®"'''***"""
графическим интерфейсом пользовед?елд^^»'
1985 г. Фирма Microsoft анонсировала* первуюТ "
1991 г. Возникла "всемирная паутина^, ^Vori< p ^_ ,
1992 г. В США был зафиксирован комт>ютернЫйДирус
2000 г. Пресловутая "проблема 2000-го грдап шнамЦвВала" Н&алО но^г^'тъйгячел^туйк^
Первое появление широко распространенного ПО датируется 1890 годом. Именно в
это время в Американских центрах по проведению переписи населения появились
перфокарты Германа Холерита. В это же время произошел первый перерасход средств по
нине "компьютеров". Результаты центров по проведению переписи населения США
изначально были протабулированы с помощью вспомогательных механических средств;
механических табуляторов Германа Холерита A860-1929 гг), Массачусетский технологический
институт, Кембридж, штат Массачусетс. В это же время и начало развиваться
производство перфокарт. Средства, затраченные на табуляцию данных центров переписи населения,
на 98 % превышали аналогичные затраты, понесенные в прошлом. Отчасти это
объясняется тем, что шаблон, используемый при табуляции данных, был разработан весьма
подробно и объем табулированных данных превышал минимально необходимое количество.
Хотя и сам процесс табуляции был значительно ускорен. В это же время появились пер
фокарты, считывание которых выполнялось электрическим способом .
Итак, ПО появилось еще в XIX столетии. Первые сведения о возникновении
"инжиниринга" датируются 2550 годом до н.э.
Первым инженером, имя и достижения которого стали широко известными, был
Имхотеп, строитель пирамид в Саккаре (Египет) примерно в 2550 году до н.э.
Последователи Имхотепа — египтяне, персы, греки и римляне — подняли инженерное
искусство на невиданную высоту. И не последнюю роль здесь сыграли достижения
' wuw.best. com/ -wilson/faq/. alt.folklore.computers, List of Frequently Asked Questions.

Введение в программный инжиниринг 623
в арифметике, геометрии и физике. Образцами высокого инженерного гения,
некоторые из которых дожили до наших дней, служат Фаросский маяк в Александрии,
храм Соломона в Иерусалиме, Колизей в Риме, персидские и римские дороги, акведук
Pont du Gard во Франции, а также многие другие величественные сооружения. Среди
множества трудов, посвященных описанию инженерных наук, один дошел до наших
времен. Он содержит полную картину, описывающую принципы инженерного
образования и практики в Древнем мире. Этот труд называется De architectura (Витрувий),
впервые он опубликован в 1-ом столетии н.э. в Риме. В этом десятитомнике можно
найти описание применяемых строительных материалов, методов монтажа, законов
гидравлики, методов измерений и разработки планов застройки городов .
Основы знаний в области программного
инжиниринга
Термин Основы знаний в применении к программному инжинирингу является
всеобъемлющим и описывает всю сумму знаний, характерных для профессии, связанной
с программных инжинирингом. И поскольку обычно невозможно "втиснуть" в один
документ всю сумму знаний даже для такой сравнительно недавно появившейся
области, как программный инжиниринг, необходимо составить подробное руководство,
посвященное этим вопросам. Подобное руководство позволит идентифицировать и
описать те основы знаний, которые являются наиболее распространенными, хотя
инженеры-программисты должны быть осведомленными не только в вопросах
программного инжиниринга, но и в смежных дисциплинах. Команда разработчиков
проекта SWEBOK определила пять основных целей .
1. Характеристика дисциплины программного инжиниринга.
2. Поддержка тематического доступа к основам знаний в области программного
инжиниринга.
3. Выполнение непротиворечивого обзора процесса программного инжиниринга.
4. Уточнение места (и набора ограничений) программного инжиниринга
относительно других дисциплин, таких как информатика, менеджмент проектов,
компьютерный инжиниринг и математика.
5. Обеспечение фундамента для обучения процессу разработки и индивидуального
сертификационного материала.
На рис. 19.4 приводится диаграмма, описывающая топологию документа SWEBOK.
Примечание 19.6 определяет еще одну точку зрения на определение программного
инжиниринга.
Примечание 19.6. Определение программного инжиниринга,
отличное от определения IEEE
Программныйинжиниринг—-jfoo'^eHM&p. ^тШмейясиык
при разработке^ По|№ержкё|^
Bourque Pierre и др. "The Guide to the Software Engineering Body of Knowledge. "IEEE
Software, pp. 35-44, 1999.
11 См. сноску 10.

Руководство SWEBOK
Человек на перепутье @.9)
Основные концепции, определимте
разработку программного проекта
Ключевые вопросы, огееделяпидие
разработку программного проекта
Структура и архитектура программного
обеспечения
Оценка и анализ качества,
достигаемого в процессе разработки
программного проекта
Заметки в процессе разработки
программного проекта
Стратегии и методы, применяемые
в процессе разработки программного проекта
Тестирование
программного
обеспечения
Определения и базовые концепции,
применяемые в процесса
тестирования
Уровни тестирования
Методики тестирования
Измерения, производимые
в процвсов тестирования
Управление процессом
тестирования
Требования, выдвигаемые
к прогрзлаынгя^ обеспечению
Менеджмент
конфигурации
программного
обеспечения (SCM)
Управление процессом SCM
Илентифиацп конфигурации
программного обеспечения
Контроль конфигурации программного
обеспечения
Учет состояния, достигаемого в процессе
конфигурации грогривяето обеспечения
Аудит, выполняемый в процессе
конфигурации программного обеспечения
Поставка и управление версиями
проггшвяпго оботечония
Конструирование
грограммного обеспечения
Процесс разработки требований
Выявление требований
Анализ требований
Спецификация требований
Аттестация требований
Управление т[яиУ)вакиями
Уиаиывение (лечим сложности
Предвидение расхождений
Структурирование процесса
аттестации
Использование внешних
стандартов
Процесс
программного
инжиниринга
Концепции, прима винные
в процесса программного инжиниринга
Инфраструктура процесса
Измерения, осуществляемые
при выполнении процесса
Определение процесса
Количественный анализ процесса
Внедрение и измай»«и процесса
Основные концепции процесса
солрсяяхкдвния
Ювочевыаяолрс
ГХХХрЯЫМЮГОО
методики, прим
Качество
программного
обеспечения
Качество программного обеспечения
Концепции, огфеделякхцие
■очество программного обеспечения
Опреде/кние и планирование
качества
Методики, требующие усилий
двух либо большего количества
исполнителей
Гюддержка других методик
методики поиска дефектов
Измерения при анализе качества
гюограммноге обеспечения
Тесты и методы, связанные
с программным инжинирингом
[прмтяымимичгфумитГ]
(^Программные методы
Рис. 19.4. Структурирование областей знаний согласно руководству SWEBOK

Введение в программный инжиниринг 625
В результате структурирования областей знаний согласно SWEBOK охватываются
перечисленные ниже области знаний. Большими римскими цифрами обозначаются
основные области.
I. Требования к ПО
1. Процесс инжиниринга требований.
2. Выявление требований.
3. Анализ требований.
4. Спецификация требований.
5. Аттестация требований.
6. Управлением требованиями.
II. Проектирование ПО
1. Основные концепции, определяющие проектирование ПО.
2. Ключевые вопросы, определяющие разработку ПО.
3. Структура и архитектура ПО.
4. Оценка и анализ качества, реализуемого в процессе разработки ПО.
5. Записи в процессе проектирования программы.
6. Стратегии и методы, применяемые в процессе разработки программ.
III. Конструирование ПО
1. Уменьшение степени сложности:
- методы лингвистического конструирования;
- методы формального конструирования;
- методы визуального конструирования.
2- Предвидение расхождений:
- методы лингвистического конструирования;
- методы формального конструирования;
- методы визуального конструирования.
3. Структурирование процесса аттестации:
- методы лингвистического конструирования;
- методы формального конструирования;
- методы визуального конструирования.
4. Использование внешних стандартов:
- методы лингвистического конструирования;
- методы формального конструирования;
- методы визуального конструирования.
IV. Тестирование ПО
1. Определения и базовые концепции, применяемые в процессе тестирования.
2. Уровни тестирования.
3. Методики тестирования.
4. Измерения, производимые в процессе тестирования.
5. Управление процессом тестирования.

626 Глава 19
V. Сопровождение ПО
1. Основные концепции процесса сопровождения.
2. Ключевые вопросы менеджмента ПО.
3. Методики, применяемые на этапе сопровождения.
VI. Менеджмент конфигурации ПО (КПО)
1. Управление процессом КПО.
2. Идентификация конфигурации ПО.
3. Контроль конфигурации ПО.
4. Учет статуса, реализуемого при конфигурации ПО.
5. Лудит, производимый при конфигурации ПО.
6. Поставка и управление версиями ПО.
VII. Управление программным инжинирингом
1. Организационный менеджмент.
2. Менеджмент процессов/проектов.
3. Измерения на стадии программного инжиниринга.
VIII. Процесс программного инжиниринга
1. Концепции процесса программного инжиниринга.
2. Инфраструктура процесса.
3. Измерения, осуществляемые при выполнении процесса.
4. Определение процесса.
5. Количественный анализ процесса.
6. Реализация и изменения процесса.
IX. Инструменты и методы программного инжиниринга
1. Программные инструменты:
- инструменты определения требований к ПО;
- инструменты, предназначенные для проектирования программ;
- инструменты конструирования программ;
- инструменты тестирования программ;
- инструменты, предназначенные для сопровождения программ;
- инструменты, реализующие поддержку процесса инжиниринга;
- инструменты, предназначенные для обеспечения качества ПО;
- инструменты, реализующие управление конфигурацией ПО;
- инструменты, позволяющие реализовывать инжиниринг ПО;
- инструменты, обеспечивающие поддержку необходимой инфраструктуры;
- различные вопросы, связанные с применением инструментов.
2. Программные методы:
- эвристические методы;
- формальные методы;
- методы прототипирования;

Введение в программный инжиниринг 627
- различные вопросы, связанные с Применением методов.
X. Вопросы качества ПО
1. Концепции, определяющие качество ПО.
2. Определение и планирование качества.
3. Методики, требующие усилий двух либо большего числа исполнителей.
4. Поддержка других методик.
5. Специальное тестирование по программе обеспечения качества ПО, а также
выполнения аттестации/верификации.
6. Методики поиска дефектов.
7. Измерения при анализе качества ПО.
Без исчерпывающего обзора основ знаний невозможен полноценный процесс
непрерывного улучшения качества процессов программного инжиниринга. Важно
отметить, что в данном аспекте речь не идет о предметной области информатики. Эта
наука таким же образом связана с процессом программного инжиниринга, как
фундаментальные законы физики соотносятся с анализом электрических цепей. Вообще
говоря, целью любой науки является разработка полезных компонентов, основываясь
на научных законах и ограничениях, накладываемых производственной средой.
Документ SWEBOK и модель SEI СММ
В других главах книги встречается множество ссылок на модель SEI CMM
(особенно в связи со способами, посредством которых эта модель обеспечивает поддержку
тем главы— жизненные циклы, экспертные оценки, метрики и т.д.). В модели СММ
(модель зрелости возможностей) различаются пять различных уровней зрелости.
Каждый тщательно определенный уровень отражает степень зрелости процесса
разработки ПО, а также потенциал возможностей, находящихся в распоряжении
разработчиков. Эти возможности распределяются по нескольким ключевым областям
процессов. Они также могут рассматриваться в качестве уровней, обеспечивающих
основу для непрерывного улучшения процесса. Причем устанавливается ряд целей
процесса во время выполнения и стабилизации задач, связанных с разработкой
важных компонентов программного процесса. По мере достижения различных уровней
зрелости все более эффективно используются различные компоненты процесса
разработки ПО, в результате чего наращивается потенциал процессов разработки в
масштабах всей организации. В этом случае не допускается пропуск отдельных уровней
организациями. Перед переходом к верхнему уровню должны быть удовлетворены
все ключевые области процессов, относящиеся к предыдущему уровню. Области КРА
позволяют организациям сосредотачиваться на процессе перемещения к более
высокому уровню зрелости. В следующих параграфах приводятся пояснения относительно
каждого уровня СММ.
На рис. 19.5 изображены пять уровней зрелости, а также соответствующие им
ключевые области процессов. На уровне 1, т.е. "начальном", области КРА
отсутствуют. Все организации начинают с уровня 1 (при первой оценке). Для всех организаций
этого уровня обычно отсутствует стабильная среда, обеспечивающая разработку и
поддержку ПО. Во времена кризисов процедуры планирования проектов обычно
отменяются, и происходит возврат к этапу кодирования и тестирования. Достигаемый

628 Глава 19
успех полностью зависит от менеджера с выдающимися способностями, а также от
наличия эффективной команды разработчиков. С течением времени происходит
изменение в процессе разработки программы. В общем случае невозможно заранее
предсказать величину бюджета, набор функциональных свойств и оценить качество
программного продукта. Достигаемая производительность может предсказываться
скорее на уровне отдельных личностей, но не для всей организации.
Рис. 19.5. Ключевые области процесса 5£7 СММ,
систематизированные согласно уровню зрелости
Уровень 2, "повторяемый", включает следующие области КРА:
1. управление требованиями;
2. планирование программного проекта;
3. обзор и отслеживание программного проекта;

Введение в программный инжиниринг 629
4. менеджмент субподрядными договорами, заключенными на разработку
программного обеспечения;
5. менеджмент конфигурации ПО;
6. обеспечение качества ПО.
На уровне 2 процесс разработки ПО можно представить в виде набора "черных
ящиков" с определенными контрольными точками (стадиями). Как показано на рис.
19.6, требования включаются в состав процесса и плавно "перетекают" в набор из
"черных ящиков". Для каждого ящика генерируются результаты вычислений, а стадии
и контрольные точки применяются с целью мониторинга процесса разработки
программного продукта. Затем следует стадия внедрения политик, стандартов и
процедур. Количественная оценка этого опыта производится с помощью элементарной
метрической системы, применяемой в данном проекте. Контроль производится
посредством применения формальных практик, задействованных в процессе
менеджмента проектов. Также отслеживаются затраты, графики и набор функциональных
свойств. Основными субъектами процесса являются требования к ПО и рабочие
продукты, а их целостность контролируется с помощью системы менеджмента
конфигурации. Для проектов характерны тесные взаимосвязи со службой поддержки
заказчиков. Также вырабатывается способность к осуществлению программных процессов.
На уровне 3, т.е. "определенном", документируется и последовательно
используется стандартный процесс, применяемый для разработки и сопровождения ПО в
организации (рис. 19.7). В рамках проектов происходит подгонка стандартных
программных процессов организации для их конкретизации. Также интегрируются процессы
менеджмента и программного инжиниринга. Возможности по выполнению
стандартного процесса являются стандартными, а группа разработчиков несет
ответственность за действия, выполняемые в программном проекте. Ниже перечислены
области КРА для третьего уровня зрелости:
1. область действия организационного процесса;
2. определение организационного процесса;
3. инжиниринг программных продуктов;
4. комплексный менеджмент ПО;
5. взаимодействие между группами;
6. экспертные оценки;
7. учебная программа.
На уровне 3 процесс разработки ПО осуществляется на основе хорошо
определенного процесса. Требуется осознание ролей и ответственности в ходе
осуществления процесса. Процесс производства программного продукта отображается в ходе
выполнения программного процесса.
Уровень 4 (см. рис. 19.8), т.е. "управляемый", включает две области КРА:
количественный менеджмент процессов и управление качеством ПО. Благодаря использованию
расширенной метрической системы происходит накопление результатов
детализированных оценок процесса разработки ПО и обеспечения качества программного
продукта. Производится количественная оценка и контроль программных процессов и
продуктов. Процесс менеджмента основывается на объективных критериях,
формулируемых для принятия решений и оценки производительности внутри заданных границ.

630 Глава 19
Рис. 19.6. Процесс уровня 2
Рис. 19.7. Процессуровня3
сЬ> сЬ> о ев еЬ>
Рис. 19.8. Процесс уровня 4
На уровне 5 ("оптимизация") области КРА сосредоточены на стадиях менеджмента
изменений технологии, менеджмента изменений процесса и предотвращении
дефектов. Благодаря непрерывному улучшению процесса осуществляется количественная
обратная связь по отношению к процессу разработки программ. На этом уровне в
организации могут апробироваться новые идеи и технологии, позволяющие улучшить
качс-ство программного продукта (см. рис. 19.9).
Рис. 19.9. Процесс уровня 5
Благодаря управляемым изменениям существующего процесса внедряется
организационный подход, позволяющий реализовать непрерывное улучшение
процесса. Придание этим изменениям организованного характера важно в силу
следующих причин:
1. процесс должен соответствовать культурным традициям организации;
2. менеджмент обязан способствовать повышению степени культуры;
3. культура должна способствовать внедрению ролевых моделей и наград.
Подводя итоги, можно отметить, что модель СММ является своего рода
"дорожной картой", гарантирующей успешное улучшение процесса. Ее
интерпретация и применение осуществляются в контексте бизнес-целей организации. В настоя-

Введение в программный инжиниринг 631
щее время в организациях, занимающихся разработкой ПО, в качестве наиболее
распространенного метода выступает именно модель СММ (причем эта тенденция
характерна для многих стран и великого множества областей применения). Эта модель
является нормативной, не предписывающей, а также характеризуется большим
запасом устойчивости. Ее разработка и поддержка осуществляется многими
разработчиками, объединенными в сообщество профессионалов.
Может быть установлено соответствие между документом SWEBOK и ключевыми
областями процесса, как показано в табл. 19.1 и 19.2.

■
ч
р
в
Я
»
ч
■о
ОХ
о
о
а
в
S
•6-
я
в
Я
»
ч
Зх
I
3
■о
о
в
я
S
■о
S
X
-а
п
а\
о
1
Менеджмент требований
3
Планирование программного проекта
Обзор и отслеживание
программного проекта
Менеджмент субподрядными договорами
по разработке ПО
Менеджмент конфигурации ПО
Гарантирование качества ПО
Область действия
организационного процесса
X
Определение организационного процесса
X
Инжиниринг программного продукта
Комплексный менеджмент ПО
а
Взаимодействие между группами
а
Экспертные оценки
X
3
Учебная программа
X
<
Количественный менеджмент процесса
§
Менеджмент качества ПО
Менеджмент технологических изменений
Менеджмент изменений процесса
Предотвращение дефектов
я
о
в
ч
о
■а
а
п
5
Зс
О
Я
■а
I
В" Я
.5 в
?
•<
■а
о
в
S
я
S
о
и
п
и
я
Н
р
0\
-а
S
Я
р
п
о
о
в
п
о
в
S
ф

Продолжение табл. 14.1
I
Проектирование ПО
Базовые концепции, определяющие
процесс проектирования ПО
Ключевые вопросы, связанные с
процессом проектирования программ
Структура и архитектура ПО
Заметки, относящиеся к процессу
проектирования
Стратегии и методы, применяемые
при проектировании ПО
Конструирование ПО
Уменьшение степени сложности:
Методы лингвистического
конструирования
Методы формального
конструирования
Методы визуального конструирования
Предвидение отклонении
Методы лингвистического
конструирования
Методы визуального конструирования
Структурирование с целью
аттестации
Методы лингвистического
конструирования
П
•■
Ч
"';
'%
к" ***!£
Ли*
ш
г
•<
*
-^
4*
#<
Ц
Р
?г«вй™5
ЭЯр^
эШ
ш
р^тСШ
»&ks
•V-АУ
№ZF§
ййй
IV
V
VI
VII
VIII
IX
X
XI
XII XIII
XIV
XV
XVI
XVII
XVIII
IXX

Продолжение таил, 19.1
I
Методы формального
конструирования
Методы визуального конструирования
Использование внешних стандартов
Методы лингвистического
конструирования
Методы формального
конструирования
Методы визуального
конструирования
Тестирование ПО
Базовые концепции и определения
процесс тестирования
Уровни тестирования
Методики тестирования
Измерения, связанные с тестами
Управление процессом тестирования
Сопровождение ПО
Базовые концепции
Процесс сопровождения
Ключевые вопросы
сопровождения ПО
Методики, применяемые для
организации сопровождения
II
.
4'Ж
:д;
vl
&
III
4.
" „,4е
'^'
Й1***"
■SPSS
щ
!?Л'\*у1*
да
IV
v
VI
Ml
VIII
IX
X
XI
XII
хш
XIV
XV
хм
Х\'П
XVIII
1ХХ

Окончание табл. 19.1
I
Менеджмент конфигурация ПО
Менеджмент процесса
конфигурации ПО
Идентификация конфигурации ПО
Контроль конфигурации ПО
Учет статуса конфигурации ПО
Аудит конфигурации ПО
Поставка и управление версиями ПО
П
...... ft. •-
:4'v '
^*?v
Щк
■i1,**?^**
'{■?•%:
Щ
*? _ 1
J'^U-'^'
•••i^'.-jst
Ж
<ж
rv
V
VI
VII
VIII
IX
X
XI
XII
XIII
XIV
XV
XVI
XVII
XVIII
IXX

1, я
1
Is
о В
в 5
9
1
К^ШЦ^Ш^Кру;^
КНйЖ**7>,;; Менеджмент требований
Тонирование программного проекта
Обзор и отслеживание
программного проекта
Менеджмент субподрядными договорами
по разработке ПО
Менеджмент конфигурации ПО
Гарантирование качестна ПО
Область действия
организационного процесса
Определение организационного процесса
X
Инжиниринг программного продукта
Комплексный менеджмент ПО
Взаимодействие между группами
Экспертные оценки
Учебная программа
X.
Количественный менеджмент процесса
Менеджмент качества ПО
Менеджмент технологических изменений
Менеджмент изменений процесса
Предотвращение дефектом

Продол.ыпшг табл. 19.2
I
Инфраструктура процесса
Измерения процесса
Определение процесса
Количественный анализ процесса
Изменение и внедрение процесса
Методы и инструменты
программного инжиниринга
Программные инструменты
Инструменты по определению
требований к ПО
Инструменты по проектированию ПО
Инструменты по конструированию ПО
Инструменты по тестированию ПО
Инструменты по сопровождению ПО
Инструменты, относящиеся к
процесс)' программного инжиниринга
Инструменты по обеспечению
качества ПО
Инструменты менеджмента
конфигурации ПО
Инструменты менеджмента
программного инжиниринга
Инструменты, обеспечивающие
поддержку инфраструктуры
Разные вопросы, связанные с
применением инструментов
II
■ •:
III
:
^
*
'::.
;"
-.;■ '
IV
V
VI
VII
VIII
IX
X
XI
XII
XIII
xrv
XV
XVI
XVII
XVIII
IXX

Окончание табл. 19.2
I
Программ н ые методы
Эвристические методы
Формальные методы
Методы прототипирования
Разные вопросы, связанные с
применением методов
Качество ПО
Концепции обеспечения
качества ПО
Определение и планирование
качества
Методики, требуемые двумя либо
большим количеством исполнителей
Поддержка других методик
Специальное тестирование согласно
спецификациям SQA или V&V
Методики, обеспечивающие поиск
дефектов
Измерения в процессе анализа
качества ПО
II
-
„ *
г1 '
PJ
'ф.
III
'
**
'
m
IV
V
VI
VII
VIII
IX
X
XI
XII
XIII
XIV
XV
XVI
XVII
XVIII
IXX

Введение в программный инжиниринг 639
Документ SWEBOK и 34 компетенции,
связанные с управлением программными
проектами
В документе SWEBOK делается акцент на основах знаний, специфичных для
программного инжиниринга. В программе сертификации менеджмента ПО
подчеркивается роль 34 компетенций в проектах по разработке ПО. Изучая шесть сегментов,
представленных в табл. 19.3, нетрудно заметить, что 34 компетенции на самом деле
фокусируются на аспектах документа РМВОК.
В целом соответствия между 34 компетенциями и документом SWEBOK
приводятся в табл. 19.4-19.9.
Таблица 19.3. Соответствие между 34 компетенциями
и разделами документа SWEBOK
Номер Раздел документа SWEBOK
сегмента
Компетенции
Требования к ПО, связанные с
менеджментом конфигурации
Менеджмент программного
инжиниринга, связанный с обеспечением
качества ПО
Требования к ПО, связанные с
менеджментом конфигурации программ
Менеджмент программного
инжиниринга, связанный с обеспечением
качества ПО
Требования к ПО, связанные с
менеджментом конфигурации
Управление программным
инжинирингом, связанное обеспечением
качества ПО
Компетенции программного продукта
1-11
Компетенции программного продукта
1-11
Компетенции проекта 12 — 22
Компетенции проекта 12 — 22
Компетенции менеджмента 23 — 34
Компетенции менеджмента 23 — 34

£
ючевые вопро
п
'£
проектир
о
Р
X
Я
а
3
О
01
О
СЯ
Z
о
X
в
п
я
в
X
я
■а
о
в
п>
п
о
и
"С!
р
■о
ст\
о
Ч
S
О
а
•о
о
г»
ч
S
■о
о
в
в
=
It
a
о
2
X
2
2
п
X
ч
н
■а
п
0\
ы
SB
S
S'
Аттестация треб
1
О
Я
в
S
•е-
S
я
№
J3
Я
а
ч
■о
X
о
а
ы
X
Я
ь
S
и
ч
"О
а\
о
в
р
Я
S
Sc
03
Е
»
ш
1э
П
X
Я
га
ч
■а
&
о
Я
S
Sc
3
Tl
о
в
п
X
X
ж
S
Я
Т)
S
3
ч
о
0\
О
р
я
S
Sc
a
1
о
^н
К-4
5
<
S
2з
X
><!
й
О
0\
р
Г)
и
S
W
S
р
С/1
о
1. Оценка процессов
2. Осведомленность о стандартах процесса
3. Определение продукта
4. Оценивание альтернативных процессов
5. Управление требованиями
6. Управление субподрядчиками
7. Выполнение начальной оценки
8. Выбор методов и инструментов
9. Подгонка процессов
10. Отслеживание качества продукта
11. Понимание сути действий по разработке
Я
о
£.
Я
п
я •*-
8 X
х z
a s
9 X
я 5
ч £
Р Я
я" 2
5 Я
-о
р
2
2

Продолжение таб.i. 10.4
I
Архитектура и структура ПО
Оценка и анализ качества, достигаемого при проектировании ПО
Записи, относящиеся к процессу проектирования ПО
Методы и стратегии, применяемые в ходе проектирования ПО
Конструирование ПО
Уменьшение степени сложности
Лингвистические методы конструирования
Формальные методы конструирования
Визуальные методы конструирования
Предвидение расхождений:
Лингвистические методы конструирования
Формальные методы конструирования
Структурирование с целью аттестации:
Лингвистические методы конструирования
Формальные методы конструирования
Визуальные методы конструирования
Использование внешних стандартов
Лингвистические методы конструирования
Формальные методы конструирования
Визуальные методы конструирования
Тестирование ПО
Базовые концепции и определения процесса тестирования
Уровни тестирования
II
III
IV
V
VI
VII
VIII
IX
X
XI
XII

Окончание табл. 19.4
I
Методики тестирования
Измерения, связанные с процессом тестирования
Управление процессом тестирования
Сопровождение ПО
Базовые концепции
Процесс сопровождения
Ключевые вопросы процесса сопровождения ПО
Методики сопровождения
Менеджмент конфигурации ПО
Менеджмент процесса конфигурации ПО
Идентификация конфигурации ПО
Контроль конфигурации ПО
Учет статуса конфигурации ПО
Аудит конфигурации ПО
Поставка и менеджмент версий ПО
II
III
IV
V
\1
VII
VIII
IX
X
XI
XII

я
-а
о
с
О
я
-а
В
S
о
я
-а
о
Я
Е
я
о
■-1
в
о
в
S
a
Я
-а
о
я
п
о
В
в
о
я
я
S
S
я
-а
о
я
п
я
-а
о
~i
"О
ы
£
£
X
о
"I
о
S
к
*
К
в
S
~а
S
X
-а
о
х
S
»
а
Я
~а
о
я
Щ
я
-а
о
*i
•о
pi
К
£
в
о
3
S
■1
Щ
в
S
я
"а
о
О
"а
3
В
S
I
1
?
В
в
Вс
03
о
1. Оценка процессов
2. Осведомленность о стандартах процесса
3. Определение продукта
4. Оценивание альтернативных процессов
5. Управление требованиями
6. Управление субподрядчиками
7. Выполнение начальной оценки
X
8. Выбор методов и инструментов
X
9. Подгонка процессов
10. Отслеживание качества продукта
Й
11. Понимание сути действий по разработке
н
и
а\
и
s
и*
'Р
in
П
о
о
ш
н
о
н
ш
S
S
4*
?!
О
£
я
л
н
л
а
я
а
х
к
О
Я
£
а
н
о
£
W
О
р
о
н
tr
N9

Окончание табл. 19Л
I
Изменение и внедрение процесса
Методы и инструменты программного инжиниринга
Программные инструменты
Инструменты, определяющие требования к ПО
Инструменты, обеспечивающие проектирование программ
Инструменты конструирования программ
Инструменты конструирования программ
Инструменты тестирования программ
Инструменты сопровождения программ
Инструменты, относящиеся к процессу программного инжиниринга
Инструменты обеспечения качества ПО
II
III
IV
V
\1
VII
VIII
IX
X
хг
XII

>
-о
хит
ектура и
о
руктура П
О
£?
в
сг
о
я
о
я
-а
о
о
сг
a
-а
о
о
3
s
-а
0
S3
a
s
Я
о
и
0
S3
Щ
к
о
a
я
я
в
S
S
я
~а
о
я
о
-а
SH
U
~а
о\
о
ч
я
S
Я
О
Я
"О
0
п
i
0
а
Я
п
Я
О
S
3
г»
1э
£
я
ч
ч
-а
E
ал
о
S3
ы
X
»
Аттест
в
S
»
ч
•а
53
ы
Я
S
*
О
Я
S
•е-
1
S
ч
-а
о
о\
о
g
ГС
S
£
S
ч
о
а
и
Я
S
St
се
сг
S
X
я
о
ч
-а
п
о\
о
а
я
S
St
Я
■п
о
я
п
-а
»
U
"О
о
ч
я
X
ч
-а
п
о>
о
В
я
я<
■?
1
I
я
о
5
<
S
3
3
I*1
й
X
0
№
23
w
0
12. Построение структуры
пооперационного перечня работ
13. Документирование планов
14. Оценка затрат
15. Оценка трудозатрат
16. Управление рисками
17. Мониторинг производительности
18. Календарное планирование
19. Выбор методов измерений
20. Выбор инструментов
менеджмента проектов
21. Отслеживание процесса
22. Отслеживание хода
выполнения проекта
*2
£ я
я 2
3 Я
Я Н
§ §
■а а
3 я
н
р
ол
S
я
и
»—»
id
сп
П
О
о
н
И
Н
О
ш
S
п
S,
п
*
*-
?!
О
9
Н
п
Я
в
S
2
S
С
а
ч
о
ел
W
О
л
р
о
tr

Продолжение табл. 19.6
I
Оценка и анализ качества, достигаемого при проектировании ПО
Записи, относящиеся к процессу проектирования ПО
Методы и стратегии, применяемые в ходе проектирования ПО
Конструирование ПО
Уменьшение степени сложности
Лингвистические методы конструирования
Формальные методы конструирования
Визуальные методы конструирования
Предвидение расхождений
Лингвистические методы конструирования
Формальные методы конструирования
Структурирование с целью аттестации
Лингвистические методы конструирования
Формальные методы конструирования
Визуальные методы конструирования
Использование внешних стандартов
Лингвистические методы конструирования
Формальные методы конструирования
Визуальные методы конструирования
Тестирование ПО
Базовые концепции и определения процесса тестирования
Уровни тестирования
Методики тестирования
II
III
IV
V
VI
Ml
VIII
IX
X
XI
XII

Окончание табл. 19.6
I
Измерения, связанные с процессом тестирования
Управление процессом тестирования
Сопровождение ПО
Базовые концепции
Процесс сопровождения
Ключевые вопросы процесса сопровождения ПО
Методики сопровождения
Менеджмент конфигурации ПО
Менеджмент процесса конфигурации ПО
Идентификация конфигурации ПО
Контроль конфигурации ПО
Учет статуса конфигурации ПО
Аудит конфигурации ПО
Поставка и менеджмент версий ПО
II
III
IV
V
VI
VII
VIII
IX
X
XI
XII

s
u
£
ене
ниеи
и
m
s
эение процес
п
W
<ч
0
!э
S
л
ствен]
й анализ проце
w
О
а
TI
еде
ление
процесса
S
ы
£
ере
нияв
X
о
выполнения
а
эоцесса
S
ж
фрас
1 и
а
роцесса
Я
о
S
цеп
циип
"П
о
я
г»
сса программ
3
ого инжиниринга
Я
"Я
«
с про
ч
*о
£
МНОГО ИНЖИ1
аринга
S
U
£
ере
нияв
м
Т)
О
и
ессе програм
2
ного инжиниринга
SS
Д
i
смент
а
■п
о
я
ессов/проект
я
О
"П
3
1
зацио
я
в
5,
менеджмент
*:
я

авл
[ЭИНЭ
[нирингом П
О
*—(
Я
III
5
<
3
VII
VIII
X
V
а
X
'""'
о
оч
а
аст
и знан]
С/5
WEBOK
12. Построение структуры
пооперационного перечня работ
13. Документирование планов
14- Оценка затрат
15. Оценка трудозатрат
16. Управление рисками
17. Мониторинг производительности
18. Календарное планирование
19. Выбор методов измерений
20. Выбор инструментов
менеджмента проектов
21. Отслеживание процесса
22. Отслеживание хода
выполнения проекта
£В
компе
мпете
тенции
нцияпр
МПП
оекта
н
о\
и
5
1С
О
О
М
И
О
5й

Продолжение табл. 19.7
I
Методы и инструменты программного инжиниринга
Программные инструменты
Инструменты, определяющие требования к ПО
Инструменты, обеспечивающие проектирование программ
Инструменты конструирования программ
Инструменты конструирования программ
Инструменты тестирования программ
Инструменты сопровождения программ
Инструменты, относящиеся к процессу программного инжиниринга
Инструменты обеспечения качества ПО
Инструменты менеджмента конфигурации ПО
Инструменты управления инжинирингом ПО
Инструменты поддержки инфраструктуры
Разные вопросы применения инструментов
Программные методы
Эвристические методы
Формальные методы
Методы прототипирования
Разные вопросы, связанные с применением методов
Качество ПО
Концепции качества ПО
Определение и планирование качества
Методы, необходимые двум либо большему количеству исполнителей
II
III
IV
V
VI
VII
VIII
IX
X
XI
XII

о
я
о
я
s
•в-
S
я
f
и
S
н
-а
X
я
St
в
S
s<
се
X
S
Щ
н
-а
п>
С\
о
Я
•а
о
я
ОХ
о
ч
я
S
н
-а
о
о
о
II
23. Оценивание производительности
24. Обработка интеллектуальных
свойств
25. Проведение эффективных встреч
26. Взаимодействие и общение
X
X
27. Лидерство
28. Управление изменениями
29. Успешное ведение переговоров
30. Планирование карьеры
31. Эффективное проведение
презентаций
32. Набор персонала
33. Выбор команды
34. Построение команды
1
I з
П Hi
g я
«
о
Я
4^
?!
О
£
а
л
н
л
а
я
а
а
Я
Я
Й
о
?!
£
л
а
н
о
£
ел
W
О
И
!i
и
о
н
В"
S
Ы
vie
-а
01
я
S
S
а
я
-а
о
с
г,
V
£
s
я
»
ест
5;
Я
о
:<
О
la
Я
S
Я
S
р
•е-
я
и
о
в
П
С
К
X
2
ч
0
JJ
Я
ч
п
;£
-о
0
аз
s
в
ел
/О
^-
я
о
ё
"О
*
;ч
&*
TJ
к
*
га
н
g
я
к
5
<
*»"
£]
*--
Я
х
Й
~й
I

Продолжение табл. 19.S
I
Аттестация требований
Менеджмент требований
Проектирование ПО
Базовые концепции процесса разработки ПО
Ключевые вопросы проектирования ПО
Архитектура и структура ПО
Оценка и анализ качества, достигаемого при проектировании ПО
Записи, относящиеся к процессу проектирования ПО
Методы и стратегии, применяемые в ходе проектирования ПО
Конструирование ПО
Уменьшение степени сложности
Лингвистические методы конструирования
Формальные методы конструирования
Визуальные методы конструирования
Предвидение расхождений
Лингвистические методы конструирования
Формальные методы конструирования
Структурирование с целью аттестации
Лингвистические методы конструирования
Формальные методы конструирования
Визуальные методы конструирования
Использование внешних стандартов
Лингвистические методы конструирования
II
III
IV
V
VI
VII
VIII
IX
X
XI
XII
XIII

Окончание табл. 19.8
I
Формальные методы конструирования
Визуальные методы конструирования
Тестирование ПО
Базовые концепции и определения процесса тестирования
Уровни тестирования
Методики тестирования
Измерения, связанные с процессом тестирования
Управление процессом тестирования
Сопровождение ПО
Базовые концепции
Процесс сопровождения
Ключевые вопросы процесса сопровождения ПО
Менеджмент конфигурации ПО
Менеджмент процесса конфигурации ПО
Идентификация конфигурации ПО
Контроль конфигурации ПО
Учет статуса конфигурации ПО
Аудит конфигурации ПО
Поставка и менеджмент версий ПО
И
Ш
rv
V
VI
VII
VIII
IX
X
XI
XII
XIII

к
s
S
в
(i
ние и
недрение г
43
0
я
ft
* 1
°
*
л
11
ствен
я
ый анализ
чз
о
г»
п
о
я
"О
1э
го
ление
процесса
S
«
ft
~а
ft
евин
X
оде выполнения
процесса
S
я
фрас
ч
■л
^
ра процесс
р
Я
о
X
я
г»
я
JS
X
S
я
TS
оцесса про
грамм
ного инжиниринга
Я 1
Т)
!
Я
с про
■1
раммного
а
шринга
*1
У
*
чз
ft
а вин
п
роцессе пр
ограм
много инжиниринга
•?
я
смент
п
роцессов/
проек
тов

Т)
3
"т
я
зацио
я
ный менед
жмент
ft 1
,ч
1
г
я
эинэ
в
нживирин
гом П
о
1
ц—«
t—1
сн
сн
5
<
5
VII]
X
X
X
XII
X
t-1
о
с\
5>
Г!
тизнаш
aflSWEBO
рч
23. Оценивание производительности
24. Обработка интеллектуальных
свойств
25. Проведение эффективных встреч
26. Взаимодействие и общение
27. Лидерство
28. Управление изменениями
29. Успешное ведение переговоров
30. Планирование карьеры
31. Эффективное проведение
презентаций
32. Набор персонала
33. Выбор команды
34. Построение команды
£
34 компет
ггенция мен
енции
еджме
X «
ч а
пп
а (перс
онал)

Продолжение табл. 19. V
I
Методы и инструменты программного инжиниринга
Программные инструменты
Инструменты, определяющие требования к ПО
Инструменты, обеспечивающие проектирование программ
Инструменты конструирования программ
Инструменты конструирования программ
Инструменты тестирования программ
Инструменты сопровождения программ
Инструменты, относящиеся к процессу программного инжиниринга
Инструменты менеджмента конфигурации ПО
Инструменты менеджмента инжиниринга ПО
Инструменты поддержки инфраструктуры
Разные вопросы, связанные с применением инструментов
Программные методы
Эвристические методы
Формальные методы
Методы прототипирования
Разные вопросы, связанные с поддержкой методов
Качество ПО
Концепции обеспечения качества ПО
Определение и планирование качества
Методики, предполагающие наличие двух или большего количества
исполнителей
II
III
IV
V
VI
VII
VIII
IX
X
XI
XII
XIII

Окончание табл. 19.9
I
Поддержка других методик
Специальное тестирование согласно методикам SQA или V&V
Методики, обеспечивающие поиск дефектов
Измерения, производимые в ходе анализа качества ПО
II
III
IV
V
VI
VII
VIII
IX
X
XI
XII
XIII
Документ SWEBOK и управление качеством программных проектов
Последнее соответствие, которое необходимо для осуществления инжиниринга ПО в процессе управления проектами,
устанавливается между областями знаний документа SWEBOOK и главами настоящей книги. Обратитесь к табл. 19.10—19.13.
Таблица 19.10. Соответствие между документом SWEBOK и управлением качеством программных проектов (часть I)
Области знаний SWEBOK
Требования к ПО
Процесс разработки требований
Выявление требований
Анализ требований
Спецификация требований
Аттестация требований
Управление требованиями
Проектирование ПО
Базовые концепции процесса проектирования
Ключевые вопросы процесса проектирования
Главы книги
!.!•.,.
' ■*
Г;
..." .
Инициализация
3.
4.
5.
6.
Планирование
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

Продолжение -табл. 19.11)
Области знаний SWEBOK
Архитектура и структура программ
Оценка и анализ качества при проектировании
программ
Записи по ходу проектирования
Методы и стратегии при проектировании программ
Конструирование ПО
Уменьшение степени сложности
Лингвистические методы конструирования
Формальные методы конструирования
Визуальные методы конструирования
Структурирование с целью аттестации
Методы лингвистического конструирования
Методы формального конструирования
Методы визуального конструирования
Использование внешних стандартов
Методы лингвистического конструирования
Методы формального конструирования
Методы визуального конструирования
Тестирование ПО
Базовые концепции и определения процесса
тестирования
Главы книги
1.
>
,• ' fc'"
.
2.
....
,,, ,-'
Инициализация
3.
4.
5.
G.
Планирование
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

Окончание табл. 19.10
Области знаний SWEBOK
Уровни тестирования
Методики тестирования
Измерения, связанные с процессом тестирования
Управление процессом тестирования
Сопровождение ПО
Базовые концепции
Процесс сопровождения
Ключевые вопросы сопровождения ПО
Методики сопровождения
Менеджмент конфигурации ПО
Менеджмент процесса конфигурации ПО
Идентификация конфигурации ПО
Контроль конфигурации ПО
Учет состояния конфигурации ПО
Аудит конфигурации ПО
Поставка и управление версиями ПО
Главы книги
1.
•
%
2.
.:
С
;. -
;
Инициализация
3.
4.
5.
6.
Планирование
7.
8.
9.
10.
П.
12.
13.
14.
15.
16.
17.
18.

Таблица 19.11. Соответствие между документом SWEBOK и управлением качеством программных проектов (часть 2)
Области знаний SWEBOK
Менеджмент инжиниринга ПО
Организационный менеджмент
Менеджмент процессов/проектов
Измерения в процессе программного инжиниринга
Процесс программного инжиниринга
Концепции процесса программного инжиниринга
Инфраструктура процесса
Измерения в ходе выполнения процесса
Определение процесса
Количественный анализ процесса
Изменении в внедрение процесса
Методы и инструменты программного
инжиниринга
Программные инструменты:
Инструменты по разработке требований к ПО
Инструменты проектирования программ
Инструменты конструирования программ
Инструменты тестирования программ
Инструменты сопровождения программ
Инструменты, применяемые в процессе
программного инжиниринга
Главы книги
1.
*
..„■" \.i
■■*4' '■
J»j/, fe
■>* *■
£L£;„.
дел; ■
Ш
'if ?*;
Л"; _
'■ ' ...^'
2.
ч -.
?
'-ft
■1 1
. 3...
-"" -'
■*'.- ■
*:
$ч*
ь
,-«
*,
Инициализация
3.
4.
5.
6.
Планирование
7.
8.
9.
10.
II.
12.
13.
14.
15.
16.
17.
18.

Окончание табл. 19.11
у
области знаний SWEBOK
инструменты обеспечения качества ПО
инструменты управления конфигурацией программ
инструменты управления программным
инжинирингом
инструменты, обеспечивающие поддержку
инфраструктуры
разные вопросы, связанные с применением
инструментов
Программные методы
Эвристические методы
Формальные методы
Методы прототипирования
Разные вопросы, связанные с применением методов
Качество ПО
Концепции, связанные с обеспечением качества ПО
Определение и планирование качества
Методики, требующие двух или большего
количества исполнителей
Специальное тестирование по методикам SQA
илиУ&У
Методики поиска дефектов
Измерения в процессе анализа качества ПО
Главы книги
д.-
: i
';
., ■«
г-- *
■
i
■vi ■-■-'■■
i:-.-k
m
pi
w
i-3
Ы
*-■■-. i;
-Я*
%
:■
I
I;
;] i.
'<
--■;■
s:
ss
гл
¥
£,. .
Инициализация
3.
4,
5.
6.
Планирование
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

Таблица 19.12. Соответствие между документом SWEBOKh управлением качеством программных проектов (часть 3)
Области знаний SWEBOK
Требования к ПО
Процесс разработки требований
Выявление требований
Анализ требований
Спецификация требований
Аттестация требований
Управление требованиями
Проектирование ПО
Базовые концепции процесса
проектирования
Ключевые вопросы процесса
проектирования
Архитектура и структура программ
Оценка и анализ качества при
проектировании программ
Записи по ходу проектирования
Методы и стратегии при
проектировании программ
Конструирование ПО
Уменьшение степени сложности
Главы книги
Выполнение
19.
20.
21.
22.
23.
24.

Контроль
25.
26.

Закрытие
27.
28.
Поддержка на уровне
компании
29.
30.
31.
32.
33.
Приложения
А.
»
'*■■ Л
■■■■:, -j
В.
--
;*"
-. А
It
'■'■"
С.
•■■
'
.-* ■*
'?"
-£-"
D.
...
™- •
Е.
...
-
...
F.
G.
;
-
—.

Продолжение табл. 19.12
Области знаний SWEBOK
Лингвистические методы
конструирования
Формальные методы
конструирования
Визуальные методы конструирования
Структурирование с целью
аттестации
Методы лингвистического
конструирования
Методы формального
конструирования
Методы визуального
конструирования
Использование внешних стандартов
Методы лингвистического
конструирования
Методы формального
конструирования
Методы визуального
конструирования
Тестирование ПО
Базовые концепции и определения
процесса тестирования
Главы книги
Выполнение
19.
20.
21.
22.
23.
24.

Контроль
25.
26.

Закрытие
27.
28.
Поддержка на уровне
компании
29.
30.
31.
32.
33.
Приложения
А.
'
В.
„
с
'
£
•
D.
-
-
• ч
?
*
Е.
r-fc
-
F.
.
"
-v
■** *
,..
G.
-
•
~

Окончание т обл. 19.12
Области знаний SWEBOK.
Уровни тестирования
Методики тестирования
Измерения, связанные с процессом
тестирования
Управление процессом
тестирования
Сопровождение ПО
Базовые концепции
Процесс сопровождения
Ключевые вопросы
сопровождения ПО
Методики сопровождения
Менеджмент конфигурации ПО
Менеджмент процесса
конфигурации ПО
Идентификация конфигурации ПО
Контроль конфигурации ПО
Учет состояния конфигурации ПО
Аудит конфигурации ПО
Поставка и управление
версиями ПО
Главы книги
Выполнение
19.
20.
21.
22.
23.
24.

Контроль
25.
26.

Закрытие
27.
28.
Поддержка на уровне
компании
29.
30.
31.
32.
33.
-. "'S '%"
А.
*
**
1*.
^
4 '
■Л'
«г
>:
%
<?
**
#
Б.
>
i *
V
Ч. 1
„~*
с.
t
J*
*&
* л -
"*"Т"'
5*
-
-*,
*>
D.
«■..
*■
^
»-
4-
rf,fl
*A
4»-<f
*
a#
4-
.*.
**
ЧР
&фЯ
-
E.
« -
>v
«Г
w
Ж
'4?
К
■*.
*
* >
**
Ш
G-
IT >-
i
J*
v*4
fe
*f*V
*8v
&*i
д -
~T
•
&
Ы
t.
t
^
***e
**
w -
-

Таблица 19.13. Соответствие между документом SWEBOK и управлением качеством программных проектов (часть 4)
Области знаний SWEBOK
Менеджмент инжиниринга ПО
Организационный менеджмент
Менеджмент процессов/проектов
Измерения в процессе
программного инжиниринга
Процесс программного
инжиниринга
Концепции процесса программного
инжиниринга
Инфраструктура процесса
Измерения в ходе выполнения
процесса
Определение процесса
Количественный анализ процесса
Изменении в внедрение процесса
Методы и инструменты
программного инжиниринга
Программные инструменты
Инструменты по разработке
требований к ПО
Инструменты проектирования
программ
Главы книги
Выполнение
19.
20.
21.
22.
23.
24.

Контроль
25.
26.

Закрытие
27.
28,
Поддержка на уровне
компании
29.
30.
31.
32.
33.
Приложения
А
..
* t.
В.
г-
•V
ъ.
■ 1
ч
С
*ч
+
S
к>
1 ' Л
г
Ч
D.
■t
,
4
1 э
Ц»^
*i
41*
r>
Е.
•
ч *
-
Z »«
.*
&
1?
Чг>
F.
»
*
«■ v
4-Г
u <
■***■
s*.
к
" «
ъ
G
*
.*
„
'.Л
.»
* *»
V
№r)
,-^w
"V

Продолжение таил. 19.13
Области знаний SWEBOK
Инструменты конструирования
программ
Инструменты тестирования
программ
Инструменты сопровождения
программ
Инструменты, применяемые в
процессе программного инжиниринга
Инструменты обеспечения
качества ПО
Инструменты управления
конфигурацией программ
Инструменты управления
программным инжинирингом
Инструменты, обеспечивающие
поддержку инфраструктуры
Разные вопросы, связанные с
применением инструментов
Программные методы
Эвристические методы
Формальные методы
Методы прототипирования
Главы книги
Выполнение
19.
20.
21.
22.
23.
24.

Контроль
25.
26.

Закрытие
27.
28.
Поддержка на уровне
компании
29.
30.
31.
32.
33.
Приложения
А.
Ч
4
t
Г '■
-*
В.
г
V-.
Л- '
■К
fcfc* v
V
с.
-
V
■г .
1*
*" г
4.
D.
'
-
' '■С
^ X
ъ
"
£.
-*,»т
* /t
-
F.
V
ч
Л
G.
-
* *
-j

Окончание табл. 19.13
Области знаний SWEBOK
Разные вопросы, связанные с
применением методов
Качество ПО
Концепции, связанные с
обеспечением качества ПО
Определение и планирование
качества
Методики, предполагающие
наличие двух или большего количества
исполнителей
Специальное тестирование по
методикам SQA или V&V
Методики поиска дефектов
Измерения в процессе анализа
качества ПО
Главы книги
Выполнение
19.
20.
21.
22.
23.
24.

Контроль
25.
26.

Закрытие
27.
28.
Поддержка на уровне
компании
29.
30.
31.
32.
33.
Приложения
А.
■>
В.
_'
С.

D.
i
•С.
" г
Е.
Й-
F.
•■
L_
G.
; -
■;
S
',.{.,
■ '

666 Глава 19
Резюме
В настоящее время ПО создается коллективами разработчиков. Любая программа
требует стандартизованного подхода к ее разработке, который невозможно реализо-
пать при отсутствии взаимодействия между отдельными программистами. Конечно,
ранее бытовало мнение о том, что процесс разработки программ сродни некоему
искусству, но эти взгляды остались в далеком прошлом. Теперь программный
инжиниринг представляет собой систематический, дисциплинированный и выраженный в
количественных оценках подход к разработке программ, позволяющий
стандартизировать этот процесс. Господствующая ранее модель "кодирование — тестирование —
повторение" не удовлетворяет потребности, возникающие при разработке
современных систем (производственных, коммуникационных, медицинских и многих других
программных проектов).
Разработка программ не слишком отличается от других инженерных задач. Поэтому
описание процессов программного инжиниринга может быть найдено в документе
IEEE, который называется Основы знаний в области программного инжиниринга (SWEBOK),
в модели зрелости возможностей Института программного инжиниринга (SEI СММ) и в
34 компетенциях, относящихся к менеджменту программных проектов.
Контрольные вопросы
1. Перечислите пять специфических инженерных задач, которые можно выполнить
при переходе от уровня 1 к уровню 2 модели СММ.
2. На каких уровнях модели СММ организация может применять CASE-инструменты.
3. Где в документе SWEBOK можно вести учет в целях определения модели
жизненного цикла проекта?
4. Каким образом устанавливается соответствие между SWEBOK и IEEE 1074?
5. Каким образом совмещение областей рынка клиента и продукта влияет на
перемещение вашей организации на более высокий уровень в процессе разработки
программного обеспечения?
Практическое занятие
Программа xTRemeObjectMaker была адаптирована BSD для применения в
качестве CASE-инструмента в целях разработки новых программных систем. Причем это
сообщение было весьма неожиданным. М-р Лу и мисс Пайтель пришли к
соглашению, что CRM получит пятилетнюю бесплатную лицензию на использование
xTRemeObjectMaker в том случае, если ваша корпорация будет назначена в качестве
конечного разработчика приложения ARRS. Для окончательного решения этого
вопроса мисс Пайтель подтвердила намерение пригласить одного из американских
участников проекта в целях установки инструментальных средств, обучения CRM-
разработчиков и оказания помощи при создании первой программы.
Как все это скажется на вашем календарном графике?
Каковы шансы на успех в случае применения приложения xTRemeObjectMaker?
Здесь возникает весьма специфичная ситуация, поскольку в случае каких-либо сбоев, их
причина не может быть связана с каким-либо инструментом или с ситуацией на рынке.

Введение в программный инжиниринг 667
Литература
Albrecht Allan J. and John E. Gaffney. "Software Function, Source Lines of Code, and Development
Effort Prediction: A Software Science Validation." IEEE Transactions of Software Engineering, SE-9F):639-648,
1983.
Basili Victor R. "A Methodology for Collecting Valid Software Engineering Data." IEEE Transactions on
Software Engineering, SE-10F):728-738, 1984.
Basili Victor R. 'Viewing Maintenance as Reuse-Oriented Software Development." IEEE Software,
January, pp. 19-25, 1990.
Basili Victor R. and R.W. Selby. "Comparing the Effectiveness of Software Testing Strategies", 1987.
IEEE Transactions of Software Engineering SE-13A2):1278-1296.
Bowan Jonathan P. and Michael G. Hinchley. Ten Commandments of Formal Methods." Computer.
28D):56-63, 1995.
Brooks Fred P. "No Silver Bullet: Essence and Accidents of Software Engineering." IEEE Software, April,
pp. 1U-19, 1987.
Dart Susan A., et al. "Software Development Environments." IEEE Computer, 20(ll):18-28. Denning,
Peter J. A992). "What is Software Quality?" Communications ofthe ACM, January, pp. 13-15, 1987.
Fagan Michael E. "Design and Code Inspections to Reduce Errors in Program Development." IBM
Systemspurna' 15C):185-211, 1976.
Fagan Michael E. "Advances in Software Inspections." IEEE Transactions on Software Engineering. SE-
15G):744-751, 1986.
Hall Anthony. "Seven Myths of Formal Methods." IEEE Software. September, pp. 11-20, 1990.
Humphrey Watts S. and W.L. Sweet. "A Method for Assessing the Software Engineering Capability of
Contiaclois." Technical Report # CMU/SEI-87-TR-23, Software Engineering Institute, Carnegie Mellon
University, 1987.
Kitchenhain Barbara and Shari Eawrence Pfleeger. "Software Quality: The Elusive Target." IEEE
.So/rwure, January, pp. 12-21, 1996.
McCabe Tom. "A Complexity Measure." IEEE Transactions on Software Engineering SE-2D):308-320, 1976.
McFarlan, Warren F. "Portfolio Approach to Information Systems." Harvard Business Лст>«ад.A,2):142-
150, 1974.
Manlev John H. "CASE: Foundation for Software Factories." COMPCON Proceedings, September, pp. 84-
91.1984.
Mills Harlan. "Software Development." IEEE Transactions on Software Engineering SE-2D):265-273, 1976.
Mills Harlan D., et al. "Cleanroom Software Engineering." IEEE Software, IEEE, 5E):19-24, 1987.
Neumann Peter G. "On Hierarchical Design of Computer Systems for Critical Applications." IEEE
Transactions on Software Engineering SE-12(9):905-920, 1986.
Parnas David L. "On the Criteria to Be Used on Decomposing Systems into Modules." Communications of
theACM, 12A2):1053-1058, 1972.
Paulk Mark C. "A Comparison of ISO 9001 and the Capability Maturity Model for Software." Technical
Report # CMV/SEI-94-TR012, Software Engineering Institute, Carnegie Mellon University, 1994.
Pressman Roger S. "Can Internet-Based Applications Be Engineered?" IEEE Software, pp. 104-110, 1998.
Svmous Charles R. "Function Point Analysis: Difficulties and Improvements." IEEE Transactions on
Software Engineering, 1988.
Tomayko James E. "Support Materials for Software Configuration Management." SEI-SM-4-1.0, Software
Engineering Institute, Carnegie Mellon University, 1986.
Wasserinan Anthony I. "Rapid Prototyping of Interactive Information Systems." Software Engineering
Notes. 7E): 171-180, 1982.
Wingjanet M. "A Specifier's Introduction to Formal Methods." Computer, 23(9):8-24, 1990.

668 Глава 19
Winh Nicholas. "Program Development by Stepwise Refinement." Communications of the АСЫ, 14D):
221 227. 1971.
Wohliii Claes and Per Runeson. "Certification of Software Components." IEEE Transactions en Software
Engineering, 9F):494-499, 1994.
Дополнительные сведения в Internet
ттдо. info-science, uiowa .edu/soft-епд/. Виртуальная библиотека программного
инжиниринга.
sel .gsfc.паса . gov/. Лаборатория программного инжиниринга (Software Engineering Labo-
i.uory, SEL) — это организация, финансируемая Американским центром управления полетов
имени Годдарда/Национального управления по авиации и космонавтике (National Aeronautics and
Spac c Administration/Goddard Space Flight Center, NASA/GSFC). Назначение этой организации
заключается в исследовании эффективности программного инжиниринга при разработке
прикладных программ.
sourceforge.net/. Бесплатная служба, обеспечивающая простой доступ разработчикам к
лучшим материалам по CVS, включая списки рассылки, отчеты об ошибках, форумы/доски обмена со-
|>Г>щошя.«и. информацию по управлению задачами. Хостингу узлов, выгрузке и поддержке файловых
архивов, а также общие задачи Web-администрирования.
nvist't. use. eciv/. Этот центр был основан д-ром Барри Боэмом в июне 1993 года. В его задачи
вхо;пп обеспечение среды для исследований и обучения в областях крупномасштабного
проектирования программ и процессов разработки, обобщенных и специфических программных архитектур,
инструментов и сред программного инжиниринга, коллективной разработки программ и экономики
программного инжиниринга.
wviw.queensu. ca/Software-Engineering/. Архиве группы новостей USENET, comp.software.eng,
включай ответы на вопросы из раздела FAQ.
www. cs . umd. edu/projects. SoftEng/tame/. Экспериментальная группа программного
инжиниринга (Experimental Software Engineering Group, ESEG) университета штата Мэрилевд
рассматривает процесс обучения программному инжинирингу в виде научной лаборатории. Специфические
н( следовательские проекты концентрируются на формализации различных аспектов парадигмы
vчучшепия качества (Q1P), экспериментальной фабрики (EF) и подхода "цель/вопрос/метод изме-
рения" (GQM). Парадигма QIP весьма полезна при создании описательных моделей программных
1Н«>це< сов, продуктов и других форм опыта. Экспериментируйте и анализируйте эти модели с целью
шч iроения ориентированных на улучшения, описательных и компактных моделей.
Организационный подход EF позволяет повторно использовать программный опыт и обеспечивает
соответствующую поддержку для проектов. При этом создаются основные компетенции ПО.
wyjw.cei.cmu.edu/. Институт программного инжиниринга (Software Engineering Institute,
sl-'.I) был основан Конгрессом США в 1984 году. Финансирование этого учреждения происходит из
Федерального бюджета, а в его задачи входит исследование изменений в технологии программно-
lii инжиниринга. Это учреждение также финансируется Министерством обороны США (DoD).
Институт SEI позиционирует себя в качестве проверенного партнера промышленных и
правительственных организаций, могущего оказать помощь при разработке, приобретении и
поддержке программных систем.
www. spmn. сот. Миссия SPMN: поиск проверенного лучшего промышленного ПО и поставка его
менеджерам, производящим закупки программных систем для Министерства обороны США.

Обеспечение
надежности ПО
После определения сути программного инжиниринга надежность ПО считается
ключевым показателем качества программного продукта. На рис. 20.1 представлена
топология факторов качества, представленная Макколом, Ричардсом и Уолтерсом
(McCall, Richards, Walters) в их совместной работе, датированной 1977 годом
прошлого века . Перечисленные в этой публикации факторы рассматриваются во всех
главах данной книги. Особое внимание уделяется обеспечению надежности ПО в силу
того, что этот показатель имеет определяющее значение для конечного
пользователя. Факторы качества, связанные с изменением программного продукта и
разработкой его новых версий, имеют определяющее значение для разработчиков ПО и групп
технической поддержки. Факторы, определяемые функционированием продукта,
относятся к личным интересам заказчика. Вряд ли ему понравится программа,
выполняющаяся некорректным образом, либо полностью неработоспособная.
Стандартный словарь терминов программного инжиниринга (IEEE Standard
Glossary of Software Engineering Terminology) определяет надежность ПО как
способность системы или компонента выполнять требуемые функции в заданных условиях
на протяжении указанного периода времени . Этот показатель также влияет на
надежность системы в целом. Степень надежности ПО (в отличие от аппаратного
обеспечения) непосредственно зависит от совершенство проекта программного
продукта, а не от технологических достижений производственного процесса. Основной
показатель, влияющий на надежность ПО, — сложность разрабатываемых программ.
Причем процесс создания надежного ПО не зависит от времени, и это
демонстрируют модели надежности программ, реализованные в виде традиционных U-образных
кривых, представленных на рис. 20.2. Методики оценки надежности ПО все еще
находятся п стадии разработки, однако если не выполнять адекватную оценку
данных, невозможным становится и выполнение расширенных статических моделей.
' McCall John и др. "Factors in Software Quality", NTIS AD-A049-014, 015, 055, ноябрь 1977 г.
! IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology (ANSI).

670 Глава 20
требуемых для анализа реальной степени надежности. До сих пор еще не был
разработан ни один надежный количественный метод оценки надежности ПО, не
содержащий чрезмерное количество ограничений.
Корректность Эффективность Целостность Надежность Применимость
Рис. 20.1. Факторы качества ПО
Степень надежности ПО можно улучшить с помощью различных методик, но,
1ч-м не менее, затруднительно достичь баланса между временем, бюджетной
стоимостью разработки и кажущейся высокой ценой, уплаченной за достигнутую
надежность ПО.
В отличие от аппаратного обеспечения, ПО с течением времени не "изнашивается",
а просто выявляет свою "дефектную натуру". Определение и планирование ошибок,
неизбежно проявляющихся при эксплуатации программного продукта,
рассматривается в главах 23, 26 и 30. На рис. 20.3 изображена U-образная кривая,
демонстрирующая распределение ошибок на протяжении эксплуатации программы. Проявление
ошибок ПО отличается от характера сбоев аппаратного обеспечения, причем их
вероятность всегда отлична от нуля. Менеджер проекта должен иметь представление о
размере средств, инвестируемых в обеспечение надежности ПО.
Начало Прекращение
эксплуатации Эксплуатация эксплуатации
.1 I ! /
о 1 ■ I /
° \ : : /
\S± [У
Время
Рис. 20.2. U-образная кривая надежности аппаратного
обеспечения

Обеспечение надежности ПО 671
Тестирование/
Отладка
Эксплуатация
Устаревание
S
8
Время
Рис. 20.3. U-образная кривая -надежности ПО
Методы, позволяющие определить достаточный размер требуемых инвестиций,
были рассмотрены в главе 18. Необходимо в одинаковой степени учитывать
вопросы, связанные с риском и достигаемой надежностью. Экономное применение
принципов надежности при проектировании ПО определяется критерием
уменьшения риска появления ненадежных программ. Если достигаемая надежность не
позволяет значительно уменьшить риск, то проект не стоит вливания
дополнительных средств.
Большая часть проблем надежности ПО не являются жизненно важными (в
отличие от пресловутой проблемы Therac или ракеты Пэтриот ). Основная масса
проблем связанных с достижением надежности, относится к области
стандартизованных тестов. Индустрия тестирования ПО появилась в те годы, когда
"посыпались градом" ошибки ПО ". Эти ошибки сказались на миллионах студентов,
сдававших стандартизованные тесты на профессиональную пригодность более чем
в 20 штатах США"'. Влияние трудно обнаруживаемых ошибок ПО может негативно
сказываться на студентах, преподавателях и административных работниках,
проходящих стандартизованные тесты. Ставятся под сомнение не только результаты
подсчета тестовых баллов, но также и более субъективные подсчеты, основанные
на уравнениях, — процесс, позволяющий проводить сравнение показателей
тестирования за несколько лет.
Как оказалось, управление СТВ (несмотря на заверения правительству штата
Индиана и других штатов) не завершило работу по проверке результатов тестирования.
При просмотре достаточно большой выборки выявилась программная ошибка.
По этой причине текущий тест выглядел более простым, чем его аналоги,
относящиеся к предыдущим годам. Чтобы уравнять сложности тестов, компьютер
Leveson Nancy and Clark S. Turner A993). "An Investigation of the Therac-25 Accidents". IEEE
Computer, 26G):18-41.
■www.ima.umm.edu/~arnoU/455.f96/disasters.html. Две катастрофы, спровоцированные
компьютерной ошибкой.
www.nytimes.com/2001/05/02/business/20EXAM.htmL "Right Answer, Wrong Score: Test Flaws
Take Toll".

672 Глава 20
усложнил их для некоторых студентов, как и в предыдущий раз. Ошибка ПО не
сказалась на корректности ответов студента, однако повлияла на значения
процентных соотношений .
В результате были уволены (или оштрафованы) административные работники, 40
тысяч студентов отправлены в летние школы, сотни тысяч долларов,
предназначенных па улучшение системы образования, потрачены впустую, и сотни студентов не
получили рекомендации для обучения в следующих классах по причине
недостаточных навыков чтения.
В данной главе мы остановимся на рассмотрении четырех методик,
обеспечивающих создание высоконадежного ПО.
1. Прогнозирование ошибок— модели надежности, анализ исторических данных;
сбор информации по ошибкам, профилирование операционной среды.
2. Предотвращение ошибок— формальные методы, повторное использование ПО,
инструменты, применяемые для конструирования программ.
3. Устранение ошибок — формальные инспекции, верификация и аттестация.
4. Устойчивость к отказам— методики мониторинга, верификация решений,
избыточность, исключение
Стадии жизненного цикла
разработки продукта
Надежность ПО необходимо планировать на начальных стадиях выполнения
проекта, определив среду проекта и определив действия по менеджменту проекта.
Процесс определения надежности разрабатываемого ПО требует сбора большого
количества информации на основе методов измерения для данного проекта. В главе 21
описываются действия по сбору и анализу метрических данных. Методы измерения
вырабатываются в течение всего жизненного цикла действиями разработчиков.
Четыре метода обеспечения надежности ПО реализуются на фазах жизненного цикла
(показаны жирной линией на рис.20.4). Прогнозирование ошибок происходит на
фазах формирования требований, проектирования и применения. Устранение ошибок
выполняется на фазах разработки проекта, применения и установки. Период
устойчивости к отказам начинается на фазе применения и длится до окончательного
выпуска программного продукта.
Таблица 20.1 обеспечивает дальнейшую привязку четырех методов обеспечения
надежности к нофазовым действиям жизненного цикла. Эти действия подробнее
рассматриваются в разделах, посвященных описанию каждого отдельного метода.
'' www. nytimes. com/2001/05/21/business/21EXAM. htmI."When a Test Fails the Schools,
Careers and Reputations Suffer".

Обеспечение надежности ПО 673
Исследование
концепции
•
Формулирование

потребности
Исследование
системы
' Спецификация'
интерфейса
системы
Требования
■ Спецификация
требований
к ПО
Разработка
проекта
'Описание

разработки ПО
Прогноз сбоев
Установка среды проекта |
Методологии
Стандарты
Инструменты
Внедрение
• План

тации/верификации ПО
Установка
•Отчет об

тестации/верификации ПО
Предотвращение сбоев
f
Менеджмент плана проекта
Отчет о проблемах и план их устранения
План управления программным проектом
План поддержки
План вывода из эксплуатации
Планирование
обеспечения
качества
программного
обеспечения
План обеспечения качества
программного обеспечения
Эксплуатация
и поддержка
'
Пользовательская
документация
Разработка
метрических
показателей
качества
I Метрические I
j показатели j
Устранение сбоев
Сопровождение
' Документация
посопровож-
Вывод из
эксплуатации
• Архивный
отчет
Управление качеством ПО
Оценивание качества проекта
Идентификация потребностей по улучшению качества
Рекомендации по улучшению качества
Сбор и анализ метрических данных
Отчеты по завершению анализа
I I
X !-
Устойчивость и сбоям
Рис. 20.4. Место обеспечения надежности программ в жизненном цикле разработки ПО

674 Глава 20
Таблица 20.1. Соответствие между подходами к обеспечению надежности ПО
и действиями, осуществляемыми на фазах жизненного цикла
Прогноз Предотвращение Устранение Устойчивость
Требования и исследование
системы
Определение функциональ- X X
ного профиля
Определение и классифика- X X
ция сбоев
Идентификация потребно- X X
стей заказчиков в
обеспечении надежности ПО
Альтернативные учебные X X
курсы
Определение целей, свя- X X
данных с достижением
надежности
Разработка проекта и
внедрение
Распределение показателей X XX
надежности среди
компонентов
Встречи с инженерными ра- XXX
ботниками, посвященные
достижению надежности
Сосредоточение ресурсов на XXX
основе функционального
профиля
Управление вводом и рас- X XX
пространением сбоев
Оценивание надежности X XX
приобретенного ПО
Установка
Определение эксплуатаци- X X
онного профиля
Обеспечение роста надежно- X X
сти процесса тестирования
Отслеживание процесса тес- X X
тирования
Требуется ли дополнитель- X X
ное тестирование проекта?
Достигнута ли требуемая X X
степень надежности?

Обеспечение надежности ПО 675
Окончание табл. 20.1
Прогноз Предотвращение Устранение Устойчивость
Зксплуатапия, поддержка и
сопровождение
Потребности в персонале
на завершающих стадиях
проекта
Сравнительный мониторинг
надежности и целей
Отслеживание степени
удовлетворенности заказчиков
достигнутой надежностью
Мониторинг надежности при
добавлении новых свойств
Управление улучшениями
продукта и процесса с
одновременным измерением
достигаемой надежности
Связь главы 20 с 34 компетенциями
Обеспечение надежности ПО связано со следующими тремя компетенциями.
Методики разработки продукта
1. Процессы оценивания— определяются оценки целей, связанных с
обеспечением надежности, в плане управления рисками, а также процессы в жизненном
цикле разработки ПО. В этом случае в непрерывный процесс улучшения включается
всеобщий подход, принятый в данной организации.
Навыки менеджмента проектов
Менеджмент рисков— единственная причина, оправдывающая большие
инвестиции в процессы обеспечения надежности ПО, — уменьшение степени риска.
Выбор метрических показателей— использование инструментов обеспечения
надежности соответствующих метрических показателей, описанных в главе, для
создания хорошо спроектированного и надежного набора проектов, процессов и
методов измерения, применяемых для разработки программного продукта.
Учебные цели главы 20
После изучения материала главы читатель должен уметь выполнять следующее:
■ использовать основные понятия надежности ПО;
■ определять преимущества разработки надежности ПО для определенных
проектов;
■ определять специфичные данные, необходимые для использования достоверных
статистических методик в контексте разработки надежного ПО;
X
X
X
X
X

676 Глава 20
■ совмещать надежность в рамках программы методов измерения проекта и
организации в целом;
■ вычислять предполагаемые ошибки, основываясь на хронологической
информации об ошибках;
■ выбирать инструменты, необходим1е для проведения статистического анализа
надежности данных;
■ использовать эксплуатационный профиль при вычислениях надежности.
Термины, используемые при определении
надежности ПО
Терминология программного инжиниринга может быть описана словами главной
героини книги Льюиса Кэрролла "Алиса в Зазеркалье":
"Когда я говорю слово, - сказал Шалтай-Болтай довольно насмешливо, - оно
означает только то, что я хочу, чтобы оно означало - не больше и не меньше".
"Интересно, - сказала Алиса, - а можешь ли ты придать словам очень много
различных значений ? "
Разработчики ПО и менеджеры проектов могут корректно и некорректно
использовать термины дефект, ошибка, проблема и некоторые другие понятия.
Надежность ПО может характеризоваться следующими определениями, принятыми в
индустрии ПО.
Дефект - ошибка, обнаруженная на последней фазе или при выполнении
завершающего процесса.
Ошибка— ошибка, обнаруженная на текущей фазе или при выполнении
настоящего процесса.
Надежность - состояние, позволяющее избежать повреждений в момент
совершения ошибки.
Отказоустойчивость - свойство, заключающееся в возможности коррекции
отдельных ошибок и продолжение выполнения программы.
Проблема - отклонение от заданных технических характеристик или ожидаемых
результатов.
Ошибка при обработке - вывод некорректных результатов при выполнении
процесса и, как следствие, неправильное состояние или положение.
Отказ при выполнении процесса- событие, посредством которого ошибочный
ресурс, использованный процессом, производит ошибку на выходе, которая в конечном
итоге становится явной.
Сбой при выполнении процесса имеет отношение к ресурсам, используемых в
процессе, и рассматривается в качестве входных данных для процесса. Он представляет
неправильное состояние или условие системы, к которой относится процесс.
Устойчивость позволяет обрабатывать некорректно введенные данные.
Ошибки ПО происходят в силу дефектов/ошибок проекта (система или ПО),
дефектов/ошибок кодирования, организационных ошибок, несостоятельности
отладки и ошибок тестирования.

Обеспечение надежности ПО 677
Прогнозирование ошибок
Прогноз сбоев воплощает предсказуемый подход к разработке надежного ПО.
Прогнозирование представляет собой упражнение по созданию интерфейса
жизненного цикла разработки программного продукта. Это упражнение выполняется
при исследовании системы и определении требований. Зрелые организации,
специализирующиеся на разработке ПО, выполняют прогнозирование ошибок
как часть интерфейса проекта/процесса оценки программного продукта.
Единственный способ обеспечения даже небольшой степени точности для
прогнозирующих моделей заключается в предоставлении доступа к соответствующим
историческим моделям обеспечения надежности данных. Анализ исторических
данных, сбор данных по ошибкам и профилирование операционной среды
являются ключевыми действиями для данного метода. В табл. 20.2 определены этапы
прогнозирования сбоев.
Таблица 20.2. Действия жизненного цикла разработки ПО, относящиеся к
прогнозированию сбоев
Требования и исследование системы Прогнозирование
Определение функционального профиля
Определение и классификация сбоев
Идентификация потребностей заказчиков в обеспечении требуемого
уровня надежности
Альтернативные учебные курсы
Определение целей, связанных с обеспечением надежности
Первый этап прогнозирования сбоев заключается в определении
функционального профиля. Прослеживая состояние переходов от модуля к модулю и от функции к
функции, можно точно определить наиболее уязвимое место системы. Если
объединить полученную информацию с функциональным профилем, можно определить,
насколько надежной будет система при заданных условиях ее использования. При
выполнении программ осуществляются отслеживаемые переходы. При переходе к
программным модулям, которые перегружены ошибками, возрастает риск неудачи.
Моделирование подобных переходов осуществляется с помощью некоего
стохастического процесса. В конечном итоге при разработке математического описания
поведения ПО, управляемого выполняемыми функциями (при выполнении этих программ
происходят переходы между модулями), возможно описание надежности
выполняемых функций. Программная система является итогом собственных выполняемых
функций. Имея представление о надежности выполняемых функций и порядке
распределения системой машинного времени среди этих функций, можно сделать
заключение о надежности самой системы.
Следующий этап— определение и классификация ошибок. Как указывалось выше,
ошибки ПО являются результатом дефектов/ошибок проекта (системы и ПО),
дефектов/ошибок кодирования, административных ошибок, несостоятельности
отладки и ошибок тестирования. Определение ошибок подразумевает установление
источника ошибки. Классификация ошибок производится по степени их серьезности.

678 Глава 20
Классификация, разработанная Борисом Бейцером (Boris Beizer), имеет
соответствующие уровни детализации .
1. Слабый — симптомы имеют эстетический характер.
2- Умеренный — выходные данные некорректны или избыточны.
3. Раздражающий — вызывает некорректное поведение системы (например,
банкомат отказывается выдавать наличные деньги).
4. Очень серьезный — вместо того чтобы учесть ваш платежный чек, система
кредитует его на другой счет.
5. Экстремальный — проблема не ограничивается несколькими пользователями.
6. Невыносимый — база данных надолго и непоправимо выходит из строя.
7. Катастрофический— решение о прекращении выполнения программы исходит
от пользователя; система разрушается.
8. Инфекционный— разрушает другие системы, даже если работоспособность
исходной системы не нарушена.
Завершив составление матрицы источников ошибок и их классификацию,
необходимо отследить метрические показатели, характеризующие ошибочные данные, как
показано в табл. 20.3. Каждая ячейка таблицы содержит итоговые значения по сбоям
согласно исторической информации, доступной для аналогичных проектов и продуктов.
Таблица 20.3. Виды и источники сбоев
Вид Ошибки/ Ошибки/ Конторские Неадекват- Ошибки тес-
дефекты дефекты ко- ошибки ная отладка тирования
проекта дирования
Слабый
Умеренный
Раздражающий
Очень
серьезный
Экстремальный
Невыносимый

Катастрофический
Инфекционный
Следующий этап — определение потребностей заказчика в надежности. Эти
потребности заранее определены и задокументированы в документе SRS (см. главу 16).
Потребности заказчика в надежности должны быть установлены в пределах
точности, обеспечиваемой методами измерения. Несмотря на то, что все требования
должны быть измеримыми и обеспечивать возможность контроля, именно
требованиям, связанным с обеспечением надежности, сопоставляются соответствующие но-
Beizer Boris. Software Testing Techniques, 2-е издание. NY: Van Nostrand Reinhold. C. 28,1990.

Обеспечение надежности ПО 679
мера. Ниже приводятся примеры соответствующих утверждений о требованиях
относительно надежности.
1. Минимальный показатель надежности функционирования системы запуска ракет
составляет 0.999 от 95-процентного доверия, основанного на подтверждении
запуска по отношению к отделению от носителя полезной нагрузки.
2. Надежность системы управления спутниками оценивается как 0.999 от 95-
процентного доверия на период, равный 15 годам с момента разделения
полезной нагрузки.
3. Для авиационной системы характерно в среднем 500 летных часов между
критическими ошибками.
4. Встроенная система самоконтроля определит неисправную ракету с
вероятностью 60 процентов.
5. Встроенная система самоконтроля примет реальную ракету за неисправную с
вероятностью менее 1 процента.
6. Среднее время исправления функционирующего ПО составляет 30 минут или
меньше.
7. Среднемаксимальное корректировочное время составляет 60 минут с 90-ым
процентным распределением.
8. Максимальное время завершения работы встроенной системы самоконтроля
составляет 20 секунд.
9. Среднее время загрузки ПО в полном объеме и выполнения полного внутреннего
самоконтроля составляет 10 минут.
10. Среднее время обновления одной интерактивной страницы документации
составляет 30 минут.
Проведение альтернативных учебных курсов составляет четвертый этап
прогнозирования ошибок. С помощью клиентского функционального профиля и
информации о классификации ошибок, почерпнутой из предыдущих систем, анализируются
особые требования для определения того, поддерживают ли цели исторические
данные. Производится анализ курсов для определения вероятности достижения целей
надежности, сформулированных в требованиях. При отсутствии исторических
данных, связанных с аналогичными продуктами и системами, вероятность достижения
искусственно установленного уровня надежности чрезвычайно низкая. На этом этапе
менеджеру проекта необходимо разработать экстенсивные системные модели,
применяемые для определения возможных уровней надежности нового продукта. Такие
инструменты, как формальные методы, применимы к требованиям надежности для
математических доказательств, связанных с наиболее критическими подсистемами.
Этот дорогостоящий процесс используется исключительно в случаях отсутствия
источника исторических данных о надежности.
Этап 5 заключается в определении целей надежности, основанных на результатах
альтернативных учебных курсов. Окончательный набор целей обеспечения
надежности передается обратно, процессу определения требований, позволяя изменить уже
существующие. Благодаря данному этапу собранная информация и проведенный
анализ передаются обратно для спецификации требований. Цели/требования
относительно надежности будут использованы для подтверждения этой надежности всей
системы и получения одобрения пользователя.

680 Глава 20
Предотвращение сбоев
Предотвращение сбоев включает итеративное уточнение системных требований и
разработки технических характеристик ПО наравне с моделированием,
проверяемыми методиками проекта и оптимальными способами кодирования. Этот процесс
имеет место на фазе разработки программного продукта, на которой формулируются
требования, проект и применение. На данном этапе разработки продукта команда
разработчиков проекта завершает исследования и первоначальное планирование,
после чего приступает к выполнению проекта. Предотвращение сбоев является
активной частью процесса разработки, а не просто пассивной попыткой их записи.
Первый раздел, связанный с предотвращением ошибки, заключается в исследовании
системы и требований, как описывалось выше. Первоначальные шаги необходимы
для анализа требований относительно надежности и целей независимо от
применяемых подходов, призванных помочь в достижении надежности.
Вторым основным методом предотвращения ошибок является разработка и
внедрение проекта. Если команда разработчиков проекта сначала начинает разработку и
внедрение, функции по обеспечению надежности распределяются среди
компонентов. В главе 22 рассматриваются методы распределения атрибутов качества среди
компонентов. Определяется процесс разработки, в результате которого создаются
компоненты. Методики уменьшения степени параллельности и увеличения связности
модулей обеспечивают способ повышения надежности компонентов. Целесообразно
применять наилучшие наработки, относящиеся к проектированию, причем
независимо от того, являются они структурированными или объектно-ориентированными.
Благодаря этому обеспечивается возможность разработки программных продуктов,
обладающих высокой степенью надежности.
На ранних стадиях жизненного цикла разработки ПО цель обеспечения
надежности направлена на предотвращение возможных ошибок. В табл. 20.4 представлены
подпроцессы основного интерфейса фаз жизненного цикла разработки ПО, которые
поддерживают предотвращение сбоев.
Цели обеспечения надежности, предварительно определенные и
задокументированные, должны быть установлены для модулей во время разработки. Разработку так
же, как и качество, никогда нельзя проконтролировать или добавить. Менеджер
проекта должен сосредоточиться на ресурсах, основанных на функциональном профиле.
За время эксплуатации системы и подтверждения использования дорогостоящих
методов обеспечения надежности должен быть завершен функциональный профиль
разрабатываемой системы. Он должен использоваться и проходить аттестацию в ходе
процесса разработки.
Единственный способ активного предотвращения ошибок заключается в
управлении вводом и распространением сбоев. Экспертные оценки и инспекционные
проверки — традиционный способ активного сокращения ошибок, появляющихся
на одной фазе, и предотвращения их перехода на другую фазу. Еще одно важное
действие— оценка степени надежности приобретенного ПО. При расширенном
использовании инструментальных средств, связанных с Internet, и при более
доступных совместно используемых библиотеках ПО обеспечение сомнительного
происхождения (SOUP, software of uncertain pedigree) становится частью продукта. Команда
разработчиков проекта нуждается в процессе верификации, аттестации, принятия и
оценки надежности SOUP-компонентов. Это должен быть формальный процесс с тем
же уровнем отслеживания и конфигурации, что и в случае с компонентами программ-

Обеспечение надежности ПО 681
ного продукта, созданными "с нуля". Повторное использование ПО обеспечивает
огромное повышение продуктивности разработчика. Однако при этом могут
проявляться скрытые дефекты и проблемы.
Таблица 20.4. Действия жизненного цикла разработки ПО, направленные на
предотвращение сбоев
Предотвращение
Требования и исследование системы
Определение функционального профиля
Определение и классификация сбоев
Идентификация потребностей заказчика в надежности
Поддержка альтернативных учебных курсов
Установка целей надежности
Разработка проекта и внедрение
Распределение надежности среди компонентов
Встреча с инженерами для установки целей достижения надежности
Сосредоточение ресурсов на основе функционального профиля
Управление вводом и распространением сбоев
Измерение надежности приобретенного ПО
Устранение ошибок
Старая поговорка о том, что "день, потраченный на предотвращение, стоит
года, потраченного на исправление последствий" остается весьма актуальной.
Устранение возникающей в системе ошибки обходится в 10-100 раз дороже, чем ее
предотвращение на начальном этапе. Автору данной книги на своем опыте довелось
это прочувствовать, когда при разработке коммерческого мультимедийного
продукта, являющегося частью Microsoft® Windows™, стоимость обнаружения и
исправления ошибки, заключающейся в трех строках объектного кода, составила
(ЮОО0 долларов. Предотвратить данную ошибку можно было бы с помощью
однократного просмотра кода, что заняло бы всего два часа при участии четырех человек.
Восемь человеко-часов стоят меньше 1000 долларов. Стоимость предотвращения
была определена временем, потраченным на изоляцию обнаруженной ошибки в
выпущенной операционной системе, и на анализ процесса разработки кода драйвера,
который привел к ошибке. Завершающее инспектирование уровня кода было
пропущено по причине спешки и привело к выпуску драйвера с ошибками для Microsoft.
Предотвращение ошибок начинается при первой же возможности с момента их
первичного обнаружения в продукте. Программные продукты, находящиеся на фазах
разработки проекта и формулирования требований, передаются команде
проектировщиков. При этом реализуется первая возможность обнаружения ошибок в
моделях и спецификациях требований. Процесс устранения ошибок распространяется на
фазу внедрения посредством процесса установки. Для продукта, предназначенного
для использования внутренними клиентами, как, например, новая система для отдела

682 Глава 20
кадров или Web-страница электронной коммерции, процесс установки должен
выполняться в одноразовом режиме. Что же касается коммерческих продуктов, то их
установка происходит всякий раз, когда новый покупатель вскрывает упаковку и
начинает процесс установки на своем персональном компьютере или на сервере
компании. Менеджер проекта и продукта должен быть осведомлен о временной природе
фазы установки, чтобы соответственным образом оценивать меры по обеспечению
надежности программы.
Первая часть этапа устранения ошибок сосредотачивается на фазах
проектирования и внедрения, о чем было рассказано в разделе, посвященном предотвращению
ошибок. Вторая часть, фаза установки, начинается с работы, которую необходимо
выполнить на фазе определения требований. На самом деле менеджеры проекта не
должны определять эксплуатационный профиль до тех пор, пока имеет место
частично функционирующая система. Его можно определить в самом начале жизненного
цикла разработки продукта с помощью использования прототипов.
После завершения работы по функциональному профилированию осуществляется
следующий шаг в разделе установки — тестирование степени увеличения надежности, что
также называется испытанием под нагрузкой. В зависимости от выполняемых
функций, функционального профиля, способа выполнения функций и операционного
профиля, определяется и выполняется набор сценариев испытаний, в результате
чего система обходит заданный ей операционный режим. Цель тестирования степени
увеличения надежности— определить совокупность нагрузок, при которых система
выходит из строя. Это формальный процесс, при котором отслеживание хода
выполнения тестирования имеет определенное значение. Результаты тестов анализируются
с целью их применения для повторной калибровки моделей, применяемых в
прогнозировании надежности на начальных стадиях проекта. Одной из задач
менеджера проекта является поддержание постоянного процесса совершенствования.
Благодаря извлечению данных из одного проекта и использованию их для
обработки инструментов и техник для будущих проектов поддерживается способность
организации к обучению.
На средних фазах жизненного цикла разработки ПО усилия по обеспечению
надежности сосредотачиваются на устранении дефектов. В табл. 20.5 отражены
подпроцессы основных фаз жизненного цикла разработки проекта (разработка проекта,
внедрение и установка) и поддержка функции устранения дефектов.
Таблица 20.5. Действия по устранению сбоев в жизненном цикле разработки ПО
Разработка проекта н внедрение Устранение сбоев
Распределение надежности среди компонентов
Встреча с инженерами для установки целей достижения надежности
Сосредоточение ресурсов на основе функционального профиля
Управление вводом и распространением сбоев
Измерение надежности приобретаемого ПО
Установка
Определение операционного профиля
Поддержка тестирования роста степени надежности

Обеспечение надежности ПО 683
Разработка проекта и внедрение
Отслеживание хода выполнения тестирования
Дополнительное необходимое тестирование проекта
Одобрение достигнутых целей обеспечения надежности
Окончание табл. 20.5
Устранение сбоев
Проектирование модуля, выполняющего дополнительное необходимое
тестирование, является результатом анализа тестируемых данных. Результаты тестирования
дополнительной нагрузкой могут быть неадекватны, вследствие чего сложно
подтверждать реализацию всех целей обеспечения надежности. Некоторые модули, возможно,
должны пройти повторное тестирование методом "черного" или "белого" ящика. При
этом должно быть расширено и увеличено в объеме регрессионное тестирование. К
моменту завершения устранения сбоев менеджер проекта должен быть удовлетворен
результатами, после чего подтверждает достижение целей обеспечения надежности.
Отказоустойчивость
Отказоустойчивость— внутреннее свойство программной системы, заключающееся в
постоянном предоставлении услуг своим пользователям, позволяющим устранять
обнаруженные неисправности. Подобный подход к надежности ПО определяет продолжение
функционирования системы после обнаружения ошибок. Внедрение принципов
отказоустойчивости ПО в значительной степени отличается от внедрения аналогичных
принципов для аппаратного обеспечения. В системе, построенной на основе
отказоустойчивого аппаратного обеспечения, параллельно функционирует один или два набора
аппаратных средств. При этом происходит отражение всех устройств массовой памяти с тем,
чтобы при выходе из строя одного устройства другое сразу же могло бы продолжить
выполнение приложения. Это касается неисправностей, показанных на U-образной кривой,
которые связаны с естественным процессом износа аппаратных средств.
Попытка реализации отказоустойчивости ПО предпринимается таким же
образом, т.е. параллельным выполнением одной и той же программы различными
процессорами, приводит только к тому, что вторая копия точно такой же программы
отстает на доли секунды от первой копии. Простое выполнение отдельной копии
программы никак не отражается на отказоустойчивости ПО.
Начиная со средних фаз жизненного цикла разработки ПО (поставка и
сопровождение продукта), усилия по обеспечению надежности фокусируются на достижении
отказоустойчивости. В табл. 20.6 представлены подпроцессы основных фаз
(разработка проекта, внедрение, установка, поставка и сопровождение), которые реализуют
поддержку отказоустойчивости.
Процесс достижения отказоустойчивости начинается на фазе внедрения продукта
и распространяется посредством установки, эксплуатации, поддержки и
сопровождения. Завершение определяется моментом устаревания продукта. До тех пор пока
приложение выполняется в обычном режиме, отказоустойчивый подход к
обеспечению надежности используется достаточно широко.
Фазы разработки проекта, внедрения и установки рассматриваются в аспекте
обеспечения надежности ПО, для которого актуально устранение дефектов. В процессе
обеспечения отказоустойчивости дополнительно рассматриваются фазы эксплуатации.

684 Глава 20
поддержки и сопровождения, позволяющие окончательно завершить подход,
применяемый в процессе обеспечения надежности ПО. Отказоустойчивость представляет собой
логическое продолжение процесса исключения сбоев. В данном случае применяются
все процессы, используемые при устранении ошибок. Различие заключается в целях,
преследуемых жизненным циклом разработки продукта после завершения процесса
установки. Определение потребностей персонала, выполняющего задачи по
сопровождению продукта, осуществляются только со ссылкой на информацию, касающуюся
разработки предыдущих версий продукта. Организация должна иметь доступ к базе данных
по ошибкам, обнаруженным после установки других продуктов. Подобная
информационная структура, включающая описания ошибок и действий, предпринятых для их
управления и устранения, используется для оценки необходимых трудозатрат,
понесенных на этапе сопровождения продукта. Используя хронологические сведения о
результатах оценок ошибок, обнаруженных на фазе разработки, и относительный размер
нового продукта сравнительно с другими, можно выполнить быструю оценку остальных
ошибок и трудозатрат, необходимых для их устранения в новой версии продукта.
Таблица 20.6. Действия жизненного цикла разработки ПО, обеспечивающие
устойчивость к сбоям
Разработка проекта и внедрение Устойчивость
Распределение надежности среди компонентов
Встреча с инженерами для установки целей достижения надежности
Сосредоточение ресурсов на основе функционального профиля
Управление вводом и распространением сбоев
Измерение надежности приобретаемого ПО
Установка
Определение операционного профиля
Поддержка тестирования роста степени надежности
Отслеживание хода тестирования
Требуемое дополнительное тестирование проекта
Одобрение достигнутых целей обеспечения надежности
Эксплуатация, поддержка и сопровождение
Потребности в персонале на стадиях, следующих после завершения проекта
Сравнительный анализ достигнутой надежности
Отслеживание удовлетворенности заказчика достигнутым уровнем надежности
Распет по времени представления нового свойства с помощью отслеживания
надежности
Управление улучшением продукта и процесса с помощью оценок надежности
Чтобы обеспечить набор данных для программных продуктов, разрабатываемых в
будущем, менеджер проекта или программного продукта должен отслеживать
надежность в ходе полевых испытаний, учитывая цели создания надежного продукта. Это
связано с отслеживанием степени удовлетворения заказчиков достижением целей,

Обеспечение надежности ПО 685
связанных с обеспечением надежности. Конечный пользователь — наилучший
источник информации о надежности программного продукта. Именно здесь
прогнозирование отказоустойчивости сталкивается с реальностями окружающего мира.
Менеджер проекта/программного продукта должен определить время
представления нового свойства с помощью отслеживания достигнутого уровня надежности. Не
стоит предоставлять заказчикам новые свойства продукта, прежде чем не будут удалены
все известные ошибки. Объединение выпусков наборов новых свойств с
исправленными ошибками является наиболее подходящей практикой для
организаций-разработчиков ПО. Руководство ходом улучшения продукта и процесса с помощью оценки
надежности дополняет информацию, собранную на основе практики заказчика. При этом
устраняются ошибки программного продукта и совершенствуется непрерывный
процесс разработки. Выполнение оценок надежности является весьма дорогостоящей
процедурой. Результаты подобных оценок передаются обучающей организации.
Инструменты, обеспечивающие
надежность ПО8
Основой всех инструментов обеспечения надежности является статистический
анализ— любые инструменты, способные анализировать наборы данных и
элементарные статистические методики. При реализации любого подхода к обеспечению
надежности ПО применяется соответствующий набор инструментов:
прогнозирование ошибок— модели обеспечения надежности, анализ
хронологических данных, сбор сведений об ошибках, функциональное профилирование,
профилирование операционной среды;
предотвращение ошибок— формальные методы, повторное использование ПО,
инструменты конструирования;
устранение ошибок — формальное инспектирование, аттестация и верификация;
отказоустойчивость— методики отслеживания, верификации решений,
избыточность, исключительные ситуации.
Данная глава не является инструментальным руководством по обеспечению
надежности разрабатываемого ПО. Если вам требуется более подробное руководство,
обратитесь к книге Мишеля Лью (Michael Lyu) 1996 года издания, Handbook of Software
Reliability Engineering. Цель данного пособия — перечислить навыки, необходимые
команде разработчиков проекта для успешного использования доступных
инструментов. Менеджеру проекта необходимо либо обладать подобными статистическими
навыками, либо прибегать к услугам опытного разработчика, прежде чем использовать
доступные коммерческие модели обеспечения надежности и статистические методы.
1. Примечания:
- дискретные случайные переменные;
- непрерывные случайные переменные;
" Вопросы обеспечения надежности ПО и проведения быстрого тестирования
рассматриваются в книге: Роберт Калбертсон, Крис Браун, Гэри Клобб, Быстрое тестирование, изд-во
"Вильяме", 2002 г. - Прим. ред.
''Lyu Michael. Handbook of Software Reliability Engineering. NY: McGraw-Hill, 1996.

686 Глава 20
- условные вероятности;
- функции плотности условных вероятностей;
- стохастические процессы.
2. Теория надежности:
- взаимосвязи "время-сбой";
- частота отказов;
- наработка на отказ;
- интенсивность отказов.
3. Аналитические методы:
- комбинаторные модели;
- модели Маркова;
- анализ поощрений с применением метода цепей Маркова;
- процесс рождения и гибели;
- пуассоновские процессы/
4. Статистические методы:
- оценка параметров;
- точечная оценка;
- оценка интервалов;
- характеристика распределения;
- эмпирическое распределение;
- установка функции распределения;
- проверка по критерию "хи-квадрат";
- тест Колмогорова-Смирнова;
- многофакторный анализ.
- корреляционный анализ;
- факторный анализ;
- кластерный анализ.
План обеспечения надежности ПО
Ниже приводится схема плана обеспечения надежности ПО, который является
производным на основе множества планов, опубликованных IEEE, SEI и ISO. План
содержит минимальное количество пунктов и используется как дополнение к плану рисков,
связанных с ПО. Обеспечение надежности ПО очень дорого обходится для
организаций-разработчиков программ. Поэтому план обеспечения надежности должен
учитывать возможность уменьшения указанных рисков, а также цену подобного уменьшения.
Необходимо определить влияние на прибыль и инвестированный капитал для
организации, учитывая его при составлении окончательного плана разработки ПО.
1. Заключение управляющего относительно потребностей в надежности ПО.
2. Определения, акронимы и аббревиатуры, ссылки на вопросы, связанные с
обеспечением надежности.

Обеспечение надежности ПО 687
3. Отношение к плану управления рисками.
A. Уменьшение специфических рисков.
B. Сбережения бюджета проекта.
C. Влияние надежности программного продукта.
D. Описание метода, предназначенного для обеспечения надежности ПО:
- прогнозирование дефектов;
- предотвращение дефектов;
- устранение дефектов;
- отказоустойчивость.
4. Метод прогнозирования ошибок.
A. Определение функционального профиля.
B. Определения ошибок.
C. Схема классификации дефектов и отказов.
D. Потребности заказчика в надежности.
E. Альтернативные учебные курсы.
F. Заданные цели обеспечения надежности продукта.
5. Метод предотвращения дефектов.
A. Определение функционального профиля.
B. Определения дефектов.
C. Схема классификации дефектов и отказов.
D. Потребности заказчика в надежности.
E. Альтернативные учебные курсы.
F. Заданные цели обеспечения надежности продукта.
G. Распределение надежности между компонентами проекта.
Н. Разработка процесса, удовлетворяющего цели обеспечения надежности ПО.
I. План обеспечения ресурсов, основанный на функциональном профиле,
j. План менеджмента представления и распространения отказов.
К. Полученный план оценки надежности ПО.
6. Метод устранения отказов.
A. Распределение надежности между компонентами проекта.
B. Разработка процесса, отвечающего целям обеспечения надежности.
C. План обеспечения ресурсов, основанный на функциональном профиле.
D. План менеджмента представления и распространения отказов.
E. Полученный план оценки надежности ПО.
F. Заданный операционный профиль.
G. План тестирования роста степени надежности.
Н. План отслеживания хода выполнения тестирования.
I. План дополнительного тестирования.
J. Процесс сертификации целей надежности.

688 Глава 20
7. Метод обеспечения отказоустойчивости.
A. Распределение функций по обеспечению надежности между компонентами
проекта.
B. Разработка процесса, отвечающего целям обеспечения надежности.
C. План обеспечения ресурсов, основанный на функциональном профиле.
D. План менеджмента представления и распространения отказов.
E. Полученный план оценки надежности ПО.
F. Заданный операционный профиль.
G. План тестирования роста степени надежности.
Н. План отслеживания хода выполнения тестирования.
I. План дополнительного тестирования.
J. Процесс одобрения целей надежности.
К. Потребности персонала на этапах, следующих за завершением проекта
L. Отслеживание соответствия целей и надежности при полевых испытаниях.
М. Отслеживание степени удовлетворенности заказчика достигнутой
надежностью.
N. Расчет по времени представления нового свойства путем отслеживания
надежности.
О. Руководство процессом совершенствования продукта и процесса с помощью
оценивания надежности.
8. Процесс одобрения плана надежности
Резюме
С момента определения разработки ПО надежность считается ключевым
показателем качества программного продукта. Во всех главах книги авторы рассматривают
следующие характеристики качества ПО: сопровождение, гибкость, допуск тестирования,
переносимость, возможность повторного использования и т.д. В данной главе особое
внимание уделяется надежности ПО в силу немедленного воздействия данного качества
на конечного пользователя. Для команд разработчиков и сопровождения ПО большое
значение имеют изменение версий программного продукта и варьирование качества.
Факторы, связанные с эксплуатацией продукта, ориентированы на заказчика, и потому
он может быть неудовлетворен неподходящим программным продуктом.
В отличие от аппаратных средств, ПО не "изнашивается", однако может
поставляться с ошибками. Определение и планирование отказоустойчивости по отношению
к сбоям, которые неизбежно появляются в программном продукте, освещается в
главах 23, 26 и 30. Менеджер проекта должен хорошо понимать, какие инвестиции
требуются для обеспечения надежности. Методы определения достаточного размера
инвестиций были рассмотрены в главе 18. Риск и надежность являются неотъемлемыми
факторами, вследствие чего рассматриваются одновременно. Экономное применение
принципов надежности при проектировании ПО определяется критерием уменьшения
риска появления ненадежных программ. Если использование надежности не уменьшает
риск, то бессмысленно вкладывать в проект дополнительные средства.

Обеспечение надежности ПО 689
В данной главе рассматриваются четыре метода создания ПО, обеспечивающие
повышение степени надежности:
1. прогнозирование дефектов;
2. предотвращение дефектов;
3. устранение дефектов;
4. отказоустойчивость.
Ранее уже говорилось о том, на каком этапе жизненного цикла разработки
продукта применимы данные методы. Используя методы и жизненный цикл разработки в
качестве руководства, был представлен набросок плана надежности ПО в его связи с
планом рисков проекта. Сталкиваясь с необходимостью использования методик
разработки надежности ПО, менеджер проекта может применить основные идеи данной
главы для включения этих методов в общий план проекта.
Контрольные вопросы
1. Система включает различные программные модули с относительной
вероятностью использования и коэффициентом отказов, как показано в табл. 20.7.
Таблица 20.7. Вероятность использования и частота отказов
программных модулей
Вероятность применения Сбои/1000 часов
Модуль 1 0.4 0.6
Модуль 2 0.3 1
Модуль 3 0.2 1.2
Модуль 4 0.09 2
Модуль 5 0.01 4
Л. Какой общий коэффициент отказов системы?
В. У вас есть возможность сократить в два раза коэффициент отказов для любых
двух модулей. Какие модули необходимо выбрать для обеспечения
наибольшего коэффициента сокращения отказов?
2. Предположим, что программа претерпевает 100 отказов за время своего
жизненного цикла. Это было определено путем сбора данных на ранних стадиях проекта.
На данный момент совершено 50 отказов. Начальная интенсивность отказов
составляла 10 ошибок на час машинного времени. Каково текущее значение
интенсивности отказов?
3. Предположим, что начальная интенсивность отказов составила 10 отказов на час
машинного времени. Коэффициент дисперсии интенсивности отказов составляет
0,02 на один отказ. Предположим, что допущено 50 отказов. Каково текущее
значение интенсивности отказов?
4. Для основной модели, где v0 = 100 отказов, начальная интенсивность отказов
составляет = 10 отказов/час машинного времени, цр = 50. Определите ожидаем'»
количество отказов, которые могут иметь место в промежутке между тек\ ии-п ни-

690 Глава 20
тенсивностью отказов, равной 3.68 отказов/час машинного времени, и реальной,
составляющей 0.000454 сбоев/час машинного времени.
5. Для логарифмической модели Пуассона вычислите ожидаемое количество
отказов, имеющих место в промежутке между настоящей интенсивностью отказов,
равной 3.33 сбоев/час машинного времени, и реальной, составляющей 0.476
сбоев/час машинного времени. Предположим, что начальная интенсивность отказов
составляет 10 сбоев/час машинного времени, а параметр распада интенсивности
отказов составляет 0.02/отказа.
Практическое занятие
Один из методов, рекомендуемых команде для снижения общей стоимости
владения CRM окончательного плана ARRS, — широкое использование "коммерчески
готовых" (COTS) программных продуктов. М-р Лу выразил глубокое удовлетворение тем,
чт< > можно использовать готовые программы, сэкономив на стоимости их разработки.
С другой стороны, д-р Чжоу отметила, что серьезная проблема с COTS-продуктами
состоит п том, что им часто не хватает гарантии хорошей практики разработки и
обширной ее документации, что традиционно является основой принятия и
сертификации ПО для важных приложений.
Доктора Чжоу можно убедить в необходимости использования COTS-продуктов,
если продемонстрировать, каким образом методы обеспечения отказоустойчивости
можно встроить в план ARRS. Используя опыт предыдущей работы в
аэрокосмической промышленности, вы знаете единственный метод— отказоустойчивость,
достигаемая с помощью определения различий при проектировании. Это довольно
заманчиво, поскольку может применяться без доступа к деталям внутреннего
устройства COTS-элемента. Систему можно защитить от ее COTS-компонентов с помощью
дополнительных компонентов, которые либо контролируют ее на предмет
отклонений от заданного поведения, либо на нарушения известного "безопасного
кодекса" поведения, которые не представляют опасности для других частей системы.
М-ру Лу необходимо представить, как повлияет на проект принятие
отказоустойчивых процедур для программных COTS-продуктов. Он уже пообещал менеджеру
CRM, что они сэкономят деньги благодаря вашему решению. Убедите в этом д-ра
Чжоу, племянницу министра транспорта Китайской Народной Республики.
Стандарты
IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Planning, IEEE Computer Society,
1996.
IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans, IEEE Computer Society, 1998.
IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software, IEEE
Computer Society, 1989.
IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce
diahle Software, IEEE Computer Society, 1989.
IEEE Std 1228-1994. IEEE Standard for Software Safety Plans, IEEE Computer Society, 1994.

Обеспечение надежности ПО 691
Инструменты
www. sre.org/sresoft .htm. Планировщик контроля надежности (RTF) ПО упрощает
создание статистических планов контроля надежности для экспоненциальных и биномиальных
распределений. Задавая параметры контроля (продолжительность, ошибки, риски заказчика или
производителя), можно быстро вычислить ОС-кривые и риски. Можно затем изменить планы
проверок, приспособив их для своих целей. Пользователь может выбрать тестовые планы в MIL-
HDBK-781 или создавать оригинальные планы контроля фиксированной продолжительности
либо последовательные (PRST).
Литература
Lvu Michael (Editor). Handbook of Software Reliability Engineering. NY: McGraw-Hill, 1996.
Musa John D. Software Reliability Engineering: More Reliable Software, Faster Development and Testing. NY:
McGraw-Hill, 1998.
Musa John D. и др. Sofiware Reliability: Measurement, Prediction, Application. NY: McGraw-Hill, 1987.
Tierney, James. "SRE at Microsoft." Keynote speech at 8th International Symposium on Software Reliability
Engineering, Albuquerque, NM, 1997.
Дополнительные сведения в Internet
members .aol. com/ JohnDMnsa/'. Муза Дж. Д. (MusaJ.D.). Как быстрее и дешевле получить более
надежное ПО (разработка надежного ПО), 1998.
гас. ii tri . org/. Задача Центра анализа надежности (Reliability Analysis Center, RAC) —
обеспечение технической экспертизы и доступа к информации, касающейся вопросов надежности,
управляемости, поддержки и качества, а также увеличения прибыльности в результате их применения на
всех фазах жизненного цикла продукта или системы.
www.asq-rd. org/. Американское общество борьбы за качество, отдел обеспечения надежности.
www. cs. emu. edii/~koopman/des_s99/sw_reliability/. Надежность ПО, университет Кар-
неги Меллон, 18-849b Dependable Embedded Systems, 1999 г.
www.ieee.org/organizations/society/rel.html. Общество борьбы за надежность в
комитете IEEE (IEEE Reliability Society) решает проблемы, связанные с достижением высокого уровня
надежности.
www.salon.com/tech/feature/2000/12/06/bad_computers/index.html. Cheryll Aimee
Barron, Миссия высокотехнологичных компаний, "надувающих" клиентов. Компьютерные
компании, которые специализируются на предоставлении покупателям некачественных продуктов— это
американский способ технокапитализма. 2001, Salon.com.
www. sre. org/. Society of Reliability Engineers.

Метрические
показатели,
применяемые при
оценке размера
программ
В среде инженеров, занимающихся разработкой ПО, любят повторять утверждение
Лорда Кельвина (Lord Kelvin), имеющее отношение к процессу измерения: "Если вы
можете измерить то, о чем говорите, и выразить это понятие в числах, вы что-либо знаете об
.лом; если же вы не можете измерить его, не можете отобразить в числах, ваши знания
Ot-дны и неудовлетворительны. Скорее всего вы только начинаете познавать мир, имея
11 i >< увеличенное представление о ваших знаниях на данном этапе исследования" .
Кельвин пополнил быстро растущие ряды инженеров-программистов и менедже-
" >н. которые пришли к выводу о непреходящей ценности процесса измерений, при-
• |.и» его незаменимым в повседневной практике инструментом. При определении це-
.■ic-ii и измерении достижений программного проекта формируется представление о
программах и самом процессе программирования. Подобный подход, в свою очередь,
может привести к установлению контроля над процессом, т.е. способствовать его
|>а:шнтик> в нужном направлении. Удачно дополнил Лорда Кельвина Том де Марко
! Г> 'in ЮеМагсо): "Вы не способны контролировать то, что не можете измерить" .
Метрические показатели позволяют менеджерам проекта представить, где именно
они находятся (определение базовой линии), благодаря чему служат руководством в
;,дчестне основы для дальнейшего совершенствования программного проекта. Как
правило, менеджеры проектов испытывают потребность в определении степени
прогресса при достижении следующих целей:
■ большая точность в оценке затрат на осуществление программного проекта и при
составлении графика;
■ рост производительности и эффективности труда;
■ более успешное удовлетворение запросов заказчиков и укрепление взаимного
доверия на основе повышения качества продукта.
' bin WT. A891-1894). Popular Lectures and Addresses.
..!!.■<.■ i i>ui Controlling Software Projects. Upper Saddle River, NJ: Prentice Hall, 1982.
Ш

Метрические показатели, применяемые при оценке размера... 693
Программисты прилагают все усилия для того, чтобы превратить практические
навыки в научное знание. Поэтому хотя и известны пути совершенствования методов
измерений, предложенные лордом Кельвином, путь этот не столь легок и прост.
В 1977 году Маурис Халстед (Maurice Halstead) опубликовал одну из первых работ,
посвященных методу подсчета программных конструкций (операторов и операндов) и
выводу связанного с этими понятиями числа, определяющего производительность
программистского труда. Он полагал, что разработал научные методы измерения и
оценки ПО. В текущем столетии мы продолжаем стремиться к достижению этой
"призрачной цели", хотя уже имеется прогресс в разработке определенных
исключительно полезных метрических показателей, которые могут служить руководством к
действию для разработчиков ПО. Во главе этого процесса стоят такие эксперты, как
Билл Куртис (Bill Curtis):
"Если мы хотим превратить программирование в инженерную дисциплину, нужно
использовать строго научные процедуры. В их основе находится проектирование
методик измерения и уточнение причин, приводящих к установке взаимосвязей между
аффектами ".
Стадии жизненного цикла
разработки продукта
Различные измерения, применяемые при разработке ПО, используются на всем
протяжении жизненного цикла (см. рис. 21.1). Интегральная задача "разработка
качественной системы метрических показателей" находится в центре внимания при
разработке проекта, а задача "сбор и анализ метрических данных" требует постоянно
проводимых аттестации и верификации. В любом случае имеется достаточно
большой "простор" для выполнения действий по измерению. Каждая интегральная задача
проекта, кроме уже рассмотренных ранее, также приводит к формированию одного
или нескольких компонентов проекта, которые нуждаются в оценивании.
Измерительные действия имеют место на всех интегральных фазах (процессы поддержки)
жизненного цикла разработки ПО.
Начало работы над проектом и этап планирования
■ Процесс установки проектной среды. Включает набор механизмов, используемых
при измерении данных.
■ Планирование управления проектами.
Отчеты, содержащие описания возникающих проблем и план их устранения,
включают также описания методов, применяемых при подсчете количества и учета
различных типов важнейших компонентов, относящихся к внутренней/внешней
области проекта, которые уже разработаны либо находятся в "зачаточном" состоянии.
План управления программным проектом включает значения оценок размера,
трудозатрат, точности графика и объемов денежных затрат. Все получаемые
числовые значения непрерывно обрабатываются и сравниваются со значениями
фактических параметров.
Curtis Bill. Measurement and Experimentation in Software Engineering. Proceedings of the IEEE,
(>8(9): 1144-1157, 1980.

694 Глава 21
Мониторинг и управление проектом
■ Управление проектом. Отчеты при проектном менеджменте часто полностью
состоят из метрических данных: менеджерам в любой момент времени важно иметь
представление о достигнутом прогрессе, а также о том, каким образом он
отражается на оценках. Отчеты содержат информацию о том, каким образом можно
успешнее пользоваться определенными величинами.
Исследование
концепции
•
Формулирование

потребности
Исследование
системы
■ Спецификация
интерфейса
системы
Распределение
ресурсов
бюджет
Требования
• Спецификация''
требований
к ПО
Разработка
проекта
■ Описание

разработки ПО
Базовая модель системного жизненного цикла
Внедрение
Выбор модели
жизненного цикла
разработки ПО
• План

тации/верификации ПО
Установка среды проекта
Методологии
Стандарты
Инструменты
Установка
■ Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
■
Пользовательская
документация
Инициализация
и планирование проекта
Сопровождение
Менеджмент плана проекта
Проектная отчетность и испытательный план
План менеджмента программного проекта
' Документация
по
сопровождению
Вывод из
эксплуатации
Контроль и отслеживание проектов
• Архивный
отчет
Отчеты по управлению проектами
Управление проектом
I
I
Сохранение записей
Хронологические записи о проекте
I
Методы, с помощью которых выполняются отчеты о возникших проблемах
Отчет об устраненных проблемах
Дополнительные сведения, имеющие отношение к отчету о возникших проблемах
Проанализированный отчет о возникших проблемах I
I
I
I
I
v^
J
Метрические показатели

Метрические показатели, применяемые при оценке размера... 695
f Обеспечение качества прогршиносо обеспечение ]
• План обеспечения качества
i
I
I
I
]| Разработка метрических показателей качества]
С
• Метрические показатели
• Оценки качества проекта
Управление качеством программного обеспечения
Управление качеством программного обеспечения
Идентификация потребностей 8 улучшении качества
■ Рекомендации по улучшению качества
План аттестации и верификации
Аттестация и верификация
■ План аттестации и верификации ПО
I
Выполнение задач по аттестации и верификации
* Оценочные отчеты
I
I
Сбор и анализ метрических показателей
• Аналитические отчеты
Т"
План тестирования
j | Разработка спецификации тестов]
• Спецификация тестов
I [Спецификация тестов] I I
I * Сводный отчет по выполненным тестам i
I •Протестированное программное обеспечение I
Выполнение учета состояния
• Изменение состояния
• Отчет о состоянии
Учебный процесс
Аттестация учебной программы
> Обновленные учебные материалы
^
J
Метрические показатели
Рис. 21.1. Местонахождение метрических показателей в жизненном цикле разработки ПО
i Ведение записей. Записи проекта, связанные с историей выполнения проекта, —
это и есть метрические показатели, которые просто неоценимы для будущих
проектов. Особенно важны записи, связанные с оценками размеров проекта и
содержания ПО, записи относительно трудозатрат на разработку, а также относительно
точности графика и объемов текущих затрат.
I Отчет о проблемах, возникающих на этапе внедрения. Отчеты о разрешенных
проблемах, основные вопросы по усовершенствованию, а также заключения
относительно анализа проблем являются богатым источником метрических данных.
Поддерживается информация о затратах времени на устранение проблемы, о типе
рассмотренной задачи, ее месте и роли в жизненном цикле разработки ПО.
I План обеспечения качества. Планы по обеспечению качества определяют
применение количественных терминов, например, используется показатель сложности
систем, которые заведомо устроены проще или же пороговое значение для
количества ошибок, которые следует обнаружить перед стадией поставки ПО.
I Разработка метрических показателей качества. Для проекта/организации
устанавливаются цели, а с помощью метрических показателей оцениваются
количественные изменения в направлении поставленных целей.
1 Управление качеством ПО. Требования к качеству проекта часто имеют вид
требований модели SEI СММ, с помощью которых уровень зрелости получает
количественную оценку.

696 Глава 21
Управление качеством ПО
■ Идентификация запросов по совершенствованию качества. Рекомендации по
совершенствованию качественных показателей обычно представлены в форме,
удобной для выполнения измерений. В этом случае, например, речь идет о
непрерывном совершенствовании (по направлению к уровню зрелости) модели
SKI CMM, уменьшении количества обнаруженных дефектов или улучшении
учебного плана.
■ План аттестации и верификации. План аттестации и верификации ПО
существенно зависит от метрических показателей, позволяющих определить количество и
гни контрольных примеров; а также от того, какие пути развития избираются
системой, каков охват тестов и сколько часов выделено для тестирования.
Аттестация и верификация
■ Выполнение задач но аттестации и верификации. Отчеты по оцениванию должны
включать метрические показатели, отраженные в диаграммах, графиках и
таблицах, где отражены результаты выполнения тестового плана.
■ Сбор и анализ метрических данных. Аналитические отчеты включают данные,
которые помогают менеджерам проекта принимать решения, которые могут быть
связаны, например, с развитием проекта или повышением его качественного
уровня. В отчеты включается информация о процессе, проекте и тех ресурсах,
которые наблюдаются непосредственно или же выявляются в ходе соответствующих
вычислений.
■ План тестирования. Планы тестирования частично базируются на метрических
показателях системы тестов, позаимствованных из предыдущих проектов.
■ Разработка спецификации тестирования. Спецификации тестирования
позволяют точно оценить предмет тестирования, выраженный в количественном
отношении.
■ Выполнение тестов. Отчеты, резюмирующие проведенные тесты, содержат
метрические показатели, основанные на результатах тестирования.
■ Учет состояния выполнения. Отчеты о состоянии и его изменении содержат
сведения о состоянии системы и его компонентах (элементы конфигурации).
Процесс обучения
ш Аттестация учебной программы. Обновленные учебные материалы формируются
на основе метрических показателей, составленных с учетом студенческих оценок
определенных курсов, записей о посещении, доведенных до логической
завершенности критериев, оценивающих степень полезности материала и т.д.
Связь главы 21 с 34 компетенциями
Программа, охватывающая метрические показатели ПО, оценивает практически
все навыки, связанные с продуктом, проектом и персоналом, составляющие 34
компетенции (табл. 21.1). Существуют также альтернативные процессы, применяемые для
определения, сбора, анализа и составления отчетов по метрическим показателям.

Метрические показатели, применяемые при оценке размера... 697
Рассмотрим пример по изучению всего одного процесса, для чего воспользуемся
парадигмой Бейзили (Basili) цель/вопрос/метрический показатель. Определенные в главе
этапы метрического процесса могут служить ориентиром, точно так же, как и типы
представленных метрических показателей вместе с методиками их представления.
ПО
Продукт
1. Процессы оценивания
2. Знание стандартов процесса
3. Определение продукта
4. Оценка альтернативных
процессов
5. Управление требованиями
6. Управление субподрядчиками
7. Выполнение начальной оценки
8. Отбор методов и
инструментов
9. Подгонка процессов
10. Отслеживание качества
продукта
11. Понимание действий по
разработке продукта
Проект
Проект
12. Создание структуры
пооперационного перечня работ
13. Документирование планов
14. Оценка стоимости
15. Оценка трудозатрат
16. Менеджмент рисков
17. Отслеживание процесса
разработки
18. Составление графика
19. Выбор метрических показателей
20. Отбор инструментов менеджмента
проектов
21. Отслеживание процессов
22. Отслеживание хода разработки
проекта
Менеджмент
Персонал
23. Оценка производительности
24. Вопросы интеллектуальной
собственности
25. Организация эффективных
встреч
26. Взаимодействие и общение
27. Лидерство
28. Управление изменениями
29. Успешное ведение
переговоров
30. Планирование карьерного роста
31. Эффективное представление
32. Набор персонала
33. Отбор команды
34. Создание команды
Рис. 21.2. Связь метрических показателей с 34 компетенциями
Существует ряд инструментов, помогающих в сборе данных, например
автоматизированные системы "электронных временных страниц" и аналитические пакеты,
применяемые при определении степени сложности программного кода. Метрические
показатели имеют большое значение при работе с субподрядчиками (решение
вопросов, связанных с выполнением графика и обеспечением надлежащего качества
продукта) и при отслеживании качества программного продукта (при условии его
надежности и функциональности). Оценивание трудозатрат, материальных затрат,
соблюдение графика, отслеживание процесса разработки и отслеживание процессов/хода
выполнения зависят от значений, полученных эмпирическим путем, или являются
результатом других вычислений. При подборе квалифицированного штата
сотрудников для выполнения проекта, большинство организаций опираются на базы данных,
где также отражены возможности по выполнению измерений.
Учебные цели главы 21
После изучения материала главы читатель должен уметь выполнять следующее:
■ объяснять преимущества использования метрических показателей, определяющих
размер ПО;
■ знать категории метрических показателей и приводить примеры для каждой
категории;

698 Глава 21
■ знать, где в жизненном цикле разработки ПО используются метрические
показатели;
■ называть этапы процесса измерения показателей ПО;
■ идентифицировать качественные метрические показатели программ;
■ объяснять основные понятия парадигмы Бейзили (Basili)
цель/вопрос/метрическая парадигма (goal/question/metric paradigm, GQM);
■ описывать "стартовый набор" метрических показателей ПО;
■ определять метрические показатели ПО, влияющие на качество конечного продукта.
В главе 21 описываются несколько метрических показателей, имеющих
отношение к ПО, и предпринимается попытка убедить недоверчивого читателя в
необходимости определять, формировать, а также анализировать метрические показатели,
включая их в отчеты. В главе определяются методы измерения, применяемые в ходе
проведения оценок программ, а также описываются характеристики "хорошего"
метрического показателя. Приводятся примеры широко пользуемых метрических
показателей программного обеспечения, а также методики их разработки с помощью
парадигмы Бейзили (Basili) цель/вопрос/метрическая парадигма. Для тех же, у кого
мало нремени, кто испытывает недостаток бюджетных средств или не желает
устанавливать в своей организации или проекте подходящую заказную метрическую
программу, предлагается "стартовый набор", где описываются три простых, но
достаточных источника метрических показателей.
Определение метрического показателя
Под метрическим показателем понимают количественную оценку программного
продукта, процесса или проекта, используемую непосредственно или на основе
которой производятся другие измерения/выполняется прогноз.
Д-р Барри Боэм (Dr. Barry W. Boehm), эксперт в области разработки ПО,
высказывания которого часто цитируются в книге, подчеркивает, что важность метрических
показателей определяется тем, в какой мере они способствуют принятию решений.
Если менеджер программного проекта будет помнить об этом, он сможет опериро-
п.пъ полезными и важными метрическими показателями, а не собирать их случайным
образом, "консервируя" большие объемы неподходящих данных.
"Измерение при разработке ПО является непрерывным процессом определения, сбора
и анализа данных, относящихся к программному процессу и соответствующим ему
продуктам. Целью этой деятельности является получение представления о процессе,
контроль над ним и программными продуктами, а также поддержка важной
информации, которая позволит совершенствовать процесс и программные продукты" .
"Измерение в ходе разработки ПО -количественное оценивание произвольных аспектов
процесса программного инжиниринга, программного продукта или контекста; оно
служит для совершенствования представления, помогает контролировать, прогнозировать и
вносить улучшения в создаваемый продукт, а также в применяемые рабочие методы' .
i Boehm Barry W. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1981.
Pfleeger Shari Lawrence. Use Realistic, Effective Software Measurement. Constructing Superior
Software. Macmillan Technical Publishing, 2000.

Метрические показатели, применяемые при оценке размера... 699
При изучении набора метрических показателей, которые используются в
различных организациях, следует принимать к сведению эти определения.
Классы измеряемых программных объектов
Каким образом процесс измерения связан с ПО? Связь эта весьма проста и может
быть легко определена. Рассматриваемое в абстрактной форме, программное
обеспечение напоминает физическую измерительную рулетку. "Наблюдаемые" сущности,
например, количество строк кода, легко можно измерить, хотя практически
невозможно увидеть сам код. Можно наблюдать только представление кода на экране
компьютера или при выводе на печать. Однако это представление позволяет выполнять
некоторые подсчеты, которые не слишком отличаются от измерений невидимых
температурных показателей с помощью термометра. Существует множество и других,
менее очевидных характеристик программных проектов, поддерживающих полезную
информацию. Например, степень сложности кода является полезным метрическим
показателем, хотя и более сложным, применяемым для производства количественной
оценки. Среди других атрибутов продукта можно отметить имеющиеся
функциональные свойства, модульность, возможность повторного применения, избыточность и
"склонность к структурированию", под чем обычно подразумевают модульное
соединение и связность (см. главу 22).
Под процессом понимается набор действий, имеющей отношение к разработке ПО.
Чтобы сформулировать решения об используемых процессах, следует получить
представление об уровне эффективности и производительности в их текущем базисе.
В этом случае продуктом является любой компонент, который может быть поставлен,
или документ, который появился в результате выполняемых действий. Менеджер
проекта должен иметь представление о том, достаточно ли высоким качеством
обладают внешние или внутренние продукты. Ресурсы — это объекты, которые необходимы
в процессной деятельности. Менеджер проекта обязан иметь представление о
собственных ресурсах, особенно об имеющемся персонале. Достаточно ли
производительно они трудятся, удовлетворителен ли уровень их подготовки и соответствует ли он
той роли, которая отведена ему в команде?
В табл. 21.1 приводятся примеры типов метрических показателей
(непосредственный, наблюдаемый, прогнозируемый или вычисляемый), относящиеся к
программным категориям продукта, процесса, проекта и персонала.
Следует отметить тот факт, что метрические показатели бывают объективными
или субъективными. Субъективные измерения предполагают наличие личностного,
субъективного взгляда, например применение веса к значению функции,
определяющей ввод/вывод данных.
Измеряемые атрибуты могут быть внешними или внутренними. Внутренние
атрибуты могут измеряться в терминах самого объекта, отдельно от его поведения.
Внешние атрибуты оцениваются с учетом связи объекта с внешней средой. Примерами
внутренних атрибутов являются показатель LOC, продолжительность выполнения
действия, величина трудозатрат, количество неудачных тестовых испытаний, объем
затрат, уровень сложности и степень модульности. В качестве внешних атрибутов
можно рассматривать время выполнения (требуются программа и компьютер),
'' Torn Aimo — Professor, Department of Computer Science Abo, Akademi University, Faculty
member Turku Centre for Computer Science (TUCS) Turku, Finland.

700 Глава 21
полезность и удобство представления (требуются приложение и пользователь),
надежность, эффективность, тестируемость, повторная применимость, переносимость
н взаимодействие между операциями.
Измерительные шкалы
В главе описываются этапы измерений ПО и рассматриваются некоторые
наблюдаемые, прогнозируемые и вычисляемые метрические показатели, которые
считаются широко распространенными. При обращении к концепции метрических
показателей ПО полезно помнить о том, что процесс измерения произвольного типа основан
на следующем важном понятии: измерительные программы обычно характеризуются
непосредственно наблюдаемыми атрибутами, причем как по абсолютной, так и по
поминальной шкалам. Абсолютная шкала применяется в том случае, если измерение
предполагает какие-либо подсчеты, например, подсчет количества строк кода в
программе. Номинальная шкала позволяет группировать элементы в классы, порядок
которых известен заранее (часто он является бинарным), например "Экспертная
оценка представлена в этом программном проекте" A - да) или "Для данного
программного проекта отсутствует экспертная оценка" Bжнет).
В качестве метрических показателей обычно применяют порядковую,
интервальную или пропорциональную шкалы.
Таблица 21.1. Типы метрических показателей, связанных с ПО
Непосредственно на- Прогнозируемый
блюдаемый
Вычисляемый
(косвенный способ)
[римеры Непосредственное измерение
атрибута некоторого
объекта не вовлекает
другие атрибуты или
объекты
Непосредственное измерение
применяется при оценивании
существующего объекта
Программный Количество строк кода
продукт Количество тестовых
примеров
Количество не
устраненных дефектов, о которых
заказчик получает отчет
Количество тестов
Количество дефектов, их
серьезность
Количество действий
Количество компонентов
системы
Метрические
показатели, определяющие
связность компонентов
Система прогнозирования
включает
математическую модель наравне
с набором процедур
прогнозирования,
применяемых для определения
неизвестных параметров
и для интерпретации
результатов
Количество строк кода
Качество программного
обеспечения
Проявление дефектов
программного
обеспечения
Представление и
характеристики оставшихся
дефектов (на основе
данных отчетов экспертов
и/или тестов)
Надежность
Количество дефектов, их
серьезность
Косвенное измерение
означает вовлечение с
помощью определенной
математической модели
других атрибутов и
объектов (всегда включает
вычисления с
использованием, по крайней
мере, двух других
метрических показателей)
Эффективность —
динамическое поведение
системы
Эффективность —
ресурсы системы
Психологические
сложности
Плотность дефектов ■
дефекты/ KLOC
Измерение достигнутой
степени надежности
(например, значение
времени наработки на
отказ)

Метрические показатели, применяемые при оценке размера... 701
Окончание табл. 21.1
Непосредственно
наблюдаемый
Прогнозируемый
Вычисляемый
(косвенный способ)
Процесс
Проект
Персонал и
другие
ресурсы
Обращение к процессу
(да или нет)
Охват и эффективность
отчетов экспертов
Эффективность
обучения
Уровень SEI.
Стоимость проекта
Время разработки
продукта
Потребность в ресурсах,
кроме сотрудников
Продолжительность
выполнения проекта
Стоимость проекта
Количество штатных
сотрудников
Перечень умений
обязанностей
Опыт программирования
Использование ресурсов
Трудозатраты
Точность оценивания =

оценка/действительное значение(целью
является 1.0).
Производительность = LOC/
штат-месяц
Охват равномерным
(peer) отчетом;
Тестирование или
верификация покрытия
Уровень выполнения
действий
Эффективность
преподавания
Вероятность риска
Обзор метрических
показателей
Анализ требований
Поддержка
метрических показателей
Обращение к графику =
объем освоенных средств
(например,
действительная стоимость
выполненных
работ/бюджетная стоимость
выполненных работ)
Индекс выполнения
графика
Производительность =
LOC/месяц
Наличие аппаратных
средств
Надежность
аппаратных средств
Другим примером служат промежуточные драйверы затрат СОСОМО (глава 11),
при использовании которых атрибуты аналитических способностей (analyst
capability, АСАР) или методик современного программирования (Modern programming
practices, MODP) характеризуются как очень низкие, низкие, номинальные, а также
как высокие, очень высокие и экстравысокие. Однако действительные значения
для каждого рейтинга отличаются для различных атрибутов. Разница между
значениями для каждого драйвера затрат между высоким и очень высоким не аналогична
различию между низким и очень низким даже в том случае, если сами величины
упорядочены. Например, значения для драйвера затрат (мультипликатор трудозатрат),
характеризующие аналитические способности, будут следующими: очень низкий = 1,46;

702 Глава 21
низкий = 1,19; высокий = 0,86 и очень высокий = 0, 71. Разница между "очень
низким" и "низким" составляет 0,27, и то же время различия между "очень высоким" и
"высоким" равны 0,15. Расстояния между точками порядковой шкалы не имеют
решающего значения.
При обращении к интервальным или пропорциональным шкалам величины могут
располагаться с учетом их ранга. В связи с этим расстояния между точками шкалы
приобретают важное значение. На интервальной шкале одно "деление" шкалы
представляет аналогичное смещение величины какой-либо характеристики или
особенности, если при этом исходить из полного диапазона шкалы. Равные расстояния на
шкале представляют одинаковые различия в атрибуте, но одно значение данных нельзя
множить или делить на другое. Поддерживается только сложение и вычитание.
Например, разница между 50 и 55 строками кода C++ составляет 5 строк, а разница
между 50 и 60 строками кода COBOL составляет 10 строк. Однако вывод о том, что 10
дополнительных строк в COBOL приводят к удвоению сложности программы по
сравнению с пятью дополнительными строками в C++ будет некорректным.
В нашем случае следует помнить о том, что разумнее начинать с простых
метрических показателей, независимо от того, являются ли они наблюдаемыми или
вычисляемыми, внутренними или внешними, относятся к процессу или продукту,
объективны ли они или субъективны.
О значении метрических показателей
в программных проектах
При более общем подходе можно отметить, что измерения в программных
проектах иризваш-i помочь менеджерам и практикам в принятии своевременных решений
в 3i. .псимости от рассматриваемых данных; кроме того, они облегчают отслеживание
организационного прогресса при появлении усовершенствований. Также появляется
иозможность оценки воздействия прогрессивных изменений. В дополнение к тому,
что программные метрические показатели используются для измерения
определенных атрибутов программного продукта, процесса или ресурса, менеджер проекта
может применять их в следующих целях:
■ анализ ошибок и дефектов программного продукта;
■ оценка состояния;
■ формирование базиса с целью проведения оценок;
■ определение уровня сложности продукта;
■ установка основных направлений разработки;
■ экспериментальное подтверждение лучших методик;
■ прогнозирование качественных показателей, графика, прилагаемых трудозатрат и
объемов других затрат;
а отслеживание прогресса в ходе выполнения проекта;
■ определение оптимальных сроков достижения необходимого уровня качества
продукта либо процесс в целом.
И вновь обращаясь к Боэму (Boehm), считаем нелишним повторить, что
метрические показатели ПО позволяют улучшить и ускорить принимаемые решения.

Метрические показатели, применяемые при оценке размера... 703
Кто же выигрывает при выполнении измерений? Вообще говоря, каждый, кто
обращается к этому процессу или же ознакомлен с результатами его выполнения,
любой пользователь или группа, интересы которых связаны с успешным
завершением проекта (заказчики, спонсоры, конечные пользователи, главные менеджеры,
менеджеры проекта, эксперты предметной области, авторы, аналитики,
разработчики, инженеры, обеспечивающие качество программного продукта,
программисты и тестеры).
В то время как менеджеры используют метрические параметры при
определении методов управления проектами, а также при оценивании изменений для
улучшения процесса разработки программ, команды разработчиков применяют их
следующим образом:
■ устанавливают достижимые цели при анализе требований, на фазах
проектирования, конструирования, тестирования и внедрения;
■ демонстрируют свой потенциал при достижении этих целей;
■ отслеживают прогресс в достижении этих целей;
■ выполняют настройку процессов для коррекции предельных условий, выходящих
из-под контроля (например, если обзоры являются достаточно важными, но
команда не желает затрачивать на них дополнительное время, их можно
отслеживать с помощью контрольного графика, как показано на рис. 21.3).
Верхний контрольный предел
Медиана
Нижний контроль предел
"~ABCDEFGHIJKLM
Модуль
Рис. 21.3. Пример контрольного графика, применяемого командой разработчиков
Заинтересованными сторонами выполняется сбор, синтез, анализ, включение в
отчеты и изучение метрических показателей. Затем происходит их постепенная
сортировка по убыванию приоритета в рамках данной организации или с учетом условий
среды. Они могут не подходить, и возможно, не допускается их применение в другой
организации. Если подобные метрические показатели применяются без учета
коррекции целей и изменения моделей, к их интерпретации следует относиться
осторожно. Однако после того как метрические показатели получили подтверждение в
If
IS
Е g
2 I
га £
х 3
Q> О
2 В.
8.0
7.0
6.0
5.0
4.0
3.0
2.0
1.0
НЕЗ

704 Глава 21
одной среде и внесены в реестр знаний, их ценность возрастает. Они играют
существенную роль при прогнозировании будущих направлений и при внесении усовершен-
< тнонаний в программный процесс, особенно если речь идет о той же самой или
аналогичной среде.
Метрические показатели
и модель SEI СММ
Измерение и анализ являются интегральной частью модели зрелости
программного обеспечения, предложенной Институтом SEI.
Способы определения измерений, согласно уровням модели СММ, отображены
в табл. 21.2.
Таблица 21.2. Метрические показатели также имеют место на ВСЕХ уровнях
зрелости модели SEI СММ
Модель SEI СММ
Уровень 1 Уровень 2
Уровень 3
Уровень 4
Уровень 5
СГюр
данных II ИХ
.шалнз
Планирование и Данные собраны
управление дан- и применяются
ними,
используемыми
отдельными проектами
во всех
определенных
процессах
Данные
систематически
используются совместно
в различных
проектах
Определение и сбор Данные использу-
данных
стандартизированы во всей
организации
ются для
оценивания и выделения

усовершенствований в процессе
Данные
используются для
представления
количественных данных
процесса и его
стабилизации
Метрические показатели также включены в модель СММ, поскольку каждая
ключевая область процесса на любом уровне зрелости содержит компонент
измерения и анализа. Термины измерение и анализ описывают основные практики
изменения, которые необходимы для уточнения состояния, имеющего отношение к
процессу. Подобные измерения применяются с целью управления и
совершенствования данного процесса.
I h\ рис. 21.4 показан пример измерения и анализа для уровня 2 ("повторяемый"), а
также ключевая область процесса, описывающая управление требованиями к ПО.
Кроме того, приведены примеры выполненных измерений.
Метрические показатели также появляются непосредственно в виде действий в
пределах области КРА, соответствующей процессу разработки программного
продукта, а также в виде отдельной области КРА на уровне 4 ("Количественный менеджмент
процесса"). Краткий обзор целей применения определенных метрических
показателей и действий помогает устанавливать стадию формирования остальных наших
предположений, представленных в данной главе.

Метрические показатели, применяемые при оценке размера... 705
Модель SEIСММ, уровень 2: повторяемый
Ключевая область процесса разработки
Управление программными требованиями
Измерения и анализ
Измерения выполняются и применяются с целью определения состояния действий,
предпринимаемых с целью управления распределенными требованиями.
Примеры измерений включают следующее:
• состояние каждого из сформулированных требований;
• действия по изменению сформулированных требований;
• накапливающийся итог по количеству изменений сформулированных требований,
включая общее число требований, предложенных, открытых, одобренных
и включенных в базовую системную линию.
Рис. 21.4. Каждая область КРА на любом уровне модели £Е/ СММ
включает компонент, применяемый в целях измерения и анализа
Второй уровень модели SEI СММ —
повторяемый
Ключевая область процесса — управление
программными требованиями
Измерения выполняются и применяются с целью уточнения состояния различных
форм деятельности по управлению распределенными требованиями.
В качестве примеров можно привести следующие измерения:
■ состояние каждого из распределенных требований;
■ изменение действия для распределенных требований;
■ общее количество изменений, внесенных в распределенные требования, включая
общее число предложенных изменений (открытых, одобренных и включенных в
базовую линию развития системы).
Ключевая область процесса: планирование
программного проекта
Измерения производятся и применяются с целью уточнения состояния различных
форм действий по планированию.
Примеры подобных измерений:
■ завершение основополагающих стадий для различных действий по планированию
программного проекта;
■ завершение работы, формирование трудозатрат, распределение средств по видам
действий, связанным с планированием программного проекта.

706 Глава 21
Ключевая область процесса: отслеживание
и реализация контроля за выполнением
программного проекта
Измерения производятся и применяются с целью определения состояния в
процессе деятельности по отслеживанию и реализации контроля за выполнением
программного проекта.
Примеры измерений:
■ понесенные трудозатраты, использование других ресурсов при выполнении
отслеживания и контроля;
■ изменение формы деятельности при планировании проектирования программ,
включая изменения в оценки размеров разрабатываемых программных продуктов,
оценки стоимости программных работ, оценки критического объема
вычислительных ресурсов и графика.
Третий уровень модели SEI СММ —
определенный
Ключевая область процесса — программа обучения
Измерения производятся и применяются с целью определения состояния
различных форм деятельности но реализации программы обучения.
Примеры измерений:
■ реальная посещаемость каждого курса обучения в сравнении с планируемой
посещаемостью;
■ прогресс, достигнутый благодаря курсам обучения по сравнению с учебными
планами, составленными для организации и проекта;
■ количество сбоев при обучении, превышающих допустимый уровень.
Измерения производятся и применяются для определения качества учебной
программы.
Примеры измерений:
■ результаты тестирования, проведенного после обучения;
■ обзоры курсов на основе студенческих опросов;
■ поддержка обратной связи с программными менеджерами.
Ключевая область процесса — программный
инжиниринг
Цель 1. Задачи программного инжиниринга определяются, интегрируются и
постоянно выполняются при разработке ПО.
Действие 9. Данные о дефектах, отмеченных в ходе обзора, и результаты
тестирования собираются и анализируются в соответствии с программным процессом,
определенным для проекта.

Метрические показатели, применяемые при оценке размера... 707
Измерения производятся и применяются с целью определения функциональных
возможностей и качества программных продуктов.
Примеры измерений:
■ количество, типы и серьезность дефектов, идентифицированных в программных
продуктах, причем отслеживание может выполняться на кумулятивной основе или
поэтапно;
■ сводятся распределенные требования с применением категорий (например,
безопасность, системная конфигурация, выполнение и надежность) и с учетом
требований к ПО и системных тестовых испытаний.
Измерения производятся и применяются для определения состояния различных
форм деятельности при разработке программного продукта.
Примеры измерений:
■ состояние каждого распределенного требования на протяжении осуществления
проекта;
■ отчеты относительно имеющихся проблем с указанием на степень их важности и
затрат времени;
■ изменения деятельности для распределенных требований;
■ трудозатраты, предпринимаемые для анализа предложенных изменений для
каждого рассматриваемого изменения и кумулятивная оценка по всем изменениям;
■ объем изменений, внесенных в базовую линию ПО по категориям (например,
интерфейс, безопасность, системная конфигурация, выполнение и практичность);
■ объем затрат и преобразований при реализации и тестировании внесенных
изменений, включая начальную оценку и действительное соотношение объем/затраты.
Четвертый уровень модели SEI СММ —
управляемый
Количественный менеджмент процессов (Quantitative process management, QPM)
является областью ключевого процесса для четвертого уровня 4 модели SEI СММ
("Управляемый"— рис. 21.4). Он включает определение целей, выполняемых
программным процессом в рамках данного проекта (описывается в интегрированной
ключевой области процесса программного менеджмента), выполнение измерений
производительности процесса, анализ этих измерений, а также настройку и
функционирование процесса в рамках допустимых ограничений. Если при выполнении
процесса произойдет его стабилизация в пределах допустимых ограничений,
определенный проектом программный процесс, ассоциированные с ним измерения и
допустимые ограничения для измерений устанавливаются и применяются в
качестве основной базы для осуществления количественного контроля выполняемого
процесса.
Что касается действий 4 и 7, рассматриваются две разновидности действий,
которые особенно тесно связаны с вопросами, обсуждаемыми в настоящей главе.
Суть действия 4, QPM, заключается в следующем: Данные измерений, которые
применяются для количественного контроля, определенного проектом
программного процесса, собираются в соответствии с процедурой, отраженной в документах.

708 Глава 21
Модель SEIСММ, уровень 4: управляемый
Ключевая область процесса разработки
Количественное управление процессами
Цель 1: Запланированы действия в рамках количественного управления процессами.
Цель 2: Выполнение определенного программного процесса проекта контролируется
количественным образом.
Цель 3: Возможности стандартного программного процесса организации выражаются
в количественных терминах.
Действие 1: План программного проекта для количественного менеджмента процессов
разрабатывается в соответствии с документированной процедурой.
Действие 2: Действия в ходе количественного управления процессами программных проектов
выполняются в соответствии с количественным планом менеджмента процессов.
Действие 3: Стратегия сбора данных и количественные анализы выполняются определяются
на основе заданного программного процесса проекта.
Действие 4: Данные измерений, применяемые для контроля определенного
программного процесса проекта, собираются количественным образом
в соответствии с документированной процедурой.
Действие 5: Определенный программный процесс проекта анализируется
и подвергается количественного контролю в соответствии
с описанной процедурой.
Действие 6: В отчетах, документирующих результаты количественных процессов программных
проектов, подготавливаются и распространяются действия по управлению.
Действие 7: Достигается и поддерживается в соответствии с описанной процедурой
базовая линия,описывающая возможности стандартного программного процесса,
осуществляемого в организации.
Рис 21.5. Четвертый уровень модели SEI СММ, "управляемый", область KPAQPM
Примеры измерений для данных:
■ оценочные/плановые данные по сравнению с реальными данными о размере и
стоимости программ, а также связанные с графиком;
■ сведения о производительности;
■ измерения качественных показателей в соответствии с планом;
■ охват и эффективность экспертных оценок;
■ эффективность обучения;
■ тестовое покрытие и эффективность;
■ меры по обеспечению надежности программ;
■ количество и серьезность недостатков, обнаруженных в требованиях к ПО;
■ количество и серьезность дефектов, обнаруженных в программном коде;
■ количество и степень приближенности к элементам выполняемых действий.
Действие 7, QPM, заключается в следующем: основные направления,
определяющие возможности стандартного для организации процесса, устанавливаются и
поддерживаются в соответствии с процедурой, которая отражена в документах.
Примеры тенденций, определяющих возможности ПО:
■ прогнозирование появления программных дефектов и сравнение прогнозов с
реальными данными;

Метрические показатели, применяемые при оценке размера... 709
■ прогнозирование распределений дефектов и их характеристик, если речь идет о
дефектах, оставшихся в продукте. В качестве основы применяются данные
экспертных оценок и/или тестирования.
Метрические показатели играют важную роль в интегрированной модели
зрелости возможностей (Capability Maturity Model Integrated, CMMI). В этой модели на
второй уровень зрелости добавляется область КРА, измерение и анализ. Краткий
обзор подобной области КРА приводится в главе 26.
Полезные метрические показатели
Необходимость сбора метрических показателей обусловлена вовсе не тем, что они
получили широкое распространение в литературе или активно применяются в
некоторых фирмах, а тем, что они действительно полезны в процессе принятия решения
по поводу определенного проекта или в пределах данной организации.
Полезный метрический показатель точно определен (т.е. измерим или же имеет
количественные характеристики). Характеристики типа "всегда", "комплексно",
"эффективно" или "дружественно по отношению к пользователю" невозможно
употребить без дополнительных определений. Полезность метрического показателя не
зависит от осознанных влияний персонала, занятого в проекте. Эффект Хауторна
(Hawthorne) представляет очевидный факт, что проведение измерений само по себе
благоприятно влияет на качество продукта.
При обращении к полезному метрическому показателю ведется необходимый
учет. Необработанные метрические и контрольные данные (результаты наблюдений,
идентификация наблюдателя и т.д.) следует сохранять вместе со сведениями по
аудиту процесса метрического анализа. Затем могут реконструироваться заключения на
основе исходных данных, особенно если требуется их дальнейшая защита или
интерпретация. Кроме того, сохраненные необработанные данные позволяют выполнять
повторный анализ с учетом новых теоретических построений.
Полезный метрический показатель является точным, с определенными допусками
либо утвержденной логикой, либо ему присущ метод сбора информации (например,
индекса удовлетворенности). Также метрический показатель позволяет определить,
достигает ли организация целей, поставленных при разработке ПО .
Полезные метрические показатели также являются практичными:
ш простыми и легкими для представления;
■ недорогими;
■ понятными;
■ последовательными и применяемыми на протяжении всего периода работы;
■ удобными для сбора данных;
■ легко доступными в интерактивном режиме для всех заинтересованных
пользователей.
Полезные метрические показатели применяются наравне с данными, которые
корректны (собраны в соответствии с правилами определения данного показателя),
они являются точными, четкими и непротиворечивыми (отсутствуют серьезные
отличия для отображаемых величин даже в том случае, если заменяется измерительное
См. сноску 6.

710 Глава 21
устройство или специалист, производящий измерения). Большая часть данных
ассоциируется с определенным действием или периодом времени. Они должны
содержать аннотации и указания даты-времени с целью ознакомления всех желающих о
точном месте и времени их сбора. Процедура измерения должна быть четко описана
с тем, чтобы любой исполнитель мог повторно выполнить необходимые измерения.
Парадигма Бейзили —
цель/вопрос/метрический показатель
Парадигма д-ра Виктора Бейзили (Dr. Victor Basili) "цель, вопрос, метрический
показатель" ("Goal, Question, Metric", GQM) является широко применяемым и хорошо
зарекомендовавшим себя подходом к определению метрического показателя, который
является наиболее подходящим для контроля над проектом и формирования решения.
Подход с применением GQM предполагает, что цель устанавливается еще до подбора
метрического показателя. Именно на сеансах "мозгового штурма" достигается
консенсус участников команды разработчиков проекта по поводу определения целей проекта.
Конечно, организационные цели могут устанавливаться высшим звеном менеджмента
либо кругом заинтересованных лиц в пределах организации. Д-р Бейзили играл
ведущую роль при основании Лаборатории программного инжиниринга (Software
Engineering Laboratory, SEL), консорциума, созданного с участием кафедры информатики при
университете штата Мэриленд (Computer Science Department of the University of
Maryland), секции по программному инжинирингу из отдела динамики полетов им. Годдарда
в NASA (Software Engineering Branch of NASA's Goddard's Flight Dynamic Division) и
управления по программному инжинирингу корпорации в области компьютерных наук
(Software Engineering Operation of Computer Sciences Corporation). В результате
деятельности лаборатории SEL была разработана методика, в основе которой лежит процесс,
состоящий из семи этапов. Благодаря этому появилась возможность систематического
применения измерений при разработке ПО. На рис. 21.6, представлены следующие этапы:
определение набора целей; разработка вопросов, характеризующих эти цели;
определение метрических показателей, необходимых для получения ответов на вопросы;
формирование механизмов, предназначенных для сбора и анализа данных; сбор, подтверждение
и анализ данных, выполнение корректирующих действий; постпроектный анализ и
продвижение вперед; поддержка обратной связи с заинтересованными лицами. Первые три
этапа имеют критическое значение для работы в рамках парадигмы GQM.
Этап 1. Определение набора целей. Формирование набора корпоративных целей,
относящихся к работе подразделения, или проектных целей, связанных с разработкой,
сопровождением, повышением производительности и качественных показателей
продукта или процесса (например, удовлетворение запросов заказчиков, своевременная
поставка, улучшение качества, создание повторно используемых объектов, заново
применяемые опытные наработки). Часто выполняется определение целей при решении
проблем методом "мозгового штурма", а также в процессе получения требований от
каждого из заинтересованных лиц. Затем можно располагать эти цели с учетом
приоритетов, а также группировать их по областям усовершенствований ПО.
Этап 2. Формирование набора вопросов, применяемых для характеристики
целей. Каждая цель позволяет сформулировать вопрос, ответ на который
определяет, будет ли эта цель достигнута. Эти вопросы характеризуют цели, обеспечивают
оценку прогресса в их достижении, прогнозируют момент достижения или являются
мотивацией для оценки продвижения к цели.

Метрические показатели, применяемые при оценке размера... 711
Рис. 21.6. Семиэтапный процесс Бейзили — цель/вопрос/метрический показатель
Этап 3. Определение метрических показателей, необходимых для ответа на
вопросы. Определим, что необходимо измерить для получения адекватного ответа
на поставленные вопросы.
Далее каждый из семи этапов GQM описывается более подробно.
Этап 1: GQM — определение набора целей
Чтобы определять цели, вопросы и метрические показатели, Бейзили (Basili) и
Ромбах (Rombach) разработали шаблон, применяемый для записи цели,
перспективы и среды, который и определяет структуру цели . Соответствующий обзор
приводится в табл. 21.3.
Basili Victor R. и др. "Goal/Question/Metric Paradigm." Encyclopedia of Software Engineering, том
1. NY: John Wiley and Sons. cc. 528-532, A994).

712 Глава 21
Таблица 21.3. Целевой формат в парадигме GQM
Анализ (что именно) Объект, который измеряется, процесс, продукт,
модель, метрический показатель и т.д.
Цель С какой целью (зачем) Характеристика, оценивание, прогнозирование,
мотивация, совершенствование, представление,
оценивание, управление, исследование, изучение или контроль
По отношению к чему Концентрация на качестве объекта (на что сфокусиро-
(фокус) вано измерение) — объем затрат, эффективность,
корректность, устранение дефектов, изменения,
измерения продукта, надежность, дружественность по
отношению к пользователю и т.д.
Перспекти Перспективы (каков ас- Пользователи, проводящие измерения на объекте —
ва пект и кто исполнитель) разработчики ПО, ведущие менеджеры, заказчики,
менеджеры проекта, корпорация и т.д.
Среда Контекст Среда, где выполняются измерения — факторы ресур-
(характеристики) сов, факторы процесса, "человеческие" факторы,
проблемы, методы, инструменты, ограничения и т.д.
Цель— характеристика, оценивание, прогнозирование, мотивирование и т.д.
процесса, продукта, модели, метрического показателя и т.д., чтобы его (ее)
представить, оценить, проконтролировать, исследовать, изучить, усовершенствовать и т.д.
■ Представление или характеристика предполагает формирование модели объекта, в
которой удобно представить собранные данные.
■ Оценивание подразумевает наличие шаблона для данных, который позволяет
разрабатывать постоянную модель, основанную на доступных (или корректно
оцениваемых) факторах.
■ Мотивация или совершенствование предполагает наличие точной модели,
позволяющей правильно представить объект или позитивное качество.
Пример: оценивание процесса сопровождения с целью его улучшения.
Перспектива— проверка объема затрат, эффективности, корректности, наличия
дефектов, изменений, измерений продукта и т.д. с точки зрения разработчика,
менеджера, заказчика и т.д.
■ Всегда важно учесть такие аспекты, как доступность информации, уровень ее
"дробления" и точность.
Пример: проверьте объем затрат с точки зрения менеджера.
Среда — определяет контекст, в котором проходит изучение. Благодаря этому
облегчается классификация текущего проекта с учетом большого разнообразия
характеристик, а также выделение подходящей среды для этого проекта. Обеспечивается
обнаружение класса проектов, имеющих аналогичные характеристики и цели, чтобы
использовать их для сравнения. Среда включает процесс, персонал, проблемные
факторы, методы, инструменты и ограничения.
■ "Человеческие" факторы— количество пользователей, уровень экспертизы
программного инжиниринга, вопросы организации групп, опыт в предметной области
разработки приложений, опыт выполнения процесса и экспертиза инструментария.

Метрические показатели, применяемые при оценке размера... 713
■ Факторы процесса— выбор модели жизненного цикла для проектирования,
методов, методик, инструментов и языков программирования.
■ Факторы продукта— внутренние поставки, размер системы и требуемый уровень
качества (например, надежность, переносимость).
■ Факторы ресурса основаны на аналогиях в целевых механизмах и механизмах
проектирования, календарном времени, объемах бюджетных средств и
существующего ПО, доступного для повторного использования.
Пример: программисты-разработчики верят в то, что производительность их
труда ограничена из-за недостатка требуемого инструментария.
Примером полностью сформированной цели служит следующая формулировка.
Проанализируйте и оцените с точки зрения команды разработчиков проекта
поставленный продукт с учетом сложности интерфейса и в контексте объектно-
ориентированной разработки, которая применяется в проекте ABC.
Цели также следует подвергать измерениям и руководствоваться моделями,
принятыми в бизнесе. Кроме парадигмы GQM, для уточнения измеримых целей служат и
другие механизмы, например, функция развертывания качества (quality function
deployment, QFD) и методика с применением метрических показателей,
используемых для измерения качества ПО (software quality metrics, SQM).
Как описывается в GQM, цели определяются для каждого объекта, для разных
условий, в соответствии с различными моделями качества, с применением разных
точек зрения и с учетом определенных характеристик среды.
Стратегические цели
Стратегические г^ели обычно устанавливаются в процессе управления. К ним
относятся: поддержка основных направлений во время проведения измерений,
обеспечение скоростной связи, предоставление возможности "взгляда изнутри" на процесс
разработки, а также формирование на исторической базе плана будущих проектов.
Примером метрического показателя, который используется для определения
продвижения по направлению к стратегической цели, является уровень зрелости модели
SEI СММ (или СММ).
Тактические цели
Типичными тактическими целями команды разработчиков и организаций по
созданию ПО являются: минимизация усилий по реализации программного
инжиниринга и формированию расписания, сокращение объема затрат, максимальное
удовлетворение запросов заказчиков, минимизация возможности появления дефектов, а
также управление качественными показателями и проведение тестирования.
Ниже приводятся примеры метрических показателей для определения прогресса
в продвижении к тактической цели при минимизации дефектов и управлении
качеством тестирования:
■ среднее время фиксации служебного запроса;
■ суммарный объем обнаруженных дефектов;
■ анализ дефектов с помощью кодированного модуля;
■ время фиксации дефектов, соотношение оценочного и реального времени;
■ идентифицированные дефекты/дефекты, остающиеся открытыми;
■ распределение источников дефектов;

714 Глава 21
■ среднее время между появлениями дефектов;
■ шаблон, имеющий цикломатическую сложность;
■ состояние проекта, учитывающий наличие дефектов.
Как тактические, так и стратегические цели можно отобразить на графе в виде
линии "протяженной цели", где отображается достигнутый количественный уровень.
Прогресс по направлению к этой цели затем изображается графически на том же
самом чертеже, как показано в примере на рис. 21.7.
Оценка достигаемой точности (оценка/фактическое значение)
1.00
0.90
0.80
0.70
0.60
0.50
,''
1999
"Ра
..^
^
2000
:тяжение" i
^
''
Знш
-Л.
2001
/~N
дели f
'''
ениебазо
\
J
2002
,+
.-'
юй линии
2003
*'
2004
Рис. 21.7. Пример "протяженной" цели
После установки целей процесс GQM смещается в сторону определения способов
измерения прогресса, характеризующего продвижение к цели.
Этап 2: GQM — определение набора вопросов,
характеризующих цели
Цели определены на абстрактном уровне, а вопросы предназначены для
освещения уровня выполняемых операций. Отвечая на вопросы, необходимо уточнять,
достигнута ли поставленная цель.
Например, если цель процесса формулируется следующим образом:
"совершенствовать способность к реагированию на проблемы заказчиков, сокращая циклическое
время, предназначенное для анализа и коррекции этих проблем", то могут возникнуть
следующие вопросы.
■ Отражен ли в документах процесс, позволяющий устранить проблемы?
■ Производились ли в процессе устранения обзоры и выполнялось ли
тестирование?
■ Точны ли оценки, используемые при устранении проблемы?
■ Применяется ли механизм по изменению формы контроля, с которым знакомы
Fice разработчики?
■ Какова фактическая продолжительность процесса обнаружения проблемы?
■ Какова фактическая продолжительность процесса устранения проблемы?

Метрические показатели, применяемые при оценке размера... 715
■ Каков в среднем объем трудозатрат, понесенных на этапе обнаружения и
устранения проблемы?
■ Каково процентное соотношение устраненных проблем заказчиков, которые
потребовали дополнительной переработки?
Если эти цели способствуют появлению усовершенствованных версий продукта.
Например, цель "упростить сложную программную систему" может способствовать
появлению следующих вопросов.
■ Количество имеющихся программных модулей?
■ Какова степень соединения модулей?
■ Каково среднее значение меры цикломатической сложности Мак Кейба (McCabe)?
■ Сколько времени занимает разработка модуля?
■ Оценивались ли возможности каждого модуля?
■ Каково количество ошибок, обнаруженных в каждом модуле?
■ Каков размер каждого модуля?
■ Связаны ли между собой модули?
■ Приме*шлась ли абстракт* 1ая программа при документировании модулей?
■ Можно ли проследить реализацию требований в модулях?
В процессе управления могут возникнуть и следующие принципиальные вопросы.
■ Можно ли выполнить это действие?
■ Сколько времени займет этот процесс?
■ Каков объем затрат?
■ Сколько сотрудников следует привлечь к работе?
■ Какова степень риска?
■ Каковы возможные компромиссы?
■ Сколько ошибок может возникнуть?
■ Можно ли измерить степень улучшения процесса?
После уточнения спектра вопросов, которые позволят уточнить продвижение к
намеченным целям, на следующем этапе процесса GQM определяются метрические
показатели, применяемые для ответа на эти вопросы.
Этап 3: GQM — определение метрических показателей,
необходимых для получения ответа на вопросы
Этап 3 парадигмы GQM предназначен для определения метрик, необходимых
для получения ответа на поставленные вопросы, а также для отслеживания
согласования процесса и продукта поставленным целям. Обычно метрические показатели,
необходимые для получения ответа на вопрос, можно легко получить,
воспользовавшись ключевыми словами, содержащимися в вопросе. Фраза "усредненные
приложенные усилия?" появляется в вопросе: "Каковы усредненные усилия,
необходимые для устранения проблем, указанных в отчетах заказчиков?" и приводит к
использованию очевидного метрического показателя, применяемого для оценки
трудозатрат. А именно: трудозатраты, выраженные в рабочих неделях/месяцах, а

716 Глава 21
также количество отчетов о проблемах заказчиков, которые были закрыты в
недельный/месячный период.
Ниже рассматривается еще один пример.
Цель: охарактеризовать заключительный продукт с учетом классов дефектов.
Один из возможных вопросов: "Каково распределение ошибок в классе в пределах
фазы уточнения дефектов?"
В этом случае применяется следующий метрический показатель: ошибки
требований — количество и классификация.
Пример был взят из работ Ван Солингена (van Solingen) и Бергаута (Berghout),
причем он является обобщением и упрощением конкретного социологического ис-
следования .
Цель: проанализировать поставленный продукт относительно четкости
представления, с учетом эффективности повторного использования, а также с точки зрения
членов команды разработчиков ПО в контексте проекта А.
Вопросы и соответствующие метрические показатели: каково процентное
соотношение модулей, которые не создаются изначально, например, некоторые
используется заново целиком или в виде отдельных подсистем?
Метрический показатель 1. Для каждого программного модуля: разработан ли с
самого начала (да, нет)?
Метрический показатель 2. Для каждого программного модуля: назвать
подсистему, к которой он имеет отношение.
Каково процентное соотношение повторно и полностью используемого кода
(завершенной системы или по подсистемам))?
Метрический показатель 1. Для каждого программного модуля: применяется ли
повторно код (да, нет)?
Метрический показатель 2. Для каждого программного модуля: назвать
подсистему, к которой он принадлежит?
Для программных модулей, где код применяется повторно: каково распределение
модулей при повторном использовании классов модификации (полностью или по
подсистемам)?
Метрический показатель 1. Степень изменения кода (неизменный;
приблизительный, удаленный; если изменено менее 20% строк; если изменено более 20% строк).
Метрический показатель 2. Название и версия для исходного модуля,
применяемого повторно.
Метрический показатель 3. Название и версия для модуля из версии,
применяемого повторно.
Метрический показатель 4. Название подсистемы, к которой принадлежит модуль.
Какова взаимосвязь между повторно используемым модулем и достигаемой
степенью надежности?
Метрический показатель 1. Для всех модулей: каков уровень повторного
использования?
Метрический показатель 2. Для модулей, имеющих наибольшее количество сбоев:
каков уровень повторного использования?
Метрический показатель 3. Для модулей без ошибок: каков уровень повторного
использования?
Van Solingen Rini and Egon Berghout. The Goal/Question/Metric Method: A Practical Guide for
Quality Imfrrovement of Software Development. NY: McGraw-Hill,1999.

Метрические показатели, применяемые при оценке размера... 717
Метрический показатель 4. Для всех модулей: какова плотность проявления
недостатков?
Метрический показатель 5. Для повторно используемых модулей: какова
плотность проявления недостатков?
Метрический показатель 6. Для неиспользуемых модулей: какова плотность
неточностей?
После сбора данных в модули с определенной степенью повторного их
использования, можно сделать следующие выводы.
■ Повторное использование больших частей модуля, результаты которых уже
зафиксированы, приводит к более низкой плотности ошибок, чем изначальный
процесс разработки модулей.
■ Наличие ошибок в повторно используемых модулях лучше проверять еще до их
поставки, поскольку эти модули изучаются и тестируются более интенсивно, чем
заново разрабатываемые модули.
Метрические показатели обеспечивают всю количественную информацию,
требуемую для получения удовлетворительных ответов на вопросы.
С помощью одного лишь метрического показателя можно получить ответы на
несколько вопросов. Например, метрический показатель "Возраст
рассматриваемых проблем" позволяет получать ответ на вопрос: "Достаточно ли собрано
ресурсов для разрешения проблемы?", а также: "Сколько времени проблемы остаются
нерешенными?"
Для ответа на один вопрос может потребоваться несколько метрических
показателей. Например, оба показателя "Возраст рассматриваемых проблем" и "Возраст
разрешенных проблем" следует использовать для ответа на вопрос: "Каким образом
определить ответную реакцию на запросы заказчиков?"
После определения целей, вопросов и метрик в организации или проектной среде
следует определить механизмы для сбора реальных метрических данных.
Этап 4: GQM — разработка механизмов сбора данных
Важно постоянно держать цель в фокусе внимания. Сбор данных, которые не
относятся к целевым измерениям, не приносит пользы. В идеале собранные данные
размещаются в хранилище организации и используются при работе с рядом проектов.
■ Кто ведет сбор метрических показателей? Сбором ведает тот, кто "ближе"
находится к данным. Например, трудозатраты персонала по разработке наиболее
эффективны у отдельных членов коллектива— аналитиков, дизайнеров и
программистов. Будучи наиболее информированными и занимая удобную позицию,
обеспечивающую поддержку точных данных, разработчики не относятся к категории
людей, составляющих отчеты о проведенных измерениях. Именно благодаря
этому обстоятельству они занимают объективную позицию.
■ Когда следует выполнять сбор данных? Все зависит от того, какие данные
необходимо собирать, и как они будут использоваться. Однако установка "чем раньше и
чем больше" не столь уж плоха. Если и желательно вести сбор данных "по
настроению", то лучше делать это ежедневно, а реально — раз в неделю. График
сбора данных, предусматривающий ежемесячную деятельность, является довольно
редким событием, поскольку зачастую сложно вспомнить о том, какой период
времени эти данные характеризуют.

718 Глава 21
■ Каким образом организовать сбор данных наиболее точно и эффективно?
Лучше всего воспользоваться автоматизированными инструментами.
Механизмы по сбору данных должны быть удобными в работе. Применение
методов сбора данных с использованием возможностей Web тяготеет к
современной объектной/реляционной базе данных. Такой способ более привлекателен
для современной дистрибьюторской организации и команды разработчиков
проекта. Гибкие системы позволяют вносить коррективы с помощью метода
обратной связи.
■ Кто же непосредственно работает с метрическими показателями? Все
зависит от "точки зрения" или от перспективы, описанной в целевом утверждении.
Однако не столь важно, кто получает отчеты. Тот, кто вводит данные, должен
знать, каким образом они интерпретируются и кому следует с ними
ознакомиться. С другой стороны, необходимо гарантированно работать только с точными
данными.
Сбор метрических данных не должен увязываться с деловой стороной ПО. Этот
процесс должен быть удобным и простым. Если сбор данных и аналитический
процесс имеют целевую направленность, автоматизированы и интегрированы в
программный процесс, инвестиции будут успешными. Как упоминалось ранее,
необходимо проявлять заботу о том, чтобы процесс измерения не вносил искажения в
данные. Необходимо также учитывать возможности Эффекта Хауторна, описанные
в глоссарии.
Этап 5: GQM — сбор, подтверждение и анализ данных
в реальном времени для поддержки обратной связи
между корректирующими действиями и проектами
Ведение записей вручную обычно служит причиной искажений, ошибок,
пропусков и задержек. Поэтому там, где это возможно, следует обращаться к
автоматизированному сбору данных. При планировании сбора данных вовлекаются метрические
показатели программы:
■ не усложняйте процедуру;
■ избегайте ненужных записей;
■ обучайте персонал вести записи в тех процедурах, которые используются;
■ выполняйте поддержку результатов, используйте форму поддержки, удобную для
участников;
■ подтверждайте все данные, собранные в центральной точке сбора информации.
Процесс анализа может принимать разнообразные формы, а также может
применяться большое число инструментов для отчетности.
Графическое представление метрических данных практически всегда облегчает
представление аналитических результатов. Обычно используются следующие
графические представления: контрольные графики, гистограммы, диаграммы Ишикава
(Ishikawa), диаграммы Парето (Pareto) и рассеянные диаграммы.
Пример диаграммы Ишикава (причина и следствие, в виде "елочки") показан на
рис. 21.8.

Метрические показатели, применяемые при оценке размера... 719
Слишком занят
для выполнения
этой операции
Невозможно
прочесть документ
\ Отсутствует
хорошая модель
Вопросы,
связанные
с интерфейсом
пользователя
Рис. 21.8. Этап 5: сбор, подтверждение и анализ данных; пример диаграммы Ишикава
Комбинирование в одном месте цели, вопроса, метрических показателей и
графического анализа (на одной "странице") является универсальным описательным
методом для представления метрических показателей заинтересованным лицам.
Предположим, что Главная электрическая компания использует следующий набор вопросов
и метрических показателей при отслеживании прогресса, направленного на
достижение одной из целей, — усовершенствование ПО.
Цель — улучшить обслуживание заказчиков
Вопрос 1. Какое количество новых проблем возникло в течение этого месяца?
Метрический показатель 1. Новые проблемы (New Open Problems, NOP) = общее
количество открытых проблем в версии в течение месяца после выпуска.
Вопрос 2. Какое количество актуальных проблем возникло на конец месяца?
Метрический показатель 2. Общее количество новых проблем (Total Open
Problems, TOP) = общее количество новых проблем в версии после выпуска, которые
остались нерешенных на конец месяца.
Вопрос 3. Каков "средний возраст" проблем, актуальных на конец месяца проблем?
Метрический показатель 3: Средний возраст актуальных проблем (Mean Age of
Open Problems, AOP) = общее время наличия проблем в версии после выпуска,
которые остались нерешенными на конец месяца/количество проблем в версии после
выпуска, которые остались нерешенными на конец месяца).
Вопрос 4. Каков "средний возраст" проблем, которые были решены в течение
месяца?
Метрический показатель 4. Средний возраст решенных проблем (Mean Age of
Closed Problems, ACP) = Общее время существования проблем в версии после выпус-

720 Глава 21
ка, решенных в течение того месяца, когда их обнаружили)/количество актуальных
проблем в версии после выпуска, решенных в течение этого месяца)
Цель, вопрос 3, метрический показатель 3, вопрос 4, метрический показатель 4 и
пример графического изображения результатов анализа показаны на рис. 21.9.
Цель: улучшение обслуживания заказчиков
Вопрос:
Что означает "возраст открытых проблем" на конец месяца?
Метрический показатель:
"Возраст открытых проблем" = общее время существования проблем,
появившихся после выпуска программы, на конец месяца / количество этих же проблем,
которые все еще остаются на конец месяца
Вопрос:
Что означает "возраст проблем", которые были закрыты в течении месяца?
Метрический показатель:
"Возраст закрытых проблем" = общее количество проблем, появившихся после выпуска программы,
и закрытых в течении месяца / количество проблем, закрытых в течение месяца
400
количество дней,
потраченных
на устранение 300
проблемы
200
ВЗП •
количество дней,
потраченных 1 оо
на устранение проблемы
0
Я
Средний возраст открытых пр
В0П: Что означает "сре
ВЗП: Что означает сре;
-•1
и--'
h—
i—
i—{
|«~~Н
1—
_^
►-......
t
1
нв Фев Map Апр Май Июн Июл Авг Сен Окт Ноя Дек
облем (В0П) и средний возраст закрытых проблем (ВЗП)
дний возраст открытых проблем на конец месяца?
1ний возраст проблем, закрытых в течении месяце
Рис. 21.9. Пример расположения цели/вопроса/'метрического показателя и
аналитического графика на одной "странице"
'" Daskalantonakis Michael К. A Practical View of Software Measurement and Implementation
Experiences with Motorola. IEEE Transactions on Software Engineering, 18A1):998-1010, 1992.
Kan Stephen H. Metrics and Models in Software Quality Engineering. Reading, MA: Addison-
Wesley, 1995.

Метрические показатели, применяемые при оценке размера... 721
Этап 6: GQM — анализ данных с использованием
подпрограммы для оценки соответствия целям
и рекомендации для дальнейшего совершенствования
Необработанные метрические данные обычно весьма трудны для понимания.
Например, если получено регистрационное сообщение об ошибке, включающее 150
записей, где в "полях" отмечена дата, время, код ошибки, эти данные трудно
интерпретировать. Однако если в течение определенного периода времени ведется подсчет
количества появлений ошибки каждого типа, эти данные наполняются определенным
смыслом. Затем их можно использовать для принятия решения относительно того,
достигнута ли цель. На рис. 21.10 показано, каким образом можно пометить
ошибочный код, используя конкретное название, а подсчет ошибок каждого типа графически
представлен в виде гистограммы.
Тип проблемы
Рис. 21.10. Этап 6: GQM— пример получения опережающих данных с
помощью гистограммы
Этап 7: GQM — поддержка "обратной связи"
для организаторов проекта
Поддержка "обратной связи" — это очень важный шаг в процессе выполнения
измерений, но все же о нем часто забывают. Все организаторы проекты, а особенно
поставщики данных, должны иметь возможность просматривать результаты своей
работы. Зачем собирать данные, если вы не представляете, что с ними делать дальше,
или каким образом они могут повлиять на ход дальнейшей работы?

722 Глава 21
Например, если разработчики и тестеры располагают информацией о
плотности распределения дефектов в рассматриваемых модулях, они могут сделать
определенные выводы или, по крайней мере, обратиться к целому ряду вопросов.
Почему столь большое количество дефектов содержится в модуле 1? Не в том ли
причина, что эксперты являются новичками в данном виде работ и добросовестно
относятся к делу? А может быть программист недостаточно хорошо знаком с этим
языком или предметной областью приложения? На рис. 21.11 показан простой
граф, имитирующий действие, которое направлено на совершенствование
процесса. Однако если разработчики и тестеры, собирающие данные обзоров и тестовых
испытаний, не ознакомятся с полученными результатами, они не только упускают
возможность высказать свое мнение при обсуждении путей совершенствования
процесса, он и, возможно, не получат мотивацию для работы с точными данными.
Как уже упоминалось, универсальным способом представления "обратной связи"
является отображение, на одной "странице" цели, вопросов, метрических
показателен и графических результатов, как это показано на рис. 21.8. Другие примеры
графических отображений механизмов "обратной связи" показаны на серии
рисунков от 21.12 до 21.16.
Представления о плотности дефектов весьма полезны, поскольку позволяют
выделить модули, имеющие наибольшее количество дефектов, с целью дальнейшего
анализа. А чаще всего процесс анализа начинается с выяснения основной причины.
Не потому ли в модуле столь большое число дефектов, что он слишком сложен? А
может, разработчик имеет недостаточно большой опыт работы с данным языком
программирования или незнаком с предметной областью приложения? Не относятся ли
обнаруженные погрешности к ошибкам определенного типа (например, ошибкам на-
чального этапа проекта), которые присущи данному программисту? Если это так, не
t к-дует ли программисту посещать "начальную школу"? Если один из этих модулей
планируется повторно использовать в будущем, но плотность дефектов в нем высока,
не следует ли пересмотреть наши планы?
Если известно значение среднего времени, в течение которого должен быть
исправлен основной дефект, и на основе определенных исторических данных можно
пр< .кказать количество ожидаемых ошибок, можно обоснованно делать вывод об
объеме средств, необходимых для исправления этих ошибок. Если же
трудозатраты направленные на коррекцию основных дефектов, постоянно растут, а не
уменьшаются, как показано на рис. 21.12, значит, что-то делается неверно.
Возможно, из-за роста энтропии структуры возросла сложность, а необходимо сделать
компонент "более четким".
В среде тестирования ошибки обнаруживаются и фиксируются, "на скорую руку"
выполняются регрессионные тесты. Всякий раз, когда реализуется регрессионная
оболочка, можно ожидать появления "на поверхности" нескольких ошибок, как
показано на рис. 21.13. Если количество сбоев растет, а не уменьшается, значит, мы
заняты только частью проблемы, а не ее решением. Менеджер проекта может
приостановить тестирование и проанализировать данную тенденцию. Если же
количество сбоев сокращается, а остаются все менее важные ошибки, менеджер и заказчик
могут придти к соглашению о выпуске данного продукта. Подобная разновидность
анализа тенденций не ограничивается фазой тестирования. Как показано на
рис. 21.14, отслеживание ошибок может начаться даже раньше, чем появятся
первые статические обзоры проекта.

Метрические показатели, применяемые при оценке размера... 723
3
п
сть дефекте
го
иная плотно
фмализова
о
X
-1
1
1
1
Плотность дефектов для проверенных модулей
1
|
\J
в
—•—1
л
\
г
i
\
\
Vj
л
1
А
1
11
1
А
|
f
/
{
I
1
ы
L
~л
/
1 3 5 7 9 11 13 15 17 19 21 23 25
Количество модулей
Рис. 21.11. Этап 6: GQM— представление о плотности
дефектов можно использовать при планировании в будущем
Усредненное время, необходимое для устранения основного дефекта
S
S.
30
25
20
15
10
5
Map
Апр
Май
Июн
Июл
Авг
Рис. 21.12. Этап 7: GQM— среднее время, затрачиваемое на
коррекцию основного дефекта

724 Глава 21
Частота сбоев со временем
О 15 45 75 105 135 165 195 225 255 285 315 345 375
Общее время тестов (часы)
Рис. 21.13. Этап 7: GQM — изменение количества сбоев с течением
времени
Входящие дефекты __^_ Устраненные дефекты _ _ _ _
0U i I I I I I I I i__l l L__l I I U
2 4 6 8 10 12 14 16 18
Недели
Рис. 21.14. Этап 7: GQM— обнаружение дефектов и
их устранение с течением времени

Метрические показатели, применяемые при оценке размера... 725
а
45-
ш 40-
f 30-
е г°-
g 15-
1 10-
^ 5-
Тип проблемы
§
те
л
о
5
S
71
m
2
стандарт
X
Соответс
1
£
бработк
о
*-
нием и>
выделе
язанная с
о
эоблемг
а
S
^
X
СР
§
о
<=г
требован
*
X
днознач
о
огика
CZ
3
выходн
2
вую
!
л
jO
еправил
01
i
ера
Ъ
!
1
$
>5
заимоде
CQ
данных
и:
щ
иза
и инициал
?
еправил
^
ура
цед
про
рректная
а
ызвана не
m
входны
вую
е/отсутст
+
-О
еправил
i
Жизненно немного
Тривиально много
Рис. 21.15. Этап 7: GQM—диаграмма Парето, описывающая типы дефектов
Требования Разработка Кодирование Тестирование Интеграция Тест Использование
проекта
модуля
системы заказчиком
Рис. 21.16. Этап 7: GQM — фаза выявления дефектов

726 Глава 21
Диаграммы Парето, напоминающие график на рис. 21.15, помогают проектному
менеджеру уточнить источники ресурсов. Если справедливо часто слышимое
утверждение о том, что "80% проблем скрыто в 20% кода", тогда следует уточнить, о каких
именно 20% идет речь. Упорядоченная диаграмма Парето— прекрасный помощник в
принятии подобного решения. После того, как "жизненно важное" будет отделено от
"тривиального большинства", дальнейший анализ позволит выявить детали.
Если известно, где именно в жизненном цикле разработки ПО сосредоточены
дефекты, тогда особое внимание уделяется именно этой фазе. Возможно, именно здесь
будет производиться больший объем обзоров и проверок. Возможно, к заданию
подключится и старший аналитик. Результаты одного проекта могут рассматриваться как
аномалия, но если несколько проектов укажут на одну и ту же "сомнительную" фазу,
как показано на рис. 21.1G, менеджер проекта получит ясные указания, которые и
позволят обосновать решение.
В метрических программах предполагается наличие "неудачного" события, когда
применение метода, подобного GQM, должно быть отложено. Однако результаты
нескольких измерений и в этом случае по-прежнему надежны. В следующем разделе
опис мпаются основные метрические показатели (своего рода "стартовый набор").
Фактические
трудозатраты
Ошибки/дефекты
Рис. 21.17. Основные метрические
показатели имеют три источника
Начальный набор основных метрических
показателей
Самые совершенные измерительные программы всегда начинаются с установки
цели, как и в методе Бейзили G/Q/M. Однако существует несколько метрических
показателен, при использовании которых проектный менеджер может смело
приступать к сбору данных, даже если подходящая измерительная программа еще не
привлечена.
При управлении программными проектами отмечают три очень обширных
источника данных. Эти три базиса (рис. 21.17) взаимодействуют друг с другом, образуя
единое основание. Их можно использовать в качестве первого шага при
формировании практической системы метрических показателей. А именно: трудозатраты, поне-
< t иные в соответствии со структурой WBS, данные экспертной оценки и изменение
запрашиваемых данных.
Во-первых, управление требует наличия точного представления относительно
объемов трудозатрат в рамках проекта, а также относительно характеристик этих
понесенных, трудозатрат.

Метрические показатели, применяемые при оценке размера... 727
Во-вторых, управление требует точного представления о количестве и типе ошибок
н дефектов, обнаруженных в процессе обзора.
В-третьих, управление требует точного представления о запрашиваемых
изменениях, о том, изменяет ли запрос исходные требования системы или полученный
компонент проекта изменяется вследствие открывшегося дефекта.
Трудозатраты
О трудозатратах больше всего говорят в связи с ресурсами, затраченными в
процессе разработки ПО. Аппаратное обеспечение, телекоммуникации, программные
инструменты и другое ценное имущество, естественно, тоже не остается вне поля
зрения. Однако вышеперечисленные факторы редко оказывают серьезное влияние
на бюджет, затраченный на разработку ПО. Эти средства, используемые для
приобретения имущества, практически всегда направляются, в основном, на оплату труда
квалифицированных работников. При разработке программ, как правило, не
требуется дорогостоящее оборудование, отсутствует потребность в станках и складских
помещениях; затраты на создание ПО существенно зависят от "человеческого
фактора". В этом случае требуется составить представление о том, чем занят персонал
(наиболее "дорогостоящий" элемент во всей конструкции), выполняется ли
обработка ценной информации, касающейся разработки проекта, каков ход выполнения
проекта и каким образом выполняется распределение бюджета на оставшуюся часть
работ по проекту. Также следует совершенствовать этот процесс как для данного, так и
для будущих проектов, увеличить степень производительности персонала
разработчиков, а также составить прогноз о стоимости будущих проектов.
Данные, описывающие подобные трудозатраты, определяют, наряду с другими
элементами, и фазу распределения трудозатрат, которые применяются при оценках
будущих проектов. Можно вести беседы в индивидуальном порядке, обсуждая
моменты, значимые для производительности, такие как "количество часов (или дней),
необходимых для определения каждого объектного класса". Это значение может
определяться в виде интервала времени, необходимого в среднем для всеобъемлющего
создания всех служб и атрибутов объекта.
Сбор данных относительно понесенных трудозатрат представляет ценность не
только для оценки следующего подобного проекта; эти сведения помогают
проектным менеджерам в принятии многих решений. Например, если известно, каков
объем трудозатрат необходим для обнаружения и устранения дефектов, найденных в
установленной базе, эти сведения окажутся весьма полезными при уточнении вопроса о
том, не является ли база слишком сложной для дальнейшей обработки.
Достаточно ли точно учитывалось время, затраченное на обзоры? Ожидалась ли
деятельность по совершенствованию процесса? Если ожидалась, является ли она
заслугой персонала или весомой частью проекта? Использовалась ли объектно-
ориентированная кривая изучения, если проектная команда впервые применяет ОО-
методы? Достаточно ли достойно представлен процесс переработки?
Для реальной оценки точного объема затрат при создании ПО следует аккуратно
отслеживать объем "трудозатрат" для каждой задачи, выполняющейся в процессе
разработки и поддержки программ. И как отражено в документах, начиная с фазы
планирования проекта, для наилучшей идентификации смежных задач следует
сформировать структуру пооперационного перечня работ (work breakdown structure, WBS)
и связать трудозатраты с выполняемыми задачами или действиями.

728 Глава 21
Данные о трудозатратах: препятствия для сбора данных
Для многих технических работников сама идея определения времени,
требуемого для выполнения инжиниринга, выглядит нереальной. Чаще всего именно из-за
такого рода действий срываются дальнейшие планы. Сбор подобных данных
считается бесполезным занятием, поскольку они не отличаются большой точностью.
В недобросовестных "руках" эти данные могут превращаться в "орудие для битья"
тех работников, чей труд признан "непроизводительным". Излишне говорить, что
все это приводит к искажению данных, получаемых от технического персонала, что
позволяет скрывать истинное положение дел и представлять его в более
выигрышном виде. Также наблюдается "обратное" влияние неверных данных, когда они
(например, в том случае, если были указаны разработчиками, не видящими особой
ценности в такого рода информации) приводят к неадекватным решениям
(например, менеджеры, исходя из того, что персонал не загружен текущей работой,
обращаются к следующему проекту, указанному в графике). А это, в свою очередь,
приводит к еще худшему положению дел. Представление о реальных объемах
трудозатрат, направленных на решение каждой задачи, приходит довольно долго. Также
непросто формируется и представление, направленное на повышение точности
будущих оценок. Обычно рабочий день оценивается как эквивалент восьмичасовой
производительной работы (сверхурочное время не учитывается и не фиксируется),
поэтому в новых проектах исходят из этой нормы. Реальный уровень
производительности остается неизвестным; ожидается, что уровень производительности
верно отражается в отчетах, и что он будет соблюдаться.
Самым крупным заблуждением, не позволяющим добросовестно собирать
сведения о временных затратах, является уверенность в том, что данный вид
деятельности "нельзя назвать профессией". Многие организации имеют в штате
"вольных" служащих наряду с "несвободными". Это позволяет некоторым
работникам трудиться по свободному графику. Такой подход основан на том, что
профессионал получает фиксированную заработную плату за соответствие
занимаемой должности. Таким образом оказывается доверие и уважение тому, кто
занимает подобную должность. Организация оплачивает работу на периодичной
основе, а профессионал выполняет заданный объем работ. Несмотря на то, что
подобный подход реально применяется в некоторых исследовательских
организациях, он становится проблематичным в производственных структурах, которые
функционируют согласно рабочим графикам. Несоответствие сроков выпуска
программной продукции может негативно сказаться на маркетинговой политике,
сформировать убеждение о том, что маркетологи и продавцы нечестны,
менеджеры — необоснованно требовательны, а инженеры — некомпетентны или просто
ленивы. Известно, что в этой сфере деятельности, где технологические
инновации не имеют параллелей в истории, творческие таланты многообразны и лишь
на первый взгляд их можно отнести к категории "ленивых" сотрудников. Есть
достаточно много добросовестных менеджеров или работников, но зачастую
отсутствуют хорошие оценщики. А недостаток сведений о работе над аналогичными
проектами, которые позволили бы сформировать реальные оценки, все еще
метает производительной работе.

Метрические показатели, применяемые при оценке размера... 729
Данные, отражающие реальные трудозатраты, — показатель
успешности процесса сбора информации
Также большое значение имеет способ сбора данных, отражающих затраченные
усилия. Следует уделить внимание созданию мягкой и спокойной обстановки при
сборе этих данных. Синдром "А во что это выльется?" (What's In It For Me — WIIFM)
играет в этом случае очень важную роль. Зачем техническим работникам скрупулезно
отчитываться о своей деятельности, если, по их мнению, эта информация "уходит в
никуда"? Зачем составлять точные и честные отчеты, если именно эти отчеты могут
послужить обоснованием неэффективности их работы?
Осведомленность о принципах сбора данных, отражающих прилагаемые
трудозатраты, часто помогает менеджерам пополнить свои знания следующими аспектами:
■ представление о том, какие фазы потребуют наибольших трудозатрат (многие
удовлетворяются тем фактом, что основные трудозатраты прилагаются отнюдь не
на фазе кодирования);
■ представление об объемах времени, затрачиваемого на решение интегральных
задач или задач по сопровождению, например, типа менеджмента конфигурации
или составления обзоров;
■ представление об объемах дополнительного времени, которое необходимо для
выполнения работы;
■ представление об объемах непроизводительной дополнительной работы, которую
обычно следует выполнять в обязательном порядке (обычно большинство людей
удовлетворяется сведениями о том, что на рассматриваемый проект необходимо
затратить определенное количество часов).
Когда у персонала разработчиков сформулировано четкое представление по этим
вопросам, обычно члены команды преисполняются желанием поддерживать самые
точные данные и быть заинтересованы в получении адекватной помощи на основе
представляемых данных. Ни один разработчик не может подтвердить, что благодаря
его личным заслугам процедура оценивания сократилась вдвое, исходя из
восьмичасового рабочего дня. (Обычно, рабочий день в организации составляет 4 часа).
Некоторые менеджеры столь щепетильны в работе с персоналом, что настаивают на
анонимной форме сбора данных по оценке трудозатрат.
Каким же образом происходит оценка трудозатрат технических работников или
команд? Лучшим источником являются современные эквиваленты временных
карточек (или электронных листов трудодней). Инженер, занятый в течение некоторого
времени решением нескольких проектных задач, как указывается в структуре WBS,
имеет категорию, где в определенное время оставляет отчет. Доступно любое число
полей отчетности — тип проекта диктует фазы жизненного цикла, формы действий и
конкретные программные продукты. Если в структуре WBS определены задачи,
связанные с менеджментом, разработкой и поддержкой (объединением), персонал
имеет возможность аккуратно и обоснованно распределять время для каждой из форм
деятельности, которая вносит свой вклад в выполнение проекта.
Система формирования отчетов персонала, включающих сведения о понесенных
трудозатратах, должна быть автоматизирована, а служащий не должен затрачивать
много времени на периодическое заполнение отчета. Не стоит надеяться на то, что
программисты, знакомые с новейшими технологиями, будут поставлены в условия
ручного режима работы с системой и им придется вводить отчетные данные. Легко

730 Глава 21
реализуемый интерактивный диалог должен воплощать самые последние новинки
мультимедийных технологий и в обязательном порядке обеспечивать доступ в Web.
На мониторе каждого работника должна отображаться категория, для которой
следует указывать временной норматив. Если требуется совершенно новая технология,
следует предусмотреть возможность ее сочетания с разработанной ранее структурой
WBS. Если организация использует действительно современную методологию работы
с персоналом, инженерные рабочие станции накапливают сведения о понесенных
труд' «атратах с помощью программных синтезаторов речи.
Обзоры
Вторым из трех важнейших типов измерения данных является сбор данных во
время обзоров. В процессе обзора ведется запись некоторой связанной с ним
информации — количество ошибок, тип каждой ошибки, фаза, которая породила данную
ошибку, а также та фаза, на которой она проявилась.
Одним из наиболее ценных метрических показателей, применяемых для
контроля за выполнением проекта, является объем времени, затраченного на обзор
каждого продукта. Если обзоры производятся произвольным образом, а время
точно о! слеживается, можно привлекать для проведения экспертиз членов команд из
других проектов. Тогда происходит обмен опытом, поскольку эксперты данной
команды могут выполнять аналогичную работу на взаимно выгодных началах. Речь
идет о взаимном обучении и поддержке. Несомненно, это благотворно сказывается
на качестве конечного программного продукта. Ведение хронометража при данном
виде работ позволяет сделать вывод, что чем сложнее процессы обзора
программных продуктов, тем меньше времени требуется для их повторной переработки.
Ожидается, что подобные обзоры приведут к экономии средств и в перспективе
улучшат качество проекта. Но каковы количественные оценки этих изменений?
О ,-Вет на этот вопрос можно получить, обратившись к метрическим данным по ка-
е,ч твенным показателям встроенных подпрограмм (время, затраченное на их
оценку). При этом сравнивать нужно с качеством поставленных программных
продуктов (т.е. сколько времени пришлось на изменения, которые пришлось вносить
из-за ошибок в программном продукте после выпуска данной версии). Аналогичным
(>бразом можно измерять и другие виды деятельности, а также оценивать их связь с
программным продуктом определенного качества.
Важно знать, на каком этапе возникли затруднения. Если проблемы проявились на
более поздних фазах жизненного цикла разработки, это влечет за собой повышенный
объем затрат на их устранение, поскольку возрастает объем переделок. Проблемы,
проявившиеся после выпуска программного продукта, обычно обнаруживает уже
заказчик. В этом случае наблюдаются максимальные издержки (затруднительно
согласовать стоимость, которая удовлетворила бы разгневанного заказчика). Оценки
позволяют получить информацию о видах затруднений, тогда целые категории проблем
можно исключить или уменьшить их влияние. В процессе формирования оценок
идентифицируются проблемы, которые можно скорректировать относительно
быстро и с небольшими издержками.
Обзоры: ошибки и дефекты
Проблемы удобно подразделять на ошибки и дефекты. Ошибка классифицируется
как проблема, обнаруженная на фазе ее зарождения (источник). Дефектом называется
проблема или ошибка, которая не была обнаружена на фазе ее появления, а лишь на

Метрические показатели, применяемые при оценке размера... 731
некоторой более поздней фазе жизненного цикла разработки ПО. Поэтому
проблемы, которые фиксируются на высоком уровне проектирования, классифицируются
как ошибки. Проблемы же, которые обнаруживаются и фиксируются на фазе
разработки низкого уровня или на этапе тестирования системы (либо на любой фазе,
следующей за фазой высокоуровневой разработки), рассматриваются как дефекты.
Устранение ошибок недешево, но устранение дефектов обходится еще дороже. Наиболее
дорогостоящим является устранение тех дефектов, которые возникли на ранних
фазах жизненного цикла, особенно, на фазе формулирования требований, а также те,
которые обнаружились на поздних фазах жизненного цикла, особенно, на фазе
тестирования системы.
При работе над проектом периодически выполняется инспектирование,
проводятся экспертное оценивание, а также структурированные сквозные измерения
дефектов продукта (для удобства назовем их "обзорами"). Обнаружение дефектов на
ранних фазах разработки путем проведения обзора является тем ценным вкладом,
который, несомненно, требует весомого вознаграждения со стороны организации.
Подобно данным, отражающим приложенные трудозатраты, оценочные данные
могут вызывать негативную реакцию и дискуссии и технических разработчиков,
дизайнеров и тестеров. Как указывается в гл. 23, плодотворное оценивание для того и
проводится, чтобы как можно раньше вскрывать проблемы. "Автора" дефекта почти
никогда не удается переубедить в том, что для самих авторов проекта довольно
трудно находить в них дефекты. Статистика дефектов должна ассоциироваться с обзором,
но не с "виновником" появления дефекта.
Что же подвергается обзору? Абсолютно все — каждый тип компонента в проекте
(но необязательно все до одного компоненты; в большой системе не представляется
возможным составить представление о каждом модуле кода).
Каким образом ведутся записи? Записывается момент выполнения обзора,
информация относительно участников этой процедуры, что именно подлежит обзору,
согласованное мнение об ошибках и дефектах, о типах ошибок или дефектов, об
источнике их возникновения, согласованности, уровнях серьезности ошибок или
дефектов, а также выполняется запись о доступности программного продукта или о
потребности проведения повторного обзора.
Каким образом осуществляется сбор данных обзора? Собирайте их в той "форме",
которая отвечает целям обзора, как вручную, так и в интерактивном режиме
(предпочтительнее). Тот, кто выполняет обзор, должен быть убежден, что
необходимая информация размещается в соответствующей базе данных.
О чем могут "рассказать" данные обзора?
■ Кто проводит оценивание (качественное) и кто какую роль в нем играет?
■ Какие фазы отличаются наибольшим количеством проблем?
■ На каких фазах обнаружены наиболее серьезные проблемы?
■ Какие встречаются типы ошибок/дефектов? Какой тип обнаруживается чаще
всего? После завершения проекта изучаются все типы проблем (как ошибок, так и
дефектов). Если, например, наибольшее количество проблем относится к типу
"интерфейсных ошибок", тогда четко определяется желательная цель для
совершенствования. Анализ Парето представляет собой распространенный метод гра-

732 Глава 21
фического отображения и изучения категорий их проявления. Необходимо
отличать небольшое число "жизненно важных проблем" от "тривиально многих".
■ Какие части системы наиболее сложно (дольше всего) восстанавливаются?
■ Какие типы сбоев труднее всего (дольше всего) устранять?
Эффективность фазы сдерживания
Устранение дефектов, обнаруженных после развертывания программного
продукта, может обходиться практически в 100 раз дороже, чем исключение дефектов,
некрытых на ранних фазах жизненного цикла разработки ПО. Многие эксперты
верят, что на каждой граничной фазе, где дефекты продолжают проявляться,
стоимость их устранения возрастает в 10 раз. Поскольку дефекты отличаются от ошибок,
эффективность фазы сдерживания (phase containment effectiveness, PCE) можно
вычислить с помощью формулы, показанной в примечании 21.1.
Примечание 21.1. Эффективность фазы сдерживания
Первоначально основная цель контроля над проектом заключается в сведении
числа дефектов к нулю, то есть РСЕ ~ 1. Граф РСЕ идентифицирует, какие из фаз
являются проблемными. Необходимо решить следующий вопрос: почему проявилось
такое большое число ошибок определенного типа? Затем возникает следующий
вопрос: почему так много ошибок определенного типа? Количество ошибок само по
себе является важным показателем. Однако более серьезные затруднения вызывает
представление о жизненном цикле для разрешения возникающих проблем. Данные
об ошибках, отображенные в формах оценок, можно классифицировать,
анализировать и включать в отчеты посредством диаграмм Парето. Например, диаграмма Паре-
то показывает, что обнаружены 153 интерфейсные ошибки, в отличие от 11 ошибок в
названиях переменных. Отсюда делается вывод, на каких моментах следует
сосредоточить внимание. Пример использования GQM подхода на фазе сдерживания
показан на рис. 21.18.
Анализ причин появления ошибок приводит к непрерывному процессу
совершенствования. Например, если дефекты пользовательского интерфейса проявляются
довольно часто, но не вскрыты в процессе оценивания, диаграмма причин и
эффективности может быть весьма полезной в обнаружении причины. Как правило, дело в том,
что не проводилось оценивание, либо оно выполнялось неэффективно.
Если на ранних фазах проекта обнаружено достаточно много дефектов, имеет
смысл воспользоваться подходом "Остановитесь и сосредоточьтесь" для устранения
проблем на более ранних фазах и повышения качества работ на промежуточных
этапах. Как минимум, дефекты и ошибки классифицируются, публикуются и изучаются
для совершенствования дальнейшей деятельности.

Метрические показатели, применяемые при оценке размера... 733
Цель; Усиление сдерживания дефектов
Вопрос:
В чем заключается известная в настоящее время эффективность сдерживания эффектов,
введенная на каждой конструктивной фазе разработки программного обеспечения?
Метрический показатель:
Фаза эффективного сдерживания относится к конструктивной фазе.
На рисунке демонстрируется связь ФЭС с ошибками,
найденными во время производимых обзоров (О) и количество дефектов,
которые были предотвращены благодаря тем же обзорам
ФЭС,=
О,
0, + Д/
Цель = 1
0.5
Формулирование Разработка Кодирование Тестирование
требований проекта
Рис. 21.18. Эффективность фазы сдерживания GQM
Каким еще эффектом отличаются данные обзора, кроме совершенствования
процесса для некоторого будущего проекта? Результаты обзора, проводимого во время
разработки, аналогичны "отчетам об ошибках", выполняемым после поставки
продукта. Эти обширные отчеты, которые здесь называют "измененными запросами",
важны для повышения качества системы и уровня удовлетворенности заказчика.
Благодаря ним можно составить представление о том, какие запросы фиксированы и
какова их причина. Здесь содержится информация о приоритетности запросов и
соблюдении статуса. Они могут служить руководством для тех, кто будет поддерживать
данную систему, а также для разработчиков следующих систем. Результаты обзора
выполняют ту же функцию. Устранение простых ошибок можно оставить на совести
автора; более серьезные ошибки можно опубликовать и постоянно обращать
внимание па поиск их в более общей системе. Данные обзора также позволяют менеджерам
проектов прогнозировать изменения графика.
Оценивание: оценочные данные плюс данные, отображающие прилагаемые
трудозатраты.
Когда указанные данные рассматриваются во время работы над определенной
проблемой, можно сделать некоторые выводы о том, где именно следует вносить
усовершенствования. Иногда большое количество проблем, связанных с
интерфейсом, можно устранить относительно быстро и безболезненно. В то же время
относительно небольшое число проблем из категории "некорректная инициализация"
могут отнять значительно больше времени на фиксирование, а также потребовать

734 Глава 21
более дорогостоящей переделки продукта. Данные о процессе переработки
получаются не из набора ошибок/дефектов, а из набора данных, отражающих
прилагаемые трудозатраты.
Чтобы уточнить, стоят ли полученные оценки затраченного времени и усилий,
можно сравнить стоимость затрат при проведении оценивания с количеством
обнаруженных проблем, а затем оценить затраты на устранение обнаруженных проблем.
Зная количество часов, потраченных на обзор и подготовку к нему, можно получить
те формы, где отображаются экспертные оценки. Здесь же приводится количество
проблем и уровень их серьезности.
Когда данные обзора объединяются с данными, отображающими прилагаемые
трудозатраты, можно уточнить, какие подпрограммы потребовали максимальных
усилий при их разработке, включая время, затраченное на выполнение обзора.
Можно установить корреляцию между некоторыми дефектами и оценками, а также
корреляцию между объемом трудозатрат на переделку и трудозатратами, направленными
на проведение обзора.
Запросы на изменение
Третий важный тип данных для измерения формируется при изменении
программной системы. В большинстве организаций процессы запросов на изменение
образуют подпрограмму, представляя богатый источник для полезных метрических
показателей. После развертывания ПО системы отслеживания обычно ведут запись
недочетов или измененных запросов, прилагая усилия по их устранению. Используя
материалы Национального института стандартов и технологий (National Institute of
Stai idards and Technology, NIST), можно привести перечень типов данных проблем.
■ Чоррект-фующий: исправление сбоя (ошибки или дефекта).
■ Адаптационный: адаптация ПО к изменениям в системе, приспосабливание к
изменившейся среде (внешним обстоятельствам) без внесения улучшений или
качественных изменений.
■ Превентивный: поддержка, состоящая в предупреждении сбоев до их проявления.
■ Усовершенствованный: поддержка с целью облегчения дальнейшего
сопровождения ".
Изменения, вносимые в существующие системы могут приводить к появлению
усовершенствований, — новых или заново определенных возможностей для существующей
системы; и изменения могут вноситься в программные продукты на фазе,
предшествующей выпуску при разработке новых систем.
В достаточно серьезной организации изменения, вносимые во время разработки в
компоненты проекта, также записываются.
Проблемы могут возникать не только на фазе сопровождения после выпуска
продукта, они могут проявиться и на фазах совершенствования продукта или на этапе его
разработки. Они могут обнаруживаться при выполнении обзоров (статические
тесты), в случае выполняемых тестов (динамические тесты). Также могут применяться
некоторые другие методы. Например, при изучении продукта самим разработчиком
или путем ознакомления с проблемами самого пользователя.
" National Institute of Standards and Technology. Guidance on Software. NBS Special Publication
500-106, 1992.

Метрические показатели, применяемые при оценке размера... 735
Необходимость внесения изменения обычно диктуется пользователем системы,
но может диктоваться и наблюдателем.
Обычно информация, обосновывающая необходимость внесения изменений,
включает следующие пункты:
■ кто сообщает о необходимости изменения;
■ описание проблемы или потребности (стандарт IEEE по аномалиям ПО (IEEE
Standard on Software Anomalies) содержит полный перечень категорий возможных
проблем) ' ;
■ где и когда проявилась проблема; или же сообщение об ошибке; другие
следствия/результаты; среда (предшествующие события); указания причины;
■ название системы или подсистемы (если известно);
■ критичность данного запроса (основанная на предварительно определенных
уровнях серьезности);
■ указание о корректности данного изменения, его месте в процессе
совершенствования продукта, приспособляемости, превентивности или связанном с ним
повышении качественных показателей;
■ влияние данного изменения.
Отклик на запрос об изменении сопровождается следующей информацией:
■ какое место в системе будет изменено или где находится проблема;
■ при наличии проблемы, определяются фазы разработки;
■ необходимая разновидность тестирования;
■ оцененное количество трудозатрат (количество часов), необходимых для
выполнения изменений;
■ когда именно (с указанием календарного времени) ожидается выполнение
изменений.
После реализации изменений заключительный набор сведений включает
информацию об обнаружении и устранении проблемы или же связанную с производимым
усовершенствованием:
■ дата реализации изменения;
■ реальный объем затраченных усилий;
■ где (в пределах системы) произведено изменение;
■ результаты тестирования.
На рис. 21.19 показан пример измененного запроса с отличающимся набором
собранных данных. После выпуска программного продукта как правило, собирается
информация, аналогичная той, которая содержится в приведенном выше списке и в
форме на рис. 21.19. Необходимо ли собирать аналогичную информацию для
продукта, находящегося в состоянии, предшествующем выпуску? Некоторые организации
используют для этих целей менее формальную и более краткую форму, полагая что
IEEE. IEEE 1044 Standard Classification for Software Anomalies. IEEE Software Engineering
Standards Collection. NY: Institute of Electrical and Electronics Engineers, 1993.
" IEEE. "IEEE 1044 Standard Classification for Software Anomalies". IEEE Software Engineering
Standards Collection. NY: Institute of Electrical and Electronics Engineers, 1995.

736 Глава 21 t
достаточно воспользоваться удобной (интерактивной) системой сбора отчетов?
Организации, находящиеся на более зрелом уровне, обычно повсеместно используют
одну и ту же форму.
При наличии новых или заново определенных возможностей значительно
усложняется процесс устранения проблемы, а также процедура совершенствования t
продукта или его адаптации. Качество и эффективность программы при этом могут !
серьезно пострадать. Вследствие этого код, который часто обновляется,
необходимо непрерывно переоценивать с использованием качественных показателей. Пра- |
пильным подходом является формирование приложения, содержащего усовершен- |
гтпованную поддержку. Особенно это нужно, если ПО претерпевает изменения
нескольких типов.
Обычно в процессе изменения ПО преследуются следующие цели:
■ сокращение времени цикла для отклика на запросы по изменению продукта;
■ уменьшение количества изменений, которые необходимы для повышения
качества программы.
С целью определения степени прогресса по направлению к достижению
поставленных целей часто задаются следующие вопросы.
■ Какова суть запрашиваемых изменений?
■ Изменения служат для устранения ошибок или для внесения усовершенствований?
■ Каковы составляющие компоненты проблемы?
■ Как часто изменяются требования?
■ Как долго проблема оставалась неустранимой?
■ Какие серьезные проблемы содержатся в отчетах?
■ На какой фазе диктуется необходимость изменения?
Какую информацию содержат данные
об измененных запросах? I
■ Тип изменения (т.е. проблемы) на гистограмме или диаграмме Парето;
■ отражаются ли изменения проблемы или с их помощью выполняется совершенст- f
вопание продукта;
■ количество "фрагментов" модуля (или подсистемы), имеющих сложную структуру;
■ произвольные вариации требований;
■ количество содержащихся в отчетах серьезных проблем;
■ "возраст открытых проблем";
■ способ распределения проблем с учетом приоритетов;
■ количество элементов, имеющих высокий приоритет и оставшихся
неразрешенными;
■ "возраст закрытых проблем" (насколько быстро получается отклик?);
■ какие модули или таблицы изменяются чаще всего;
■ сравнения оценок и реальных трудозатрат;
■ определение фаз, нуждающихся в изменениях.

Метрические показатели, применяемые при оценке размера... 737
Клиент: Дата:
Система: Подсистема:
ФОРМА КОНТРОЛЯ ВЕРСИЙ СИСТЕМЫ
Изменение номера запроса:
Проблема или усовершенствование:
Заголовок запроса изменений:
Серьезность:
Приоритет:
Описание проблемы/усовершенствования:
Описание разрешения:
Фаза проявления дефекта
Фаза устранения дефекта
Оценка степени влияния
Затронутые таблицы:
Затронутые программы:
Затронутая документация:
Контроль изменений
Идентифицировано:
Идентифицированная фаза:
Дата одобрения:
Оцененные трудозатраты:
Влияние на график:
Фактические трудозатраты:
Назначено:
Выпущенная версия:
Дата завершения:
Рис. 21.19. Пример формы запроса изменений

738 Глава 21
Данные о трудозатратах и запросах
на изменения
При объединении с данными, отображающими трудозатраты, запросы могут
предоставлять следующую информацию:
■ сравнение оцененных и реальных трудозатрат;
■ перечень лиц, ответственных за переработку системы;
■ перечень компонентов системы, которые являются наиболее дорогостоящими.
Комбинации данных, поддерживающих основные механизмы отслеживания,
требуются для выполнения управления проектом. Другим примером контрольной
информации являются сведения о надежности системы, называемые средним временем
наработки на отказ (mean time between failure, MTBF). Эта информация помогает
получить ответ на вопрос о том, завершено ли тестирование.
Комбинации данных также поддерживают исторически сложившуюся базовую
линию, определяющую совершенствование процесса. Примерами подобной
информации служат:
■ время, затрачиваемое в жизненном цикле разработки продукта;
■ дефекты на единицу измерения (LOC);
■ объем заработанных средств;
■ точность оценивания;
■ производительность;
■ качество;
■ общая эффективность изоляции дефектов (total defect containment effectiveness,
TDCE).
Аспекты измерений, отражающие
качество ПО
Большинство слушателей, осваивающих курс программного инжиниринга,
обращаются к авторитету Мак Колла (McCall), который впервые опубликовал
определение качества ПО. В 1977 году он идентифицировал атрибуты корректности,
эффективности, гибкости, общности, взаимодействия между операциями, возможностями
по сопровождению, переносимости, обеспечения надежности, повторной
применимости, тестируемости и полезности в качестве методов описания аспектов
обеспечения качества программного продукта . Соответствующий перечень Боэма был
опубликован в 1978 году6. В табл. 21.4 содержится перечень некоторых факторов,
которые следует учитывать различным пользователям и организациям в качестве важной
характеристики среды программного продукта.
'' McCall J.A.., и др. Metrics for Software Quality Evaluation and Prediction. Proceedings of Second
Sиm?ner Software Engineering Workshop, Greenbelt, MD. 1977.
"' Boehm Barry и др. Characteristics of Software Quality. Amsterdam: North-Holland Pub. Co.; NY:
American Elsevier, 1978.

Метрические показатели, применяемые при оценке размера... 739
Остается выразить задачи по совершенствованию качества программного
продукта в вопросах и метрических показателях, напоминающих парадигму GQM. Ниже
приводятся некоторые распространенные подходы.
Существует расхожее мнение о том, что типы архитектур и модулей,
измерительные работы для которых отличаются большей степенью сложности, более трудны для
понимания, вследствие чего возрастает вероятность появления дефектов, требуются
большие затраты на фазе сопровождения. Также затрудняется повторное
использование по сравнению с теми объектами, для которых характерны менее сложные
измерения. Однако если "качество" можно определить понятиями "сложности", каким
же образом определить саму сложность? Ниже приводятся некоторые из
определений, которые связаны с аспектами выполнения измерений:
■ логическая (цикломатическая) сложность— количество линейно независимых
способов тестирования ';
■ сложность данных — количество типов данных и параметров, передаваемых между
модулями;
■ сложность вызовов — количество вызываемых модулей или количество
вызывающих модулей;
■ использование безусловных переходов — количество операторов "Go To" ;
■ функциональная сложность —операторы и операнды ;
■ уровни вложения — глубина вложения условных операторов.
Согласно исследованиям, выполненным в Национальной лаборатории Лос-
Аламоса (Los Alamos National Laboratory), можно сделать вывод, что сложность
растет вместе с размером модуля и при наличии "лишенных значения" названий
переменных .
Различные подходы по отношению к архитектуре ПО могут как повышать, так и
снижать степень сложности. Неточные спецификации, противоречивые подходы к
конструированию, большое количество элементов проекта, типа функций и
классов, относятся к измеримым характеристикам, которые Можно отслеживать и
контролировать" .
Японские компании используют фактор качества для оценки систем, называемый
spoilage (добыча). Этот фактор определяется как время, необходимое для устранения
дефектов после выпуска продукта/общее время разработки.
Полезность программного продукта определяется диапазоном, в котором продукт
удобно использовать с практической точки зрения. Этот атрибут определения
качества измерять довольно затруднительно. Лучше разложить его на менее
фундаментальные атрибуты, каждый из которых должен оцениваться только пользователем
при обращении к программному продукту.
' McCabe Thomas. "A Complexity Measure". IEEE Transactions of Software Engineering, SE-2D):308-
320, 1976.
'" Dijkstra Edsger Wybe. A Discipline of Programming. Englewood Cliffs, NJ: Prentice Hall, 1976.
Halstead Maurice H. Elements of Software Science. Amsterdam: North-Holland Pub. Co.; NY:
American Elsevier, 1977.
"" Conell John и Linda Shafer. "Reducing Software Maintenance Costs". Computer Programming
Management, Auerbach Publishers, 1986.
" Jazaycri Medhi и др. Software Architecture for Product Families. Reading, MA: Addison-Wesley, 2000.

Таблица 21.4. Критерии/цели, применяемые для оценки качественных показателей
Критерии/цели
Мак Боэм
Колла' 1978"
1977
Hewlett-Packard
FURPS Functionality,
Usability,
Reliability,
Performance,
Serviceability' (функциональность,
полезность, надежность,
производительность, сервисные
свойства, общность)
IBM CUPRIMDSO Capability,
Usability, Performance, Reliability,
Installability, Maintainability,
Documentation, Service, Coverall
(возможности, полезность,
производительность, надежность, уста-
навливаемость, поддерживаемость,
документирование, сервисные
возможности, итого)
Аллен 2000'
1
Точность
Адаптируемость
Четкость
Корректность
Наличие документации
Экономично сть
Эффективность
Гибкость
Функциональность
Возможность обобщения
Способность к установке
X
X
X
X
X
X
X
X
X
X
X
X (возможна)
* McCallJ.A., и др. "Metrics for Software Quality Evaluation and Prediction". Proceedings of Second Summer Software Engineering Workshop, Green-
belt, MD, 1977.
ь Boehm Barry и др. Characteristics of Software Quality. Amsterdam: North-Holland Pub. Co.; NY: American Elsevier, 1978.
' Grady Robert B. (). Practical Software Metrics for Project Management and Process Improvement. NY: Prentice Hall, 1992.
* Radice R.A. и др. (). "A Programming Process Study". IBM Systems Journal, 24B):91-101, 1985.
'Allen Paul. Realizinge-Business with Components. Reading, MA: Addison-Wesley, 2000.

Окончание табл. 21.4
Целостность
Взаимодействие между
операциями
Возможности по
поддержке
Модульность
Общность
Производительность
Переносимость
Надежность
Заменяемость
Устойчивость
Возможность
повторного использования
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Масштабность X
Сервисные возможности X (возможности по сервисному об- X
служиванию)
Тестируемость X
Представляемость X
Применимость XXX X
Проверка достоверности X

742 Глава 21
Удовлетворение запросов заказчика измеряется по пятибалльной шкале: полная
удовлетворенность, довольство, нейтральное состояние, неудовольствие, большая
неудовлетворенность. Затем процентное соотношение, определенное для каждой
категории, отображается с помощью секторной диаграммы.
Индекс обратной регистрации представляет количество проблем, устраненных в
течение месяца/количество проблем, появившихся в течение месяца х 100%.
Точность оценки графика определяет реальная продолжительность
проекта/оцениваемая продолжительность проекта (см. рис. 21.7).
Точность оценивания трудозатрат определяет реальные трудозатраты при работе
над проектом/оцениваемые трудозатраты проекта (см. рис. 21.7).
Количество сбоев представляет количество сбоев/время исполнения.
Производительность ПО определяется как размер/трудозатраты.
План выполнения измерений
Организации, оперирующие с важными метрическими показателями, обычно
начинают с того, что трактуют измерение процесса таким образом, как будто речь идет о
самостоятельном проекте. При этом возникает потребность в планировании. Удобнее
составлять план измерений, обращаясь к парадигме Бейзили (GQM). Сюда входят основные
сведения о метрических показателях типа "кто, что, когда, где, каким образом и зачем".
Планирование подразумевает уточнение, выбор продуктов для измерения,
размещение продукта с учетом контроля конфигурации, определение того, какие атрибуты
следует измерять, разработку автоматизированных механизмов для сбора данных.
Планирование также предполагает определение процедур для обработки собранных
данных, анализ и отчет о результатах, ведение документации всех процедур, а в
случае необходимости и обучение всех желающих пользователей из круга
заинтересованных лиц.
Резюме
То, что нельзя измерить, надо сделать измеримым.
Галилео Галилей.
Менеджеры программных проектов должны прислушаться к длинной череде
советов (от Галилея до де Марко) о необходимости проведения измерений. Благодаря
этому облегчается представление о задачах проекта, а также обеспечивается
контроль за их выполнением. И все же менеджеры часто вопреки очевидным фактам
относятся весьма формально к метрическим показателям. Эти показатели должны
наполняться смыслом, быть полезными и точными, они должны попадать в руки тем,
кому следует, и причем в нужный момент времени.
Измерения можно и нужно проводить в течение полного жизненного цикла
разработки программ. В частности, их можно выполнять во время:
■ спецификации требований (Каким образом они влияют на способность к
тестированию? Насколько они произвольны?);
■ кодирования (Сколько ошибок обнаружено в каждом из модулей? Сколько
дефектов? На какой фазе появились дефекты? Где обнаружились? Какие виды ошибок
проявились?);

Метрические показатели, применяемые при оценке размера... 743
■ документирования процесса проектирования (Какие соотношения являются
входными, а какие — выходными для структурных диаграмм? Как измерить степень
соединения и связности?) ;
■ тестирования (Сколько ошибок обнаружено в каждом из модулей? Сколько
путей выполнения программы протестировано? Какова их цикломатическая
сложность?);
■ интегральных фаз (отслеживание проекта, оценка трудозатрат, объем затрат и
соответствие реальных событий составленному ранее графику).
Метрические показатели важны для проектных менеджеров, поскольку они
помогают принимать решения. В достаточной ли степени программный продукт
"прогонялся" во время тестирования на компьютере? Много ли проблем обнаружено
перед его выпуском? Достаточно ли средств, чтобы выполнить обязательное оцени-
вание? Сильно ли изменились требования и нельзя ли сделать вывод о том, что
программный продукт, который необходимо создать, существенно изменился и речь идет
уже о другом продукте?
Важность метрических показателей отражена в моделях SEI СММ и CMMI.
Измерения входят в качестве компонента в любую область ключевого процесса. Каким еще
образом организация может получить представление об основных направлениях в
работе над продуктом? И есть ли продвижение по направлению к целям КРА?
Парадигма Бейзили цель/'вопрос/метрический показатель включает семь этапов,
каждый из которых углубляет содержание метрических показателей для организации.
Определяется процесс, достаточный для формирования плана метрических
показателей, либо для данного проекта, либо для всей организации. Значение GQM состоит
в том, что начало лежит в установке целей, что препятствует сбору результатов
измерений, бесполезных для организации или проекта.
Несколько метрических показателей несут основное значение и столь полезны в
работе, что сбор данных и анализ с учетом этих показателей может при
необходимости выполняться еще до реализации плана типа GQM. Речь идет о данных,
отображающих трудозатраты, оценочные данные и данные об измененных запросах.
Каждый из этих типов данных, как и все остальное вместе, позволят менеджеру получить
ответы на все вопросы и затем на основе этих ответов принять решение. Куда
должны быть направлены основные трудозатраты? На этап кодирования или сбора
требований? Какие проблемы позволит разрешить опыт, приобретенный при работе над
проектом? Умело ли персонал пользуется Инструментами? Большая часть сбоев
относится к ранним этапам работы над проектами? Не подвержены ли некоторые модули
ошибкам более других? Можно ли сделать вывод, что ошибки были выявлены на фазе
их появления?
Метрические показатели, оценивающие качество, обсуждаются, а
соответствующие данные собираются, начиная с середины 70-х годов. Высококачественное ПО
всегда является целью работы менеджеров проекта, однако, не так просто
определить критерии создания подобного программного продукта. Обращаясь к
публикациям, которые прошли проверку временем и авторитетом авторов, можно определить
стандартный набор атрибутов. Однако даже если принять этот набор (например,
"полезность"), в дальнейшем их следует разбивать на составляющие части, чтобы
"" Stevens W.P., Glenford J. Myers и Larry L. Constantine. Structured Design. IBM Systems Journal,
No.2, cc. 115-139, 1974.

744 Глава 21
можно было производить измерения. Стандартный набор измерений, например
плотность дефектов, определен в литературе и часто служит хорошим основанием
для такой работы.
Недопустимо использование метрического процесса для сведения личных счетов.
Этот процесс должен быть простым и открытым, чтобы на него не оказывали
влияния те или иные привычки персонала. На этапе составления отчета о данных по
возможности следует применять автоматизацию, собранные сведения должны
располагаться в базе данных для манипулирования ими и анализа, а проанализированные
данные измерений (предпочтительно в графическом виде) должны возвращаться
назад (в виде "обратной связи") к тем, кто собирал данные, а также всем, кого
интересуют эти вопросы.
Контрольные вопросы
1. Как вы думаете, почему 34 компетенции, связанные с навыками оценивания,
ведения переговоров и управления изменениями, перечислены среди тех
компетенций, где можно использовать метрические показатели?
2. Имеются ли другие метрические показатели, в дополнение к перечисленным,
которые можно получить в виде комбинации данных по прилагаемым
трудозатратам, данных оценивания и данных об измененных запросах?
3. Каково ваше определение качества и сложности?
4. Почему авторы занимают столь твердую позицию по вопросу неприменения
измерений для "оценки" качеств людей?
Практическое занятие
Вы ознакомились с метрическими показателями, основанными на жизненном
цикле разработки вашего проекта и работой, выполненной в BSD. Но это только
первая часть задания. М-р Лу желает знать, какую роль в проекте играет персонал CRM.
Он хочет получить отчет о том, насколько эффективна их работа с учетом BSD.
Кроме того, поскольку вы максимально использовали COTS-продукты, каким образом это
отразилось на метрических показателях, включенных в отчет? Для проекта ARRS
необходимо рассмотреть формат плана метрических показателей и адаптировать его с
учетом специфики ARRS. Мисс Пайтель забраковала ваш план метрических
показателен как "процесс, для которого он сам является самоцелью". К сожалению, теперь вам
необходимо разработать его. К счастью, м-р Лу ушел в очередной отпуск, поэтому вам
необходимо завершить этот план до собрания, которое состоится в следующем
месяце и посвящено рассмотрению состояния проекта.
Литература
Abieu Г.В. Metrics for Object-Oriented Environment. Proceedings of the Third International Conference on
Sojlwtne Quality, Lake Tahoe, NV. cc. 67-75, 1993.
Albrcchi A.I. Measuring Applications Development Productivity. Proceedings of IBM Application
Dmlopmrni joint SHARE/GUIDE Symposium, Monterey, CA. pp.83-92, 1979.
Albrecht A.I. and S.H. Gafiiiev. Software Function, Source Lines of Code and Development Effort
Prediction: A Software Science Validation. IEEE Transactions on Software Engineering, 9F):639-648, 1983.

Метрические показатели, применяемые при оценке размера... 745
Bache Richard and Cualtiero Bazzana. Software Metrics for Product Assessment. NY: McGraw -Hill, 1994.
Baker A.L. и др. A Philosophy for Software Measurement. The Journal of Systems and Software, 12C):277-
281, 1990.
Barns Michael C. Inheriting Software Metrics". Journal of Object-Oriented Programming, November-
December, cc. 27-34. 1993.
Basili Victor and D. Hutchens. An Empirical Study of a Complexity Family. IEEE Transactions on Software
Engineering, 9F):664-672, 1983.
Basili Victor and Barry T. Perricone. Software Errors and Complexity: An Empirical Investigation.
Communications of the ACM, 27(l):42-52, 1984.
Basili Victor and D. Weiss. A Methodology for Collecting Valid Software Engineering Data. IEEE
Transactions on Software Engineering, SE-10F):728-738, 1984.
Becker Shirley and Mitchell Bostelman. Aligning Strategic and Project Measurement Systems. IEEE
Software, 16C):46-51, 1999.
Boegh Jorgen и др. A Method for Software Quality Planning, Control, and Evaluation. IEEE Software,
IGB):69-77, 1999.
Boloix Germinal and Pierre Robillard. Inter-Connectivity Metric for Software Complexity. Information
Systems and Operation Research, 26(l):17-39, 1988.
Briand Lionel C, Sandro Morasca and Victor R. Basili. Property-Based Software Engineering
Measurement. IEEE Transactions on Software Engineering, 22(l):68-86, 1996.
Card David N. and Robert L. Glass. Measuring Software Design Quality. Englewood Cliffs, NJ: Prentice
Hall, 1990.
Chapin Ned. A Measure of Software Complexity. Proceedings of the AFIPS National Computer Conference,
1979, cc. 995-1002, 1979.
Charette Robert N. (). Applications Strategics for Risk Analysis. NY: McGraw-Hill, 1990.
Chen J.Y. and J.F. Lu. A New Metric for Object-Oriented Design. Journal of Information and Software
Technology, 35D):232-240, 1993.
Chidamber Shyam R., David P. Darcy and Chris F. Kemerer. Managerial Use of Metrics for Object-
oriented Software: An Exploratory Analysis. IEEE Transactions on Software Engineering, 24(8):629-639, 1998.
Christensen K., G.P. Fitsos and C.P. Smith. A Perspective on Software Science. IBM Systems Journal,
20D):372-387, 1981.
Conte S.D.. H.E. Dunsmore and V.Y. Shen. Software Engineering Metrics and Models. Menio Park, CA:
Benjamin/Cummings, 1986.
Cook Jonathan E., Lawrence Votta, and Alexander L. Wolf. Cost-Effective Analysis of In-PIace Software
Processes. IEEE Transactions on Software Engineering 24(8): 640-649, 1998.
Curtis Bill. In Search of Software Complexity. Proceedings of the Workshop on Quantitative Software Models for
Reliability, cc. 95-106, 1979.
DeMarco Tom. Controlling Software Projects: Management, Measurement and Estimation. Englewood Cliffs,
NJ: Prentice Hall, 1982.
Dutoit Alien H. and Bernd Bruegge. Communication Metrics for Software Development. IEEE
Transactions on Software Engineering 24(8):615-628, 1998.
Fairlev Richard E. Software Engineering Concepts. NY: McGraw-Hill, 1985.
Fenton Norman E. and Shari Lawrence Pfleeger. Software Metrics-A Rigorous and Practical Approach, 2-е
издание. Boston, MA: PWS Publications, 1997.
Kenton Norman E. and Martin Neil. Software Metrics: Successes, Failures and New Directions.yourtmio/
Systems and Software;4."/'B-3): 149-157, 1999.
Fenton Norman. Software Metrics: A Rigorous Approach. New York, NY: Chapman & HallCRC Press, 1991.
Fenton Norman and Martin Neil. A Critique of Software Defect Prediction Models. IEEE Transactions on
Software Engineering, 1999.

746 Глава 21
Hall Tracy and Norman Fenton. Implementing Effective Software Metrics Programs. IEEE Software.
14B):55-67, 1997.
Gilb Tom. Software Metrics. Cambridge, MA: Winthrop Publishers, 1977.
Goodman Paul. Practical Implementation of Software Metrics. New York, NY: McGraw-Hill, 1992.
Giiible Ross и др. Metrics for Small Projects: Experiences at the SED. IEEE Software, 16B):21-29, 1999.
Grady Robert B. and Deborah L. Caswell. Software Metrics: Establishing n Company-Wide Program.
Lnglewood Cliffs, NJ: Prentice Hall, 1987.
Grady Robert B. Measuring and Managing Software Maintenance. IEEE Software. 4D):35-45, 1987.
Halstead Maurice H. (). Elements of Software Science. NY: Elsevier, 1977.
Harrison Warren and Kenneth Magel. A Complexity Measure Based on Nesting Eevel. ACM SICPLAN
Xotim. 16C):63-74, 1981.
Humphrey Watts S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989.
IEEE STD 982.2-1988. "IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce
Reliable Software". NY: The Institute of Electrical and Electronics Engineers, 1988.
IEEE STD 1061-1992. IEEE Standard for a Software Quality Metrics Methodology. NY: The Institute of
Electrical and Electronics Engineers, 1992.
IEEE STD 1045-1992. IEEE Standard for Software Productivity Metrics. NY: The Institute of Electrical
and Electronics Engineers. 1992.
I nee Darrel. Software Metrics. Measurement for Software Control and Assurance, Barbara Kitchenham and
B. I.iillewood, eds. NY: Elsevier Applied Science, 1989.
Jackson Michael. "Will There Ever Be Software Engineering?" IEEE Software, 15(l):36-39, 1998.
Jensen Howard A. and K. Vairavan. An Experimental Study of Software Metrics for Real-Time Software.
IEEE Transactions on Software Engineering SE-I lB):231-234, 1985.
Jones Capers. Measuring Programming Quality and Productivity". IBM Systems Journal, 17A), 1978.
Jones Capers. Applied Software Measurement: Assuring Productivity and Quality. NY: McGraw-Hill, 1991.
Kan Stephen H. Metrics and Models in Software Quality Engineering. Reading, MA: Addison-Wesley, 1995.
Kafura Dennis. A Survey of Software Metrics. Proceedings 7985 Annual Conference of the ACM, Denver, CO,
October 14-16, ACM Press, cc. 502-506, 1985.
Kearney Joseph К. и др. Software Complexity Measurement. Communications of the ACM, 29A1 ):1044-
1050, 1986.
Kiichenhain Barbara and B. Eittlewood eds. Measurement for Software Control and Assurance. NY: Elsevier
Applied Science. 1989.
Kitchenham Barbara, Shari Eawrence Pfleeger, and Norman Fenton. "Towards a Framework for
Soltware Measurement Validation". IEEE Transactions on Software Engineering, 21A2):929-944, 1995.
Lakshinanan K.B.. S. Jayaprakash and P.K. Sinha. "Properties of Control-Flow Complexity Measures".
IEEE Itansactions on Software Engineering 17A2):1289-1295, 1991.
Laiidsbaurn Jerome B. and Robert L. Glass. Measuring and Motivating Maintenance Programmers.
Englewood Cliffs, NJ: Prentice-Hall, 1992.
Lind Randy K. and K. Vairavan. An Experimental Investigation of Software Metrics and Their
Relationship to Software Development Effort. IEEE Transactions on Software Engineering, I5E):649-653. 1989.
MaiciniakJohnJ. Encyclopedia of Software Engineering. NY: John Wiley and Sons, pp. 131-166, 1994.
McCabe, Т., and Charles W. Butler. Design Complexity Measurement and Testing. Communications of the
Л CM, 32A2):1 H5-1424, 1989.
Mendonta Manoel G. and Victor R. Basili. Validation of an Approach for Improving Existing
Measurement Frameworks. IEEE Transactions on Software Engineering, 26F):484л99, 2000.
Miller George A. The Magic Number Seven, Plus or Minus Two. Psychological Review, 63, pp.81-97, 1956.
Moller K.H. and D.J. Paulish. Software Metrics: A Practitioner's Guide to Improved Product Development, 1-е
издание. NY: Chapman He Hall, 1993.

Метрические показатели, применяемые при оценке размера... 747
Nielsen Jakob. Usability Metrics: Tracking Interface Improvements. IEEE Software, 13F):12-13, 1996.
Offen Raymond /., and Ross Jeffery. Establishing Software Measurement Programs. IEEE Software,
14B):45-53, 1997. ,
Oviedo Enrique I. "Control Flow. Data Flow and Programmers Complexity". Proceedings ofCOMPSAC80,
Chicago, IL, pp. 146-152, 1980.
Park Robert E. Software Size Measurement: A Framework for Counting Source Statements. Software
Engineering Institute Technical Report SEI-92-TR020. Pittsburg, PA: SEI, Carnegie Mellon University, 1992.
Patel Sukesh, William Chu and Rich Baxter. "A Measure for Composite Module Cohesion". Proceedings
of the 14th International Conference on Software Engineering, Melbourne, Australia, cc. 38-48. NY: Association for
Computing Machinery, 1992.
Perils, Alan, Frederick Sayward, and Mary Shaw, eds. Software Metrics: An Analysis and Evaluation.
Cambridge, MA: MIT Press, 1981.
Pfleeger, Shari Lawrence, and J.C. Fitzgerald. Software Metrics Tool Kit. Support for Selection, Collection
and Analysis. Information andSoftware Technology, 33G):477-482, 1991.
Pfleeger Shari Lawrence, Ross Jeffery, Bill Curtis and Barbara Kitchenham. "Status Report on Software
Measurement". IEEE Software, 14B):33-43, 1997.
Pressman Roger S. Software Engineering: A Practitioner's Approach, 5-е издание. Boston, MA: McGraw-Hill,
2001.
Putnam Lawrence H., and Ware Myers. Measures for Excellence: Reliable Software on Time, Witfiin Budget.
Englewood Cliffs, NJ: Yourdon Press, 1992.
Putnam Lawrence H. "A General Empirical Solution to the Macro Software Sizing and Estimating
Problem". Transactions ofSoftware Engineering SE-4 D):345-361, 1978.
Rifkin Stan. What Makes Measuring Software So Hard? IEEE Software, 18C):41-45, 2001.
Rising Linda, and Frank W. Callis. "Problems with Determining Package Cohesion and Coupling".
Software Practice and Experience, 22G):553-571, 1992.
Sawyer Pete, Ian Sommerville and Stephen Viller. Capturing the Benefits of Requirements Engineering.
JJFJ Software, 16B):78-85, 1999.
Schneidewind Norman F. Setting Maintenance Quality Objectives and Prioritizing Maintenance Work
by Using Quality Metrics. Proceedings of the Conference on Software Maintenance (CSM91), October, 1991.
Schneidewind Norman F. Measuring and Evaluating Maintenance Process Using Reliability, Risk, and
Test Metrics. IEEE Transactions on Software Engineering, 25F):769-781, 1999.
Schnciderwirid Norman F. "Software Metrics Model for Quality Control". Proceedings of the 4tli
international Software Metrics Symposium (Metrics '97), Albuquerque, NM, 1997.
Shepperd Martin, ed. Software Engineering Metrics-Volume I: Measures and Validations. New York, NY:
McGraw Hill, International Series in Software Engineering, 1993.
Shepperd Martin and Darrel Ince. Derivation and Validation of Software Metrics. NY: Oxford University
Press, 1993.
Shooman, Martin L. Software Engineering: Design, Reliability, and Management. NY: McGraw-Hill, 1983.
Sommerville Ian. Software Engineering, 6th ed. NY: Addison Wesley, 2000.
Tervonen Likka. Support for Quality-Based Design and Inspection. IEEE Software, 13A): 44-54, 1996.
Von Mayrhauser Anneliese. Software Engineering: Methods and Management. Boston, MA: Academic Press,
1990.
Walston C.E. and C.P. Felix. A Method of Programming Measurement and Estimation. IBM Systems
Journal. 16(l):54-73. 1977.
Wasserman Anthony I. Toward a Discipline of Software Engineering. IEEE Software, Vol. 13, No. 6, 1996.

I
748 Глава 21
Дополнительные сведения в Internet
hissa.ncsl.nist.gov/. Центр обеспечения высокой степени интеграции программных
систем — NIST International Software Metrics Symposium.
irb. cs. uni -magdeburg. de/sw-eng/us/index, shtml. Лаборатория программных измерений.
satc.gsfc.nasa.gov/support/STC_APR96/gualtiy/stc_qual.litml. 8-я ежегодная
конференция по программным технологиям. Юта, апрель 1996 г.
sel.gsfc.nasa .gov/website/documex\ts/contents.htm#l. Лаборатория программного
инжиниринга — секция 6, программные измерения.
stsc.hill.af.mil/. Американский центр поддержки программных технологий при ВВС
(поиск "программных метрических показателей").
www.software.org. Консорциум по вопросам обеспечения производительности при
разработке ПО.
www.acm. org. Ассоциация по механизации вычислительных работ.
www. cmg.org. Фирма Computer Measurement Group, Inc.
www. iese. fhg.de/ISERN/. Международная исследовательская сеть в области программного
инжиниринга (International Software Engineering Research Network, ISERN).
www. if pug. org. Международная группа пользователей метода функциональных точек.
www. incode. org. Международный совет по вопросам программного инжиниринга
www. instmc. org. uk. Институт по вопросам измерений и контроля.
www. rust. gov/. Национальный институт стандартов и технологий.
www.psmsc. com. Центр по обеспечению практической поддержки измерений программ и систем.
www. ssg. org. Совет по обеспечению качества ПО.

Методы анализа
и разработки проекта
Процесс документирования требований к ПО включает их сбор, анализ,
спецификацию и верификацию. Каждый из этих видов деятельности предполагает создание
моделей требований, что позволит поддерживать корректность и облегчит
"материализацию" требований в виде готовых программных продуктов. Менеджеры
программных проектов предпочитают не обращать внимания на подробности
разработки проекта и моделирования на более низком уровне. Однако они принимают
активное участие при создании моделей высокого уровня, а также в презентациях этих
моделей, производимых с целью получения финансовой помощи со стороны спонсоров.
Менеджер проекта, несомненно, выигрывает в результате ознакомления с процессом
моделирования и выполняемыми в этом случае оценками. Эти сведения помогут
более четко наладить работу с членами команды разработчиков проекта, точнее
оценивать трудозатраты и рабочий график.
Процесс разработки проекта важен еще потому, что позволяет оценивать
выполняемые задачи и отслеживать проект в процессе его внедрения. В результате
менеджер проекта начинает понимать язык разработчиков, учится задавать вопросы
и уметь отвечать на них.
Моделирование процессов, используемых в ходе проведения анализа и разработки
проекта, позволяет разработчикам ПО лучше представлять вопросы, связанные
с достижением оптимальной производительности, а также интерфейс программы,
обеспечивающий связь с другими компонентами системы. Аналитики в области
разработки программ формируют данные, создают функциональные и поведенческие
модели, которые передаются разработчикам ПО. Разработчики выстраивают
структуры данных, образуют архитектурные, интерфейсные и функциональные модели.
Подобные модели часто называют черновиками ("blueprint") и применяют в процессе
разработки ПО. С ростом системы увеличивается степень сложности
представляющих ее моделей.
В процессе анализа и разработки проекта могут использоваться несколько различных
моделей. Наиболее доступными из них являются структурированный анализ/разработка

750 Глава 22
проекта (Structured analysis/structured design, SA/SD) и объектно-ориентированный
анализ/разработка проекта (object-oriented analysis/object-oriented design, OOA/OOD)
средствами унифицированного языка моделирования (Unified Modeling Language, UML). Эта
тематика освещена в нескольких прекрасных и подробных работах, поэтому здесь
подробно не рассматривается. Назовем основные модели, используемые в каждом методе, и
рассмотрим соответствующие примеры. Также перечислим некоторые аспекты,
отражающиеся на качественных характеристиках проектов. В результате внимательного
изучения материала менеджер программного проекта станет лучше понимать проблемы,
стоящие перед аналитиками и разработчиками проекта.
Стадии жизненного цикла
разработки продукта
Этапы анализа и разработки проекта выполняются после исследования системы
и до внедрения в жизненный цикл процесса разработки ПО. Описание
аналитических моделей часто включается в документ SRS, а модели разработки проекта
можно обнаружить в документе SDD (software design description, описание разработки
программного проекта). Также в целях поддержки фаз активной разработки
программных продуктов широко используются различные интегральные задачи, не
показанные на рис. 22.1.
Связь главы 22 с 34 компетенциями
Подобно подавляющему количеству видов ответственности, вовлекаемых в
процесс осуществления программных процессов, анализ и разработка проекта требуют
многих навыков, связанных с продуктом, проектом и персоналом.
Методики разработки продукта
1. Знание стандартов процесса — существуют стандарты, описывающие
практические реализации аналитических методов и способов разработки проекта.
Например, следует учитывать диаграммы потоков данных, применяемые при создании
достоверной модели, в процессе выполнения балансировки и выравнивания.
2. Определение продукта— требования становятся аналитическими моделями,
которые, в свою очередь, становятся моделями, применяемыми при разработке
проекта. В этом смысле компоненты анализа и разработки проекта являются
программными продуктами.
3. Управление требованиями — модели формулирования требований часто
пересматриваются н даже частично изменяются заказчиками, пользователями и
другими организаторами проекта, не принимающими непосредственного участия
в выполняемых работах. В этом случае поддержка моделей разработки
программных продуктов будет полезной при формулировании требований.
4. Отбор методов и инструментов — анализ и разработка проекта могут
выполняться посредством различных методов. Рассмотрим два основных из них:
структурный анализ/разработка проекта и объектно-ориентированный
анализ/разработка проекта. Выбор наиболее подходящего метода осуществляется
менеджером проекта.

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

потребности
1
i
N
Исследование
системы
.
• Спецификация'
интерфейса
системы
, .
N
Требования
.
■ Спецификация ■
требований
к ПО
, .
к
Базовая модель системного жизненного цикла
i'
ч
Разработка
проекта
„
■ иписание ■

разработки ПО
, .
ч
Внедрение
тации/вери-
фикации ПО
< <
ч
Установка
-
А
v. j
нализ и разработка проек
тестации/ве-
та рификации ПО
1
1 <
<
Ч
Эксплуатация
и поддержка
i
•
Пользовательская
документация
1
\
Сопровождение
■ До сументация'
по
сопровождению
ч
i'
ч
Вывод из
эксплуатации
• Архивный
отчет
Рис. 22.1. Анализ и разработки проекта выполняются в средней области жизненного цикла
разработки программного продукта
Навыки менеджмента проектов
6. Оценка стоимости и оценка трудозатрат — аналитическая деятельность и
разработка проекта должны, особенно на ранних стадиях, отвечать всем требованиям
по стоимости, трудозатратам, а также вписываться в график выполняемых работ.
7. Менеджмент рисков — тщательная проработка анализа качества и моделей
разработки проекта приводит к уменьшению риска, поскольку способствует четкому
формулированию требований. Обычно неясности с требованиями существенно
увеличивают фактор риска для программного проекта.

752 Глава 22
8. Отслеживание процесса разработки — готовые продукты аналитической
деятельности и разработки проекта используются для оценки общего прогресса
в выполнении основных пунктов рабочего графика.
Навыки менеджмента персонала
9. Проведение эффективных встреч — часто модели формируются в процессе
"мозговых штурмов" или JAD-сеансов и рассматриваются на встречах с экспертами.
10. Взаимодействие и общение— анализ представляет собой расширение
деятельности, обеспечивающей уточнение требований. Применяемые в этом случае
навыки аналогичны используемым в случае анализа методикам.
11. Успешное ведение переговоров — как показывает процесс сбора требований
и создания документов SRS, не все необходимые функции могут выбираться
изначально. Процесс формирования наборов возможностей и сложных свойств
поставки продолжается при выполнении моделирования и требует навыков по
ведению переговоров.
12. Эффективное представление — модели представляют собой коммуникационные
механизмы, используемые для представления и реализации на практике
требований — предмет деятельности менеджеров и спонсоров.
Учебные цели главы 22
После изучения материала главы читатель должен уметь выполнять следующее:
■ описывать способы, которые используются в моделях структурного
анализа/разработки проекта (SA/SD) и объектно-ориентированного анализа/разработки проекта
(OOA/OOD) с целью формирования требований по отношению к ПО;
■ создавать компоненты структурного анализа: диаграмма содержимого данных
(data context diagram, DCD), диаграмма потока данных (data flow diagram, DFD),
спецификация процесса (process specification, PSPEC), словарь данных (data
dictionary, DD), диаграмма взаимосвязей сущностей (entity relationship diagram, ERD),
диаграмма управления содержимым (control context diagram, CCD), диаграмма
управления потоком (control flow diagram, CFD), спецификацию контроля (CSPEC);
■ описывать качественные импликации моделируемых данных, используя третью
нормальную форму;
■ описывать преобразование моделей структурного анализа в модели структурной
разработки проекта;
■ описывать архитектурные диаграммы и определять степень их полезности при
моделировании требований к системе;
■ создавать компоненты структурной разработки проекта: структурные диаграммы
и диаграммы Чейпина (Chapin);
■ разрабатывать компоненты объектно-ориентированного анализа/разработки
проекта (OOA/OOD): модель класса, модель объекта, варианты использования,
диаграмму действий, диаграмму сотрудничества, последовательную диаграмму,
диаграмму взаимодействия;
■ сравнивать и находить отличия для процессах SA/SD и OOA/OOD;
■ распознавать качественные аспекты моделей SA/SD и моделей OOA/OOD.

Методы анализа и разработки проекта 753
Анализ/разработка проекта
и модель SEI СММ
Достижение высокого качества в процессе управления программными проектами
базируется на трех взаимосвязанных основаниях: документ Основы знаний
Института проектного менеджмента (Project Management Institute's Body of Knowledge,
PMBOK), IEEE-стандарты и процессы, а также модель зрелости возможностей,
разработанная Институтом SEI. Вопросы, связанные с моделью СММ, неоднократно
обсуждаются в этой книге, особенно в главах 4 и 26. Менеджеры программных проектов
вынуждены действовать на втором уровне зрелости (повторяемость). Если
организация поднимается выше по ступеням зрелости, видимость программного процесса
улучшается с каждым уровнем наряду с совершенствованием управления, прогнози-
руемостью и эффективностью. Третий уровень (определенный) служит ориентиром
для ьсех организаций, разрабатывающих ПО, и в настоящее время еще не достигших
его. На третьем уровне зрелости организации применяется интегрированный
менеджмент и процессы инжиниринга.
Ключевой областью процесса (key process area, KPA) на третьем уровне является
разработка программных продуктов (software product engineering, SPE). Эта область
KPA включает выполнение инженерных задач по созданию (и поддержке) ПО с
помощью определенного в проекте программного процесса, а также с привлечением
соответствующих методов и инструментов. Эти методы могут базироваться на SA/SD
или на OOA/OOD.
Следуя Полк}' (Paulk), можно указать следующие цели применения модели SEI
СММ KPASPE.
Цель 1. Задачи по разработке ПО определяются, интегрируются и постоянно
выполняются в ходе осуществления производственного процесса.
Цель 2. Рабочие программные продукты тесно связаны между собой.
В связи с поставленными целями реализуются следующие действия:
Действие 1. Соответствующие методы и инструменты программного
инжиниринга интегрируются в определенный программный процесс для данного проекта.
Действие 2. Требования к ПО разрабатываются, поддерживаются,
документируются и удостоверяются путем систематического анализа распределенных требований
в соответствии с программным процессом, который определен в проекте. Процессом
разработки требований к ПО руководят отдельные специалисты. Они
пересматривают распределенные требования, чтобы обеспечить корректный анализ требований
к ПО. Эти требования включают описание функций, выполняемых ПО,
аппаратные/программные интерфейсы, а также другие компоненты системы (например,
человеческий фактор). В качестве примеров методик, применяемых для анализа
требований, можно указать функциональную декомпозицию, объектно-ориентированную
декомпозицию, изучение компромиссов, имитации, моделирование, прототипирова-
ние и генерирование сценариев.
Действие 3. Разработка программного проекта разрабатывается, поддерживается,
документируется и верифицируется в соответствии с определенным программным
процессом проекта. Это позволит достичь соответствия требованиям к ПО и
сформировать базу для разработки программного кода.

754 Глава 22
1. Постоянно совершенствуются и пересматриваются критерии разработки
проекта. Их отличает способность к верификации, строгое соблюдение стандартов
разработки, конструктивная легкость, упрощенность и простота планирования.
2. R ходе разработки программного проекта применяются эффективные методы.
К ним относятся: прототипирование, структурные методы, повторное
использование проекта, объектно-ориентированная разработка и анализ важнейших систем.
5. Разработка программной архитектуры производится, начиная с ранних фаз,
в пределах ограничений жизненного цикла разработки ПО и применяемой
технологии .
Программная архитектура определяет высокоуровневую схему программы
наравне г хорошо определенными внутренними и внешними интерфейсами.
В главе нашли отражение специфические методы функциональной
декомпозиции (диаграммы потоков данных, диаграммы управления потоками), объектно-
ориентированная декомпозиция (классы, объекты, диаграммы сотрудничества,
диаграммы действий), а также генерирование сценариев. Также представлены структурные
мподы (структурные диаграммы, диаграммы Чейпина), объектно-ориентированные
методы разработки проекта (классы, объекты, диаграммы сотрудничества, диаграммы
лсис гний, варианты использования) и основные положения системного анализа.
(лть применяемого подхода состоит в том, что если менеджер проекта следует
рекомендациям главы, требования к области КРА, связанной с разработкой программ,
\дов летворяются на третьем уровне модели SEI СММ. В главе 16 представлены
обобщенные шаблоны высокого уровня, предназначенные для моделирования дан-
пых в форме диаграмм взаимосвязей сущностей (ERD), описывается моделирование
процесса в виде диаграмм потоков данных (DFD и варианты использования), а также
моделирование процесса/данных (объектные модели). Подобные представления
i рсооклний к ПО удобно использовать в качестве коммуникативных механизмов при
опросах, проведении сеансов "мозгового штурма" и JAD-сеансов. Уровень
детализации в этом случае не слишком велик, однако на их основе может осуществляться
кодирование и внедрение программ. Для перевода моделей в это состояние применяет-
. я процесс поэтапного совершенствования. Здесь уместна аналогия, описывающая
i ] роитсльство зданий. Аналитические модели высокого уровня являются
аналогами чертежей, демонстрируемых архитектором будущему владельцу дома. Именно
модели позволяют "прощупать" реализуемую структуру. Обычно архитектору
приходится решать много вопросов, связанных с обустройством дома. Две или три
спальни, одну или две ванные, место для гаража — все необходимо предусмотреть.
Анализ, выполняемый на низком уровне, и модели разработки проектов не
представляют большого интереса для будущих "домовладельцев". В этих документах
описывается, к примеру, место размещения электропроводки и канализационных
груб. Невольно "напрашивается" аналогия с участниками контракта, которые
работают с черновыми набросками. В результате анализ ПО и разработки проекта позво-
чяет совершить переход от "архитектурных набросков" до завершенных, подробных
черновых схем будущего программного продукта.
P,iulk Mark С, Charles V. Weber, Bill Curtis and Mary Beth Chrissis. The Capability Maturity
Model: Guidelines loi Improving the Software Process. Reading, MA: Addison-Wesley SEI Series in
Niiliware Engineering. 1994.

Методы анализа и разработки проекта 755
Структурный анализ/разработка
проекта (SA/SD)
Структурный анализ и разработка проекта приводят к возникновению
графических представлений создаваемой программной системы. В роли компонентов в
данном случае выступают некоторые из следующих объектов: диаграмма содержимого
данных (DCD), диаграммы потока данных (DFD), спецификации процесса (PSPEC),
словарь данных (DD), диаграмма взаимосвязей сущностей (ERD), диаграмма
управления содержимым (CCD), диаграммы управления потоком (CFD), деревья решений,
диаграммы преобразования состояния и диаграммы архитектуры потока (AFD). Как
и для OOA/OOD, существует большое число возможных моделей. Некоторые из них
приводятся в табл. 22.1.
Таблица 22.1. Модели структурного анализа/разработки проекта
Данные, Тип модели
функция, ее
поведение
Описание
Элементы
Фаза: структурный анализ
Функция Диаграмма Общая "картина" системы и ее ин-
содержимого терфейсы для внешних сущностей
данных (Data или систем. Показывает границу
Context Dia- между системой и средой, а в пер-
gram, DCD) спективе — границу между
системой и реальным миром.
Идентифицируются все сетевые вводы
и выводы. Рассматривая только
один процесс, система на этом
этапе является "черным ящиком",
представляет все преобразования,
выполняемые системой
Функция Диаграммы Документ DFD является
потока дан- "снимком" системы как рабочей
ных (Data сети функциональных процессов.
Flow Diagram, связанных между собой "кана-
DFD) лами" данных (потоками данных)
и хранилищами данных.
Процессы преобразуют данные.
Диаграмма разбивает систему на
отдельные компоненты
Внешние сущности (поля),
один процесс (система —
окружность/пузырек),
потоки наименованных
данных (стрелки)
Отмеченные "пузырьки"
процесса, именованные
потоки данных, хранилища
данных. Обратите
внимание, что в документе DFD
не показаны внешние
сущности, но данные
сохраняются. Опущены указатели
на завершение диаграмм
DCD; сохраняется только
информация, направляемая
в систему и из системы
(поток данных). Один
основной цикл обработки
разбивается на несколько
более совершенных циклов
обработки

756 Глава 22
Продолжение табл. 22.1
Данные, Тип модели
функция, ее
поведение
Описание
Элементы
Фаза: структурный анализ
Функция Спецификаци Описание функции или процесса
и процесса на нижнем уровне декомпозиции.
(Process Speci- Выполняется для любого функ-
fications, ционального примитивного про-
PSPEC) цесса. Отображает
преобразование, которое выполняется в
каждом процессе. То есть, показано,
каким образом обрабатываются
начальные данные с целью
достижения требуемого результата
Данные Модель взаи- Позволяет программисту иденти-
мосвязей фицировать объекты данных и их
сущностей взаимосвязей с помощью графи-
(Entity Rela- ческих записей. В контексте
tionship структурного анализа ERD опре-
Model, ERD) деляет все данные, которые
вводятся, хранятся,
преобразовываются и производятся в пределах
приложения. Получаем данные,
организованные в группы по их
значению, показаны
ответственности между группами
Поведение Диаграмма Аналогично DFD, CCD-диаграмма
управления отображает только один процесс,
содержимым Показаны вводные и результи-
(Control Con- рующие данные для внешних сущ-
text Diagram, ностей. Они разбиты на компо-
CCD) ненты, которые завершаются
спецификациями. Различие состоит в
том, что данные, отображаемые
диаграммой CCD или диаграммой
управления потоком (CFD),
являются контрольными и
приводящими к изменению состояния
системы. В результате
преобразования активизируются или же не
выполняются
Поведение Диаграммы Моделируется управление пото-
управления ками, а не потоки данных. Назва-
потоком ния, нумерация, использование
(Control Flow уровней и свойства балансировки
Diagram, используются вместе с DFD-
CFD) диаграммами
Документы PSPEC могут
принимать форму
структурного языка (псевдокод),
таблиц решений,
уравнений, графиков,
математических уравнений, блочных
диаграмм или других
графических изображений
Сущности (поля),
атрибуты, взаимосвязи
(направленные линии),
кардинальные числа
Внешние сущности, один
процесс (система),
названные потоками управления.
Элементы и символы для
CCD те же, что и для DCD,
за исключением того, что
контрольные данные
представлены точечной линией,
что позволяет отличить их
от других данных и
выполнить четкое моделирование
поведения
Отмеченная обработка
"наростов", потоки
управления (точечные линии),
хранилища данных,
контрольные полосы для
CSPEC

Методы анализа и разработки проекта 757
Продолжение табл. 22.1
Данные, Тип модели Описание
функция, ее
поведение
Элементы
Фаза: структурный анализ
Поведение
Управления

спецификациями
(Control
Specifications, CSPEC)
Указывает полосу для CFD; может
изменять состояние системы
Диаграммы переходов
между состояниями —
состояние, переход,
событие/действие
Фаза: структурная разработка проекта
Данные
Усовершенствованная
диаграмма
взаимосвязей
сущностей
(Enhanced Entity
Relationship
Diagram, ERD)
Функция/по Диаграммы
ведение
архитектурного
содержимого
(Architecture
Context
Diagrams, ACD)
Функция/по Архитектурна
ведение я диаграмма
потока
(Architecture
Flow Diagram,
AFD)
Функция/по Структурные
ведение диаграммы
Функция
Диаграммы
Чейпина
Определяет информационную
границу между системой и средой.
Показывает физическое
распределение требований для данных
модели (DFD) и контролирует
(CFD) обработку. Присваивает
процессы из модели требований
к физическим модулям, которые
составляют систему и
устанавливает взаимодействие между ними
Процесс является производным
от DFD и выполняет перестройку
в соответствии с
дополнительными физическими свойствами.
Результирующий процесс должен
быть организован с учетом
реализации интерфейса пользователя
Структурные диаграммы
организуют системы, которые
распределены по "черным ящикам" с
учетом иерархии. Структурные
диаграммы демонстрируют
вертикальную, но, а не
горизонтальную составляющую
временной последовательности
Структурные диаграммы потоков.
Один вход и один выход
Сущности, атрибуты,
взаимосвязи, кардинальные
числа
Модуль = прямоугольник с
закругленными углами;
перегруппированные "пузырьки"
процесса. Вектор потока
информации = стрела
(данные)/пунктирная
стрела (управление); связки
данных и управляющие
потоки
Разложенные на составные
части, ACD. Модули,
вводные данные,
результирующие данные, поддержка
интерфейса пользователя и
самостоятельное получение
справки
Модульные окна,
управление, данные
Четыре обрабатывающие
инструкции: простая
последовательность, do while/do
until, if-then-else, do case

758 Глава 22
Данные, Тип модели Описание
функция, ее
поведение
Фала: структурная разработка проекта
Окончание табл. 22.1
Элементы
Поведение Архитектуры Представление коммуникативных Аналогично AFD, с допол-
ые диаграм- каналов, существующих между ар- нением каналов коммуника-
мы взаимо- хитектурными модулями. Показы- ции. Несколько каналов вы-
связей вает физическое содержимое, с ступают в качестве трасс
(Archiieciure помощью которого поддержива- (или единиц)
Interconnect ется связь между модулями. При-
Diagrams) мерами являются радиоканалы,
электрические шины,
механическая линия и оптоволокно
Эти методы используются еще с 70-х, а поэтому признаны "проверенными и
правильными". Они применяются совместно с любым типом приложения и могут быть
реализованы па любой платформе. Хотя в течение многих лет вносились усовершен-
i пюпания. призванные повысить качество разработанной методики, вклад
нескольких талантливых исследователей в создание концепции и ее популяризацию трудно
переоценить. Отдавая должное некоторым из этих авторитетных личностей и
отмечая их плодотворные работы, приведем их имена. Это — Питер Чен (Peter Chen),
И.Ф.Кодд (L.F. Codd), Ларри Констентайн (Larry Constantine), С.Дж.Дейт (CJ.Date),
S ом Демарко (Tom DeMarco), Дерек Дж. Хетли (Derek. J. Hatley), Майкл Джексон
..Michael Jackson), Джеймс Мартин (James Martin), Стефен Дж. Меллор (Stephen
J Mellor). Мейлир Пейдж-Джонс (Meilir Page-Jones), Имтиаз А. Пирбхаи (Imtiaz
Л. I'irhhai), П.Дж. Плайджер (P.J. Plauger), Дуглас Росс (Douglas Ross), Паул Т. Уорд
■• Paiii Т. Ward), Джин Доминик Уорнер (Jean Dominique Warmer) и Эдвард Йордон
(lMward Yourdon).
Цель разработки концепции SA/SD заключалась в повышении качества ПО,
'. пнжении риска сбоев в работе, а также в получении дополнительных возможно-
i теп по увеличению степени надежности, гибкости, универсальности и
эффективности. В результате осуществления этих качественных усовершенствований система
"оказывается в выигрыше", поскольку метод, применяемый в данном случае метод
направлен па достижение основополагающей цели системы. На каждом этапе
разработки ведется документация, создается план-карта системы. Несмотря на то, что SA/SD
первоначально рассматривался как подход, управляемый процессом, здесь пользова-
!<-ц. имеет дело с прогнозируемыми данными и поведением системы. В 1980-х
получила признание концепция важности данных, в результате чего стало уделяться
внимание их моделированию. Итак, где же начинается аналитическая работа? При моде-
шровапии данных или самого процесса? С практической точки зрения это не имеет
оодыпого значения. Существует ряд аналитиков, по мнению которых данные "задают
гчп" сн< геме, остальные полагают, что ведущую роль выполняет процесс. Начнем
i моделирования данных, учитывая их поведение как элемент процесса.

Методы анализа и разработки проекта 759
Структурный анализ SA/SD: модели данных
Моделирование данных — это абстрактный способ описания методики хранения
данных в системе. Моделирование данных отличается от моделирования процесса
тем, что в этом случае не учитываются функции системы, а также ее поведение,
изменяющееся с течением времени. В результате модели придается статический характер.
Существует несколько способов моделирования данных, но ни один из них не
получил такого распространения, как диаграмма взаимосвязей сущностей (entity
relationship diagram, ERD). Благодаря этой диаграмме происходит подготовка к
физическому хранению данных с применением ряда форматов; чаще всего используется
формат реляционных баз данных.
Существуют системы, которые управляют явлениями внешнего мира (например,
радиоуправляемые системы) и системы, моделирующие явления внешнего мира
(например, система отдела кадров предприятия). Оба типа систем полезны в
процессе моделирования данных, но для систем, имитирующих явления внешнего мира,
модель данных просто необходима. В случае ее применения можно получить ответы на
следующие вопросы.
■ Какого типа данные требуются для решения деловой проблемы?
■ Каким образом элементы данных соотносятся друг с другом?
■ Кто владеет информацией?
■ Кто может иметь доступ к данным?
Модели данных способствуют построению эффективной системы базы данных,
отличающейся тремя важнейшими функциями: логичностью транзакций (транзакции
ведут себя так, как если бы они применялись постоянно), целостностью данных в
динамическом режиме (данные не теряются и не искажаются во время сбоев в
аппаратуре или ПО хост-компьютеров) и независимостью данных (отсутствуют
ограничения, заключающиеся в физической реализации данных).
Американский национальный Институт стандартов (American National Standards
Institute, ANSI) и Комитет по планированию стандартов и требований (Standards
Planning and Reqiurements Commitee, SPARC) определили стандарт, с помощью
которого описываются способы просмотра данных в системе. Благодаря учету
различных точек зрения аналитики и разработчики ПО могут создавать
завершенные модели.
Модель ANSI/SPARC описывают концептуальные моменты, связанные с
просмотром данных: логическую организацию всех данных приложения, управляемых
системой, синтез внешних моделей и способы связи различных вариантов
просмотра с общим языком и структурой. Внешний просмотр является специфическим
подмножеством концептуального просмотра данных, причем в этом случае
отражается субъективный взгляд пользователя. Логический просмотр основан на
концептуальной модели. При этом учитывается применяемый тип системы управления
базой данных, например, иерархическая, реляционная, сетевая или объектно-
ориентированная. Внутренний просмотр направлен на формирование
специфической физической организации устройств хранения; организация данных
достигается в физической среде .
■ Коннолли Томас, Каролин Бегг. Базы данных - проектирование, реализация и сопровождение.
Теория и практика. 2-е изд. "Вильяме", 2000

760 Глава 22
В настоящей главе ограничимся моделированием концептуального просмотра
данных. При этом применяются термины модели данных для полной базы данных,
известной под названием "глобальная концептуальная схема". Вообще, разные
пользователи предъявляют различные требования к данным, так что модель данных
может быть разделена на подклассы с учетом конкретных запросов.
С чего же следует начать? С системы реляционной базы данных (relational database
system, RDBS), на основе которой можно получить диаграмму ERD, определяющую способ
храпения данных? Или же лучше начать с ERD, которая определяет способ построения
RDBS? Сначала создадим модель с применением ERD-диаграммы, однако, хорошая
осведомленность о принципах функционирования СУБД не помешает ни аналитику, ни раз-
работчику, ни менеджеру проекта. И.Ф.Кодд (E.F. Codd), научный сотрудник фирмы IBM,
впервые предложил модель реляционных данных в конце 60-х годов. В качестве
'фундамента" для архитектуры базы данных он предложил воспользоваться
независимостью данных и ввел понятие математического множества. Вплоть до этого момента
приложения баз данных имели непосредственный доступ к файлам данных и манипулировали
ими, а информация хранились в записях, оформленных в виде полей, состоящих из
элементов индивидуальных данных. Модель реляционных данных подробно описана в
различных книгах, например, втруде "Теория реляционных баз данншг"(Майер).
Модель реляционных данных поддерживает очень простую конструкцию для
представления структур данных, табулярную структуру, называемую отношением. Эта
структура состоит из столбцов, называемых атрибутами, причем каждый атрибут
является атомарным (неразложимым на компоненты) и одномерным. Строки таблицы
представляют собой записи, каждая из которых содержит один и тот же набор
атрибутов. Определенные поля могут играть роль ключей, что означает применение
индексирования с целью ускорения поиска специфических значений, определенных для
данного поля. Модель реляционных данных также поддерживает широкий диапазон
ограничений целостности.
Диаграммы взаимосвязей сущностей
Диаграмма взаимосвязей сущностей (entity relationship diagram, ERD) позволяет
идентифицировать объекты данных и их отношения, используя при этом систему
графических обозначений. В контексте структурного анализа диаграмма ERD определяет
все данные, которые вводятся, хранятся, преобразуются и создаются приложением.
Атрибуты каждого объекта, указанные в ERD, описаны в словаре данных. Набор
атрибутов, соответствующий конкретному объекту данных, определяется с учетом
конкретной задачи. Эти атрибуты в системах управления базами данных
сопоставляются с идентификаторами и ключами. Предоставим аналитикам и администраторам
баз данных более подробно изучать этот вопрос. Эта глава является обзорной. Она
призвана лишь помогать менеджеру проекта четко представлять сложности, с
которыми связано моделирование данных. Также менеджеру проекта требуется учитывать
специфику этого вида деятельности при подборе кадров и планировании проекта. Он
должен четко оценивать усилия, затрачиваемые на разработку различных модификаций
программного продукта. Но вряд ли сам менеджер будет принимать активное участие
в анализе и разработке моделей. В этой книге не исследуются вопросы проектирования
баз данных и недостаточно последовательно изучаются процессы разработки ПО.
()собенностям разработки ERD-диаграмм здесь также уделяется недостаточно
внимания, не раскрываются такие важные понятия, как опциональные отношения,
ассоциативные объекты, обособленные ассоциативные объекты, производные отношения или

Методы анализа и разработки проекта 761
ссылочная целостность. Перечисленные темы очень важны, и разработчик всегда
может найти исчерпывающую информацию соответствующей литературе.
Ознакомившись со ссылками, нетрудно убедиться в том, что существует множество
источников информации по структурному анализу и моделированию данных, к которым могут
обращаться аналитики и дизайнеры. Некоторые из этих книг обязательно должны
быть в личной библиотеке программиста.
Сущности
Диаграммы ERD состоят из полей, отображающих сущности, и линий,
показывающих отношения между ними. Основная система обозначений показана на рис.22.2.
Сущность представляет собой "нечто такое, данные о котором нужно сохранять".
В ходе предварительного анализа разрабатываемой системы существительные (файлы,
хранилища данных, создаваемые элементы, функциональные роли, выполняемые
людьми, предметы, используемые в качестве орудий либо для поставок и контроля
над другими предметами и т.п.) предоставляют "путеводную нить" по направлению к
сущностям. События или действия также могут быть сущностями: "визуальная
инспекция", к примеру, является этапом при выполнении процесса, который может
выступать в качестве сущности.
Объект данных
Мощность
У \
Взаимосвязи -Ц О^
Рис. 22.2. Базовая запись диаграммы взаимосвязей сущностей
Как обсуждается далее в этой главе, сущность, не является "физическим объектом",
который используется в объектно-ориентированном анализе. Объект в объектно-
ориентированном смысле включает в себя данные и функцию; он состоит из данных и
методов (процедур, функций, операций), которые могут обрабатывать эти данные.
Объект в смысле "сущность" является представлением только данных, причем он не
является объектом в исходном смысле этого слова. "Автор" является сущностью; "Боб
Фатрелл" является экземпляром этой сущности. Пример обычно занимает одну строку в
таблице реляционной базы данных. Сущность имеет следующие характеристики.
■ Каждая сущность в системе должна быть идентифицирована. Она существует и
отличается от других сущностей. Этот объект может быть конкретным, например,
таким, как штаты в Соединенных Штатах, книги в библиотеке или автомобили.
Объект может быть абстрактным, т.е. таким, как событие (совершение покупки,
празднование). Объект представлен набором атрибутов или характеристик.
■ Между отдельными экземплярами сущности должна быть дифференциация.
Сущности применяют разные атрибуты для различных экземпляров.
■ По крайней мере, один атрибут или комбинация атрибутов должна уникальным
образом идентифицировать каждый экземпляр сущности. (Этот атрибут и станет
"первичным ключом" реляционной базы данных.)
■ Каждая сущность должна играть в системе определенную роль. Если система может
функционировать без участия сущностей, она не принадлежит к диаграмме ERD.
■ Атрибуты сущности отображаются в виде списка, озаглавленного названием
сущности. Атрибуты первичного ключа отмечены звездочкой, как показано на рис. 22.3.

762 Глава 22
Заказ
* Идентификатор
заказа
Заказчик
Дата
Рис. 22.3.
Диаграмма взаимосвязей
сущностей
Атрибуты
Атрибут является уникальной характеристикой сущности. Например, объект
"Покупатель" должен иметь такие атрибуты, как "Имя", "Адрес", "Индекс",
"Идентификационный номер покупателя" и т.п.
Отношения
Отношения определяют связи между сущностями. Каждое отношение
представляет связь между двумя сущностями. Мощность множества эквивалентна количеству
отношений, устанавливаемых между двумя сущностями. Примеры величин мощностей
множеств перечислены ниже:
■ один к одному;
■ один ко многим;
■ нуль (дополнительно);
■ многие ко многим.
Величина мощности указывается путем указания символов на линии,
соединяющей две сущности.
Как показано в верхнем поле рис.22.4, отношение "один ко многим" показывает,
что каждый уровень содержит один или больше линейных элементов. Каждый
элемент содержится на своем собственном уровне.
Заказ
Содержит
К Элементлинии
ОДИН КО МНОГИМ
Менеджер
Управляет
1 |
1 1
"один годному"
Отдел
поставляет
Поставщик |5Н Н^ Продукт
многие ко многим
Рис. 22.4. Мощность отношений сущностей

Методы анализа и разработки проекта 763
Среднее поле иллюстрирует отношение "один к одному". Каждый менеджер
руководит одним отделом; в свою очередь, каждый отдел управляется одним менеджером.
Нижнее поле демонстрирует отношение "многие ко многим". Каждый поставщик
поставляет один или большее количество продуктов. Каждый продукт поставляется
одним или большим количеством поставщиков.
Определение сущностей, их отношений и атрибутов не относится к области
точных наук, а является тем умением, которое приходит с опытом. Хороший путь для
начинающего специалиста в этом случае — беседы с пользователями, приглашение их на
сеансы "мозгового штурма", поиск существенных особенностей в имеющихся
документах и отчетах и, как всегда, применение аналитических знаний с целью
понимания сути пользовательского приложения.
Сразу де после формулирования новых сущностей и атрибуты происходит их
помещение в словарь данных. Даже если определение не является четко
сформулированным, все равно оно должно быть внесено в DD-диаграмму и служить накопителем
для собранной в дальнейшем информации.
Нормализация
Менеджеры программных проектов, как правило, сознают важность
нормализации, даже если они не в состоянии самостоятельно выполнить эту работу. Изучение
формирующегося хранилища данных может потребовать больше времени на этапе
моделирования, однако, мышление "на перспективу" приводит к существенной
экономии усилий. Нормализация означает реструктуризацию данных с целью
устранения избыточной информации и случайных связей, а также усиления степени
гибкости модели. Избыточная информация "засоряет" дисковое пространство и усложняет
техническую поддержку. Если в существующие данные будет внесено несколько
изменений, потребуется соблюдение строгой идентичности и синхронности.
Идеи, на которых основано применение нормализации, поразительно просты.
Просто следует создать набор файлов для реляционной базы данных. Сюда требуется
включить все требуемые данные, что и обеспечивает разрабатываемая база данных.
Также этот набор файлов должен иметь как можно меньше избыточной информации,
аккумулировать несколько значений для определенных типов данных, разрешать
эффективные обновления данных в базе данных и не допускать потери данных .
Кроме процесса устранения избыточной информации и усиления степени гибкости,
нормализация снижает риск появления аномалий при обновлении (идентичные
данные, сохраняемые в различных местах, могут стать несинхронными), аномалий
поддержки при добавлении (новые данные не сохраняются требуемым образом), аномалий
при устранении информации (исключение данных, которые не связаны с теми,
которые предназначены для устранения; ошибочное удаление нужной информации).
Перед началом выполнения нормализации данных можно выполнить чистку
глобальной модели данных. Некоторые ненужные сущности из модели устраняются.
Внимательно рассмотрите те из них, которые состоят только из одного
идентификатора, сущности, включающие один экземпляр, сущности, связанные с обособленными
ассоциированными сущностями (для которых имеется только один экземпляр) и
производные отношения (которые могут быть учтены). Все эти сущности являются
"кандидатами на удаление".
Wvllys R.E. "Overview of Normalization: Introduction". LIS 384К.П, Database Management
Principles and Applications. The University of Texas at Austin Graduate School of Library and
Information Science, 2001.

764 Глава 22
Существует пять степеней нормализации, которые называются нормальными
формами. Первые три очень важны; остальные две становятся понятными при более
глубоком изучении. Модели можно представлять как результат успешных
преобразований данных. Обычно аналитики признают, что ERD-диаграммы корректно
построены и реализованы в качестве реляционной базы данных, которая находится
и третьей нормальной форме (что и неплохо для большинства операций). Однако
аналитики не всегда могут начинать с "чистого листа". Чаще бывает так, что в
системной среде уже существуют наследственные данные или созданные вручную
формы. Эти данные обычно не подвергаются нормализации, содержат несопоставимые
элементы, недостаточно четко соотносящиеся друг с другом, а также включают
повторяющиеся группы. И эти их следует перестроить в нормальные формы до того,
как будет создана новая или усовершенствована старая база данных.
Поэтапное преобразование ненормализованных данных, от первой до пятой
нормальной формы, в этой главе рассматривается на примере Daisy Hill Puppy Farm. Этот
пример обычно приводил Марк Реттинг (Marc Retting) в статьях из журнала Database
Programming & Design. В "некоторое объединение" щенков входит определенное
количество этих созданий. Каждый щенок обучен или обучается некоторому количеству
трюков. Владельцы объединения заинтересованы в удобном размещении щенков,
которые могут выполнять определенные трюки. Таким образом, облегчается выбор
определенного щенка для показа предполагаемым клиентам (циркам, агентам Голливуда
и т.д.). Имеющаяся система опирается на форму записи возможностей щенка, которая
показана на рис.22.5. Аналогичная форма заполняется для каждого щенка, который
обучен, как минимум, четырем трюкам. Сведения подобного рода заносятся
карандашом на обратной стороне формы. Ненормализованные данные, или данные
в "необработанной" форме (имя, номер), данные о происхождении (код, имя,
местонахождение) и трюк (имя, костюм, место обучения, навыки).
Пример Daisy Hill Puppy Farm Normalization Exercise, созданный Марком Реттингом,
широко используется в общедоступной предметной области. Соответствующие примеры
можно найти:
- fiat.gslis.utex.as.edu/~1384kllw/rw38411.html. R.E. Wyllys. "Overview of
Normalization". LIS 384K, "Database-Management Principles and Applications". The University
of Texas at Austin Graduate School of Library and Information Science, 2001.
- ola. aacc. cc.md.us/csil22/norm/datanorm.html. Kari Siner. "Personal Computer
Database Management System with Microsoft Access 2000". CSI 122. Arnold, MD: Anne
Arundel Community College, 2001.
- l'heatt Chuck. Computer Science CS 444. Emporia State University, Emporia, KS, 2000.
- Retting Marc. "Five Rules of Data Normalization". Poster for Database Programming & Design, San
Francisco, CA: Miller Freeman Publications, 1992.
- stein.cslil.org/genome_informatics/sqll/lecture_notes.htmL Robert Peitzsch. Genome Informatics,
SQL and Relational Database Section, Genomic Informatics Class, CSHL. Stein Laboratory,
Cold Spring Harbor Laboratory, Cold Spring Harbor, NY, 1999.
- Wiorkowski, Gabrielle и David Kull. DB2: Design and Development Guide, 3-е издание.
Reading, MA: Addison-Wesley, 1992.
- www.bal(lwinw.cdu/~gbouw/courses/csc280/puppy.htmL Gerardus Bouw. Department of Math
and Computer Science, CSC 280. Baldwin-Wallace College, Berea, OH, 2001.
- www. support. lotus. com/simsold. nsf /. Lotus Customer Support Technote. "The Five
Rules of Database Normalization", 1998.

Методы анализа и разработки проекта 765
Щенки Daisy Hill: информация о щенке
Номер-, (идентификатор щенка) Имя: (кличка щенка) Порода: (порода щенка)
Код породы:
Название питомника:
Местоположение
питомника:
Трюк
(идентификатор,
имя, описание)
Костюм
(идентификатор,
название, описание)
Место обучения
Уровень навыков
A-10,10—наивысший)
Рис. 22.5. Пример ненормализованной формы, описывающей собачий питомник
Код
питомника
Название
питомника
Местоположение
питомника
Номер щенка
Кличка щенка
Порода щенка
Идентификатор трюка
Название трюка
— Описание трюка
Место изучения трюка
Уровень навыков трюка
»
/
Идентификатор костюма ^ I \
Название костюма \
Описание костюма
Рис. 22.6. Глобальная ЕШ)*)иаграмма, составленная для примера с собачьим питомником
При первом введении записей в файл предполагалось, что ни один из щенков за
время обучения не сможет выучить более 12 трюков. Но один щенок, обычный пудель
по кличке Буллит де Вианде, выучил более 20 трюков. Это повлекло за собой
"разбухание" файла, но наряду с этим его большая часть осталась незаполненной,
потому что в среднем щенок обучался только четырем из возможных 20 трюков. Кроме

766 Глава 22
того, большинству агентов Голливуда требуются щенки, которые знают
специфические трюки. Перед нормализацией потребовалось изучить весь файл, содержащий
сведения о 697 щенках, с целью установки требуемого соответствия.
Глобальная ERD-диаграмма, содержащая информацию о собачьем питомнике,
может быть представлена, как показано на рис.22.6.
Правило I. Первая нормальная форма ANF) определяет, что в таблице нет
повторяющихся строк, в каждой ячейке содержится только одно значение (нет повторяющихся групп или
массивов), и записи в колонках таблицы отличаются такой же особенностью. Чтобы
получить 1NF, исключите повторяющиеся группы.
Предположим, что информация из индексных карточек введена в некоторую базу
данных. Чтобы эта информацию соответствовала правилам 1NF, нужно образовать
отдельную таблицу для каждого набора связанных данных и придать каждой из них
первичный ключ, причем в отдельной таблице для хранения подобных данных
нельзя использовать несколько полей. Последовательность строк не играет важной роли.
Требование, состоящие в том, что в таблице не должно быть повторяющихся строк,
означает и наличие ключа (хотя он может состоять более чем из одной колонки).
Заметьте, что в данном случае данные могут содержать несопоставимые элементы,
нечетко связанные друг с другом, и остается опасность возникновения аномалий при
обновлении и удалении.
Исключение повторяющихся групп проиллюстрировано на рис.22.7 и 22.8. Теперь
сформированы две таблицы: таблица щенков и таблица трюков. Таблица трюков
имеет первичный ключ, который является многозначным или "композиционным"
ключом, состоящим из номера щенка и ID трюка.
Ненормализованные элемеш
♦ Номер щенка
♦ Кличка щенка
* Код питомника
* Название питомника
* Местоположение питомника
♦ Трюки щенка
• Идентификатор трюка 1
• Название трюка 1
• Изучаемый трюк
• Уровень навыков 1
• Идентификатор трюка 2
• Название трюка 2
• Место изучения трюка
• Уровень навыков трюка 2
• Идентификатор трюка п
• Название трюка п
• Место изучения трюка п
• Уровень навыков п
Рис. 22.7. ERD-диаграмма для примера с щенками до применения правила нормализации

Методы анализа и разработки проекта 767
Таблица щенков
Номер щенка
Кличка щенка
Код питомника
Название питомника
Местоположение питомника
Номер щенка
Идентификатор трюка
Название трюка
Место изучения трюка
Уровень навыков
Рис. 22.8. ERD-диагрчмма для примера со щенками после применения правила
нормализации
Правило 2. Вторая нормальная форма BNF) определяет, что таблица находится в 1NF,
и атрибуты, не являющиеся ключевыми, полностью зависят от ключа. Чтобы получить 2NF,
исключите избыточные данные.
Если атрибут зависит только от части многозначного ключа, переместите его в
отдельную таблицу. Неключевое поле, содержащее ключи, должно поддерживать
некоторые факты, имеющие отношение к целому ключу. Установите связь между
таблицами с помощью внешнего ключа. Обратите внимание, что поля, определяющие
ключевые данные, содержат описание только ключа и разъяснения, относящиеся к целому
ключу (слово "целый" означает, что ключ может иметь сложную природу). Все
элементы, не являющиеся ключевыми, функционально полностью зависят от
первичного ключа. Данные в таблице могут описывать элементы данных из этой таблицы,
которые не являются ключевыми. По-прежнему велика вероятность появления
аномалий обновления данных и их удаления.
Далее обратитесь к рис. 22.9. В таблице трюков первичный ключ включает номер
щенка и идентификатор трюка. Подобный подход имеет смысл при использовании
атрибутов "где обучалась" и "навыки", поскольку эти атрибуты отличаются для любой
комбинации щенок/трюк. Однако название трюка зависит только от
идентификатора трюка. Одно и то же название выступает в качестве избыточной информации,
поскольку связанный с ним идентификатор (ID) отображается в таблице трюков.
Предположим, что необходимо заново провести классификацию трюков, то есть
каждый трюк получает иной идентификатор. Изменения коснутся каждого щенка,
который выполняет данный трюк. Если же вы допустите ошибку, несколько щенков,
исполняющих один и тот же трюк, получат различные идентификаторы, что
приведет к аномалии при обновлении данных.
Или предположим, что последний щенок, выполняющий определенный трюк,
''получил назначение" и переехал в Лос-Анджелес. Записи, относящиеся к этому щенку,

768 Глава 22
Номер щенка
52
53
54

Идентификатор трюка
27
16 f
27 Л
Название трюка
Кувырок
Стойка на носу
Кувырок
Место изучения трюка
16
9
9
Уровень навыков
9
9
9
Рис. 22.9. Второе правило для ЕШМиаграммы, описывающей пример со щенками
удаляются из базы данных, и трюк полностью "теряется". Так проявляется аномалия,
связанная с операцией удаления. Чтобы избежать такого положения, воспользуемся
второй нормальной формой.
Чтобы получить подобную форму, отделите атрибуты, зависящие от двух частей
ключа, от тех атрибутов, которые связаны с идентификатором трюка. В результате
получится два объекта: таблица трюков, содержащая название для каждого
идентификатора трюка, и таблица трюков, выполняемых щенками, в которую входят
действия, разученные каждым щенком.
Таблица трюков отражает лишь тематику. Таблица трюков, выполняемых
щенками, также посвящена одной теме. Здесь отражены отношения между отдельными
щенками и трюками, которые они разучили. В таблице трюков, выполняемых
щенками, атрибут трюка "где обучался" четко зависит от двух частей ключа. Дело в том, что
данный атрибут базируется не только на сведениях об определенном трюке, но также
на информации о том, где именно данный щенок обучался этому трюку. Аналогичное
замечание справедливо и для атрибута "навыки", поскольку данный атрибут
базируется не только на сведениях об определенном трюке, но также на информации об
уровне мастерства щенка при выполнении данного трюка.
Теперь проведем повторную классификацию трюков в "одно" действие: найдем
идентификатор трюка в таблице трюков и изменим его название. Данный результат
незамедлительно станет доступен всему приложению.
Удобно выделить все данные о трюках в отдельную таблицу. Это приведет к
сокращению ее размеров, поскольку сюда будет включено имя каждого щенка,
разучившего пятнадцатый трюк. Если последний щенок, умеющий выполнять пятнадцатый
трюк, переедет в Лос-Анджелес, соответствующая запись удаляется и все сведения о
пятнадцатом трюке будут утеряны.

Методы анализа и разработки проекта 769
Правило 3. Таблица находится в третьей нормальной форме CNF), если она находится в
2NF и не имеет транзитивных зависимостей. Для перехода к 3NF, удалите столбцы, не
зависящие от ключа.
Если атрибуты не участвуют в описании ключа, переместите их в отдельную таблицу.
Колонка, содержащая сведения, которые не относятся к ключевым данным, должна
описывать какой-либо факт, связанный с ключом, т.е. ключ в целом и ничего, кроме
ключа. Если поле не описывает ключ в целом, переместите его в отдельную таблицу.
В общем случае, если содержимое группы полей может применяться более чем к одной
записи в таблице, перемещайте эти поля в отдельную таблицу. Иногда эти действия
трактуют как удаление транзитивных зависимостей. То есть данные описывают поле
таким образом, что содержимое поля, в свою очередь, описывает ключ.
Обратите внимание, что все элементы, не являющиеся ключевыми, полностью
зависят от первичного ключа и не связаны друг с другом. Обычно, третья нормальная
форма CNF) достаточна для формирования эффективной структуры базы данных.
Если база данных создана с использованием четко очерченной ERD-диаграммы,
вполне вероятно, что она находится в 3NF.
Теперь обратимся к рис. 22.10. Таблица, включающая описания щенков,
соответствует первой нормальной форме — не содержит повторяющихся групп. Также
она соответствует и условиям второй нормальной формы, поскольку в ней
отсутствуют многозначные ключи. Однако ключ определяет номер щенка, а название
всей группы и расположение группы описывается только с помощью
определенного наименования. Чтобы получить третью нормальную форму, необходимо
переместить название группы в отдельную таблицу. Код группы становится ключом
таблицы новых групп.
Обоснование здесь такое же, как и при формировани второй нормальной
формы: желательно избегать аномальных обновлений и удалений информации.
Например, предположим, что в настоящее время в базе данных отсутствуют щенки
из "объединения черных щенков Бэда". Учитывая предварительное замечание, не
будет и записи о том, что они существуют!
Таблица групп посвящена одной теме. Таблица щенков тесно связана с однотем-
ной таблицей, поскольку в ней сосредоточены сведения о щенках и соответствующих
им номерах. Если дело будет обстоять так, что ни один из щенков не входит только
в одну группу, можно воспринимать таблицу щенков как однотемную. Если же щенки
иногда совершаются переходы из одной группы в другую, таблица щенков перестанет
быть однотемной. Необходимо внести обновления, которые помогут при обработке
подобной информации.
Правило 4. Таблица находится в четвертой нормальной форме DNF), если она находится в
3NF и каждый детерминант является ключом-кандидатом (она также известна как
Нормальная форма Bouca-Kodda(Boyce-Codd) - BCNF). Для получения 4NF изолируйте независимые
многократные отношения.
Третья нормальная форма достаточна для большинства ситуаций. Однако для
определенных целей она все же не подходит, а поэтому обращаются к правилу 4 —
таблица не может включать два или больше отношений 1:п или п:т, которые не
связаны непосредственно. Форма 4NF изолирует независимые многократные
взаимосвязи. Если в таблице хранятся два различных факта, каждый из которых описывает
ключ, ключ в целом и ничего, кроме ключа, но эти факты не имеют между собой
значительной связи, их следует распределить по отдельным таблицам.

770 Глава 22
Вторая нормальная форма
Рис. 22.10. Пример реализации третьего правила для ERD-диаграмм,
включающих описание щенков
Подобный подход можно реализовать, применяя связи "один ко многим" и
"многие ко многим". Одна группа может включать большое количество щенков, что и
является примером связи "один ко многим" (рис. 22.11). Примером связи "многие ко
многим" служит отношение щенка к трюкам (щенок может выполнять много трюков,
а несколько щенков способны выполнить один трюк).
Предположим, что в таблицу трюков, выполняемых щенками, нужно добавить
новый атрибут "костюм" (примечание 22.1). Тогда можно найти щенков, которые умеют
"стоять на шаре" в маске Регис Филбин. И эти два требования не связаны друг с другом.
Именно для этой цели и служит четвертая нормальная форма. Рассмотренные два
атрибута не образуют вместе важного качества. Щенок умеет ходить на руках и может
выполнять трюки во влажной одежде. Отсюда не следует, что обе эти возможности
реализуются одновременно. Как можно отобразить эти особенности, если оба
атрибута представлены в одной таблице?
Здесь номер щенка определяет четко обозначенные идентификаторы трюков и
костюмов. В результате получилась многозначная зависимость. Как же в этом случае
предотвратить появление аномалий? Разделим таблицу трюков щенков на две
таблицы, где будут указаны трюки щенков и их костюмы.
Форма 4NF в этом примере включает таблицы в форме 3NF плюс две новые
таблицы для трюков и костюмов щенков. Обратите внимание, что таблица костюмов
щенков имеет составной первичный ключ, который образован из двух ключей
другой природы. Соответственно использованы таблицы щенков и костюмов, что
и показано на рис. 22.12.

Методы анализа и разработки проекта 771
Рис. 22.11. Отношение "один ко многим" в примере с питомником щенков
Примечание 22.1. Пример реализации правила 4-й нормальной формы
для ERD-диаграммы
Правило 5. Таблица имеет пятую нормальную форму ENF), если она находится в 4NF и
если каждая объединяющая зависимость в таблице является следствием ключей-кандидатов
таблицы. Чтобы получить таблицу в 5NF, изолируйте сематически связанные
множественные отношения.
Разделение логически связанных отношений "многие ко многим" может быть
оправдано практическими соображениями.

772 Глава 22
Обычно связанные атрибуты "выступают" вместе. Например, если необходимо
отобразить, какие трюки может выполнять каждый из щенков в определенном
костюме, необходимо сохранить в таблице трюков щенков атрибут "костюм". Однако
иногда специальные характеристики данных таковы, что эффективнее разделить
даже логически связанные атрибуты.
Третья нормальная форма
Рис 22.12. Правило 4-й нормальной формы для ERD^uazpoMMu примера со щенками
Представим, что в базе данных содержится запись о породах щенков в каждой из
групп, а также о том, от какого производителя получены щенки, находящиеся в этих
группах. Таким образом появляется таблица в четвертой нормальной форме,
содержащая сведения о группе-породе-производителе. Поскольку в каждую группу
могут входить щенки любой породы и от любого производителя, такой подход вполне
приемлем. Рассмотрите рис. 22.13 как пример таблицы в 5NF.
Рис 22.13. Форма 5NF для ERDJuae-
раммы примера со щенками
Предположим, что вышел закон, препятствующий образованию эксклюзивных
объединений: группа, предлагающая на продажу щенков конкретной породы,
вынуждена предлагать всех известных ей производителей. Предположим, что группа желает

Методы анализа и разработки проекта 773
предложить три новые породы: спаниели, таксы и банановые пудели. Далее
предположим, что собаки поступают от трех производителей. Тогда в базе данных
потребуется девять новых строк, по одной для каждой комбинации производитель/порода.
Конкретный пример приводится на рис. 22.14.
Q
Питомник-порода
Номер питомника
Порода
Производитель-порода
Производитель
Порода
-L** ii^aisA.,*.
5
5
5
Спаниель
Такса
Банановый пудель
5
5
5
Пик
Фабрика
щенков
Вотапаппи
Пик
Пик
Пик
Фабрика щенков
Фабрика щенков
Фабрика щенков
Вотапаппи
Вотапаппи
Вотапаппи
Спаниель
Такса
Банановый пудель
Спаниель
Такса
Банановый пудель
Спаниель
Такса
Банановый пудель
Рис. 22.14. Правило 5-й нормальной формы для ERD-диаграммы примера со щенками
При разбиении таблицы количество вставок уменьшается до шести. Здесь
приводятся таблицы, которые необходимы для образования пятой нормальной формы.
Полужирным шрифтом выделены шесть заново включенных строк. Если приложение
выполняет ответственную работу по обновлению, пятая нормальная форма может
применяться для реализации важных операций по сохранению данных. Заметим, что
обычно рассмотрение данной комбинации таблиц не входит в задачи по анализу
взаимосвязей между объектами.
Правила, приводящие к формированию третьей нормальной формы и
регламентирующие этот процесс, можно суммировать в едином утверждении. Каждый атрибут
представляет собой фактически ключ, ключ в целом и не может представлять ничего,
кроме ключа.
Кратко резюмируя изложенные сведения, можно заключить, что моделирование
данных представляет собой просмотр данных с учетом трех системных
представлений (данные, функция и поведение). При этом используются методы структурного
анализа (разработки проекта). Наиболее распространено применение такой модели
данных как диаграмма взаимосвязей объекта (ERD). Эти диаграммы часто
конструируются таким образом, что при ее использовании в качестве проектного документа,
встроенные в нее структуры данных уже являются нормализованными. Однако
большинство аналитиков и разработчиков ПО не могут позволить себе формировать
структуры данных изначально. Довольно часто им приходится иметь дело с
существующими данными и обрабатывать их автоматизированным способом или же

774 Глава 22
в ручном режиме. Обычно эти данные не являются нормализованными. При
формировании на основе данных в формах INF, 2NF и 3NF обеспечиваются
следующие преимущества:
■ постоянство — затрудняется появление аномалий, связанных с обновлением или
удалением данных;
■ удобство в применении — легкость представления;
■ гибкость;
■ точность— использование алгебры отношений и проведение сравнительных
вычислений;
■ легкость, с которой можно реализовать элементы управления мерами
безопасности;
■ простая связь между атрибутами из различных объектов/файлов/баз данных;
■ удобство при внедрении;
■ независимость данных;
■ ясность.
Аналитик/разработчик находит и нормализует существующие данные (вручную
или с применением автоматизированных методик), моделирует их с помощью ERD-
диаграмм для разрабатываемой системы и затем добавляет "новые" данные. Модель
"вырисовывается" постепенно. Сначала появляются основные сущности, затем
добавляются связи, присоединяются ключи, а только затем — другие сущности.
Структурный анализ SA/SD: модели процессов
Информация, передаваемая программам, модифицируется с помощью набора
преобразований. Диаграмма потока данных (Data flow diagram, DFD) представляет
графическую методику, которая описывает поток информации и те преобразования,
которые применяются к данным при их перемещении от устройства ввода к
результату. Эта диаграмма применяется при графическом моделировании данных; рисунки
помогают рассмотреть подробности и облегчают знакомство со всей структурой. При
условии незначительной предварительной подготовки пользователи могут
участвовать в создании графических набросков.
Процесс моделирования представляет возможность для описания функций,
выполняемых системой. Хотя при этом описываются данные, передающиеся через
систему, в описание не входят статические связи между данными, сохраняемыми
в системе, как это показано в ERD-диаграмме. Также не отражены особенности
поведения системы во времени. Модель процесса описывает преобразования данных
в системе, предлагая обзор функциональных особенностей с учетом трех "точек
отсчета" системы (данных, функций, поведения).
Диаграмма содержимого данных
Диаграмма содержимого данных (Data context diagram, DCD) является
высокоуровневой диаграммой потока данных. Она отражает "картину" системы в целом
и интерфейсы внешних объектов или систем. Также отображается граница между
системой и средой, перспектива с учетом реальных запросов, идентифицированы все
сетевые вводы и выводы. Если выполняется лишь один процесс, система
представляет собой "черный ящик". Представлены все преобразования, реализуемые системой.

Методы анализа и разработки проекта 775
Система обозначений для DCD-диаграмм продемонстрирована на рис. 22.15. Сюда
входят поля (объекты, находящиеся вне системы), отмеченный поток данных
и "система".
Внешняя сущность (терминатор)
Квадрат (прямоугольник) обозначает объект или систему, которая находится
вне изучаемой системы. Внешний объект может входить в другую компьютерную
систему, представлять пользователя, организацию или физическое устройство,
находящееся вне контекста системного определения. Каждый из этих специальных
объектов представляет данные из передающего источника или информацию,
получаемую по назначению. И хотя важно провести идентификацию всех объектов,
взаимодействующих с системой, особо тщательно следует рассматривать только те
из них, которые реально взаимодействуют с системой. Они отображаются только
в DCD-диаграммах (но не в DFD-диаграммах), когда модель системы подвергается
поэтапным усовершенствованиям.
Внешняя сущность может служить источником данных, получаемых системой,
оболочкой для данных, формируемых системой или же совмещать обе эти функции.
В названии используют имя существительное, причем выбирают имя,
идентифицирующее объект, с которым связана система. Применяемое название не обозначает
процесс обработки.
Данные, формирующие поток между внешним объектом и системой,
представлены с помощью интерфейсов между системой и ее средой. Внешние
объекты не контролируются системой, создатель модели не может ими
манипулировать. Могут существовать и отношения между терминаторами, но они не
моделируются в DCD-диаграммах, поскольку обычно интересуются только
пограничными состояниями системы, находящейся в разработке, а также объектами, с
которыми она взаимодействует.
Процесс
Пузырек иллюстрирует процесс по преобразованию вводных данных в результаты.
Символически этот процесс представлен названием и номером. Название процесса,
представленного с помощью круга, должно отражать все процедуры, которые он
включает. В названии используется глагол, отражающий те действия, которые выполняются
с определенным объектом или группой объектов (именем существительным). Название
представляет глагольно-объектную фразу, процесс представляет действия,
воспринимаемые системой. Данные можно преобразовывать только с помощью процессов.
Внешняя
сущность
©Объект данных
Рис. 22.15. Диаграмма системы обозначений для
содержимого данных
Поток данных
Кривая линия демонстрирует поток данных, поступающих в процесс или
выводящихся из него, а также может обозначать хранилище данных. Поток данных является
"каналом", по которому перемещаются пакеты, входящие в поток данных. При этом

776 Глава 22
данные описываются в динамике. Символически это обозначается кривой линией,
которой присвоено соответствующее имя. Здесь применяется имя существительное
и не выполняется какая-либо дополнительная обработка. Название представляет
содержимое потока, который может представлять собой единый элемент данных или
группу элементов. В потоке может отображаться более одного названия элемента
данных. Поток поддерживает только один тип информации, как указано с помощью
его названия. Если требуется смоделировать поток на основании двух различных
типов информации (например, заказчики и счет-фактуры), создайте два потока
данных. Каждый поток данных должен отображаться в словаре требований и составляться
из примитивных элементов.
Классический пример — задача о лифтах, описанная в примечании 22.2.
Примечание 22.2. Задача о лифтах
DCD-диаграмма для задачи о лифтах показана на рис. 22.16. Внешними сущностями
являются пользователь и лифт; потоки данных включают информацию о нажатии кнопки,
подсветке кнопки, лифтовых командах и сведения о местоположении лифта. В данном
случае имеется только один процесс, "система", реализующая управление лифтом.
Диаграммы потоков данных (DFD)
DFD-диаграммы представляет картину системы как сети функциональных
процессов, соединенных между собой "каналами" данных (потоков данных) и содержащих
хранилища данных. Процессы преобразуют информацию. При использовании этой
диаграммы система разбивается на составные части.
DFD-диаграммы позволяет воспользоваться системой символов для процессов,
потоков данных и хранилищ данных. Заметим, что внешние записи не отражены
в DFD-диаграмме (показаны лишь хранилища данных). Не указываются терминаторы
им DCD-диаграммы; сохраняется только информация, поступающая в виде потока
в систему и выходящая из него (поток данных), один основной круг процесса
разлагается на несколько более четко очерченных процессных кругов. Система обозначений
DFD-диаграмм приведена на рис. 22.17.

Методы анализа и разработки проекта 777
Нажать кнопку
Команда
управления
лифтом
Местоположение,
лифта
Лифт
Рис. 22.16. Диаграмма содержимого данных для
примера с лифтом
Пузырек иллюстрирует процесс, преобразующий вводные данные в выходные
результаты. Кривая линия демонстрирует поток данных, поступающих в процесс и
исходящих из него (или отображает хранилище данных). Набор параллельных линий
показывает совокупность пунктов данных, которые не перемещаются, и местонахождение
данных. Хранилище данных определяет хранение информации где-либо с целью
дальнейшего применения. Сюда могут включаться отдельные элементы или группы
элементов. Для названия используется имя существительное, определяющее содержимое
хранилища данных. Название не должно включать определение процесса. Оно должно
подходить для пакетов данных, поступающих в хранилище и исходящих из него.
Данные, сохраняемые в DFD-диаграммах, соответствуют объектам в диаграмме отношений
объекта. Обычно название в DFD-диаграмме отражает несколько характеристик, а
название в ERD-диаграмме — одну из них. Каждое хранилище данных должно
отображаться в словаре требований и формироваться из простых элементов.
/ Д Объект данных Хранилище данных
I Процесс I — ►
Рис. 22.17. Система обозначений для диаграммы
потока данных
Хранилища и потоки данных
Поток информации, поступающий в хранилище данных и исходящий из него,
распределяется на входящий или выходящий потоки. Если поток данных, входящий или
исходящий из хранилища, включает находящуюся там информацию, ему можно не
присваивать имя. Это означает, что полный экземпляр пакета данных направляется
в хранилище или извлекается из него. Например, если при обновлении хранилища
Customers (Заказчики) добавляются или заменяются все записи, относящиеся к
заказчикам, входящий поток можно оставить без названия.
Если же поток, направленный в хранилище или выходящий из него, содержит
подмножество хранящихся там сведений, следует обязательно присвоить ему имя.
Имя требуется, если, например, система осуществляет выборку телефонных номеров

778 Глава 22
заказчиков или все названия, соответствующие определенному Zip-коду. Словарь дан-
пых указывает хранилище данных, а также определяет все элементы, которые
поступают в хранилище или исходят из него.
Потоки данных перемещаются между пузырьками. На низкоуровневой DFD-
диаграмме данные, исходящие из круга, показаны в виде потока без терминатора.
Данные, направляемые в круг, показаны на DFD-диаграмме невысокого уровня как данные,
поступающие из неизвестного источника. Конечно, в данном случае существуют
терминаторы и источники; просто они отображаются на диаграмме более высокого уровня.
Единственной областью, где приветствуются избыточные данные, являются
хранилища данных. Хранилище данных отображается на самом высоком уровне, причем
изначально оно используется в качестве интерфейса между процессами (и не следует
отображать его на более высоких уровнях). Затем такое же хранилище данных
отображается на любой диаграмме более низкого уровня, которые используются для
дальнейшего разбиения "пузырьков" интерфейса.
Потоки данных можно разделять и комбинировать. При разбиении можно указать
полное содержимое потока, направленного в более чем одно место (дублирование
копий пакетов данных). В этом случае необязательно разделенным потокам
присваивать различные названия. Разделение также может состоять в дроблении на элементы
или подгруппы. Таким образом пакет сложных данных разбивается на несколько
более простых пакетов данных. В этом случае следует именовать каждую подгруппу.
Скомбинированные данные показаны, как и данные, которые разделяются, но
стрелки при этом направлены в другую сторону. Здесь применяются аналогичные правила
наименования. Разбиения и разделение потоков данных показаны на рис. 22.18.
Содержимое потока в целом распределяется
по нескольким местам
Счета-фактуры
Счета-фактуры
по контрактам
jf на приобретение
Счета-фактуры,
не имеющие отношение
к почтовым переводам
Сложные пакеты данных могут распределяться на несколько
более простых пакетов данных
Рис. 22.18. Потоки данных можно разбивать и делить на части

Методы анализа и разработки проекта 779
Высокоуровневая DCD-диаграмма для примера с лифтом показана на рис. 22.19. На
этом рисунке процессами являются анализ нажатия кнопки, формирование
команды лифта и подсветка кнопок; хранилище данные называется команды лифта;
потоками данных являются нажатие кнопки, выбор этажа, расположение лифта,
команда лифта и подсвеченная кнопка. Поскольку данные, которые перемещаются
между хранилищем данных и процессом формирование команды лифта, не
отмечены, можно потребовать, чтобы было доступным все хранилище данных. Поток
данных выбор этажа можно отобразить как разделенный поток данных. Сетевые
вводные и результирующие потоки соответствуют этим замечаниям на DCD-диаграмме.
Подсвеченная кнопка
Нажать кнопку
Местоположение
лифта
Рис. 22.19. Нулевой уровень DFD-диаграммы для примера с лифтом
Функциональная декомпозиция (разбиение на уровни)
DFD-диаграмма представляет систему в качестве сети процессов. Ее используют
для функционального разложения системы на образующие ее процессы. Для
большинства несложных систем довольно трудно отобразить одновременно все входящие
в него процессы. Обратитесь к соответствующему примеру на рис. 22.20.
Затруднительно обозреть сразу все особенности данной процедуры. Поэтому
сосредоточим свое внимание на отдельной странице. Применяемый в этом случае
принцип хорошо известен; "Разделяй и властвуй!" Приступите к серьезному анализу и
разбейте систему на подсистемы. Если подсистемы слишком велики, разделите их на
меньшие подсистемы и продолжайте этот процесс до тех пор, пока не получите некие
приемлемые объекты на каждом из уровней.

780 Глава 22
На каждом абстрактном уровне (исключая самый нижний) располагается один или
несколько пузырьков процесса. Каждый пузырек (родительский) разлагается,
образую DFD-диаграмму более низкого уровня (дочерняя), где отображается
"родительское" содержимое.
Верхний уровень представляет собой диаграмму содержимого потока,
отображающую сетевые вводы и выходы системы. Существует только одна функция,
позволяющая очертить область и границы системы. Исключая из рассмотрения самый
низкий уровень, "дочернее" содержимое характеризуется наличием большего количества
пузырьков и потоков данных. Каждый расположенный ниже уровень отображает
больше подробностей, связанных с уровнем, находящимся выше. На самом низком
уровне, где круги не могут разлагаться на составные процессы, соответствующим
инструментом для описания функциональных возможностей является PSPEC.
Рис. 22.20. DFD-диаграмма не должна содержать слишком
много пузырьков
Декомпозиция DFD-диаграммы на составные части и присвоение меток
На рис. 22.21 демонстрируется процесс декомпозиции диаграммы на составные
части с частичным применением уровней. Также показана процедура назначения
меток DCD-, DFD-диаграммам и пузырькам процессов на DFD-диаграммах.
Самым высоким уровнем для DFD-диаграммы (не следует путать с DCD-
диаграммой) является DFD 0. Заголовок этого уровня приводится в пузырьке
процесса для DCD-диаграммы. Эти круги нумеруются цифрами 1, 2, 3 и т.д. Эта
нумерация не отражают последовательности выполнения или очередности действий,
реализуемых при обработке данных.
Пузырек 3 на DFD 0 разлагается на пузырьки, относящиеся к более низкому уровню
DFD 3. Нумерация пузырьков на DFD 3 выглядит как 3.1, 3.2 и т.д. Пузырек 3.2 на DFD 3
разложим на DFD 3.2. Формат нумерации этих пузырьков имеет вид 3.2.1,3.2.2 и т.д.

Методы анализа и разработки проекта 781
Рис. 22.21. Декомпозиция DFD-диаграммы на составные части
Общее правило таково: номер DFD-диаграммы совпадает с номером "родительского"
пузырька, а название совпадает с названием этого же пузырька. Пузырьки,
находящиеся внутри, нумеруются с учетом номера DFD-диаграммы плюс десятичная точка и
дополнительная цифра: пЛ, п.2, п.Ъ и т.д. Подобное соглашение о нумерации
справедливо для каждого более низкого уровня.
Номер DFD не совпадает с номером уровня. В данном примере DFD О находится на
уровне 1; DFD 3 располагается на уровне 2 (аналогичное правило справедливо для DFD 1 и

782 Глава 22
2, которые не показаны); a DFD 3.2 находится на уровне 3 (так же, как и DFD 3.1, DFD 3.3 и
т.п., точно так же, как и DFD \.n, DFD 2.п и т.п.). Уровень DFD-диаграммы можно
определить, подсчитывая число цифр во внутренней части пузырька. "Родителя" DFD можно
обнаружить, удаляя из номера последнюю цифру: "родителем" для DFD 3.2 является DFD 3.
Представления о качественной разработке совершенствуются в процессе анализа
моделей. При конструировании DFD-диаграмм можно руководствоваться
следующими соображениями, которые окажут большую помощь при разработке и кодировании.
Группируйте вместе связанные функции, разделяйте функции, не связанные друг
с другом, исключайте из рассмотрения избыточные функции, логически связывайте
между собой пузырьки процессов (каждый из которых отображает одну и только одну
функцию), ограничивайте количество процессов, показанных с помощью одной DFD-
диаграммы до семи плюс-минус два E-9), не моделируйте процессы инициализации
или прерывания, а также применяйте автоматизированные инструменты.
Внутренняя связность (балансирование)
Балансирование предоставляет возможность удостовериться в том, что
требования являются внутренне связанными. Входные и выходные данные для каждой DFD-
диаграммы должны согласовываться с входными и выходными данными для
соответствующего "родительского" пузырька.
На самом низком уровне входные и выходные данные для спецификации процесса
(PSPEC) должны согласовываться с вводными данными и данными вывода для их
"родителя", который представлен функциональным примитивным пузырьком.
Каждый поток данных и хранилище данных нужно определить в словаре
требований. Причем все эти понятия можно разложить на примитивные элементы. Свойство
связности особенно важно при обращении к крупным проектам, где анализом и
моделированием различных частей системы заняты разные исполнители.
Следующий перечень отображает основные моменты, которые следует учитывать
при создании DFD-диаграмм.
1. Избегайте "черных дыр", пузырьков, имеющих входные данные и не
располагающих выходными данными.
2. Избегайте "спонтанного генерирования" пузырьков, имеющих вводные данные,
но располагающих данными вывода. Процесс очень редко "магическим образом"
создает новые данные.
3. Присваивайте метки всем потокам и процессам. Поток может не помечаться
только в том случае, если он содержит полный экземпляр данных хранилища,
поступающих туда или же из него выходящих. Если наименование процесса
вызывает затруднение, возможно, он недостаточно логически последователен или же
требуется получить разъяснения пользователя.
4. Отслеживайте хранилища, предназначенные только для чтения или для записи.
Корректное образование подобных хранилищ данных встречается редко.
5. Не беспокойтесь, если родительские процессы не имеют того же номера, что
и дочерние. DFD-диаграмма разлагается на составные части на различных
уровнях, поскольку одни процессы более сложны, а другие — более просты.
6. Удостоверьтесь в том, что действительно используются все входные данные процесса.
7. Постарайтесь уяснить "смысл преобразования". Можно ли сгенерировать данные
вывода на основе вводных данных?

Методы анализа и разработки проекта 783
Разбиение структуры DFD-диаграммы на уровни
Уточните, где вы собираетесь остановиться. Декомпозиция на составные части не
должна доходить до абсурда. В примере, показанном на рис. 22.21 диаграмма DFD 3.2
является наиболее реальным кандидатом для размещения на структуре DFD-диаграмм
самого низкого уровня. При этом пузырьки 3.2.1, 3.2.2 и 3.2.3 не разлагаются далее.
Затем учитываются четыре связанных с ними PSPEC, по одной для каждого пузырька.
Ниже приводятся общие правила, оговаривающие условия завершения процесса
декомпозиции:
■ содержимое пузырька на самом низком уровне может описываться в PSPEC
максимум на одной странице;
■ существует только один поток вводных данных и один поток выходных данных
(пузырек 3.2 отображен в нарушение этого правила — он не является "нерушимым");
■ в потоке данных установлены четкие взаимосвязи "один-к-одному" или "многие-к-
одному". Если пузырьки нуждаются в преобразовании, например, три входа
требуется превратить в два выхода, возможно, в дальнейшем можно выполнить
разложение на составные части.
Процессы, находящиеся на "нижнем" уровне, называют функционально
примитивными процессами. Они описываются с помощью кода PSPEC.
Преимущества представления структуры DFD-диаграмм с учетом уровней
Спецификации могут просматриваться в направлении "сверху-вниз". При
рассмотрении высокоуровневых диаграмм менеджеры смогут получить полную картину.
Пользователи и программисты, занятые внедрением, могут ознакомиться с
необходимыми подробностями, не "размениваясь" на подробности, относящиеся к другим
частям этой же системы. Каждая диаграмма является функциональной единицей,
описываемой на отдельной странице.
Большинство автоматизированных инструментов, предлагаемых на рынке ПО,
поддерживают графику, балансирование и разбиение на уровни. И хотя инструменты
не заменяют выполнения регулярных обзоров, они значительно снижают
интенсивность трудозатрат.
Спецификации процесса (PSPEC)
С помощью PSPEC описываются функции или процесс на самом низком уровне
после выполнения декомпозиции. Подобная спецификация формируется для любого
функционально примитивного процесса. То есть, она отображает, что произойдет
с каждым вводимым значением при создании требуемых выводимых результатов.
Спецификация PSPEC может находиться в форме структурного языка (псевдокода),
таблиц решений, уравнений, диаграмм, математических соотношений, блочных
диаграмм и других графических представлений. Подобно тому, как это происходит в
случае применения пузырьков процесса, с помощью PSPEC выполняется
преобразование входных данных в выходные результаты, уточняются методы обработки данными
при формировании результата. Также PSPEC проверяет условия, налагаемые на
данные, которые отражают изменения состояния системы. Процессы, не являющиеся
примитивными, разбиваются на более подробные DFD-диаграммы и не имеют
соответствующего описания PSPEC. В примечании 22.3 демонстрируется пример PSPEC,
оформленной в виде псевдокода.

784 Глава 22
Правила оформления PSPEC
Названия данных должны совпадать с теми, которые применяются в словаре
требований и DFD-диаграммах. В PSPEC необходимо воспользоваться той же
нумерацией, что и в пузырьках, которые они представляют. Например, PSPEC для
пузырька 4.3.3.1 выглядит как "PSPEC 4.3.3.1".
Основные правила, применяемые при создании PSPEC:
■ создавайте PSPEC для каждого функционального примитива;
■ не поддерживайте PSPEC для процессов высшего уровня;
■ записывайте PSPEC для описания правил, в соответствии с которыми
выполняются преобразования потоков вводных данных в потоки выходных результатов;
■ производите балансировку PSPEC с учетом "родителей". Входные и выходные
данные должны согласовываться с данными соответствующего пузырька
функционального примитива;
■ записывайте PSPEC с учетом требований четкости, недвумысленности и точности;
ш не забывайте о том, что PSPEC описывает требования, но не оказывает влияния на
специфику разработки или принятие решения по реализации.
Управляющие модели
Большинство зависящих от времени (реального времени), интенсивных и
снабженных средствами от защиты сбоев систем необходимо оснастить управляющими
моделями. Эти средства привлекаются в дополнение ко всем данным, поскольку они
очень важны для процесса функционирования системы.
Диаграмма управления содержимым (CCD)
Подобно DFD, диаграмма управления содержимым (Control context diagram, CCD)
содержит только один процесс, отображая вводные данные и результаты вычислений
для внешних объектов. Рассматриваемая диаграмма разбивается на компоненты,
которые отражаются в спецификациях. Отличие этих диаграмм в том, что данные,
отображаемые на CCD-диаграмме или на диаграмме управления потоком (Control flow
diagram, CFD), контролируют данные, приводящие к изменению состояния системы.
Именно такой подход приводит к активизации и деактивизации преобразований.
Основная система обозначений для управляющих диаграмм показана на рис. 22.22.
Состояние
Переход
Событие
"► Действие
Ж5Г /-CSPEC УП-~6
хранилищем
Рис. 22.22. Основная система обозначений для
управляющих моделей
Элементы и символы, применяемые в CCD-диаграммах, аналогичны тем, что
используются в DCD-диаграммах. Исключение составляют управляющие данные,
представленные с помощью точечных линий. Это позволяет отличить их от других
данных и выполнить более рациональное моделирование их поведения. CCD-диаграмма
для примера с лифтом показана на рис. 22.23.

Методы анализа и разработки проекта 785
Примечание 22.3. Пример структуры PSPEC
Вход
: 1< &'■•.&>?;'■£*'* *~'-
Инициализация fi::-'' ;4w;:W- -'rVv.'-1 -.c.^w^^^■'^',■'->■'-.-'■' >; ~
Пока не исчерпаются транзакции>либоШ ошибка
Получить транзакциюч '"' '"': ?'*>'■ '*'^"-'"^ybte-WJi'■.'■**? '?■ -'
Если имеется транзакция"' ":"'jf^r ./*-'*,v'."^:.;1K-'. ''".'"■'.'.'. - .;■
Если происходит -пфхм/атЦ^^^и^^^сту/^ясщйе
Вызватьобработ^тр|«завфда;^ ,ц... ^'i ,.
Если код возврата "jO*,,; .■^yi^Vv^ji^fe? >,^-': -':' •
Переместить Чйеуспешнде 'с^ьййе** 1ЦШ^Шйгь со<>бщение об ошибке
, Вызвать процедуру обработки si^aitt ошибках
Если кодстатуса ^пробе^'" ;r '.''y.-'-%^J!'i'^v ■■' ','.-''
Отобразить ^а^вкаче&^^р»й«1а^^
КонецЕсли" ■■■■: ''-"^й. -. ^ >-''"":!' ■
КонецЕсли -( y.\s* <••->;£/. : ■
Иначе Отобразить в с6обш^нии!Ьбчз)Шбке йж^ректность.
типа транзакции;■■,ь^ „; ._i ';. .
Вызвать процедуру,отображающую сообщение об ошибке
КонецЕсли j.i, , .,._.. i
Иначе ПрисвоитьуслЬвию?С1Тсутству^от значение "истина"
КонецЕсли ,.у;'::Г". '-. '.,:'Г-Ч-У-^1:-'-'1'■"-■•."'-"■
Конец Блока •-.• . / 'У
ВЫХОД „ -;.»■;-,. .-: _■.: ' Г ; ,v-v- ■-• •
■ v^f,-
Пользователь
А*с. 22.23. Диаграмма управления
содержимым для задачи о лифте
Диаграммы управления потоком (CFD)
CFD-диаграммы во многом подобна DFD-диаграммам, различие состоит в том, что
в данном случае моделируются потоки управляющих данных (потоки управления),
а не потоки данных. При составлении CFD-диаграмм используется система
обозначений, нумерации, уровни и свойства балансировки, аналогичные тем, которые приме-

786 Глава 22
няются в ходе проектирования DFD-диаграмм. Процессы и хранилища данных
приобретают точно такой же вид, как и в случае DFD-диаграмм. Отличия проявляются
в том, что управляющие потоки показаны в виде точечной линии, а символ полосы
добавляется для представления спецификации управления (CSPEC), которое может
изменять состояние системы. Аналогично тому, как это происходит в случае с DCD-
и DFD-диаграммами, CCD-диаграммы не отображают хранилищ данных, a CFD-
диаграммы не могут применяться с целью представления внешних сущностей. CFD-
диаграмма высокого уровня (CFD 0) для примера с лифтом показана на рис. 22.24.
/ Анализ \
\ нажатия кнопки J
I Кнопки |
I подсветки ]
ыдатькоманду \
управления
лифтом /
Команды
управления лифтом
jc—N
Дверьзакрыта
1
\
К
ч^ Кнопка •
нажата
Рис. 22.24. Уровень 0 диаграммы управления потоками
для задачи о лифте
Диаграммы переходов состояния
Диаграмма переходов состояния (State transition diagram, STD) представляет
поведение системы путем изображения наблюдаемых состояний и тех событий,
которые привели к изменению состояния системы.
STD- и CFD-диаграммы служат основанием для моделирования поведения системы.
В спецификации по управлению (CSPEC) содержатся дополнительные сведения
относительно различных аспектов контролирующего ПО. Основной задачей
CSPEC является изменение откликов процессора данных в соответствии с
изменением внешних и внутренних условий функционирования системы.

Методы анализа и разработки проекта 787
Таблицы принятия решений, STD-диаграммы, таблицы перехода состояний,
матрицы состояния событий и диаграммы состояний представляют собой модели машин
с конечным числом состояний, описывающих поведение системы.
STD-диаграмма отображает состояния системы или подсистемы, переходы между
состояниями, события, которые привели к изменению состояния, а также те
действия, которые можно предпринять для перехода в новое состояние.
[кнопка нажата,
кнопка подсвечена]
С
1
[отсутствуют вызовы лифта,
двери закрыты]
Цикл контроллера лифта
[кнопка нажата, [лифт движется
кнопка не подсвечена] в направлении d,
следующим будет этаж f]
Обработка запроса
выполнить/ обновить запросы
выполнить/ нажать кнопку
Определить, был ли выдан запрос
на команду останова
выполнить/ проверить запросы
[пользователь [пользователь
выдал команду инициировал
останова на 1 этаже] остановку на этажа 1]
Продолжение
движения
выполнить/
переместить лифт
на один этаж
в направлении d
Остановка на этаже
выполнить/ остановить
лифт
выполнить/ открыть двери
выполнить/ обновить
запросы
подсвечена кнопка
кнопка лифта
лифта не подсвечена
Выключена
кнопка лифта
выполнить/
отключить
кнопку лифта
(лифт
остановлен,
отложен
запрос(ы)]
[лифт
остановлен,
отсутствуют
вызовы
лифта]
Перейти
в состояние ожидания
выполнить/закрыть двери
через какой-то интервал
времени
Закрыть двери лифта
выполнить/закрыть двери
через определенный
интервал времени
[подсвечена [на подсвечена
кнопка кнопка
на этаже! на этаже!
Кнопка на этаже
отключена
выполнить/
отключить
кнопку на этаже
Обработать
следующий вызов
выполнить/
переместить лифт
на один этаж
в направлении!)
*Ы-
Рис. 22.25. Диаграмма переходов между состояниями (машина с конечным
числом состояний) для задачи о лифте

788 Глава 22
Обычно, аналитик/разработчик сначала уточняет все возможные состояния,
затем определяет начальное состояние и все возможные переходы. STD-диаграмма,
подобно всем внутренним компонентам проекта, является средоточием "правил" по
верификации и завершенности проекта: все возможные состояния, включая и ошибки,
следует определить, все состояния должны быть достижимыми, а также следует
учитывать, что все состояния, за исключением конечного состояния, имеют
"преемников". Как и в случае с DFD, для STD-диаграмм важно использовать PSPEC или CSPEC,
где условия представлены с помощью центростремительных (входящих)
управляющих потоков, а действия (реакции) представлены с помощью центробежных
(исходящих) управляющих потоков.
В STD-диаграммах поддерживаются детали, имеющие важное значение при
реализации и создании исчерпывающей документации, учитывающей аспекты системы,
зависящие от времени. И если эти вопросы важны для управляющих систем, их
значение не столь велико для большинства типов приложений, ориентированных на
обработку данных. Для конструирования и просмотра STD-диаграмм требуются серьезные
усилия разработчиков, причем затраченные усилия не всегда оправданы. Даже при
работе с системами реального времени только часть системы может потребовать
проработки на столь детализированном уровне.
STD-диаграмма для задачи о лифте показано на рис. 22.25.
Словари данных (словари требований)
Центральной частью модели структурного анализа является словарь данных. Здесь
хранятся описания всех объектов данных, которые запрашиваются ПО или же им
производятся. Словари данных (DD) представляет собой спланированный перечень
всех элементов системы. Применение подобного словаря облегчает анализ системы
и приводит к уменьшению трудозатрат, предпринимаемых при разработке программ.
Причем не имеет значения, используется ли анализ SA/SD или OOA/OOD, поскольку
словарь содержит точные и достаточно строгие определения. "Словарь данных"
означает не совсем то, что определяется этими словами. В этот словарь входят
описания объектов, отличных от "чистых" данных.
DD-диаграмма отображает композицию для каждого объединения или группы
пунктов, описывает значения элементов данных и определяет подходящие значения
и единицы для простых элементов данных. В словарь входят определения
терминаторов и внешних данных/управляющих потоков, которые используются в DCD-
и CCD-диаграммах; определения потоков данных, управляющих потоков и хранилищ
данных, показанные в DFD- и CFD-диаграммах; сущности, атрибуты и отношения,
отображенные в ERD; имена PSPEC и CSPEC для DFD- и CFD-диаграмм; информация
об элементах структурных диаграмм. Если применяются методы OOA/OOD, DD-
диаграммы также содержат подобные элементы, хотя они и базируются на ОО-
терминологии, например, классы, методы, сообщения и т.д.
Обычно DD-диаграммы определяют для каждого элемента данных имя,
представление, единицы/формат, указание на точность/соответствие, диапазон и методику
применения, а также другую описательную информацию. DD-диаграммы не содержит
сведения по обработке данных (они находятся в спецификации PSPEC) или
информацию о маршрутизации данных, которыми обмениваются процессы из DFD-
диаграмм. К счастью, рассматриваемый репозитарий поддерживается почти всеми
инструментами, предлагаемыми на рынке разработки ПО (CASE-инструменты).

Методы анализа и разработки проекта 789
Архитектура ПО
Термин Архитектура ПО применяется в различных ситуациях и имеет разные
значения. Чтобы избежать путаницы, приведем некоторые классические
определения, а затем кратко опишем подход Хатли-Пибхаи (Hatley-Pirbhai) к архитектуре ПО,
применяемого в системах реального времени.
Архитектура является организационной структурой, а также соответствует
поведению связанной с ней системы. Архитектура может быть рекурсивным образом
разложена на составные части, взаимодействующие между собой с помощью
интерфейсов, отношений, связывающих эти части и ограничений, позволяющих их
объединять. Рассматриваемые части архитектуры объединяются с помощью интерфейсов.
Архитектура представляет собой набор важных решений по организации
программной системы, выделению структурных элементов и их интерфейсов , составляющих
систему. Сюда следует включить и поведенческие аспекты, отразившиеся в
соглашениях относительно этих элементов, композицию структурных и поведенческих
элементов, образующих прогрессивные и более крупные подсистемы. Также необходимо
учесть архитектурный стиль, которому подчинена данная организация —
рассматриваемые элементы, их совместное применение и композиция .
Архитектура ПО включает:
■ набор программных и системных компонентов, связи и ограничения;
■ набор операторов, потребность в которых испытывают участники совместного дела;
■ логическое обоснование, подтверждающее, что компоненты, связи и ограничения
определяют систему, которая в случае ее реализации, будет отвечать системным
требованиям .
Архитектура ПО — свободно определенная организационная структура
программной системы, включающая компоненты, взаимосвязи, ограничения и логические
обоснования. Компонентами могут служить небольшие фрагменты кода, например,
модули, или большие компоненты, такие как отдельные программы, типа базы
данных систем управления. В качестве архитектурных связей выступают абстрактные
отношения, показывающие, каким образом компоненты взаимодействуют в системе
(т.е. связями служат вызовы процедур, каналы и вызовы удаленных процедур).
Архитектура включает различные ограничения и связанные с ними логические
обоснования, включая ограничения на компоненты выделения и логические обоснования по
выбору определенных компонент в данной ситуации .
Независимо от того, выполняется ли моделирование с использованием
возможностей SA/SD или OOA/OOD, желательно иметь представление об общей архитектуре
для определенных типов систем, в основном, систем реального времени. Такого рода
деятельность обычно находится на пересечении возможностей анализа и разработки.
www.omg.org. Object Management Group (OMG). Unified Modeling Language (UML)
Specification, Version 1.3, March, 2000.
l' Booch Grady, James Rumbaugh и Ivar Jacobson. The UML Modeling Language User Guide.
Reading. MA: Addison-Wesley, 1999.
Gacek Cristina, Ahmed Abd-Allah, Bradford Clark и Barry W. Boehm. "On the definition of
software system architecture". Proceedings of the First International Workshop on Architectures for Software
Systems, Seattke, WA, 1995.
www. sei.cmu.edu/architecture/definitions.html. Институт программного
инжиниринга. "How Do You Define Software Architecture?", 2001.

790 Глава 22
Диаграмма архитектурного потока (AFD) является сетевым представлением для
физической конфигурации системы.
AFD-диаграмма демонстрирует физическое распределение требований к данным
для модели, контролирует процесс обработки и потоки, направляемые в физические
объекты (подсистемы), которые выполняют указанные задачи. Здесь
демонстрируется физическое разбиение системы на составные части, отображены
информационные потоки между этими частями. При этом главная задача заключается в уточнении
расположения функциональных процессов для модели требований в соответствии
с физическими модулями системы и добавление процессов, необходимых для
поддержки новых физических интерфейсов. Определение физических модулей
добавляет новые возможности в состав двух областей (функциональная и управления
обработкой) , которые адресуются с использованием возможностей модели формирования
требований. Сюда входит обработка вводных данных и данных вывода, обработка
интерфейса пользователя, а также поддержка (обработка) в процессе тестирования.
Шаблон для AFD-диаграммы приведен на рис. 22.26.
Обработка пользовательского интерфейса
X
3
X
X
9
«*
О
со
S
S
а
8
Функциональная
обработка
Сопровождение и выполнение
процесса самотестирования
8
!
S
5
£,
И
Рис. 22.26. Шаблон диаграммы для потока архитектуры
Блок интерфейса пользователя предназначен для обработки вводной информации
и результатов. Этот блок следует отделить от блоков ввода/вывода, поскольку для
этого имеются определенные соображения, например, следует учитывать
человеческий фактор, т.е. влияние, которое оказывает определение интерфейса пользователя.
Точно так же, как и случаях с диаграммами содержимого данных и управления
содержимым, существует диаграмма управления архитектурой (Architecture control
diagram, ACD), представляющая наивысший уровень. Элементами, образующими ACD,
являются один архитектурный модуль, представляющий систему; терминаторы,
представляющие объекты в среде, с которыми связана система; а также векторы
информационных потоков, которые указывают на связи системы с этими объектами.

Методы анализа и разработки проекта 791
AFD-диаграмму можно разложить и представить определение архитектуры
системы на следующем уровне, как это показано на рис. 22.27. При этом символы
AM используются для обозначения модуля архитектуры, а символы IF
применяются для представления потока информации. Диаграмма взаимосвязей
архитектуры (Architecture interconnect diagram, AID) представляет коммуникационные
каналы, существующие между модулями архитектуры; она демонстрирует физические
возможности, позволяющие модулям поддерживать связь друг с другом.
Спецификация внешних связей для архитектуры отражает такие характеристики каналов,
благодаря которым модули обмениваются информацией.
<
'
IF 14
Обработка
входных данных
1
1=
2
AM 2
СМ
\
1F3
' А
♦IF 4
3
" АМЗ
«IV, О ^
"
1
М1
IF 15
пользовательского интерфейса
•IF5*-
1 .

^Нефункциональная
и контрольная
обработка
IF 9 {
Выполнение
операций в рамках
сопровождения
Обработка событий
пользовательского интерфейса
Обработка
ВХОДНЫХ
данных
AM
2.1 -
,
г*
' Л.. '
AM
' 2.2
*|
1
IF В
1 ,
Функциональная
и контрольная
обработка
AM
2.3
т 1
II
IF С
IFD
Выполнение
операций в рамках
сопровождения
С
1
\\
AM
2.4
ж
М
С
»
'
с
'
4
AM 4
1 1
IF 6
""*■ ■ "*\
6
AM 6
.
IF 10
IF 8
IF 12*
5
AM 5
«IF 13*
Обработка
выходных
данных
Обработка
входных
данных
'
Tl
о
AM
5.1
_.
н
AM
5.2
IFE
-J
Функциональная
и контрольная
обработка
Выполнение
операций в рамках
солрововдения
»
>
'
Обработка событий
пользовательского интерфейса
s
л
IFG
L
Г
•>
с
I
AM 1
5.4
брабо*
ыходн
данны
IF 131
гка
ых
X
IF 12
Рис. 22.27. АПУдиаграмма, прошедшая процедуру декомпозиции

792 Глава 22
Декомпозиция архитектурной модели не совпадает с функциональной
декомпозицией системы. Этот процесс следует понимать в том смысле, что архитектурный
шаблон успешно применяется к каждому из модулей в "родительской" AFD-
диаграмме с целью образования следующего уровня этой диаграммы. Затем этот
процесс продолжается, вплоть до полного структурирования системы.
Рассматриваемый процесс отличается от функционального представления, при реализации
которого пользователи или автоматизированные системы нуждаются в
специальных интерфейсах, обладающих физическими свойствами. В дополнение к тому, что
удовлетворяются функциональные требования, полностью интегрированная
система спецификации с помощью AFD-диаграммы также используется и при
физической разработке.
Поскольку AFD-диаграмма описывает физические характеристики системы
(указание времени событий и т.д.), ее рассматривают как задачу "низкого уровня"
(в реализуемом позднее процесса анализа/разработки — низкий уровень разложения).
Менеджер программного проекта редко принимает участие в подобной разработке,
однако, при создании сложных систем реального времени, где моделируется система
контроля, очень важно, чтобы большая часть времени рабочего графика была
выделена именно для конструирования подобных образований.
Структурированная разработка проекта SA/SD:
структурные диаграммы
Компоненты, которые можно рассматривать как иерархии, отображают в
предсказуемом порядке создаваемую процедуру. Часть системы, выполняемая задачу
"спускового крючка" для данных системы, может рассматриваться как сеть (AFD-
диаграммы). Структурная диаграмма представляет собой инструмент, который
позволяет определить иерархическую модель реализации для программной системы,
состоящей из модулей. В 60-х годах структурная диаграмма являлась основным
инструментом для анализа и разработки проекта, позволяя разработчикам и
проектировщикам ПО увидеть общую "картину" процесса разработки. По-прежнему структурная
диаграмма представляет собой полезный инструмент, применяемый на этапе
разработки проекта, хотя в настоящее время "структурированная разработка проекта"
реализуется в виде "структурированного кода". Рассматриваемая диаграмма появляется
далеко не в начале общего жизненного цикла разработки программного продукта, что
позволяет предотвратить многие проблемы. Подобная реализация приводит к
использованию понятий структурного и объектно-ориентированного анализа.
Учитывая, что применяется анализ SA либо ООА, структурированная разработка
проекта позволяет подробно описывать модули, подпрограммы ввода/вывода
данных, функции низкого уровня, механизм их функционирования и внутренние данные.
Символы, применяемые в структурных диаграммах, показаны на рис. 22.28.
Структурные диаграммы позволяют разбить систему на "черные ящики". Это оз1
начают, что пользователю известна функция, но он не знаком с выполняемыми
внутри системы операциями. Использование "черных ящиков" уменьшает степень
сложности системы, поскольку лишняя информация скрывается от тех, кто не
заинтересован (или не желает) ее знать. "Черный ящик" получает ожидаемые
вводные данные и возвращает выводимые данные. Однако не требуется, чтобы
пользователь представлял, каким образом реализуются определенные функции. Системы с
"черными ящиками" удобно конструировать, тестировать, корректировать и изме-

Методы анализа и разработки проекта 793
нять, а также представлять механику их функционирования. Структурные
диаграммы организуют системы, которые разбиваются на "черные ящики" в иерархиях, как
показано на рис. 22.29.
*■ Данные
-*■ Контроль
Модуль
о
Физическое Л
хранилище J
Рис. 22.28. Система обозначений для структурных диаграмм
Рис. 22.29. Шаблон структурной диаграммы
Структурные диаграммы составлены из модулей. Модуль представляет собой
набор проблемных операторов, обобщающих ввод, вывод, функционирование,
механику и внутренние данные. Механика являет собой процедурный код или логику, в
соответствии с которой модуль поддерживает соответствующие функции; частным
рабочим пространством модуля являются внутренние данные. На структурной
диаграмме модули представлены именованными полями. Модули имеют связи с
другими модулями: Один модуль может вызывать (обращаться, выполнять) другой модуль
и затем возобновлять обработку. Если модуль вызывает другой модуль, вызываемый
модуль рассматривается в качестве "черного ящика". Ему передаются параметры,
необходимые для функционирования, а также принимаются от него ответы.
Система обозначений для структурных диаграмм, таких как DFD и CFD, отличает
управляющие данные. В структурной диаграмме "обычные" данные, передаваемые
между модулями, отображаются с помощью направленных стрелок с метками, на
концах которых находится пустой круг (на конце, противоположном "стрелке").
Управляющие данные (флажки) отличаются зачерченным кругом. Структурные
диаграммы отображают временную последовательность вертикально, а не
горизонтально. На рис. 22.29 модули, находящиеся на верхнем уровне, выполняются до вызова

794 Глава 22
модулей, расположенных в нижней части. Но если вызывается несколько модулей,
отсутствуют какие-либо указания на порядок их исполнения.
Модули могут описываться с помощью модульных спецификаций (MSPEC).
Обычно они записываются с использованием псевдокода, типа PSPEC и CSPEC, но при
этом подробности отображаются на более низком уровне (как это происходит в ре-
алмюм коде). Спецификации MSPEC, подобно другим конструкциям, использует
основные элементы: простая последовательность, принятие решения (if-then),
выделение (do-while) и повторение (do-until). Эти конструкции обсуждаются в дальнейшем,
в разделе, посвященном диаграммам Чейпина. Таблицы решений, деревья решений и
диаграммы переходов состояния также могут применяться в спецификациях MSPEC
(наряду с другим компонентами SA и динамическими диаграммами OOA/OOD).
Структурная диаграмма качества — соединение
Одной из возможностей оценить качество разработки структурной диаграммы
является исследование методики соединения, степени независимости двух модулей.
Задача состоит в минимизации последствий соединения, приведение модулей к
наиболее независимому друг от друга состоянию. Невысокая степень соединения указывает
на то, что проведено удачное разбиение системы. Для этого устраняются отношения,
не являющиеся необходимыми, или сокращается количество необходимых
отношении, уменьшается "натяжение" обязательных отношений. Малая степень соединения
минимизирует проявление волнового эффекта (ошибка, проявляющаяся в том, что
влияние одного модуля проявляется в другом модуле в качестве симптома) и
уменьшает влияние изменений (изменение одного модуля не требует изменения нескольких
других); при работе с одним модулем подробности, относящиеся к другим модулям, не
используются либо используются незначительно. Структура соединения
проиллюстрирована на рис. 22.30. Пейдж-Джонс (Pages-Jones) описал подобную структуру как
спектр, изменяющийся от хороших качеств (свободное) до неважных (тесное), что
зависит от применяемого типа диаграмм (табл. 22.2).
Таблица 22.2. Типы соединений
Тип Пример Качество
Нормальный: данные Передаются аргументы Лучшее
I {ормальный: структура дан- Передаются структуры в целом (например, таб-
ных (тип) лицы)
Нормальный: контроль Информация, статус
Общий В глобальной структуре данных происходит
разделение данных
Содержимое Разделение содержимого Худшее
Рассматривая соединение двух модулей, можно заметить, что стандартное
соединение является наиболее подходящим. Два модуля, А и В, стандартно соединены, если А
вызывает В, В возвращается к А, а вся информация, передаваемая между ними,
описывается с помощью параметров, содержащихся в самом обращении. Стандартное
соединение также известно как соединение данных: другой вызывающий оператор
может применять вызванный модуль, поскольку информация о вызывающем модуле
не требуется.

Методы анализа и разработки проекта 795
Сильная связность
Слабая связность
Рис. 22.30. Два варианта соединения: степень
независимости модулей
Типовое соединение не столь уж плохо, но уступает соединению данных. Два
стандартно связанных модуля являются соединенными типовым образом, если один из
модулей передает другому сложную часть данных (важную внутреннюю структуру).
Если структура данных передается полностью, хотя необходима только ее часть,
необязательные при этой передаче данные называются "блуждающими" данными.
Большинство модулей просто пропускают эти данные, однако, иногда они
непроизвольно изменяются при этом и "путешествуют" далее в измененном виде. Отсюда
можно сделать вывод, что не следует передавать записи, содержащие большое число
полей, тем модулям, которым необходимо воспользоваться только одним или
несколькими полями. Между модулями, не связанными при обычных условиях, могут
установиться определенные зависимости, что приведет к ненужному обращению к
типовым соединениям.
Управление соединением находится в сердцевине диапазона "хорошо-плохо". Два
модуля являются подконтрольно соединенными, если один передает другому часть ин-

796 Глава 22
формации, которая предназначена для управления внутренней логикой другого
модуля. Если управляющий флажок переходит в нижнее положение при обращении
главного к подчиненному, главный модуль должен быть осведомлен о внутренних
особенностях подчиненного модуля. В этом случае подчиненный модуль не является
"черным ящиком" Если управляющий флажок устанавливается при переходе от
подчиненного к главному модулю, иерархия нарушена. Избегайте контрольных пар,
предполагающих наличие определенного порядка, или формируйте решение для
получателя. Доступными контрольными парами являются информационными
флажками или флажками статуса. Если получатель имеет максимум свободы в процессе
применения такой "информационной состязательности" для поддержки "черных
ящиков" для модулей, не усиливайте образовавшиеся зависимости.
Соединение, построенное на общих основаниях, является неудовлетворительным.
Модули соединены на общих основаниях, если они совместно используют данные,
ссылаясь на глобальную структуру данных (данные не передаются в качестве параметров).
Недостаток любого модуля, применяющего глобальную область, может проявиться
в любом другом модуле, обращающемся к этой же области. Дело в том, что
глобальные данные не находятся в "защитном укрытии" модуля. Если доступ к данным носит
глобальный характер, могут возникнуть следующие затруднения: при внесении
изменений в общее определение все модули, имеющие ссылку на данное общее
определение, должны повторно компилироваться; в общей среде можно получить доступ ко
веем элементам данных и повредить их; если модуль обращается в общую среду, он не
может служить "черным ящиком". Глобальные данные представляют наибольшую
•( рудпость при их осознании и отладке и для программистов, реализующих
поддержку. Иногда довольно трудно понять, какие же данные применяются определенным
\мдулем. Если модуль выбирает часть "плохих" данных, довольно сложно отследить,
• п куда они поступают.
Соединение но содержанию является очень неважным и предполагает большую
связанность. Два модуля представляют содержательное соединение, если один каким-либо
способом ссылается во внутреннюю область другого. Например, если один модуль
является ответвлением другого или же входит в него, если один модуль ссылается (или
изменяет) данные, находящиеся в другом, или один модуль изменяет оператор,
содержащийся в другом модуле. Также два модуля содержательно соединены, если один
модуль включен в состав другого модуля, один модуль обновляет операторы,
находящиеся в другом модуле, один модуль ссылается на внутренние данные другого модуля или
обновляет эти данные. Иногда в этом случае модули совместно используют одно и то
же содержимое. Соединение по содержанию представляет собой пример
рискованной практики.
Структурная диаграмма — связность
Связность является мерой для степени функционального соединения элементов
в модуле. Ее также можно измерять с использованием шкалы "хорошо-плохо"
("наилучший-наихудший"), что позволит отобразить качественный аспект. Чем тес-
псе отношения среди элементов модуля, тем больше "сила" самого модуля.
"Элементами" в этом контексте являются программные операторы, группы операторов
пли модуль.
Функциональная связность является наилучшей. Каждый элемент модуля является
интегральной частью в процессе выполнения отдельной функции. Несвязанные
элементы отсутствуют. Функционально связанный модуль содержит элементы, оказывающие

Методы анализа и разработки проекта 797
влияние на выполнение одной и только одной задачи, относящейся к общей
проблеме. Примерами могут служить математические функции, типа синус/косинус.
Таблица 22.3. Типы связности
Уровни связности Краткое описание Поддержка
Функциональный "Загляните" на следующий уровень Лучшая — "черный ящик"
И нформативный Разделяются данные илн структуры
данных
Последовательный Важен порядок следования событий
Коммуникационный Обработка входов/выходов
Временный Основано на времени
Процедурный Программная процедура (итерация, выбор
решения и т.д.)
Логический Требуется контроль
Синхронный Отсутствуют конструктивные взаимосвязи Худшая — "белый ящик"
Модули, отличающиеся сильными, строго-определенными целями, являются
наиболее удобными, и, следовательно, поддерживать их проще всего. Функционально
связанный модуль очень похож на "черный ящик".
Последовательная связность не столь плоха, но это уже и не "черный ящик".
Последовательно связанный модуль отличается тем, что его элементы вовлечены в
деятельность такого рода— данные вывода из одного рода деятельности служат вводными
данными для следующего. Ниже приводится пример:
и уберите паутину с рабочего стола бабушки;
■ заделайте отверстия в древесине;
■ отшлифуйте поверхность рабочего стола;
■ примените лак;
и натрите воском рабочий стол.
Эти пять функций нельзя объединить в одной функции, вместе они образуют
хороший модуль под названием ref inish_desk.
Коммуникационная связность в соединении обладает почти такой же "степенью
сближения", что и последовательная связность. Связанный с применением коммуникаций
модуль отличается тем, что его элементы оказывают влияние на такие формы
деятельности, где применяются одни и те же вводные данные и данные вывода. Ниже
приводится пример:
■ найдите дату создания фильма;
■ уточните фамилии актеров, занятых в фильме;
■ узнайте фамилию директора фильма;
■ определите, стал ли фильм блокбастером.
Все эти направления связаны, поскольку обрабатывают одни и те же вводные
данные: титры представленного фильма. Если это необходимо, модуль можно разбить на
четыре связных функции, которые поддерживают друг друга.

798 Глава 22
Процедурная связность является "серым ящиком", но не "черным". Процедурно
связанный модуль является таковым, если его элементы вовлечены в различные и,
возможно, несвязанные формы деятельности, при которых управление переходит от
одной формы деятельности к другой (обратите внимание: управление, а не данные,
как в случае с последовательной связностью). Контрольный поток применяется
только в одном случае, но не с помощью отдельной функции, связанной с проблемой.
Ниже приводится соответствующий пример:
■ выгуляйте собак;
■ примите душ;
■ проверьте электронную почту;
■ обратитесь к дворникам;
■ запишите благодарность.
Несмотря на то, что таким образом можно представить дневной распорядок дел
определенного индивидуума, этот процесс не подлежит факторизации. Распорядок
можно перенести и на другой день.
Временная связность также представляет собой "серый ящик". Временно связанный
модуль отличается тем, что его элементы вовлечены в формы деятельности,
связанные во времени. Ниже приводится пример:
■ отключите сигнализацию;
■ наденьте шорты;
■ выгуляйте собак;
■ почистите зубы;
■ примите душ;
■ сварите кофе.
Эти виды работ выполняются утром, однако, их можно представить как
"мышление блок-схемой", особенно если речь идет об известных процедурах,
связанных с инициализацией, содержанием дома и окончанием работ. Этот модуль лучше
разделить с помощью функции.
Логическая связность реализует худший вариант поддержки. Вместо "черного
ящика" здесь идет речь о "белом" и даже о "прозрачном" ящике. Логически связанный
модуль отличается тем, что его элементы вносят вклад в деятельность той же самой
категории, в которой различные формы деятельности выделяются некоей силой,
находящейся пне модуля.
Если вы планируете обед, следует обратить внимание на такие сценарии:
■ неформальная стойка буфета вне помещения;
■ формальная стойка буфета внутри помещения;
■ использование столов внутри помещения.
Однако в любом случае следует выбрать только один план. Логически связанный
модуль определяет несколько действий, относящихся к одному общему роду. Чтобы
применять такой модуль, необходимо выбрать только ту часть, которая необходима
в данном случае. Все эти формы деятельности, будучи различными, совместно
используют один интерфейс модуля и должны быть разделены на отдельные функции.

Методы анализа и разработки проекта 799
Синхронная связность является наиболее сложной формой связности при
реализации поддержки. Синхронно связанный модуль характеризуется тем, что его элементы
влияют на формы деятельности, не имеющие между собой прямой связи. Ниже
приводится пример:
■ сварите кофе;
м испеките торт;
■ выгуляйте собаку;
м обратитесь в медицинскую школу;
■ натрите воском рабочий стол;
■ воспользуйтесь неформальным буфетом вне помещения.
Вызывающий модуль должен переслать флажок для указания, что же предпринять
вызванному модулю, причем здесь нарушается принцип независимости "черных ящиков".
На рис. 22.31 приведены вопросы, которые может задать разработчик при
уточнении вариантов связности модуля.
выполняющего
функцию,
связанную
с одной проблемой?
Важно ли
соблюдение
последовательности
действий?
к:
Нет.
Коммуникационная
Важноли
соблюдение
последовательности
действий?
Нет
Процедурная
Временная
Все ли действия
принадлежат
к одной общей
категории?
—-— Да
Логическая
Нет
N1
Совпадающая
Рис. 22.31. Краткая сводка по видам связности
Далеко не всегда легко создать связный модуль. Одна из возможностей,
предложенная Пейджем-Джонсом, состоит в "тестировании" связности. Необходимо написать
короткое предложение, в котором точно и полно отражено название модуля и описана его

800 Глава 22 j
функция. Если название можно представить в виде точной комбинации глаголов и
объектов с применением сильных, повелительных глаголов и определенного сингулярного
непосредственного объекта, тогда степень связности наверняка будет высокой.
"Пристегнитесь к креслам в салоне самолета" — вот пример подобной связности.
Создание моделей структурной разработки проекта на основе
моделей структурного анализа
Структурный анализ обращается к одному типу моделей (DFD, CFD), в то время
как при структурной разработке проекта используется другой тип (структурная
диаграмма). Преобразования между различными типами моделей обычно выполняются
посредством методов "анализа преобразований" или "анализа транзакций".
Сбалансированная система, структурные диаграммы которой описывают преобразования
Рис. 22.32. Преобразование DFD в структурную диаграмму

Методы анализа и разработки проекта 801
между центростремительными модулями (пересылающими информацию в верхние
"эшелоны") и центробежными модулями (пересылающими информацию в нижние
"подчиненные" структуры), более удобная в применении. Для поддержки
сбалансированной системы необходимо прилагать меньше усилий, чем для поддержки
обычной системы. На рис. 22.32 показана обобщенная программная модель DFD (вверху),
для которой отсутствует влияние временных факторов, а также ее преобразование в
структурную диаграмму (внизу), где отображена иерархическая структура и передача
данных/управления.
Анализ преобразований: стратегия, используемая для преобразования DFD
в структурные диаграммы
Ниже приводятся этапы, выполнение которых позволит преобразовать модели
анализа в модели разработки проекта.
1. Создайте диаграмму потока данных.
2. Определите центральное преобразование (существенные функции) — можно
отметить знаком "глазного яблока", как на рис. 22.33.
3. Уточните центростремительные и центробежные ответвления (вводный и
результирующий поток).
4. Упростите эти ответвления, как показано на рис. 22.34.
5. Создайте эскиз структурной диаграммы, как показано на рис. 22.33 и 22.34.
6. Заново определите и сбалансируйте структурную диаграмму.
7. Если центральная DFD-топология является сетевой, как на рис. 22.35, обратите
внимание на "босса"; если центральная DFD топология является иерархической,
как на рис. 22.36, определите "босса".
Анализ транзакций
Для систем, обрабатывающих транзакции, может потребоваться разбиение DFD-
диаграммы на меньшие части. Возможно каждая из частей разбиения будет
соответствовать одной транзакции, обрабатываемой системой. Небольшие DFD-диаграммы
затем можно преобразовать в структурные диаграммы небольших размеров. Часто
бывает так, что на DFD-диаграмме легче распознать центры транзакций и пузырьков
процесса.
Центр транзакции представляет часть системы, которая может получить стимул
к транзакции, проанализируйте ее с целью уточнения типа, проведите разбиение тем
способом, который соответствует типу и завершите обработку транзакции, как
показано на рис. 22.37.
С помощью анализа транзакций значительно облегчается разделение потоков
данных, применение обеих частей стратегии "разделяй и властвуй" (путем разбиения
обработки по подсистемам) и разумное определение коэффициента объединения по
вход)' для совместно используемых модулей.

I ыи.1 ti.
i i \ i n wunir i с помощью "глазного яблока ") иентральное преобразование

Методы анализа и разработки проекта 803
ПолучитьА
Т1, определяющий
действие #1
L3
Т2, определяющий
действие #2
1Ий ^ ТЗ,опр(
I, определяющий
действие #3
Детали
модуля 1
Детали
модуля 2
Детали
модуляS
Рис. 22.34. "Упрощение" центрального преобразования

804 Глава 22
БОСС
Процесс 1
Процесс 2
Процесс 3
Процесс 4
Рис. 22.35. Анализ преобразований: выберите "босса"

Методы анализа и разработки проекта 805
Рис. 22.36. Анализ преобразований: назначьте "босса"
Форма и организация структурной диаграммы
Коэффициент объединения по входу/выходу
Коэффициент объединения по входу для модуля представляет количество
непосредственных "боссов", которые в него входят. Высокий коэффициент объединения
по входу характеризуется положительно, поскольку указывает на наличие повторно
используемого и исключающего дублирование обновления модулей в процессе
поддержки. Также справедливо, что модули, отличающиеся высоким коэффициентом
объединения по входу, должны иметь высокую связность (функциональную или, по
крайней мере, последовательную связность или связность в соединении), а также
низкий уровень соединения (свободный, например, при соединении данных).
Коэффициент объединения по входу/выходу показан на рис. 22.38.
Коэффициент объединения по выходу из модуля представляет количество
непосредственных "подчиненных" данного модуля, также известное как диапазон
контроля. Чтобы избежать "расплющивания" (расположение слишком большого числа
"подчиненных" на одном уровне), ограничьте коэффициент объединения по выходу
проверенным правилом 7+/-2. Остальные промежуточные уровни устанавливайте
с учетом иерархии. При реструктуризации модулей, как показано на рис. 22.39,
повышается коэффициент объединения по выходу.

806 Глава 22
XX,
определяющий
действие #1
XX,
определяющий
действие #п
Детали
модуля #1
Детали
модуля #2
*v
Рис 22.37. Анализ транзакций
Поместить Н
Рис. 22.38. Коэффициент
объединения по входу/выходу

Методы анализа и разработки проекта 807
zsz^^zx
в
Рис. 22.39. Большой коаффициент объединения по выходу
Диапазон контроля
Диапазон контроля модуля представляет собой модуль вместе со всеми
"подчиненными", как показано на рис. 22.40.
Рис. 22.40. Связи модуля

808 Глава 22
Связи модуля
Желательно, чтобы связи модуля были нормальными, когда данные перемещаются
сверху вниз и поддерживается контроль, а данные передаются снизу вверх. Если же
перемещения вверх и вниз по иерархии не столь ясны, или же если один модуль
отклоняется к центру другого, либо в другом модуле происходит обновление "скрытых данных",
соединения именуются "патологическими". Как показано на рис. 22.41, обычные связи
являются привлекательными, если их легко представлять и удобно поддерживать.
Обычные соединения:
1. А вызывает В, передавая вниз М.
2. А вызывает С, передавая вниз Р
и получая обратно N.
Патологические соединения:
1. X считывает значение частной переменной Y, Q.
2. Y перезаписывает частный флаг для Z, R.
3.1 передает управление в X.
Рис. 22.41. Сбалансированная структурная диаграмма
Сбалансированная структурная диаграмма
Сбалансированная иерархическая система имеет в верхней части управляющую
структуру, под нею расположена структура функций, а затем — структура управления
данными, которая поддерживается структурой абстрактного интерфейса. Если
разработчик рассматривает интерпретацию структурной диаграммы и замечает что-либо,
отличное от изображения на рис. 22.42, следует сделать вывод о необходимости
проведения реструктуризации.
Диаграмма Чейпина: модель для разработки
на нижнем уровне
Диаграммы Чейпина (также известные как диаграммы Несси-Шнайдермана (Nassi-
Schneiderman)) описывают процедуры, применяемые для получения, обработки
и передачи информации, во многом похожие на спецификации PSPEC или CSPEC.
Эти диаграммы поддерживают все логические построения, необходимые
программистам для немедленного создания структурных программ, поддерживающих
определенные функции на любом языке программирования. Черновик для компьютерной

Методы анализа и разработки проекта 809
программы создается на любом языке, являясь производным от спецификаций
процесса и описаний модулей. Эти спецификации и описания создаются при уточнении
диаграмм потоков данных и поддержки работ по проектированию.
Рис. 22.42. Диапазон контроля
Диаграммы Чейпина используют только пять основных структур, причем каждый
символ соответствует определенной структуре языка программирования и
поддерживает удобную трансляцию в компьютерный код. Как показано на рис. 22.43,
используются следующие конструкции: последовательная, если-тогда-в противном случае (if-then-else),
выполнять во время (do-while), выполнять до определенного момента (do-until), выполнять при
случае (do-case). Эти визуальные представления служат в качестве набора блоков для
построения программ, обеспечивающих только один вход и один выход для процесса и
строго ограничивая образование ветвей. Невозможно произвольным образом вы-

810 Глава 22
полнить передачу управления, если программы базируются на хорошо
разработанных диаграммах Чейпина.
Диаграммы Чейпина выполняют ту же функцию, что и привычные блок-схемы.
Преимуществом использования диаграмм Чейпина является то, что они
просматриваются подобно печатной странице; отсутствуют сложные стрелы, пересекающие всю
диаграмму. Установлен иерархический поток, направленный к инструкциям и
вариантам выбора, который усиливает логику процедур. Все это компактно расположено и
занимает не более одной страницы. Подобно традиционным блок-схемам эти
диаграммы можно вкладывать друг в друга, что помогает на более сложных уровнях
успешно демонстрировать подробности.
Для менеджера программного проекта важно представлять, как распределяются
финансовые потоки всех средств, выделенных на разработку. Причем этими
сведениями следует располагать как до демонстрации версии заказчику, так и после нее.
Если программа несложно кодируется, обновляется, просматривается и ее можно
легко понять, следует непосредственно обратиться к ее сохранению.
Базовые конструкции
Рис. 22.43. Диаграмма Чейпина: 4 конструкции

Методы анализа и разработки проекта 811
Отлично разработанные программы естественно "рождаются" на основе хорошо
продуманных диаграмм Чейпина. Приведем несколько простых "правил".
■ График NS всегда начинается сверху.
■ Ход выполнения на графике всегда проходит в направлении сверху вниз, за
исключением нижней границы для циклической структуры (L-форма и рамки L-формы из
верхней части — вниз). Если достигнуто завершение цикла, но условие выхода из
цикла не выполнено, прогресс возобновляется из верхней части этого же поля
цикла. Циклы могут заканчиваться только на горизонтальной полосе рамки L-формы.
■ Вертикальные линии никогда не пересекаются.
■ Из прямоугольника можно выйти в любой момент времени только в одном
направлении, в нижней части. Если прямоугольник содержит решение ("если-тогда — в
противном случае" или "выполнять выбор среди нескольких вариантов"), тогда из него
следует выходить в направлении прямоугольника, находящегося непосредственно
под тем решением, которое соответствует выходу в настоящий момент.
■ Нуль означает, что условие решения "проваливается" в нижнюю часть
прямоугольника.
■ Любой прямоугольник, не содержащий ни одной "посторонней" линии,
представляет либо одно действие (а возможно, и его отсутствие), либо другую диаграмму.
Способ, с помощью которого диаграмма Чейпина поддерживает карту "перехода
к меньшему", графически отображая логику программы, показан на рис.22.44. Этот тип
документа является прекрасной возможностью для "перехода" при проведении стати-
Ввод
(Последовательная обработка)
IF
Истина
Ложь
Пока выполняется условие
(Последовательная
обработка)
(Последовательная
обработка)
IF
Истина
Ложь
(Последовательная
обработка)
Нуль
Выполнить переключение
12 3 4 5 6 7 8
(Случай 1) (Случай2) (Случай3) (Случай4) (Случай5) (Случай6) (Случай?) (СлучайВ)
До тех пор, пока условие не стало ложным
(Последовательная обработка)
(Последовательная обработка)
(Последовательная обработка)
Выход
Рис. 22.44. Шаблон диаграммы Чейпина

812 Глава 22
ческого тестирования. На рис. 22.45 показан более реальный пример, который может
применяться при визуальной проверке или при переходе к статическому тестированию.
Модели, описанные в предыдущих разделах, представляют основной набор
моделей, применяемых при структурном анализе/ разработке проекта. Некоторые
разработчики считают, что эти модели мало чем отличаются от тех, которые применяются
при объектно-ориентированном анализе/разработке проекта. Но в
действительности это не так. Далее мы опишем некоторые основные модели OOA/OOD, обсудим
определенные "за и против" для каждого из этих двух подходов, а в конце главы
остановимся на подобных элементах.
Вход
Инициализация
Пока отсутствуют-дополнительные-транзакции или ошибка терминала
Выполнить операцию получить-транзакцию
Если отсутствуют транзакции или происходит ошибка терминала
Или
Если операции "добавить" или "обновить" или "удалить"
Затем
Выполнить обработку-транзакции
Если код-возврата = 0
Затем
Присвоить
"неуспешно"
сообщению
об ошибке
Вызвать "CAXXERR"
Или
Присвоить "успешно"
экранному сообщению
Вызвать "CBLTDLI"
Если код-состояния = "пробел"
Затем
Присвоить"да"
ошибке
терминала
Или
Нуль
Или
Присвоить тип
некорректной
транзакции
сообщению об ошибке
Вызвать "CAXXERR"
Затем
Нуль
Выход
Рис. 22.45. Диаграмма Чейпина
Объектно-ориентированный
анализ/разработка npoeKTa(OOA/OOD)
Анализ SA/SD длительное время применялся при разработке в качестве методики
моделирования процесса, данных и поведенческих аспектов. В условиях этой методологии
основной акцент делается на уточнении и разложении на составные элементы
функциональных возможностей системы. Для функционального разложения и структурирования
данных применяются диаграммы потоков данных, диаграммы управления потоками,
словарь данных, диаграммы переходов состояния и диаграммы отношений объекта.

Методы анализа и разработки проекта 813
DFD- и CFD-диаграммы при перемещении данных в системе моделируют
трансформацию данных/контроль данных. Словарь данных определяет потоки данных
и их хранилища. Диаграммы взаимосвязей иллюстрируют отношения между
хранилищами данных. Подобный подход при тестировании оказывается не совсем
точным, особенно если изменяются функциональные требования, что часто приводит
к реструктуризации модели.
ОО-модель организует систему на основе объектов реального мира или
концептуальных объектов, важных для пользователя. Этот подход является
противоположным разделению функций и данных. Объект реального мира, существующий
внутри области действия приложения, определяется в терминах ответственностей
(поведения), соответствующих данных (атрибутов) и отношения к другим
объектам. Все функции объекта скрыты в самих деталях объекта. Поэтому если
необходимы функциональные изменения, они производятся внутри объекта, что
приводит к незначительным изменениям в оставшейся части модуля. Для применения
в объекте обновленных или добавленных функций, оставшиеся объекты в модели
поддерживаются с помощью интерфейса.
Как показано в табл. 22.4, ОО-разработчики обычно используют как статическую,
так и динамическую модели.
Таблица 22.4. Объектно-ориентированные модели
Данные, функ- Тип модели
ция, поведение
Описание
Элементы
Фаза: объектно-ориентированный анализ
Статические Диаграммы
модели; данные, класса
функция
Граф классов, связанный
статичными отношениями
Динамические
модели;
функция,
поведение
Диаграммы
объектов
Применение
регистра
Сценарий
Граф экземпляров классов,
включающий объекты и значения
данных. Показывает мгновенный
снимок состояния системы в данный
момент времени
Модель как исполнитель
взаимодействует с системой
Экземпляр варианта
использования; единственный путь
исполнения с помощью варианта
использования показывает взаимодействие
объектов (не классов)
Классы (атрибуты,
операции), отношения
(ассоциации), типы
данных (операции
могут быть описаны DFD-
диаграммой или
псевдокодом, а также с
помощью анализа SA/SD)
Объекты (атрибуты,
методы), связи,
значения
Исполнители (фигуры
в виде палочек),
системные функции
(овалы), «uses»,
«extends», стрелки
Исполнители,
системные функции

814 Глава 22
Окончание табл. 22.4
Данные, функ- Тип модели
ция, поведение
Описание
Элементы
Фаза: объектно-ориентированный анализ
Диаграмма Графическая модель варианта ис-
действий пользования, показывающая
управляющий поток. Виды деятельности,
которая доводится до конца,
включая формирование временных
последовательностей и условий. Не
показаны объекты или классы
Блок-схема, действия
(капсулы),
последовательность (стрелки
с метками), условия
(ромбы), завершения
рабочего потока
("бычьи глаза"),
полосы синхронизации
(формы параллельной
деятельности)
Фаза: объектно-ориентированная разработка проекта
Статичная
модель
Динамические
модели
Усовершенст- Совершенствование модели
вованный класс
диаграмм
Диаграммы

взаимодействия —
Диаграммы
сотрудничества
Диаграммы

взаимодействия —
последовательные
диаграммы
Пространственные диаграммы
с акцентом на объектах и связи
между ними
С помощью методологии
сотрудничества показано, каким образом
варианты использования задейст-
вуются в терминах кооперирования
объектов, определенных с
помощью классов внутри объекта.
Применяя регистр для объекта, можно
переопределить вариант
использования для элементов объекта. В
соглашении о сотрудничестве может
быть также отображено, каким
образом эти "подчиненные"
реализуют варианты использования при
взаимодействии
Графы, отображающие временные
последовательности, где внимание
акцентируется на порядке
сообщений
Диаграммы пе- Привязка к одному классу — со-
реходов между стояния, с помощью которых мож-
состояниями но передать экземпляр класса
Исполнители, плавные
узкие линии,
завершающиеся объектами,
связи (стрелки),
сообщения, размещенные
вертикально
Событие, состояние,
переход,
инициированный событием
Целью формирования объектно-ориентированной модели является наличие
самодостаточных объектов. Этот тип объекта способен инициализировать себя

Методы анализа и разработки проекта 815
и допускает управление собой при переходе из одного состояния в другое. Такой
подход позволяет поддерживать в модели функциональную ответственность.
Как и в случае со структурными моделями, ОО-модели рассматривается в этой
книге лишь поверхностно. Большое количество книг посвящено рассмотрению ОО-
подхода, где содержится достаточно глубокое толкование каждого аспекта данного
подхода. Желательно, чтобы менеджер программного проекта хорошо понимал
различия между анализом SA/SD и OOA/OOD. Тогда он сможет выбрать такие методы
анализа и разработки, которые успешно дополнят выбранный жизненный цикл, а
также запросы определенного проекта.
Надеемся, что использование ОО-методов будет строго согласованным, поскольку
преимущества такого подхода хорошо известны:
■ возрастает производительность труда разработчиков благодаря переходу от
низкоэффективного подхода, основанного на применении кода/отладки к
высокоэффективному — на базе анализа/разработки;
■ запросы реального мира моделируются путем концентрации внимания на классах,
а не на алгоритмах;
■ компоненты системы легко изменяются и применяются повторно;
■ требования легко отслеживаются;
■ легко обрабатываются итерации между фазами;
■ поддерживается прототипирование;
■ разработка проекта представляет собой "бесшовный" процесс; он отличается
непрерывностью в представлении (одни и те же типы диаграмм применяются как
при анализе, так и в период разработки);
■ работа по моделированию осуществляется с помощью универсальных инструментов.
Конечно, анализ OOA/OOD не являются панацеей от всех бед. Продолжают
существовать и извечные "враги анализа и разработки проекта", а именно —
затруднения со связью, бюджетные ограничения и рамки графика, недостатки экспертиз в
предметной области и т.д. В ОО предпринимается попытка преодоления этих
недостатков с помощью различных инноваций.
■ Упрощение может вызвать некоторые затруднения в понимании следующего:
- функция и спектр работ хорошо определенного объекта, которые могут быть
легко представлены;
- основное внимание уделяется взаимодействиям и более элегантной разработке
проекта;
- принцип "разделяй и властвуй" — инкапсуляция и формирование модулей.
■ Модели динамического и статического анализа описывают требования и их суть.
■ Одни и те же динамические и статические модели описывают в разработке
"способы" взаимодействия с объектом.
■ Инкапсуляция скрывает "внутренние наработки" объекта, позволяя разработчику
уделять больше внимания методам использования объектов (их существенные,
неотъемлемые характеристики); позволяет разделять статус, функцию, поведение;
ограничивает доступ к переменным, которые функционируют внутри алгоритма.
■ Агрегация позволяет создавать крупный объект из небольшого, упрощать
объекты, позволяя выполнять обработку сложных состояний.

816 Глава 22
■ Разбиение на модули находит отражение в функциональных блоках.
■ Полиморфизм позволяет понять, каким образом каждый объект выполняет свои
операции.
Напомним, что точно так же, как и в случае с SA/SD, "анализ" является этапом
разработки программного продукта, который позволяет формулировать модель в
проблемном домене. Благодаря анализу основное внимание уделяется тому, что
следует делать, каким образом добиться цели, а уж процесс достижения целиком зависит
от разработки.
Унифицированный язык моделирования
В конце 90-х годов прошлого столетия в ОО появился открытый стандарт,
выраженный в форме языка UML (Unified modeling language, унифицированный язык
моделирования). Этот стандарт в основном разработан тремя наиболее влиятельными
специалистами в этой области, а именно Гради Бучем (Grady Booch), Иваром Джакоб-
соном (Ivar Jacobson) и Джеймсом Румбафом (James Rumbaugh). Язык UML не
является языком программирования в полном смысле этого слова. Его также трудно назвать
"методом", поскольку он не предназначен для использования при работе со всем
процессом, не предписывает каких-либо подходов и не содержит основных направлений
для разработки. Этот единственный в своем роде, общедоступный и широко
применяемый "язык моделирования", унифицирующий, по крайней мере, 10 стандартов для
"спецификации, визуализации, конструирования и документирования компонентов
программных систем, а также оказывающий неоценимую помощь при моделировании
бизнес-проектов и систем непрограммного профиля". Язык UML "представляет
набор отлично разработанных инженерных задач практического профиля, которые
успешно испытаны при моделировании крупных и сложных систем". Здесь
поддерживается метамодель для диаграмм классов и набор семантических/синтаксических
правил, определяющих суть элементов и отношений. Модель поддерживается
большим количеством автоматизированных инструментов, включая Rational Software's
Rose, Computer Associates' Paradigm Plus, Rosch Consulting's Very Quick Modeling
(VQM), Secant products и Microsoft's Visual Modeler. Обычно разработка ОО-проектов
реализуется с помощью таких языков программирования, как Java, C++ и Visual Basic.
Ниже перечислены основные цели использования языка UML на этапе
разработки проекта:
■ поддержка на уровне пользователей готового к применению, выразительного
визуального языка моделирования, применяемого для разработки и обмена моделями;
■ поддержка спецификаций, независимых от определенных языков
программирования и процессов разработки;
■ поддержка формального базиса для представления языка моделирования;
■ обеспечение роста рынка объектных инструментов;
■ поддержка высокоуровневых понятий, таких как компоненты, элементы
сотрудничества, каркасы и шаблоны;
■ интеграция наилучшего опыта.
Некоммерческая Группа объектного менеджмента (Object Management Group,
OMG), стремится реализовать требуемые стандарты и добиться скорейшего
внедрения на практике языка UML. В настоящее время она продолжает поддерживать эти

Методы анализа и разработки проекта 817
стандарты, причем пользуется услугами более 800 привлеченных членов. Полные
открытые стандарты UML можно загрузить с Web-узла Группы объектного
менеджмента по адресу www. отд. org.
Язык UML применяется в контексте процесса, однако, авторы не определяют
специфики этого процесса, она складывается в результате разработки проекта.
Появилось реальное осознание того факта, что различные организации и проекты требуют
различных шагов по обработке (т.е. обработка транзакций в противовес вложенным
приложениям реального времени). Язык UML обязан поддерживать среду разработки,
которая управляется с помощью вариантов использования, архитектурно оформлена,
является итерационной и может наращиваться.
Разработчики UML также установили, что даже при использовании современных
передовых технологий, при сборе требований анализе и разработке приходится
преодолевать сопротивление "все тех же старых врагов", т.е. продолжается борьба с
неадекватными и постоянно изменяющимися требованиями заказчиков.
Варианты использования (use case) предназначены для уточнения динамических
требований и выработки более четкого представления о возможных изменениях
в поведении. Они позволяют реализовать функциональные усовершенствования,
которые отражаются и адресуются в организованной форме. Классы и объекты языка
UML демонстрируют гибкость и управляемость при использовании статично и
динамично несовершенных описаний. Для оживления общения в команде ОО-разработка
позволяет реализовать группе программистов интегрированный подход с помощью
общего словаря и языка; инкапсуляция данных и алгоритмов позволяет членам
команды работать над компонентами в параллельном режиме. Также в этом случае
можно ограничить влияние изменчивости требований; наследственные свойства
функций и атрибутов являются эффективным дополнением к функциональным
возможностям.
Объектно-ориентированный анализ
Анализ ООА служит в основном для создания диаграмм "класс/объект", вариантов
использования/сценариев и примеров/диаграмм, отражающих определенные
действия (табл. 22.4). Но, как и в случае с SA/SD, ООА-анализ служит лишь
вспомогательным средством в такой работе. Некоторые аналитики предпочитают начинать
работу с конструирования диаграмм классов, в то время как другие — с разработки
вариантов использования. Чарльз Рихтер (Charles Richter) указывает, что работать с
OOA/OOD удобнее, поскольку в данном случае соблюдается непрерывность
представлений. Действительные элементы, отображаемые в аналитических моделях,
продолжают свое существование на протяжении всего процесса разработки. При
помощи ОО анализ превращается в процесс разработки проекта, поскольку ОО-
разработка представляет собой процесс совершенствования во время доработок'.
Статическое представление объектно-ориентированного
анализа: диаграмма класса
Статическая модель ОО представляет собой диаграмму класса (а также диаграмму
объекта для представления определенного экземпляра класса), куда входят
компоненты атрибутов, служб и отношений наряду с понятиями, взятыми из иерархии,
Richter Charles. Designing Flexible Object-Oriented Systems with UML. Indianapolis, IN: Macmillan
Technical Publishing, 1999.

818 Глава 22
абстракции, инкапсуляции, наследования и полиморфизма. Идентифицируются
ответственности классов, затем обработка "идет наверх", а для достоверности
применяются сценарии вариантов использования (use case). В этом случае реализуется
подход "снизу-вверх". Подобный способ достаточно хорош, но существует еще путь
"сверху-вниз", когда при идентификации классов начинают с практических примеров,
а затем продолжается обработка "вниз", доходя до сценариев. Если начать с классов,
можно сначала идентифицировать их через абстракции или же в имеющейся
документации поискать существенные фразы. Затем для каждого класса перечисляются
ответственности, идентифицируются атрибуты и операции (поведение — снова через
абстракцию или осуществляется поиск фраз с глаголами) и, наконец, обращаются к
сценариям вариантов использования для подтверждения диаграммы класса. Однако
сначала рассматривается описание диаграмм классов.
Классы
Класс представляет собой абстракцию в предметной области приложения, в
общем случае выраженную существительным. Абстракция может быть концептуальной
или физической; она отражает возможности системы по хранению информации о
ней же, по взаимодействию с ней или же оба эти фактора. Класс включает атрибуты
(данные, описывающие объект, а также тот объем информации об объекте, который
хранится в системе), отношения с другими классами и операциями (поведение
данного объекта, которое и описывает соответствующие ответственности). Диаграмма
класса портретирует содержимое классов (набор декларативных, статичных
элементов модели), отражая их взаимоотношения.
Также класс определяет интерфейсы соответствующих экземпляров. Несмотря на
то, что классы абстрактны, его экземпляры специфичны. Объект является отдельным
(особенным) экземпляром класса. Все объекты, проиллюстрированные примерами из
класса, имеют значения атрибутов, соответствующие атрибутам из полного
дескриптора классов. Эти объекты будут также поддерживать операции, описываемые
дескриптором классов. Например, телефон является классом; телефон Сюзанны пред-
стапляет собой объект, как и телефон Уойласа.
Объекты
Объекты являются экземплярами класса и совместно используют свойства (атрибуты
и операции) данного класса. Каждый объект отличается собственной идентичностью и
имеет характерный набор значений для атрибута. Он является сущностью,
инкапсулированной в двух воплощениях — состояния и поведения. Состояние представлено с
помощью атрибутов и связей; операции и механизмы состояния представляют поведение.
Состояние сохраняет эффекты от производимых некоей сущностью операций.
Диаграмма объекта отображает объекты и их ассоциации/отношения (связи) в их развитии
во времени. Диаграммы объекта могут восприниматься как диаграммы сотрудничества,
поскольку в них отображаются отношения, "связывающие" объект.
Класс может быть "абстрактным". Это означает, что он применяется для
определения подклассов, которые могут быть проиллюстрированы примерами. Однако
класс нельзя проиллюстрировать непосредственно, опираясь только на него самого.
Классы обладают поведением, которое также называется операцией, службой,
функцией или методом. Эти термины используются в спецификации OMG UML, где
"операция" описывает класс и объект, а "метод" — реализацию операции. Если
операция вызывается, то поведение предписывается.

Методы анализа и разработки проекта 819
Классы должны отличаться идентичностью, иметь четко определенные
ответственности и поддерживать системные функции, взаимодействуя с другими объектами
посредством сообщений.
Классы описываются с помощью атрибутов (данные, свойства), операций
(службы, функции, поведение, процесс, методы), жизненного цикла разработки ПО
(состояние, идентичность, независимость существования) и ассоциаций (отношения,
связи, соединения). Классы имеют свойства, структуру, поведение и отличаются
независимостью существования.
Объектом (если он подобен сущности) может быть:
■ материальный предмет (или индивидуум);
■ выполняемая роль;
■ событие (например, визит к врачу);
■ взаимодействие (контракт);
■ операционная процедура (обзор);
■ организационная единица (SQI);
■ место (банк);
■ структура (Эйфелева башня).
Интерфейсом называется набор операций, характеризующих поведение элемента.
Сообщение является спецификацией по транспортировке информации из одного
экземпляра в другой, причем ожидается, что эта деятельность имеет какой-либо результат
(сообщение может указывать на формирование сигнала или на вызов операции). Метод
представляет реализацию для операции (указывает алгоритм или процедуру, которая
ассоциируется с операцией). Стимул определяет передачу информации из одного
экземпляра в другой, например, формирование сигнала или вызов операции; получение
сообщения означает обработку стимула, который передается из экземпляра
отправителя. Получатель (объект) является объектом для обработки стимула, который передается
из экземпляра отправителя. Отношение представляет семантическую связь между
элементами модели (примеры отношений включают ассоциации и обобщения). Ответственность
является контрактом или обязательством создателя классов; для пересылки сообщения
стимул передается из экземпляра отправителя к экземпляру получателя. Отправитель
(объект) представляет собой объект, передающий стимул в объект получателя.
Объект является экземпляром, который порождается классом. Он структурирован
и функционирует в соответствии со своим классом. Все объекты, порожденные одним
и тем же классом, структурированы одним способом, хотя каждый из них имеет свой
собственный набор связей атрибутов. Каждая связь атрибута имеет ссылку на
экземпляр, обычно на значение данных. Объект может иметь несколько классов (т.е. может
порождаться несколькими классами). В этом случае объект обладает всеми
свойствами, которые объявлены во всех этих классах, как структурными, так и
поведенческими. Более того, набор классов (т.е. набор свойств, которые согласуются с объектом)
со временем может варьироваться. К объекту можно добавлять новые классы, а
старые классы отделять. Это значит, что свойства новых классов динамически
добавляются к данному объекту, а свойства, объявленные в классе, удаляемом из объекта,
динамически также удаляются из объекта .
См. сноску 5.

820 Глава 22
Атрибуты
Атрибут представляет собой описание набора значений, которые могут
вызываться экземплярами данного класса. Эта информация является для объекта внутренней и
характеризуется следующими особенностями:
■ представление с помощью существительного;
■ описание объекта в терминах реального времени;
■ возможность, служить индикатором состояния;
■ обладание типом данных;
■ идентичность для объектов одного класса (может отличаться по значению, но не
но сути);
■ возможность получения значения, определенного с помощью домена пересчета
(набор определенных значений).
Операции
Операция представляет собой услугу, которая может запрашиваться из объекта
д.тя оказания влияния на его поведение. Операции можно описывать согласно
следующим параметрам:
■ инкапсулирование внутри объекта;
■ отклик на стимул (сообщение);
■ возможность действия, выполняемого объектом с помощью другого объекта;
■ возможность преобразования, которому подвергается объект;
По отношению к UML метод является специфической реализацией операции.
Операция (метод) является средством, с помощью которого объект может
реализовать свою ответственность. Операция для объекта вызывается с помощью
сообщения, пересылаемого из другого объекта. Все объекты имеют методы, применяемые
для их инициализации и выявления в рамках модели, а также возможности для
"приобретения" атрибутов и "избавления" от них.
Ассоциации
Ассоциация провозглашает "важное и интересное" соединение (связь) между
"понятиями" или классами (объектами). Рассматриваемое понятие включает, по
крайней мере, два "ассоциативных конца". Свойство множественности для "концов
ассоциации" показывает, какое число экземпляров можно ассоциировать с отдельным
.жземпляром класса.
Сообщения
Каждый объект имеет интерфейсы, которые требуются для выполнения
возложенных на него задач. Эти интерфейсы определяют средства взаимодействия между
объектами. Каждому объекту пересылаются сообщения других объектов. Интерфейсы
относятся к общедоступным методам, поскольку они имеют отношение к другим объектам.
Полезно определять интерфейсы заранее, т.е. в жизненном цикле разработки ПО.
В этом случае команда программистов может быть разделена с учетом границ между
объектами, что предпочтительнее разделения по функциональным границам. После
того, как интерфейсы и набор ответственностей четко определены, они могут функцио-
i шровать независимо, объединяясь лишь позднее, в цикле по тестированию модели.

Методы анализа и разработки проекта 821
Интерфейсы можно использовать для установки атрибута, возвращения значения
атрибута и для запроса объекта с целью выполнения операции.
Методы представляют собой способы взаимодействия объектов между собой,
передачи сообщений для вызова (стимулирования) определенной деятельности
(поведения) в пределах объекта получателя. В ходе проведения анализа SA/SD для
этого к каждому объекту, имеющему ссылку на другие объекты, добавляется внешний
ключ. В объектной методологии ID объекта представляет собой альтернативный
подход ко внешним ключам. Он создается и поддерживается ОО-системой. Для
установления связи между объектами они просто включаются в определение атрибутов
целевого объекта.
Сообщения содержат объект назначения (включающий операцию,
предназначенную для выполнения), название выполняемого оператора и параметры, которые
необходимы для выполнения операции.
Икапсуляция
Процесс инкапсуляции заключается из отделения внешних аспектов объекта от
деталей внутренней реализации этого объекта. Другим термином инкапсуляции является
сокрытие информации. Внешние аспекты объекта доступны другим объектами с помощью
методов самого объекта, в то время как внутренние реализации этих методов скрыты от
внешнего объекта, пересылающего сообщения. Инкапсуляция важна для получения
потенциала или для поддержки объектно-ориентированной модели. Поскольку
подробности реализации скрыты от других объектов, они содержатся в пределах объекта.
Влияние изменений, вносимых в реализацию метода минимально для всей модели. В ходе
выполнения инкапсуляции применяются атрибуты и операции.
Наследование
Наследование определяет совместное использование атрибутов и поведение
объектов в пределах иерархической структуры (суперклассов и подклассов). Каждый
подкласс наследует все свойства (атрибуты и операции) суперкласса (предка) и
добавляет свои собственные уникальные свойства. Класс содержит описание всех
атрибутов, ассоциаций и операций, входящих в объект, — это и является обобщением
объекта. Каждый класс имеет набор наследуемых свойств— атрибутов, операций и
ассоциаций. Эти структуры данных и алгоритмы немедленно становятся доступными для
подклассов наследников. Класс может иметь потомков (подклассы, подтипы), где
"ребенок" является специализацией "родителя". "Ребенок" наследует (включает в
себя) эту структуру и поведение "общих родителей", при этом он оказывается
способным добавлять свои собственные атрибуты и операции. Такое отношение также
известно как обобщение (генерализация). Наследование/специализация/обобщение
является преимуществом метода ООА, поскольку поддерживает повторное
использование классов. Благодаря применению этих понятий свойства суперклассов
повторяются в каждом объекте подкласса, и таким образом поддерживается высокий фактор
обновления. Изменения для атрибутов или операций немедленно наследуются всеми
подклассами.
Полиморфизм
В определениях ОО этим термином обозначают способность различных
объектов отвечать различным образом на одно и то же сообщение. Если сообщение "go"
пересылается различным объектам, различия в реагировании определяются типом

822 Глава 22
отдельного объекта. Таким образом, различные операции могут иметь одно и то же
название; "go_boat" может означать "поднять паруса" для парусного судна или
"запустить двигатель" — для моторной лодки. Благодаря полиморфизму объекты
приобретают большую степень независимости.
Проектирование классов
В ходе проектирования классов в разрезе рассмотрения их ответственностей
желательно представлять объект в качестве полной сущности. Появляется искушение
ограничить рассмотрение только теми данными, которые необходимы для хранения,
или выбранными методами. Однако подобный подход вызывает чрезмерное
использование процедурных, а не объектных терминов.
Чтобы рассматривать объект как цельную сущность, попытайтесь уточнить, каким
образом он будет выполнять все обязательства. Подобный подход основан на
ответственностях в противовес подходу, базирующемуся на данных. Применяя результаты
основательного изучения, определим и четко обозначим роли объектов-кандидатов.
После этого уточним, что же должно быть известно каждому объекту о самом себе.
Суперклассы и подклассы
Набор классов можно структурировать иерархически, применяя суперклассы и
подклассы. Суперкласс представляет собой более высокий уровень группировки классов
(подклассов) с общими атрибутами и методами, ограниченными рамками этого класса.
Абстрактные классы
Абстрактный класс является суперклассом, который не имеет экземпляров и
вводится в данную структуру в дополнение к уже существующим классам. Основной
целью класса этого типа служит группировка классов и охват информации, которая
имеет общий характер для всей группы.
Обнаружение объектов-кандидатов
Процесс идентификации объектов-кандидатов часто начинается с поиска
существительных в определении делового цикла, а также методик, которые применяются на
этапе анализа требований для SA/SD. Аналитик должен руководствоваться
следующими критериями.
■ Должна ли система помнить что-либо об объекте?
■ Должен ли объект поддерживать определенное поведение или функцию?
■ Должен ли объект быть наделенным ответственностью?
■ Должен ли объект иметь множественные атрибуты?
■ Следует ли объекту иметь специальные случаи, которые могут привести к
наследственной структуре?
■ Следует ли объекту совместно использовать свойства с другими потенциальными
объектами? (Отсюда может следовать, что объект является частью потенциально
наследственной структуры для другого объекта.)
■ Содержит ли объект некие сущности, которые уже определены как объекты?
Если аналитик решил сформировать диаграммы вариантов использования до
создания диаграмм классов, сценарии вариантов использования обеспечат исходные
данные для идентификации классов.

Методы анализа и разработки проекта 823
Поиск атрибутов
После определения класса/объекта атрибуты позволят уточнить, что означает
объект в контексте предметной области проблемы. Представление о протекании
процесса может способствовать появлению терминов, определяющих объект. При
обработке атрибутов выполните следующие действия:
■ заново определите атрибуты объекта, включая производные атрибуты (значение
может быть полностью определено с помощью значений других атрибутов);
■ отмените те атрибуты, которые не являются обязательными, например,
внутренние идентификаторы, внутренние состояния и несоответствующие уровни
детализации;
■ не забывайте о том, что с помощью прилагательных могут отображаться
специфические значения перечисления для атрибута;
■ помните, что, как и в случае с анализом SA/SD, атрибуты размещаются в словаре
данных.
Поиск операций
Ознакомьтесь с описанием процесса обработки или утверждением, описывающим
предметную область проблемы, а также выполните грамматический анализ глаголов.
Рассматривайте связи, возникающие между объектами. Помните, что операции
определяют поведение объекта, изменяют значения атрибута. Необходимо знать
атрибуты объекта, иметь возможность манипулировать структурами данных. Также следует,
выполнять вычисления или просматривать объект относительно появления
контролирующего события.
Для разработчиков, не имеющих опыта работы с предметной областью,
существует три стадии, от высокой абстракции до менее абстрактных диаграмм классов:
краткое определение, неформальная и формальная стратегии. Ниже приводится пример
классической проблемы с лифтом, описанной в примечании 22.2.
"Создание точного определения" означает определение программного продукта
в форме лаконичного предложения, если, конечно, это возможно. Это предложение
может иметь следующий вид "Кнопки в лифтах и на этажах используются для
управления движением лифтов (и) в здании, где количество этажей равно т".
"Создание неформальной стратегии" означает включение ограничений,
выраженных в отдельном параграфе. Возможно, следующее высказывание будет
справедливым для задачи о лифте: "Кнопки в лифтах и на этажах контролируют движение
лифтов (м) в здании, где количество этажей равно т. Кнопки подсвечиваются при
нажатии, что и определяет вызов лифта на определенный этаж; подсветка затухает
после выполнение команды. Если лифт не вызывается, он остается на том или ином
этаже с закрытыми дверьми".
"Формализация стратегии" заключается в идентификации существительных в
неформальной стратегии и применение их в качестве классов-кандидатов.
Существительные в нашем примере— это кнопка, лифт, этаж, движение, здание, подсвечивание
и дверь. Существительные этаж, здание и дверь выходят за границы проблемы
(находятся вне зоны контроля). Существительные движение к подсвечивание являются
абстракциями, которые в настоящий момент исключены, но следует помнить, что
они необходимы для потенциальных атрибутов. Остаются классы-кандидаты лифт и
кнопка. Появляются подклассы — кнопка лифта и кнопка на этаже.

824 Глава 22
Класс-Ответственность-Сотрудничество (CRC)
Предложенные в 1989 году, CRC-карточки доказали свою экономическую
эффективность и оказали большую помощь при идентификации классов. Они особенно успешно
используются при проведении сеансов "мозгового штурма" экспертами в данной
предметной области. Действия, производимые в этом случае, заключаются в заполнении
"карточек", содержащих название потенциального класса наряду с описанием его
функциональных возможностей, а также перечень классов, для которых реализуется
сотрудничество. Затем участники команды используют эти карточки для выполнения
сценариев. Поскольку изменения удобнее вносить именно в карточки, они становятся
универсальным инструментом для определения ошибочных или некорректных
действий, возникающих в процессе работы команды. В табл. 22.5 показано, какой вид
могут иметь CRC-карточки для задачи с лифтами. Также эти карточки оказывают
влияние па диаграмму классов, как показано на рис. 22.46.
Диаграммы
класса
отображают
статическую
структуру
объектов,
их внутреннюю
структуру
и взаимосвязи
Лифт
■*■ Управление -
Контроллер лифта
Управление-»-
Дверь
Взаимодействует с
Кнопка
/—ч
Кнопка лифта
Кнопка двери
Рис. 22.46. Диаграмма классов для задачи о лифтах
На этой диаграмме в роли классов выступают лифт, контроллер лифта, дверь
п кнопка. Кнопка лифта и кнопка на этаже являются подтипами класса кнопок. Эти
подтипы наследуют атрибуты и операции кнопки, которая является обобщением
кнопки лифта и кнопки на этаже, которые являются, в свою очередь,
специализациями кнопки.
Статические представления объектно-ориентированного
анализа — диаграммы вариантов использования
Диаграммы вариантов использования позволяют выполнить статичный или
организационный обзор системных функций и их отношений, как с внешними
объектами, так и между собой. Вариант использования является описательным
документом, где представлена последовательность событий для исполнителя (внешнего
агента), использующего систему для завершения процесса. Также приведены
хронологические сведения или случаи применения системы с изображением
требований. Этот термин был предложен Джекобсоном (Jacobson) с целью описания тех
способов, с помощью которых исполнитель (сущность, находящаяся вне системы и
взаимодействующая с ней) использует эту систему.

Методы анализа и разработки проекта 825
Таблица 22.5. CRC-карточка для задачи о лифтах
Класс: Контроллер лифта
Ответственности
Нажмите кнопку лифта
Отпустите кнопку лифта
11ажмите кнопку на этаже
Отпустите кнопку на этаже
Откройте дверь лифта
Закройте дверь лифта
Переместите лифт на один этаж вверх
Переместите лифт на один этаж вниз
Сотрудничество
Кнопка лифта
Кнопка лифта
Кнопка на этаже
Кнопка на этаже
Дверь лифта
Дверь лифта
Лифт
Лифт
Система, подсистема или класс поддерживают согласованную единицу
функциональности, которая определяется с помощью последовательности сообщений. Этими
сообщениями обмениваются компоненты системы, а также один или больше
внешних исполнителей, как показано на рис. 22.47. Исполнитель может играть отдельную
роль с учетом каждого варианта использования, с которым он взаимодействует.
Лифт
1. Пассажир нажимает кнопку,
находящуюся на этаже
2. Система лифта обнаруживает,
что нажата кнопка,
находящаяся на этаже
3. Лифт перемещается
на указанный этаж
4. Открывается дверь лифта
5. Пассажир входит в лифт
и нажимает его кнопку
6. Закрывается дверь лифта
7. Лифт перемещается
на требуемый этаж
8. Открывается дверь лифта
9. Из лифта выходит пассажир
10. Закрывается дверь лифта
Обнаруживает факт нажатия кнопки (E,F)
Включена/отключена подсветка кнопки
Переместить/остановить лифт
Открыть/закрыть дверь
Рис. 22.47. Вариант использования в задаче о лифте/сценарий вариантов использования
Варианты использования определяют поведение сущности, например, системы
или подсистемы, не указывая своей внутренней структуры. Каждый вариант
использования определяет последовательность действий, которые может выполнять
сущность в условиях взаимодействия с собственными исполнителями. Экземпляры
вариантов использования и исполнителей взаимодействуют, если задействуются услуги
этих сущностей.
Диаграммы вариантов использования отображают исполнителей и варианты
использования наравне с их отношениями. Варианты использования определяют

826 Глава 22
функциональность системы, подсистемы или класса, как это указывается для
внешних исполнителей. Исполнители связываются с рассматриваемой сущностью,
отправляя и получая сообщения, отображающие реализацию вариантов использования.
Несколько определений помогут упростить терминологию: вариант
использования (класс) характеризует последовательность действий, которые система (или иная
«ущиосп.) может выполнять, взаимодействуя с исполнителями системы. Диаграмма
вариантов использования отображает отношения между исполнителями и
вариантами п. пользования в пределах системы. Экземпляр варианта использования
определяет последовательность действий, которые указаны в вариантах использования.
Варианты использования могут определять внешние требования для объекта,
а также указывать функциональные возможности, предлагаемые уже реализованной
сущностью. Вес это можно описать подробным образом, включая описание операций
имеете с атрибутами в графы действий или с помощью других методик.
Если исполнители инициируют сообщения, варианты использования откликаются
путем выполнения определенных последовательных действий. Варианты
использовании, подобно диаграммам потоков данных, не используют возможности по
временном}- образованию последовательностей, а функции могут появляться в произвольном
порядке.
Динамическое представление объектно-ориентированного
анализа — диаграмма действий
Добавляя поведенческие характеристики, диаграммы действий придают
определенную динамику процессу обзора системных функций. Их можно трактовать как
абстрактный рабочий ноток представлений о деятельности. Подобно блок-схемам 60-х
годов, здесь имеется ограниченное число конструкций: Одна форма деятельности
должна вытекать из другой (простая последовательность), одна форма
деятельности накладывает определенные условия на другую (принятие решения или
последовательность if/then/else) или же одна из видов деятельности вытекает из многих
в. шожных конкретизации или других форм деятельности (конструкции do-while,
do-uiuil или do case). Отличие блок-схемы от диаграммы действий состоит в том,
что формы действий, заключенные между полосами синхронизации, могут
протекать в любом порядке или параллельно.
Связи между объектами моделируются как события. Когда отправитель генерирует
событие, которое доставляется получателю, может проявиться асинхронизация
(отправитель продолжает выполнение) или синхронизация (отправитель
приостанавливает выполнение до тех пор, пока получатель обработает отправленное
событие). На рис. 22.48 показана диаграмма действий для примера с лифтом.
Объектно-ориентированная разработка проекта
Напомним, что в случае с SA/SD "разработка проекта" относится в фазе процесса
создания программного продукта, основная цель которого состоит в определении
способа внедрения системы. На этапе разработки стратегические и тактические
решения предпринимаются с учетом функциональных требований и ограничений по
качеству для данной системы. В процессе разработки проекта развитие модели более
важно, чем создание полностью новых моделей. Сюда входят формирование
интерфейсов и реализации, которые позволяют репозитариям стать экземплярами и получить
распространение на базе существующих моделей.

Методы анализа и разработки проекта 827
Г Нажата кнопка "\_
\^ на этаже у"
У Контроллер устанавливает А
Д^ факт нажатия кнопки J
Лифт перемещается
на этаж
«■ т <
•-
-Нет-
< Пассажир нажимает \
кнопкуэтажа J
\
(Закрываются Л
дверилифта J
Да.
(Лифт перемещается Л
на выбранный этаж J
Рис. 22.48. Диаграмма действий для задачи о лифте
Нет
Статическое представление объектно-ориентированной
разработки проекта: диаграмма класса
На фазе OOD диаграммы класс/объект определяются повторно путем их
уточнения. Если при рассмотрении задачи о лифте сформирован самый общий обзор и
проведены определенные исследования, более подробная диаграмма класса может быть
представлена так, как это показано на рис. 22.49.
Объектно-ориентированная разработка проекта — диаграммы
взаимодействия
Диаграммы взаимодействия— это обобщенный термин, применяемый к описанию
нескольких типов диаграмм, в которых основной акцент делается на
взаимодействие объектов. Речь идет о диаграммах сотрудничества и последовательных
диаграммах. Диаграммы сотрудничества отображают отношения между экземплярами
и служат демонстрации эффективности применения того или иного экземпляра.
Последовательные диаграммы показывают точную последовательность входных
сигналов и позволяют представить спецификации с учетом запросов реального времени,
а также сложные сценарии. Диаграммы взаимодействия описывают динамические

828 Глава 22
iu-димодействия между классами и характеризуют способы взаимодействия объектов в
определенном сценарии. Также в диаграммах указывается, какие объектные методы
i к пользуются в данном сценарии и в каком порядке они вызываются. Однако в
диаграммах взаимодействия не отражено, какие объекты функционируют во внутренней
оодасти и сколько их изменилось со временем.
Лифт
Щ, direction : boolean
Щ> current..floor: int
* move()
© stop()
e status()
n 1
Контроллер лифта
4 floor id : int
• position: int
• direction: boolean
1
m
Кнопка
4 illuminate: boolean = off
*illuminate()
♦ cancel illuminate()
♦ status()
Двери
ft close: boolean = true
♦close()
♦open()
Кнопка лифта
4 floorjium: int
Кнопка на этаже
4 floorjium : Int
4 direction: boolean
Рис. 22.49. Диаграмма детализированного класса
< «этическое представление объектно-ориентированной разработки проекта —
диаграммы взаимодействия и сотрудничества
Диаграммы сотрудничества отображают взаимодействия, которые
пространственно ориентированы на окружение модели и характеризуют классы и ассоциации
(экземпляры и связи). Диаграмма сотрудничества отображает отношения между
экземплярами объектов. Последовательные диаграммы и диаграммы сотрудничества
отображают сходную информацию, но используют для этого различные подходы.
Поведение реализуется с помощью набора объектов, обменивающихся входными
сигналами в рамках общего взаимодействия, что позволяет достичь поставленной
цели. Для представления механизмов, применяемых при разработке, важно обращать
внимание только на определенные объекты и изучать взаимодействие между ними.
Рассматриваемые объекты всегда проектируются из большей системы, в которой
данные объекты являются лишь компонентами.
Целью сотрудничества является определение способов реализации вариантов
использования. Сотрудничество уточняет контекст, который позволяет выразить
поведение реализуемого элемента в терминах, единых для всех участников сотрудничества.
Таким образом, в то время как модель представляет систему в целом, сотрудничество

Методы анализа и разработки проекта 829
является лишь частичным отображением данной модели. Именно сотрудничество
определяет эффективность применения подмножества содержимого модели.
Сотрудничество можно охарактеризовать на двух различных уровнях: на уровне спецификации
или на уровне экземпляра. Диаграмма, представляющая сотрудничество на уровне
спецификации, характеризует роль классов и ассоциаций. В то же время диаграмма на
уровне экземпляра отображает экземпляры и связи, которые согласуются с ролями в
сотрудничестве. При отображении сотрудничества указывается, какие экземпляры
свойств должны принимать участие в сотрудничестве (т.е. каждый участник указывает
необходимые свойства, которыми должен обладать согласуемый экземпляр) .
Примеры диаграмм сотрудничества для задачи о лифте показаны на рис. 22.50.
На диаграмме
сотрудничества
отображены взаимосвязи
между объектами
Пассажир
1: нажать
2:обновить запрос
Кнопка на этаже
3:подсветить
^переместить/ Постанов
7:отменить подсветку >^^^ S Nsv"'4
5:достичь этажа «^закрыть
Лифта
Рис. 22.50. Задача о лифте: пример диаграммы сотрудничества кнопки лифта и кнопки у двери
Динамическое представление объектно-ориентированного проектирования —
диаграммы взаимодействия и последовательные диаграммы
Последовательные диаграммы демонстрируют взаимодействие, отображенное в
динамике. В частности, на ней отображаются экземпляры, участвующие во
взаимодействии с помощью соответствующих "линий жизни", а также входные сигналы,
которыми они обмениваются. Эти сигналы собраны во временную последовательность.
См. сноску 5.

830 Глава 22
В отличие от диаграммы сотрудничества, последовательная диаграмма включает
временные последовательности, но не содержит объектных отношений.
Последовательная диаграмма может существовать в общей форме (описывать все возможные
сценарии) и в форме экземпляра (описывать один действительный сценарий).
Последовательные диаграммы и диаграммы сотрудничества выражают подобную информацию,
однако, используют различные способы.
Пассажир
Кнопка лифта
Контроллер
лифта
Лифт
Дверь
1 нажата
обновить
подсветить
отменить подсветку
переместить ^
^ достичь этажа
остановка
1
ощ
Г
)ЫТЬ
закрыть
'У
У
Последовательная диаграмма отображает явно выраженный набор сообщений,
пригодный для моделирования системы реального времени
Рис. 22.51. Последовательная диаграмма для задачи о лифте
Последовательная диаграмма имеет две размерности:
1. размерность по вертикали представляет время;
2. размерность по горизонтали представляет различные объекты.
Обычно значение времени отображается в нижней части страницы. Объекты
могут группироваться в ряды на диаграмме . На рис. 22.51 показана последовательная
диаграмма для задачи о лифте.
"' См. сноску 5.

Методы анализа и разработки проекта 831
Пассажир
Кнопка лифта
Контроллер
лифта
Лифт
Дверь
X нажата
1
обновить
подсветить
отменить подсветку
переместить
достичь этажа f
остановка |_
1
OTKJ
Г
зыть
1
закрыть
у
т1
Последовательная диаграмма отображает явно выраженный набор сообщений,
пригодный для моделирования системы реального времени
Рис. 22.51. Последовательная диаграмма для задачи о лифте
Примечание
Динамическое представление объектно-ориентированной разработки
проекта — диаграммы переходов между состояниями
Диаграммы, описывающие переходы между состояниями (state transition diagrams,
STD) представляют основанное на состоянии поведение класса экземпляров объектов
для всех сценариев. Обычно моделируются лишь классы с объектами, которые, как
ожидается, проходят через наборы состояний.
В данном случае применяются следующие определения. Состояние представляет
условие или ситуацию во время жизни объекта, при которой удовлетворяется
определенное условие, реализуется некоторая деятельность или же ожидается какое-либо

832 Глава 22
событие. Диаграмма состояния графика является диаграммой, где отображается
механизм состояния (поведение, определяющее последовательности состояния, которые
проходит объект или взаимодействие во время своей жизни при отклике на события,
имеете с соответствующими откликами и действиями).
Механизм состояния определяет набор понятий, которые могут использоваться
для моделирования дискретного поведения с помощью конечных систем переходных
состояний. Экземпляры событий генерируются в результате определенного действия
в пределах системы или ее окружения. Затем событие ориентируется на одну или
несколько целей. Средства, с помощью которых экземпляры событий транспортируют-
< я к месту назначения, зависят от типа действия, цели, свойств среды коммуникации
и многих других факторов. В некоторых случаях это происходит практически
мгновенно и вполне надежно, в то время как в других случаях могут происходить
периодические задержки передачи, потеря событий, переупорядочивание или дублирование.
С учетом вышеперечисленного никаких особых требований обычно не выдвигается.
Поддерживается полная гибкость при моделировании различных типов
коммуникационных возможностей. Событие получено, если оно размещено в очереди событий по
целевому назначению. Событие отправлено, если оно извлечено из очереди событий и
доставлено к механизму состояния для обработки. С этой точки зрения на него
ссылаются как на текущее событие. Наконец, событие поглощено, если завершена его обра-
6< > гка. Поглощенное событие становится недоступным для обработки. Никакие
требования не предъявляются к интервалам времени между получением события,
отправлением и поглощением. Вполне возможно использование различных
семантических моделей и типов нулевого времени.
Состояние во время выполнения может быть активным или неактивным.
Состояние становится активным, если оно вводится как результат некоторого перехода, а
неактивным, если завершается как результат перехода. Состояние может быть
завершено и начато как результат одного и того же перехода.
Диаграммы состояния представляют объекты, способных к динамическому
поведению, путем указания соответствующего отклика на получение экземпляров
события. Обычно они применяются при описании поведения классов. Состояние
представляет собой условие во время жизни объекта или взаимодействие, во время
которого оно удовлетворяет некоторое условие, выполняет определенное действие
или ожидает некоторое событие. Концептуально объект остается в состоянии во
время некоторого интервала. Однако семантики позволяют моделировать
состояния "протекания через", которые являются мгновенными, а также переходы,
которые не носят мгновенного характера . На рис. 22.52 показан механизм состояния
для задачи о лифте. Этот механизм аналогичен конечному механизму состояния из
t груктурного анализа.
Преимущества ОО-моделирования
Объектно-ориентированное моделирование находится в центре объектов
реального мира, непосредственно отображает предметную область задачи и
ответственности системы, оно задерживает определение подробностей реализации, переносит их
па более поздний момент на этапе разработки и минимизирует влияние изменений в
функциональных требованиях.
См. сноску 5.

Методы анализа и разработки проекта 833
I Общие черты анализа SA/SD и OOA/OOD
' Структурный анализ/разработка проекта имеют много общего с объектно-
ориентированным анализом/разработкой проекта. Конечно, имеются и отличия,
однако иногда более новые методики опираются на то, что хорошо известно. Ниже
перечислены их общие характеристики:
■ моделируют данные, функции и поведение;
■ обеспечивают выигрыш благодаря обобщающему архитектурному подходу;
■ нуждаются в наличии словаря данных или репозитария информации, который
называет как сложные, так и атомарные и описывает элементы модели;
■ опираются на диаграммы переходов между состояниями для отражения поведения
в реальном времени;
■ отображают границы системы и внешних объектов, взаимодействующих с
системой (DCD, CCD и сценарии вариантов использования);
■ предполагают наличие документации и спецификаций, состоящих из записанных
требований для идентификации фраз с существительными для элементов данных
и фраз с глаголами для элементов функции или поведения;
■ предлагают итерационный процесс, так как во время фазы разработки
необходимо возвращаться к аналитической фазе;
■ акцентируют внимание на достоинствах невысокого уровня соединения и
высокого уровня связывания: SA/SD — при разработке структурных диаграмм (в отличие
от интерфейсов модули очень тесно связаны), a OOA/OOD— при создании
классов (в отличие от объектов методы очень тесно связаны);
■ формируют системные модули, где группируются похожие понятия.
Основным преимуществом анализа OOA/OOD является способность проекта к
повторному определению или сотрудничеству, в связи с чем Рихтер (Richter)
упоминает о представительской непрерывности. На протяжении всего процесса разработ-
I ки создаются диаграммы одних типов, а действительные элементы, отображаемые в
' аналитических моделях, продолжают существовать до завершения разработки.
Диаграмма класса, играющая роль аналитического инструмента, обладает свойствами,
I которые проявляются во время разработки и при внедрении системы. Такие
обширные возможности ОО-анализа контрастируют с анализом SA/SD, где DFD- и CFD-
диаграмы становятся структурными с применением анализа преобразований или
транзакций, причем аналитические модели отличаются гораздо большим
разнообразием форм, чем модели разработки проекта.
Основным преимуществом применения анализа SA/SD является возможность
упрощения многих конструкций и относительная легкость их понимания. Данные
"проходят" через систему таким образом, что становятся вполне приемлемыми для
восприятия в реальном мире. Многие аналитики/разработчики утверждают, что
после ознакомления с данными, их структурой и преобразованиями они могут
охарактеризовать основные моменты рассматриваемой системы.
Сделаем предположение, что вариант подхода (смешение стилей только
приветствуется) уже определен менеджером проекта и командой, занятой в проекте на
ранних этапах. Если подход отражен в документах, аналитики и разработчики привычно
общаются на одном языке и каждый из них может самостоятельно решить, какой
подход будет лучшим.

834 Глава 22
Резюме
В главе рассматриваются вопросы моделирования с использованием большого
количества примеров и результирующих компонентов проекта по каждому методу.
Обзор: этапы структурного анализа
и разработки проекта
При реализации методик структурного анализа и разработки проекта менеджер
должен задать себе следующие вопросы.
■ Какие задачи будут выполняться?
■ Появления каких компонентов проекта следует ожидать?
■ Сколько времени на это потребуется?
■ Какой процесс используется?
■ Какой метод применяется— структурный метод или его комбинация с ОО-
методами?
■ Каким образом необходимо структурировать организацию для поддержки
процесса?
■ Какие инструменты— автоматизированные или выполняющие работу в ручном
режиме —должны использоваться для поддержки процесса?
Процесс анализа SA/SD "крупным планом" показан на рис. 22.52. Просматривая
его сверху вниз, можно заметить, что в верхней части модели могут содержаться
диаграммы отношений объекта или модели класса, а также то, что функциональными
моделями служат диаграммы содержимого данных, контрольные диаграммы
содержимого, диаграммы потока данных и диаграммы управления потоком. В верхней
части, или в начале, при обращении к анализу SA/SD удобно начать словарь данных и
расширить спецификации процесса, а также спецификации управления (которые
часто представлены в виде диаграмм перехода состояния).
В центре схемы находятся диаграммы контекста архитектуры, диаграммы потока
архитектуры и диаграммы архитектурных взаимосвязей. На этом этапе модели
требований анализируются с помощью пяти полей ("сердцевина" системы, интерфейс
пользователя, ввод, вывод, поддержка и помощь самому себе), потоки данных
соединяются, а затем система снова разбивается на составные части. Для большинства
проектов этот подход является весьма актуальным, особенно при наличии особо
сложных систем, функционирующих в режиме реального времени, или же в случае
наличия управляющих систем.
В нижней части, на третьем из рисунков, показано, каким образом перемещенные
функциональные модули подвергаются преобразованию или как реализуется анализ
транзакций при образовании набора структурных диаграмм, разложенных на самом
низком уровне. На самом низком уровне, где идентифицируется на структурной
диаграмме каждый модуль "черного ящика", может выполняться их преобразование
путем формирования внутренней структуры ("белого ящика"). Эти объекты, известные
как диаграммы Чейпина или диаграммы Несси-Шнайдермана, применяются при
конструировании реального программного кода.

Методы анализа и разработки проекта 835
Класс
Служба
Класс
Служба
Класс
Служба
Класс
Служба
l,m \/Ч^1
Модели
требований: 00,
DFD.ERD,
CFD
Класс
Служба
Класс
Служба
Процессы
формирования
расширенных
требований,
сопоставленные
с архитектурным
шаблоном
Требования,
соответствующие
системным
модулям
Обработка пользовательского
вйса
©
Функциональная
обработка
О
Сопровождение
и выполнение
самотестирования
Истина
12 3 4 5 6 7В
Истина
Ложь
( Реальный I
4ZV
Соэдани*
структурной
диаграммы
Система
<3
Разработка проекта программы
Рис. 22.52. Анализ и разработка проекта крупным планом

836 Глава 22
Обзор: этапы объектно-ориентированного
анализа/разработки проекта
Менеджер проекта должен получить ответ на те же вопросы, которые решаются
методами анализа SA/SD. В основном ответы на эти вопросы будут получены после
определения того, где именно применяются модели OOA/OOD и будет ли
рассматриваться вариант комбинирования с моделями SA/SD.
Существует несколько способов создания, применения и введения новых
определений для моделей ОО с использованием диаграмм вариантов использования/сценариев,
диаграмм действий, диаграмм класс/объект, а также диаграмм сотрудничества,
взаимодействия, перехода состояния, контекста данных и словаря данных. Некоторые
вводятся "сверху-вниз", другие — "снизу-вверх", и все они итеративно определяются
заново с помощью сотрудничества. Исходя из положений работ Рихтера (Richter)
и Лермана (Larman), ниже дана характеристика двух подходов.
Одна из возможных последовательностей этапов предполагает следующее.
1. Идентифицируйте исполнителей и их взаимодействия с системой.
Определите варианты использования, начиная с высоких уровней и задерживая их
распространение на фазе проектирования или до тех пор, пока до них не дойдет
очередь.
2. Разработайте модели класса/объекта высокого уровня, акцентируя вниманиена
очевидных ролях, предметах и понятиях. Используйте фразы с
существительными из спецификации проблемы. Анализируйте жизненные циклы для каждого
класса, учитывая, какие варианты использования приведут к созданию экземпляра
каждого класса, к изменению или удалению.
3. Документируйте поток сообщений между экземплярами, а также вызов методов
посредством диаграмм сотрудничества. Проанализируйте глагольные фразы в
спецификации проблемы, ориентированные на действие.
4. Воспользуйтесь диаграммами сотрудничества для уточнения способа взаимосвязи
объектов, а также тех методов, которые принадлежат каждому классу.
Альтернативный подход заключается в следующем.
1. Запишите проблемный оператор или воспользуйтесь подробными описаниями из
SRS-документов.
2. Идентифицируйте объекты. Начните с существительных, выбирайте только
объекты и понятия, которые соответствуют данному объекту. Отложите процессы
агрегирования и обобщения на более поздний период итерации.
Сконцентрируйте внимание на объектах и наиболее очевидных атрибутах. Их можно расширять
в дальнейшем. Создайте диаграмму контекста данных, исключите терминаторы
и исполнителей. Приступите к созданию словаря данных.
3. Выберите классы. Устраните избыточные классы или те, которые могут быть
представлены каким-либо иным образом (с помощью атрибут или операций);
устраните конструкции, предназначенные для реализации. Проясните содержание
неточно сформулированных классов. Постарайтесь привлечь к работе экспертов
в рассматриваемой предметной области.
4. Создайте словарь данных. Внесите запись для каждого класса объектов и уточните
диапазон, требования, связи, атрибуты, операции и методы.

Методы анализа и разработки проекта 837
5. Создайте диаграмму класса. Проведите итерацию моделей и диаграмм, которая
ранее начата в проекте, прибегая к помощи экспертов домена и пользователей.
6. Идентифицируйте ассоциации и аргегации. Устраните те ассоциации,
которые не являются подходящими или же избыточными, а также обратите
внимание на ассоциации, специфичные для данной реализации. Начните с
оценки сложности каждой ассоциации, а затем уменьшайте ее по мере
возможности. Проясните сложные ассоциации. Разложите на составные части
ассоциации высокого уровня.
7. Идентифицируйте атрибуты.
8. Упростите применение наследственных свойств. Разыщите классы для подобных
атрибутов, ассоциаций или операций и присвойте их суперклассам. Заново
определите существующие классы в специализированных подклассах (определите
подклассы, где класс трактуется несколько иначе, чем в приложении). Избегайте
дополнительной сложности — большого количества подробностей и глубоко
вложенных обобщений.
И как всегда, настойчиво выполняйте последовательные итерации.
Контрольные вопросы
1. Рассмотрите набор ненормализованных данных, как описано в форме на
рис. 22.53, преобразуйте их, сначала в 1NF, затем в 2NF и SNF.
Порядковый номер
Номер заказчика
Имя заказчика
Адрес заказчика
Дисконт заказчика
Тип заказчика
Порядковая дата
Дата поставки
Партии; при неодноразовой реализации для каждой требуется еще следующая
информация:
помер партии
описание партии
цена
количество
общая стоимость
2. Какие вопросы будет решать ваша команда в связи с выполнением соединения и к
чему оно может привести?
3. Если в пределах системы реализовано некачественное связывание, на какие
этапы вашего проекта прежде всего окажет влияние этот факт? Какую помощь
можно оказать менеджеру проекта для исправления сложившейся ситуации?

838 Глава 22
Пример компании
Заказ клиента
Номер заказа:
Номер клиента:
Скидка:
Тип:
Дата поставки:
ПОЗИЦИЯ
ЦЕНАПОЗИЦИИ
ОПИСАНИЕ
Имя клиента:
Адрес клиента:
Дата:
КОЛИЧЕСТВО
ИТОГОВАЯ ЦЕНА
Итого:
Рис. 22.53. Форма для нормализации проблемы
4. Что можно сказать об уровне соединения при рассмотрении этих примеров?
Достаточно ли он "хорош"?
A. Вызов SQRT.
B. Вызов SQRT (число, квадратный корень, состояние).
C. Вызов SQRT (число, квадратный корень).
D. Вызов SQRT (число).
E. Вызов SQRT (Рагат(З)).
5. Определите связывание для данных примеров.
A. Если flag ■ 1, вычислите квадратный корень; если flag » 2 сортируйте массив.
B. Получите новые данные, просмотрите сенсор, получите системный статус,
постройте новую позиционную матрицу.

Методы анализа и разработки проекта 839
C. Откройте файлы, получите первую транзакцию и первую главную запись,
выведите на печать заголовки страниц.
D. На основе матрицы электрических соединений, образуйте диаграмму
электрической цепи.
E. После ввода данных, добавьте контрольные пункты и проверьте общие
суммы.
F. Вычислите FICA, определите удержания и сделайте выводы.
G. Определите ведущую позицию.
Н. Вычислите квадратный корень по методу Ньютона.
I. Обновите текущую кредитную запись и обновите базу данных.
6. Сформулируйте свое мнение по поводу двух следующих проектов для задачи о
лифтах.
A. Система управления лифтами, действуя как контроллер, присваивает лифту
запрос вводных данных, выполняя итерацию среди лифтов и запрашивая
каждый лифт о его текущем расположении, направлении движения и
состоянии. Затем этой информацией пользуются для определения того, какой из
лифтов находится ближе всего, и присваивают запрос данному лифту.
B. Система управления лифтами требует, чтобы каждый лифт вычислял
приближение к запросу. Используя информацию о месте расположения,
направлении движения и т.п. (переменных состояния X), каждый лифт делает
"собственные выводы" о степени близости к источнику вызова и отображает
это значение.
7. Какой проект является более гибким? Предположите, что эту систему необходимо
распространить для работы в здании, где некоторые лифты не могут
останавливаться на всех этажах? Какую из этих систем легче модифицировать?
Предположим, что система должна распространяться для работы с лифтами,
которые находятся вне сферы обслуживания. Какой из проектов наиболее
приемлем в этом случае?
Практическое занятие
Прототип ПО завершен и реализован. Вся полученная исходная информация
корректна. С вами заключили контракт на разработку проекта ARRS. Все ресурсы
CRM выделены одному проектному менеджеру, м-ру Сангу. Соглашение на уровне
служебных взаимоотношений установлены между мистером Ли, мисс Пайтель и
мистером Лу. Вас в этот перечень не включили, поскольку м-р. Ли заметил: "Этот
проект связан с продажами и рыночными взаимоотношениями, а не с задачами по
разработке ПО." Они перешлют вам соответствующий документ после сбора всех
официальных подписей— где-то через три месяца. Перед вами сейчас стоит одна
задача— выполнение функций менеджера всего проекта, о чем вам сообщили
д-р Харита и м-р Санг.
Поскольку в настоящее время вы располагаете рабочим прототипом, министр
CRM предполагает, что проект близок к завершению. Он желает ознакомиться с
планом, где указаны даты поставок завершенного программного продукта, а также план
установки. В качестве менеджера проекта, вы желаете рассмотреть все существующие

840 Глава 22
компоненты проекта и обновить их, чтобы продемонстрировать новый проект,
появляющийся после прототипирования. Министр очень занят и проявляет
нетерпение. Лучше приступить к работе немедленно.
Литература
Bass Len и др. Software Architecture in Practice. Reading, MA: Addison-Wesley, 1997.
Bass Len. Paul Clements and Rick Kazman. Software Architecture in Practice: The SE1 Series. New York, NY:
Addison-Wesley. 1998.
Batini Carlo и др. Conceptual Database Design: An Entity-Relntionship Approach. Reading, MA: Addison-
Wesley, 1991.
Hooch Grady. Object Oriented Design with Applications. Reading, MA: Addison-Wesley, 1994.
Booch Grady и др. Unified Modeling Language User Guide. Reading, MA: Addison-Wesley, 1998.
Cantor Murray R. Object-oriented Project Management with UML. NY: John Wiley 8c Sons, 1998.
Cassel Paul and Pamela Palmer/ Sams Teach Yourself Access 2000 in 21 Days. Indianapolis, IN: Sams,
1999.
Cliapin Ned. "A New Format for Flowcharts". Software-Practice and Experience, 1974. Chapin, Ned.
"Software Maintenance: A Different View". Proceedings of the 1985 National Computer Conference. AFIPS Press,
pp. 507-513, 1985.
Chen Peter. The Entity-Relationship Approach to Logical Database Design. Wellesley, MA: Q.E.D. Information
Sciences, 1977.
Coad Peter and Edward Yourdon. Object Oriented Analysis. NY: Prentice Hall Yourdon Press Computing
Series, 1991.
Coad Peter и др. Object Models: Strategies, Patterns and Applications, 2-е издание. NY: Prentice Hall
Yourdon Press Computing Series. 1996.
Codd E.F. "A Relational Model of Data for Large Shared Data Banks." Communications of the ACM,
13((i):377-387, 1970.
Codd E.F. The Relationship Model for Database Management, Version 2. NY: Addison-Wesley, 1990.
Coiinell John and Linda Shafer. Object-Orienfed Rapid Prototyping. NY: Prentice Hall Yourdon Press
Computing Series, 1995.
Date CJ. (). An Introduction to Database Systems, 6-е и 7-е издания. NY: Addison-Wesley, 1999.
DeMarco Tom. Structured Analysis and Systems Specification. NY: Prentice Hall Yourdon Press Computing
Series. 1979.
DeMarco Tom and P.J. Plauger. Structured Analysis and System Specification. NY: Prentice Hall Yourdon
Press Computing Series, 1985.
Eriksson Hans-Erik and Magnus Penker (). The UML Toolkit NY: John Wiley & Sons, 1998.
Flavin Matt. Fundamental Concepts of Information Modeling. NY: Prentice Hall Yourdon Press Computing
Scries, 1981.
Harmon Paul and David A. Taylor. Objects in Action: Commercial Applications of Object-Oriented Technologies.
Reading, MA: Addison-Wesley, 1993,
Hatley Derek J. and Imtiaz A. Pirbhai. Strategies for Real-Time System Specification. NY: Dorset House, 1988
IEEE 1016.1-1993 "Guide to Software Design Descriptions". NY: The Institute of Electrical and
Electronics Engineers, 1993.
IEEE 1016-1998 "Recommended Practice for Software Design Descriptions". NY: The Institute of
FJectrical and Electronics Engineers, 1998.
IEEE 1320.1-1998 "Standard for Functional Modeling Eanguage—Syntax and Semantics for IDEFO".
NY: The Institute of Electrical and Electronics Engineers, 1998.
IEEE 1320.2-1998 "Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97
i IDEFobject)." NY: The Institute of Electrical and Electronics Engineers. 1998.

Методы анализа и разработки проекта 841
1KF.E 1471-2000 "Recommended Practice for Architectural Description of Software Incentive Systems".
NY: The Institute of Electrical and Electronics Engineers, 2000.
Jacobson Ivar. Object-oriented Software Engineering: A Use Case Driven Approach. Addison-Weslev Object
Technology Scries, 1994.
jacobson Ivar, Grady Booch and James Rumbaugh. The Unified Software Development Process. Reading,
МЛ: Addison-Wesley, 1999.
Kruchten Philippe. "A Rational Process". CrossTalk, 9G): 11-16, 1996. Kruchten, Philippe. The Rational
I 'mjied Process: An Introduction. Reading, MA: Addison-Wesley, 2000.
Uu man Craig. Applying UML and Patterns: An Introduction to Object-oriented Analysis and Design. Reading,
MA: Addison-Wesley, 1998.
Maicr David. The Theory of Relational Databases. Rockville. MD: Computer Science Press, 1983. Martin
James. An EndUser's Guide to DataBase. Englewood Cliffs, NJ: Prentice Hall, 1981. Martin James. Computer
Database Organization. Englewood Cliffs, NJ: Prentice Hall, 1982.
McConncll Steve C. Code Complete: A Practical Handbook of Software Construction. Redmond, WA: Microsoft
Press. 1993.
McMenamin Stephen M.. and John Palmer. Essential Systems Analysis. New York, NY: Prentice Hall
Yourdon Press Computing Series, 1984.
Mellor Stephen and Paul T. Ward (). Structured Development/or Real-Time Systems: Implementation Modeling
Techniques. NY: Prentice Hall Yourdon Press Computing Series, 1989.
Nassi I. and B. Shneiderman. "Flowchart Techniques for Structured Programming". ACM SIGPLAN
Notices. 8(8): 12-26, 1973.
Pagejones Meilir. The Practical Guide to Structured Systems Design, 2-е издание. Englewood Cliffs, NJ:
Prentice Hall, 1988.
Pratt Philip J. and Joe Adamski. Concepts of Database Management, 3rd ed. Boston, MA: Course
Technology, 2000.
Pressman Roger S. Software Engineering: A Practitioner's Approach, 5-е издание. Boston, MA: McGraw-Hill,
201I.
Rob Peter and Carlos Coronel. Database Systems: Design, implementation, and Management, 4-е издание.
Cambridge, MA: Course Technology, 1999.
Royce. Walker, Jr. Software Project Management, a Unified Framework. Reading, MA: Addison-Wesley, 1998.
Rumbaugh James и др. Object-oriented Modeling and Design. Englewood Cliffs, NJ: Prentice Hall, 1991.
Schach Stephen R. Classical and Object-Oriented Software Engineering: with UME and Java, 4-е издание. NY:
McGraw-Hill, 1999.
Shiaer Sally, and Stephen Mellor. Object-oriented Systems Analysis: Modeling the World in Data. NY: Prentice
Hall Yourdon Press Computing Series, 1988.
Taylor David A. Object-oriented Technology: A Manager's Guide. Reading, MA: Addison-Wesley, 1990,
Taylor David A. Object-oriented Information Systems: Planning and Implementation. NY: John Wiley & Sons,
19l.J.
Ullman Jeffrey. Principles of Database Systems. Rockville, MD: Computer Science Press, 1982.
Ward Paul T. and Stephen J. Mellor. Structured Development for Real-Time Systems: Essential Modeling
Techniques. NY: Prentice Hall Yourdon Press Computing Series, 1986.
Wiorkowski Gabrielle, and David Kull. DB2: Design and Development Guide Book, 3-е издание. Reading,
МЛ: Addison-Wesley. 1992.
Wirfs-Brock Rebecca и Др. Designing Object-oriented Software. NY: Prentice Hall, 1990.
Yourdon Edward. Modern Structured Analysis. NY: Prentice Hall Yourdon Press Computing Series, 1989.
Yourdon Edward. Object-oriented Systems Design: An Integrated Approach. NY: Prentice Hall Yourdon Press
Computing Series, 1994.
Yourdon Edward and Larry Constantine. Structured Design. NY: Prentice Hall Yourdon Press Computing
Series, 1975.

842 Глава 22
Дополнительные сведения в Internet
www-4. ibm. com/sftware /data /db2/udb/. Универсальная база данных DB2.
www. lotusnotes. com. ПО фирмы Lotus Notes Software.
http://www.omg.org. Группа Object Management Group, Inc. (OMG), является международной
организацией, насчитывающей более 800 членов. Среди членов этой организации поставщики
информационных систем, разработчики ПО и пользователи. Основанная в 1989 году, OMG
поддерживает теоретические разработки и практические аспекты объектио-ориентированной технологии
при разработке программного обеспечения. Организация предоставляет поддержку спецификаций
объектного менеджмента обеспечении общеупотребительного каркаса для разработки приложений,
а также услуги по повторному использованию, портативности и поддержке взаимодействия
операций по объектно-ориентированному ПО в распределенных гетерогенных средах. Благодаря наличию
соответствия с указанными спецификациями предоставляется возможность разработки среды
гетерогенных приложений с применением всех основных аппаратных платформ и операционных
систем В задачи OMG также входит поддержка роста объектных технологий и оказание влияния на их
дальнейшее развитие путем выбора архитектуры (Object Management Architecture, ОМА).
Архитектура ОМА обеспечивает концептульную инфраструктуру, на которой базируются все спецификации
OMG. Так как OMG воспринимает спецификацию UML, значительно уменьшается вероятность
возникновения затруднительных ситуаций в индустрии, связанной с моделированием языков. Она
располагает аргументами о неэффективности использования метода примечаний и механизма по
взаимообмену моделей, что позволяет сконцентрировать внимание на улучшении управления и более
производительных формах деятельности. Кроме того, возможен семантический взаимный обмен
между инструментами визуального моделирования.
www. oracle, com. Фирма Oracle Corporation!.
www. rational. com/ index. j sp. Фирма Rational Software.
www.open.org/~prslkg/sy_chap.htm. Paul R. Seesing и ARMA International. Основные
инструменты системного анализа для пользователей компьютеров, 1993.
www. sybase. com/. Фирма Sybase.

Аттестация
и верификация
Аттестация и верификация (Verification and validation, V&V) ПО— это процесс,
благодаря выполнению которого гарантируется, что программа, которая находится в
стадии разработки или подвергается изменениям, будет отвечать функциональным
или каким-либо другим требованиям (аттестация). При этом каждый шаг,
предпринимаемый в процессе разработки ПО, приводит к созданию требуемых программных
продуктов (верификация). В результате осуществляется систематическая и
техническая оценка программ и компонентов, связанных с процессом разработки и
сопровождения ПО. В финале каждой фазы процесса разработки выполняются обзоры и
тестирование. Благодаря этому гарантируется завершенность и возможность контроля
требований, предъявленных к ПО, а также соответствие этим требованиям процесса
разработки проекта, компьютерной программы, документации и данных .
В результате проведения процесса верификации оценивается система/компонент
для определения того, соответствует ли продукт, созданный на определенной стадии
жизненного цикла разработки ПО, условиям, сформулированным в начале
выполнения этой фазы. В ходе осуществления этого процесса, как правило, проводятся
собрания, на которых рассматриваются документация, планы, программный код,
требования и спецификации. При этом применяются контрольные списки, перечни
вопросов, стандарты, а также соглашения, принятые в данной организации. Верификация
выполняется на каждой фазе жизненного цикла разработки ПО.
Процесс аттестации подразумевает фактическое тестирование компонентов,
которое выполняется после завершения верификации. Это действие выполняется на
завершающем этапе совместно с приемочными испытаниями со стороны
пользователей. Однако вопрос о построении "надлежащей системы" можно считать уместным на
протяжении всего жизненного цикла разработки ПО, поскольку матрицы,
определяющие возможность отслеживания требований, обеспечивают выполнение
непрерывного оценочного анализа.
National Aeronautics and Space Administration. Software Formal Inspections Guidebook, NASA-GB-
A-302, Office of Safety and Mission Assurance, National Aeronautics and Space Administration, 1993.

844 Глава 23
Специалисты-практики по разработке ПО используют термин V&V (АиВ) для
обозначения всех действий, направленных на достижение соответствия требованиям,
сформулированным по отношению к ПО.
Все программные продукты имеют определенные скрытые или явные недостатки.
Хотя даже самые жесткие процессы V&V не позволят обнаружить все недостатки
системы, они целенаправленно ведут в повышению качества ПО. Каждое действие
в процессе V&V повышает вероятность того, что возникшие проблемы будут
обнаружены именно командой разработчиков, а не заказчиком. Ведь любая выявленная
вовремя проблема уменьшает степень возможного замешательства,
недоброжелательности, затрат, а также вероятность потери заказчика.
Два основных действия, входящих в состав процесса V&V, называются
экспертными оценками и тестированием.
Обзоры, инспекционные проверки
и сквозной контроль
Статическая экспертная оценка— это процесс, в ходе осуществления которого
предпринимается попытка обнаружения ошибок в готовых программных продуктах,
получаемых по мере выполнения проекта. При этом реализуется выполняемый
вручную обзор каждого компонента системы. Обзоры выполняются на протяжении
и в конце каждой фазы жизненного цикла разработки ПО. При этом определяется
степень выполнения сформулированных требований, концепции, применяемые при
разработке проекта, и технические спецификации. Для осуществления этого
процесса группе экспертов предоставляется необходимый материал.
Наиболее полезным методом обнаружения ошибок является способ формальной
инспекционной проверки, разработанный Майклом Фейгэном (Michael Fagan) в период его
сотрудничества с компанией IBM. При использовании этого метода производится
последовательное оценивание программного продукта. Процесс экспертной оценки
осуществляет команда, каждый участник которой исполняет определенную роль.
Роль лидера играет координатор, который обладает профессиональными навыками,
требуемыми при выполнении подобного процесса. Также привлекается корректор,
который руководит командой на протяжении всего процесса анализа объекта, один
или несколько рецензентов, которые ищут возможные недостатки, регистратор,
фиксирующий найденные недостатки, а также автор, который помогает объяснить
особенностям поведения инспектируемого объекта.
Применение формального структурированного на высшем уровне процесса
инспекционных проверок чрезвычайно эффективно при обнаружении и устранении
ошибок. Его можно использовать по отношению к любому продукту, создаваемому
в процессе разработки программного обеспечения, включая документацию,
проектирование и код. Одним из важнейших второстепенных преимуществ применения
инспекционного контроля является непосредственная обратная связь с
разработчиком/автором, а также значительное повышение качественных характеристик
получаемого программного продукта.
Процесс оценивания также называется сквозным контролем (инспекционной
проверкой), хотя многие специалисты-практики различают формальные и
неформальные аспекты каждого метода. На более высоком абстрактном уровне используется
термин обзор, подразумевая формальный процесс, который отдаленно напоминает
инспекционную проверку.

Аттестация и верификация 845
Тестирование
Динамическое тестирование — это процесс создания выполняемых тестовых
случаев, используемых в процессе реального тестирования функционирующей системы.
15 данном случае идет речь о процессе обнаружения возможных неполадок, то есть об
установлении факта некорректного поведения системы. На предмет наличия
определенных функциональных свойств тестируются отдельные компоненты (программные
модули), а также интегрированные элементы (подсистемы). В ходе тестирования
обнаруживаются недостатки программного продукта, а симптомы проявления
неисправностей используются в отладочных процедурах с целью обнаружения
некорректного кода, служащего причиной появления ошибок.
Процесс тестирования ПО осуществляется на основе фактических или
смоделированных входных данных (как стандартных, так и нестандартных) при определенных
контролируемых условиях. Если программный продукт не соответствует
сформулированным требованиям, идентифицируются значительные отличия между ожидаемыми и
фактическими результатами. Уровни тестирования ПО бывают самыми различными:
начиная с поэлементного тестирования, переходящего в интегрированное
тестирование и тестирование рабочих характеристик, а завершающим уровнем считаются
приемочные испытания и тестирование программной системы в целом.
Процесс тестирования отличается от процесса обеспечения качества (Quality
assurance, QA) тем, что в ходе осуществления QA выделяются действия, которые
предотвращают возникновение дефектов, в то время как процесс тестирования
сосредотачивается на реальном обнаружении ошибок и дефектов. Тестирование отличается от
выполнения оценивания тем, что оцениваться может любой компонент проекта, в то
время как предметом тестирования является программная система (код, языки
интерфейса, язык управления заданиями). Зачастую этот процесс направлен на
обнаружение проблем, связанных с выполнением, синхронизацией, трафиком, частотой
транзакций и взаимодействиями в системе.
Неформальное тестирование осуществляется разработчиками для того, чтобы
оценить выполняемый процесс разработки ПО. В данном случае термин
"неформальный" вовсе не означает, что тестированию не придается серьезного
значения. Это подразумевает, что заказчик официально не принимает участия в
процессе тестирования. Также отсутствует потребность в наличии наблюдателей за
процессом тестирования, а основная цель — обнаружение различного рода ошибок.
Примерами неформальных тестов являются поэлементное, покомпонентное, а также
интеграционное тестирование подсистем.
В процессе осуществления формального тестирования демонстрируется
готовность к эксплуатации ПО с учетом заданных спецификаций. Формальный тест
предполагает наличие утвержденного плана и процедур тестирования, состава
наблюдателей, регистрации всех расхождений и составление акта о результатах выполнения
тестирования. Формальное тестирование всегда основывается на сформулированных
требованиях, и его цель заключается в том, чтобы продемонстрировать соответствие
программы выдвинутым к ней требованиям.
При выполнении каждого программного проекта, независимо от его объема,
должен предусматриваться, как минимум, один формальный тест, а также приемочные
испытания, подводящие итог действиям по разработке программ, и
демонстрирующие их готовность к коммерческой эксплуатации. Помимо завершающего
приемочного испытания, при выполнении проекта может производиться другой

846 Глава 23
вид формального тестирования. Например, если требуется разработать или
поставить программу в виде последовательных версий (или подверсий), могут
потребоваться приемочные испытания последовательных версий. Любой предусмотренный
контрактом тест может относиться к категории формальных.
После приемки программного продукта, все вносимые изменения должны
утверждаться только после завершения очередного формального тестирования. Фаза тестирования,
следующая после приемки, включает регрессионное тестирование. В этом случае
повторно выполняются ранее проведенные тесты, в результате чего можно гарантировать, что
внесенное изменение не нарушило выполнение утвержденных ранее функций.
Статическое оценивание и динамическое тестирование являются составляющими
элементами процесса V&V и воспринимаются как присущие ему задачи, играющие
решающую роль при создании качественного программного продукта. Тем не менее, эти
процессы не играют решающей роли при выполнении самой разработки. В качестве
примера сначала рассмотрим процесс получения статических экспертных оценок, поскольку
он является более трудоемким, чем обычное динамическое тестирование. Реализация
оценки подобного рода возможна на более ранних стадиях жизненного цикла разработки
программного продукта, и ее можно осуществлять по отношению к одному или
нескольким программным продуктам. Более того, применение статической экспертной оценки
в некоторых случаях оказывается более эффективным, чем использование динамического
тестирования. Этим утверждением мы не намереваемся опровергнуть важность
динамического тестирования, которое, несомненно, является необходимым составным
компонентом процесса разработки системы, а хотим лишь порекомендовать уделять
достаточное внимание процессу выполнения статических экспертных оценок с целью повышения
эффективности процесса динамического тестирования и сокращения затрат времени на
этой фазе жизненного цикла разработки ПО.
Осуществление динамического тестирования предполагает наличие
скомпилированного программного кода и ранее разработанных тестовых случаев. Выполнение
статической экспертной оценки осуществляется на основе ранее разработанного
функционирующего продукта (полученного по мере выполнения проекта). Обзор
реализуется в соответствии с планом менеджмента программным проектом (Software project
management plan, SPMP), дейтаграммой потока данных (Data flow datagram, DFD),
объектно-ориентированной моделью (Object-oriented model, OOM), диаграммой
архитектурного потока (Architecture flow datagram, AFD), диаграммой переходов между
состояниями (State transition datagram, STD), структурной схемой, программным
абстрактным объектом, псевдокодом, диаграммой Чейпина (Chapin) и Несси-
Шнайдермана (Nassi-Schneiderman). Также учитывается скомпилированный код или
какой-либо другой компонент проекта, (внутренний или внешний, созданный
вручную или на автоматизированной основе). Поскольку для проведения оценки не
требуется наличие компонента, созданного на автоматической основе, к ее выполнению
можно приступать уже на ранних фазах жизненного цикла разработки ПО.
Независимая аттестация и верификация (Independent verification and validation,
IV&V) — это процесс, в ходе осуществления которого программные продукты,
полученные на различных фазах жизненного цикла разработки ПО, поочередно
подвергаются оценке, аттестации и верификации со стороны организации, которая не
является ни разработчиком, ни спонсором разработки данного программного продукта.
Исполнитель процесса IV&V может быть не заинтересован в успешном или
неудачном исходе процесса разработки. В его задачи входит тщательное тестирование ПО
с целью определения соответствия всем поставленным требованиям. Действия по

Аттестация и верификация 847
реализации процесса IV&V последовательно дублируют действия,
предпринимаемые в процессе V&V для всех фаз жизненного цикла разработки ПО, за
исключением того, что исполнитель процесса IV&V не производит неформальное
тестирование. Если в процессе принимает участие исполнитель IV&V, то формальное
приемочное испытание может быть однократным, предпринимаемым исполнителем
IV&V. В этом случае разработчик официально демонстрирует готовность ПО к
проведению приемочных испытаний.
Стадии жизненного цикла
разработки продукта
Чтобы дать приблизительную оценку затрат, графика выполнения и сложности
проекта, а также обеспечить адекватные возможности для выполнения тестирования,
менеджеру программного проекта, конечно же, не обойтись без специального плана
V&V. На каждой фазе жизненного цикла производятся внутренние или внешние
готовые продукты (рис. 23.1), полученные по мере выполнения проекта, и каждый из
этих продуктов должен оцениваться должным образом.
■ На фазах исследования концепции ПО и системы потребуется получить
представление о том, каким образом выполнены оценка и тестирование. Следует
просмотреть все документы по планированию, такие как формулирование
потребностей, технические спецификации системного интерфейса, план
менеджмента ПО (SPMP) и план управления рисками.
■ На фазе определения требований к ПО разработчикам следует убедиться в том,
что требования к ПО не противоречат общим требованиям к системе. Каждое
требование должно подвергаться контролю, а также быть выполнимым, поэтому
именно на этом фазе следует подумать о том, какие тесты позволят выполнить
поставленные требования (план приемки). Кроме того, необходимо просмотреть
документ SRS.
■ На фазе разработки проекта выполняются неформальные оценки, сквозной
контроль и инспекционные проверки архитектуры (разработки проекта) ПО. Они
могут производиться согласно предварительно созданным проектам,
низкоуровневыми программными моделям и структуре базы данных. Также потребуется
реализовать оценивание SDD и плана приемочных испытаний.
■ На фазе внедрения следует оценить план V&V для программы, а
инспекционные проверки кода будут выполняться наравне с поэлементным и
интеграционным тестированием. После проведения тестирования составляется отчет по
его итогам.
■ На фазе внедрения производится приемка и поставка программного продукта,
причем непосредственно после того, как согласно результатам тестирования,
анализа и инспекционной проверки, становится очевидным, что
разработанная система отвечает поставленным функциональным, рабочим и
интерфейсным требованиям.
■ На фазе эксплуатации и поддержки все действия процесса V&V, предпринимаемые
в процессе разработки, повторно выполняются в меньшем масштабе при внесении
изменений в программный продукт.

848 Глава 23
v Ч
Исследование
концепции
,
рование

потребности
.
к
ч
Исследование
системы
• Спецификация'
интерфейса
системы
,
Требования
.
• Спецификация'
требований
к ПО
. .
к
Базовая модель системного жизненного цикла
1'
V
Разработка
проекта
■иписание •

разработки ПО
• Пл
V
i'
\
Внедрение
тации/вери-
фикации ПО
. .
1 <
V.
Установка
;
тестации/ве-
рификации ПО
1 .
V
11
ч
Эксплуатация
и поддержка
•
Пользовательская
документация
11
ч
Сопровождение
• Документация ■
по
сопровождению
V
11
ч
Вывод из
эксплуатации
^
• Архивный
отчет
__J
Аттестация и верификация
Рис. 23.1. Аттестация и верификация выполняются на протяжении всего жизненного цикла
разработки программного продукта
Связь главы 23 с 34 компетенциями
Как и при рассмотрении большинства тематических вопросов в этой книге,
процесс V&V находится во взаимосвязи с несколькими навыками, имеющими отношение
к программному продукту, проекту и персоналу. Вкратце их можно охарактеризовать
следующим образом.
Методики разработки продукта
1. Процессы оценивания — как статическое, так и динамическое тестирование
в значительной мере зависят от спроектированных организационных процедур.

Аттестация и верификация 849
2. Знание стандартов процесса — благодаря экспертным оценкам выполнясь )■■
проверка рабочих продуктов с целью определения их соответствия принятым ь
данной организации стандартам.
3. Отслеживание качества продукта — весь процесс V&V связан < обео/ечешп pi
качества продукта, включая представление о его внутренней структуре. Цель про
ведения экспертных оценок и всех динамических тестов заключается в < >бпар\ »а
нии и устранении дефектов, которые приравниваются к недостаточному уровню
качества.
Навыки менеджмента проектов
4. Оценка стоимости — менеджер программного проекта должен учитывать !«;.>;;.
фициент возврата инвестиций (Return on investment, КОИ) наряду с эффемнп
ными процессами экспертной оценки и тестирования.
5. Оценка трудозатрат — для достижения требуемого качества и экономии срсд< i n
необходимо обеспечить выполнение процесса V&V на ранних фазач жпчпсншм1-
цикла разработки ПО.
6. Менеджмент рисков — риск, определяющий разработку программного продукт;-,
с неприемлемым уровнем качества, относится к той группе рисков, менеджмент
которых следует осуществлять на протяжении всего жизненного цикла
разработки программного продукта, начиная с ранних фаз.
7. Выбор метрических показателей— в процессе выполнения
аттестации/верификации интенсивно используются метрические показатели, позпп
ляющие менеджеру проекта получить информацию об уровнях качества и их
влиянии на затраты и график.
8. Отбор инструментов менеджмента проектов— в ходе динамического тестиро
вания интенсивно применяются автоматические инструментальные t рс.д< i па.
9. Отслеживание процессов— процессы обзора и тестирования необходимо он м
живать на предмет соответствия техническим условиям. Мониторинг -них длины--
не только помогает руководству проекта при выполнении текущего проекта, но
и предоставляет ценную информацию, стимулирующую усовершенствование cvimiiv
процессов (дополнительные сведения по этой теме приведены в главе 'jii)
Навыки менеджмента персонала
10. Оценка производительности — цели, связанные с достижением производитель
ности, как правило, немного расходятся с целями выполнения экспертных од<
нок. поскольку в последнем случае участники команды получают козширажлсшн
за проявленное внимание, участие, внесенный вклад и обнаружение имекнциче н
ошибок. Их никогда и ни в коем случае не "наказывают" за возникновение иолов
пых ошибок.
11. Организация эффективных встреч— собрания по проведению экспертных
оценок должны быть краткими и контролируемыми, поскольку они представляю-;
собой целенаправленные, насыщенные событиями мероприятия. Организаторы
подобных собраний должны иметь соответствующий уровень подготовки.
12. Взаимодействие и общение — отдельные разработчики создают небольшие
модульные рабочие продукты; команды обеспечивают завершенное! ь и
корректность этих продуктов, а также их интеграцию с остальными элементами < штечи=

850 Глава 23
13. Лидерство — в состав работающей над проектом команды обязательно входят
менеджеры, управляющие процессом выполнения экспертных оценок
(координаторы, организаторы), а также руководители команды тестеров.
Учебные цели главы 23
После изучения материала главы читатель должен уметь выполнять следующее:
■ обосновывать уместность применения процессов V&V (аттестация и
верификация) в рамках рассматриваемого жизненного цикла разработки
программного продукта;
■ описывать, какие именно из навыков, относящихся к персоналу, продукту или
процессу, наиболее тесно связаны с процессом V&V;
■ сравнивать и противопоставлять процессы статического и динамического
тестирования;
■ объяснять, в чем заключается важность выполнения процесса V&V для
программного проекта;
■ приводить веские контраргументы для тех, кто считает, что оценки,
инспекционные проверки и сквозной контроль ПО не являются экономически
обоснованными методами;
■ описывать важнейшие аспекты статического тестирования (отвечать на вопросы
почему?, что?, кто?, когда? и как?);
■ формулировать цели проведения тестирования;
■ описывать основные типы динамических тестов: тестирование поэлементное,
интегрированное (подсистем), системное, альфа-, бета-тестирование, приемочное со
стороны пользователя, регрессия;
■ сравнивать и противопоставлять тестирование методами "белого" и "черного"
ящиков;
■ объяснять, каким образом менеджер может узнать о моменте прекращения
тестирования программного продукта.
Статическое тестирование: обзоры
Обзоры являются наиболее эффективным средством, предохраняющим от
необходимости повторной переделки кода. В случае проведения на достаточно высоком
уровне они могут представлять собой весьма эффективное средство управления
программными проектами. Согласно Фейрли (Fairlay), процесс переделки поглощает 30-50%
общих затрат в связи с выполнением проекта — довольно ощутимая доля I
Обзор и тестирование выполняются наряду с действиями, имеющими отношение
к процессу V&V. Тестирование — это последнее действие, предшествующее выпуску
продукта, поэтому все предшествующие "неувязки" рабочего графика
компенсируются за счет выделенного на проведение тестирования времени. Даже если исходные
общие и приблизительные подсчеты по проекту выполняются как можно более точно,
" Fairley Richard E. "Recent Advances in Software Estimation Techniques." IEEE 14lb International
ConUrenre on Software Engineering, Los Alamitos CA, IEEE Computer Society Press, с 382-391, 1992.

Аттестация и верификация 851
на выполнение начальных фаз проекта уходит зачастую больше времени, чем
хотелось бы. Это приводит к сжатию сроков, выделенных на выполнение последующих
фаз, особенно это касается фаз, на которых выполняется тестирование. Зачастую
бывает затруднительным определить необходимую длительность тестирования при
любых обстоятельствах, поэтому на тестирование отводится любой промежуток
свободного времени между кодированием и выпуском продукта. На первый взгляд
кажется противоречивым утверждение относительно того, что в процессе обзора
(оценивания) уменьшается вероятность появления проблем, связанных с нехваткой
времени на фазе тестирования (ведь на самом деле на фазах, предшествующих
тестированию, выполняются дополнительные действия). Действительно, обзор — это
"лучший друг" процесса тестирования, так как становится возможным найти столько
дефектов на ранних стадиях процесса разработки, что динамическое тестирование
становится обычной формальностью.
Экспертные оценки и модель SEIСММ
В модели SEI СММ экспертные оценки относятся к ключевой области процесса
третьего уровня. При этом ставится задача по разработке плана выполнения экспертных
оценок, а также в определении и устранении дефектов в рабочих программных продуктах.
Проведение экспертных оценок позволяет эффективно устранять дефекты
рабочих программных продуктов уже на ранних этапах разработки,
дополнительный результат выполнения таких оценок заключается в возможности более
глубокого изучения рабочих программных продуктов. Также не допускается появление
дефектов, появления которых можно избежать. Экспертные оценки включают
методологическое исследование рабочих программных продуктов экспертами фирмы-
разработчика с целью определения ошибок, а также идентификации предметных
областей, в которые необходимо внести изменения.
Ниже перечислены действия, которые выполняются с целью достижения
соответствия требованиям области КРА.
■ Планирование экспертных оценок и описание составленных планов.
■ Выполнение экспертных оценок в соответствии с описанной процедурой, которая,
как правило, предполагает, что выполнением экспертных оценок будут руководить
обученные координаторы. Причем материалы для обзора распространяются
заранее, рецензентам назначаются определенные роли, определяются и
устанавливаются критерии завершения оценки, а также отслеживаются выполняемые действия.
■ Регистрация данных по проведению экспертных оценок и полученных
результатов. В качестве примеров данных можно назвать идентификатор и размер
программы, состав и размер выполняющей экспертную оценку команды, время
подготовки на каждого рецензента, длительность собрания по проведению экспертной
оценки, типы и количество обнаруженных и устраненных дефектов, а также объем
выполненной переработки.
Обязательства по выполнению экспертной оценки представляют собой
разработанную стратегию организации. Она частично определяет, что процессом
выполнения экспертных оценок руководят координаторы, а сами оценки сфокусированы на
рассматриваемом рабочем программном продукте, а не на его авторе. Кроме того,
результаты проведения экспертных оценок не используются руководством с целью
обзора результатов работы отдельных лиц в рамках выполняемого проекта.

852 Глава 23
Определения, применяемые в процессе
статического тестирования
Термины, определяющие статическое тестирование, иногда используются
специалистами но разработке программных средств весьма противоречивым образом,
и,, ному для обеспечения коммуникации на должном уровне используются несколько
. lijH ДС.'КНИЙ.
/ а.1ршютка проекта на уровне архитектуры определяет проектирование программ-
!'<ii 4 нстемы на высшем уровне. Оно должно соответствовать утвержденным требо-
|.. .iiuiM, сочетаться со всеми необходимыми компонентами, описывать общие функ-
: i.ii лля каждого модуля, включать процесс обнаружения дефектов и восстановления.
•,л:с должна быть рассмотрена возможность применения повторно используемых
■jii« шентон и выполняться отслеживание выполняемых требований.
Классификация дефектов — это процесс, в котором все выявленные при инспекци-
i i toii проверке дефекты классифицируются по степени серьезности и типам.
.Ъфгкт — это проблема, которая была выявлена не на этапе ее возникновения,
- >раздо позже. В данном случае идет речь о любом событии, происшедшем при соз-
•.'HH1I программного продукта, которое реализовано частично или некорректно от-
:< - ителыю предъявляемых к продукту требований или программных стандартов.
ц< Ыкты обнаруживаются в конечном продукте, но большинство из них возникает
•.же на этапах разработки требований/проекта, кодирования или в результате
внесении изменений. Согласно Фейгэну, дефект — это отдельный случай, когда не
выполняются какие-либо требования. Любое требование представляет собой согласованное
обязательство. Это не только внешне определимое требование к программному про-
;.\krv, но оно также может включать в себя внутренние требования к разработке
например, выходные критерии операции), которым необходимо соответствовать,
•бы обеспечить выполнение требований, выдвигаемых к конечному продукту,
i ачегтпе примера можно привести требование, согласно которому план тестирова-
■ :чн должен полностью подтверждать, что данный продукт удовлетворяет
согласованные потребности пользователя или же требование, согласно которому разработка
программного кода должна быть полностью завершена, прежде чем он будет под-
l.epnivT тестированию. Согласно Боэму (Boehm), дефект нарушает стандарты каче-
■■ i г..1. гакие как внутренние качественные характеристики кода, отсутствие проблем
н процессе работы программного продукта, удобство и простота в использовании,
;•<■ 1можпость установки, техническая документация, способность к коррекции и рас-
•лриемогть либо пригодность к применению (удовлетворяются неявные стандарт-
■i.ic потребности пользователя).
Ошибка — это проблема, обнаруживаемая в момент ее возникновения. Это
несоответствие между вычисленным, наблюдаемым или измеренным значением или
условием и истинным, заданным или теоретически корректным значением или условием.
Формальный обзор производится в конце каждой фазы жизненного цикла. Этот
процесс осуществляется в том случае, если автор считает, что продукт не содержит
ошибок. Формальный обзор выполняется согласно официально установленному
регламенту. При этом фиксируются полученные результаты. Для выполнения
формального просмотра заказчик программы назначает группу или совет, которые
уполномочены принимать решения относительно продолжения/прекращения работы над
проектом или оказывать влияние на его принятие, чтобы перейти к следующей фазе
■ «пенного цикла. Формальные обзоры включают просмотр документов SRS и SDD,

Аттестация и верификация
а также оценку готовности ПО к проведению тестирования. При зтом не p-i-iwu.
ся формальные обзоры и инспекционные проверки.
В случае необходимости выполняются неформальные обзоры. Они moivi hi и >ii.»i» :>nn > •.
в любое время на собраниях, посвященных поиску творческих идей, нри'к м и\ и-,..
дение не подчиняется какому-либо заранее определенному плану. Па таком • поручи
требуется документация. Разработчик выбирает рецензентов и предосл лн;ыег им ?<,..
риал на просмотр или обнародует его сам. Эти сведения могут носить н<ч|н>;>1к. >ы
характер (программный листинг или написанная от руки документация).
Инспекционные проверки — это подробные обзоры продукта подпаши. и,ш а-- .-■;,-.-
ципу линейности кода согласно строго установленному набору правил, i U '!•■.<. «
дения подобных действий является обнаружение ошибок. Группа, иыпч.шя,- , i.:..
спекционную проверку, состоит из экспертов по разработке, let шроваппи. г,
чению качества.
Эксперт — это лицо, которое не может контролировать деятельное i i.. пл..,..
ную на выполнение оценок, со стороны другого человека (т.е. он не об „i.vi-i i=-
мочиями по непосредственному принятию решений по попод\ поокцн ми;. .;■
и ости других сотрудников).
В презентациях могут принимать участие лица, не являющиеся :<к< ic-pi f-ns i,
зентации, как правило, не предполагают обратной связи и при их выполнении г
иится цель обнаружения возможных проблем. Цель презентации — отм-.i г i,. м. ,•
системы для людей, имеющих отношение к данному проекту.
Проблема— это термин, обозначающий ошибку или дефект.
Требования к ПО— это функции программы, входные и выходные д.нин.к
и режимы работы, требования ко времени реакции системы, а также <>л и ■: -. ;vi
чиком интерфейсы. Определенные требования связаны с прицепом >.'< ь.
ошибок и восстановления системы, обеспечением надежности, речош4i.,..j
рабочих характеристик и точности. Они должны обеспечить ocuonv tv-i »- ■ i«..
проекта ПО, атаюке быть измеримыми, непротиворечивыми и kohtjhi • '>ч>; . \}-
Требования к системе— это требования к программной системе, форчу т,•.;■•.>••.
высшем уровне. Они регулируют должное распределение всех фунмшй но '-и,
пню к ПО, программно-аппаратным средствам, аппаратному обеспечении! а .,г
соответствии с выполняемыми операциями. Речь идет об аттестации iwiuc'i
щих интерфейсов, рассчитанных на внешнее применение. В соотвеь мши с •!■■
лируемыми системными требованиями функции разбиваются на идетифиц^ьи ■.•
конфигурационные элементы. При этом определяются соответствующие шпе,.
сы. При этом важно обеспечить возможность выполнения верификации.
Обзоры (оценки) — это методологические осмотры рабочих программных ч\ >• -.'о
экспертами производителей, направленные на установление дефектов и rev чч
тей, в которых необходимо внести изменения. Работающие над проемом ли ил <•■
линяют свои усилия, чтобы обеспечить достижение приемлемого уровни ir.i-i.-.-
технической корректности продукта. Обзор представляют собой пргдиее.. ; л
часть процесса разработки, усовершенствования и сопровождения uporpaw:
обеспечения. Обзор (оценка) и инспекционная проверка иногда рассматривают» я каь
совершенно разных процесса: считается, что обзор носит менее формальный .\ i
тер, чем инспекционная проверка. В этой главе инспекционная проверка par. %
вается как разновидность формального обзора.
Способность к трассировке - определяет степень взаимосвязи между двумя и
сколькими продуктами процесса разработки, в особенности между продуктами, ко-.-.

854 Глава 23
связаны между собой по принципу "предшественник-преемник" или "главный-
подчиненный". Например, обратите внимание на степень, в которой соответствуют
друг другу требования и проект данного программного компонента (стандарт ШЕЕ
610.12-1190). Способность к трассировке— это свойство системы, которое позволяет
установить и контролировать взаимосвязи между требованиями, компонентами ПО,
данными и документацией на разных уровнях системы.
Определение сквозного контроля может быть самым различным. Некоторые
говорят, что сквозной контроль — это неформальный обзор, другие утверждают, что в
этом случае идет речь о формальном обзоре. Мы будем придерживаться последнего
определения, но вместо него воспользуемся термином обзор.
Многие из приведенных здесь определений компонентов проекта (т.е. разработки
проекта на уровне архитектуры) можно использовать в качестве контрольного списка
при проведении экспертной оценки. Приняв во внимание эти определения,
перейдем к вопросам статического тестирования — "почему?", "что?", "когда?", "кто?" и "как?",
которые в общем случае определяют сущность обзоров.
Для чего нужен обзор?
Когда на проведение обзоров и исправлений заранее выделяются деньги и время,
во многих случаях вложенные в проект средства можно сэкономить на более поздних
фазах процесса разработки ПО (тестирование, сопровождение и поддержка
заказчиком). Изначальное капиталовложение может быть основательным, но организации,
которые внедрили эффективные программы по обзору и отслеживали полученную
и итоге прибыль на инвестированный капитал, отмечают, что результаты
применения подобных программ действительно стоят затраченных усилий, причем польза от
выполненных обзоров выражается не только в виде финансовых результатов.
Для того чтобы подтвердить наличие дефекта в коде, который остался вплоть до
фазы тестирования, требуется выполнить несколько тестов, позволяющих
выполнить проверку на наличие ошибки, а также предпринять дополнительное
тестирование с целью вывода отладочной информации. Как только обнаружен неустраненный
ранее дефект, программисту потребуется отложить выполнение текущего задания и
перенести внимание на исправление дефекта и подтверждение корректности
программы, а затем вернуться к выполнению прерванной работы. Экономические
принципы обеспечения качества ПО в значительной мере связаны с затратами на
обнаружение дефектов, их предотвращение и устранение. Согласно Уотсу Хамфри (Watts
Humphrey), затраты на обнаружение и исправление дефекта включают затраты для
каждого из перечисленных ниже элементов:
■ определение наличия проблемы;
■ установление источника проблемы;
■ точная локализация дефектов программного продукта;
■ коррекция требований (в случае необходимости);
■ исправление проекта (в случае необходимости);
■ коррекция внедренного продукта (в случае необходимости);
■ инспекционная проверка исправленной ошибки с целью гарантирования
корректности этого действия;
■ -I естирование исправленной ошибки для подтверждения устранения проблемы;

Аттестация и верификация 855
■ инспекционная проверка исправленной ошибки для подтверждения того, что
исправление не привело к возникновению других проблем;
■ необходимые изменения документации с целью учета исправленной ошибки .
Единственный способ снизить затраты на обнаружение и исправление дефектов —
это устранить их, то есть, прежде всего, не допускать их появления в самом
программном продукте. Благодаря выполнению обзоров допущенные в процессе
разработки ошибки обнаруживаются еще до того, как они превратятся в дефекты.
Экономические принципы осуществления обзоров
Что же касается эффективности обзоров, то на сей счет существуют различные
аргументы. Утверждения о том, что обнаруженные на ранних стадиях дефекты
минимизируют общие затраты проекта и объем работы, высказываются уже многие
годы. Считается, что в результате осуществления обзоров обнаруживаются 60-90% всех
дефектов. Также общепринятым считается тот факт, что применение обзоров с
целью обнаружения дефектов в 2-10 раз эффективнее, чем динамическое тестирование.
Согласно Фэйгэну, в результате осуществления обзора можно выявить ошибки за
четверть промежутка времени, потраченного на обнаружение этих ошибок при
использовании методов динамического машинного тестирования . Графики, подобные
графику, изображенному на рис. 23.2, на котором обзоры отмечены как фактически
сокращающие общий объем работы и ускоряющие поставку продукта, пользуются
популярностью среди приверженцев процедурных принципов разработки.
Рис. 23.2. Результаты обзоров, выполненных с
меньшими трудозатратами
Хотя это и может показаться странным, обзор зачастую "навязывается"
разработчикам. Проводятся диспуты, в ходе которых обговаривается ценность не связанных
Humphrey Watts. A Discipline for Software Engineering. Reading, MA: Addison-Wesley, SEI Series in
Software Engineering, 1995.
Fagan Michael. "Design and Code Inspection to Reduce Errors in Program Development". IBM
Systems Journal, 15C), 1976.

856 Глава 23
с финансовой стороной преимуществ использования обзоров, таких как
распространение информации, но эти положительные результаты часто забываются в сумятице,
выгнанной угрозой срыва сроков выполнения, определенных в графике.
Рассматривая какое-либо капиталовложение, менеджеры программных проектов часто в своей
непреклонности походят на банкиров. Они утверждают, что окупаемость необходимо
определять с применением объективных, конкретных, фактических и финансовых
терминов. Любое действие, которое даже отдаленно воспринимается как
нарушающее график выполнения проекта, — это "проклятье" для руководителей, а избитые
фразы о полезности обзоров, бытующие с ранних дней существования
вычислительном техники, уже едва ли проводят на них какое-либо впечатление.
К счастью, за последние два десятилетия были накоплены данные,
оправдывающие статическое тестирование. Были подтверждены результаты первых
исследовании, проведенных в 1970-х и 1980-х годах. Современные данные, предоставленные
лабораторией программного инжиниринга SEL (Software Engineering Laboratory),
а также Уотсом Хамфри (институт SEI), помимо других данных, начинают
подтверждать то, что ранее было понятно на интуитивном уровне. Большой вклад в банк
данных вносит лаборатория программного инжиниринга. Финансирование лаборатории
осуществляется ПАСА — американской государственной организацией, занимающей-
< я исследованием космоса, а также центром управления космическими полетами
имени Годдарда (NASA/GSFC). В задачи этой организации входит исследование
эффективности применения программного инжиниринга при разработке прикладных
программ. Лаборатория SEL была основана в 1976 году и состоит из трех главных
организационных единиц: NASA/GSFC, подразделение по инжинирингу ПО; Универ-
(II те г штата Мэриленд, департамент вычислительной техники; а также корпорация
но поддержке и развитию вычислительной техники, по сопровождению технологи-
чес кнх систем, размещенных в космосе и на Земле'.
Часто бытует мнение, что для процедурного ПО, созданного на основе
использования принципа последовательного жизненного цикла, устранение дефектов,
выявленных после ввода продукта в эксплуатацию, может потребовать в 100 раз больше
.sarp.it, чем исправление дефектов, обнаруженных на ранних этапах жизненного цик-
ча. Факторы, служащие причиной этого феномена, включают в себя кумулятивный
анализ, переработку проекта и кода, а также усиленный волновой эффект для всей
разрабатываемой системы. Теперь мы знаем, что к этим утверждениям следует отно-
< и п.( я довольно серьезно. В результате выполнения исследований Уотса Хампри
было установлено, что обнаружение дефектов на ранних этапах разработки ПО не про-
< то приводит к небольшому уменьшению временных и прочих материальных затрат,
а позволяет добиться весьма значительной экономии. Средний показатель времени,
потраченного при устранении ошибки на этапе определения требований, соответст-
вмоишй 1 часу, превращается в 3-4 часа при устранении дефектов, выявленных на
этане разработки проекта, в 10 часов — на этапе кодирования, 15-40 часов — при
проведении стендового тестирования. 30-70 часов— во время проведения приемочных
испытаний и 40-1000 часов — при эксплуатации программного продукта! Более того,
in следования показывают, что средние затраты на устранение одного дефекта
составили от $90-$ 120 при инспекционной проверке и $10000 при тестировании.
Компании, которые использовали систему инспекционной проверки на ранних этапах,
(ччйщили, что количество дефектов, обнаруженных при тестировании, снизилось
~eJ . qst'c.nasa . gov /webs ite/ index .htm. Лаборатория программного инжиниринга.

Аттестация и верификация 857
десятикратно, а затраты на тестирование сократились на 80%, включая затраты на
проведение инспекционной проверки.
В результате проведения национального эксперимента по проверке качества ПО
(National Software Quality Experiment) были определены показатели, на основе
которых выполняются оценки состояния качества программного продукта и измеряется
скорость продвижения к цели, определяющей улучшение временных показателей
жизненного цикла разработки ПО. Этот механизм позволяет получить базовые
образцы качества программного продукта на основе информации промышленных,
государственных и военных организаций. Благодаря этим сведениям, включая данные,
собранные с 1992 года по 1997 год, появляется возможность для оценки
производительности и оценки продвижения к поставленной цели. В результате эксперимента
было установлено, что прибыль на инвестированный капитал (чистые
сбережения/затраты на обнаружение дефектов), полученная в результате осуществления
обзоров ПО, находится в диапазоне от 4 до 8, независимо от контекста конкретного
применения.
В 1997 году было 112 лабораторий по инспектированию, на базе которых 2317
участников прошли обучение и провели сеансы по инспектированию. В результате
исследования было обнаружено, что прибыль на инвестированный капитал составила 4,48%.
Менеджерам программных проектов было бы интересно узнать размер прибыли на
инвестированный капитал, полученной в результате выполнения действий по
усовершенствованию процесса разработки ПО. После проведения инспекционных проверок ПО
собираются необходимые для таких подсчетов данные... Прибыль на инвестированный
капитал в результате применения инспекционных проверок ПО определяется
следующим образом.
Сбережения/затраты
где:
Сбережения = (основные дефекты х 9) + незначительные дефекты
Затраты = (затраченное на подготовку время + (временя проведения (в минутах) х 4))/60
В этой модели, отображающей прибыль на инвестированный капитал, размер
сэкономленных средств определяется в зависимости от величины затрат, которых
удалось избежать благодаря обнаружению и исправлению дефектов на ранних, а не на
поздних фазах цикла разработки продукта. На обнаружение и исправление основгюго
дефекта на поздних стадиях разработки может потребоваться десять часов. Десять
часов, потраченных на корректировку дефекта на более позднем этапе разработки,
минус один час, потраченный на устранение дефекта в настоящий момент времени, дает
константу, равную девяти (9), которая применяется к крупномасштабным дефектам.
На устранение незначительного дефекта на более позднем этапе может
понадобиться два часа. Отнимем один час, потраченный на исключение этого дефекта в данный
момент, и получим константу один A), которая применяется в случае
незначительных дефектов. Чтобы продуктивно использовать отведенное на устранение дефектов
время, привлекается среднее число участников D). Константа, равная 60 минутам,
применяется для превращения значений минут в значения часов. Результаты,
демонстрирующие прибыль на инвестированный капитал, для каждой организации,
участвующей в национальном эксперименте по проверке качества ПО, предполагают,
что прибыль на инвестированный капитал, полученная в результате проведения
инспекционных проверок программного продукта, находится в соотношении от 4:1 до 8:1.

858 Глава 23
На каждом долларе, потраченном на инспекционные проверки программного
продукта, организация может потеущиалъно сэкономить 4-8 долларов, необходимых для
влекущей большие затраты переработки .
Помимо i .чсопомлепных средств, организация, которая руководствуется таким
i-piiHiuinoM. получаст возможность точнее прогнозировать необходимые затраты и
;...iiii».'uuiiiii-' графика, уменьшить количество дефектов, достигнуть более высокого
\; лг.-.м i:i'K4T!ia программного продукта, что способствует более оптимистичному
цеп 'Логическому настрою среди специалистов-практиков .
1 !а риг. 23.3 иллюстрируется адаптированный вариант исследования,
проведенного фирмой IBM, "Software Product Assurance". Суть этого исследования заключается в
том, что некоторые дефекты обнаруживаются и устраняются относительно просто, в
то время как другие неполадки обладают волновым эффектом, в результате которого
затрагиваются несколько компонентов проекта. В приведенном примере на ранних
фадач проекта, посвященных исследованию концепции и системы, было допущено
met i). ошиГк!.. Они не были обнаружены без выполнения обзора и перешли на фазу
oiijK деления требований, где четыре ошибки послужили причиной возникновения
волнового эффекта (хотя и не имеющего негативный характер). На этом этапе к 6
деф> i гам прибавилось еще 9 ошибок, так что на фазу разработки проекта перешло в
це юм 15 дефектов. На фазе разработки проекта из этих дефектов осталось 8, что
выли.! ю волновой эффект 3,5 (то есть, в общем эффект составил 8 х 3,5 = 28) и
послужило появлению 80 новых ошибок. Теперь, общее количество дефектов 55 G + 28 + 20)
переходит ii.i фазу кодирования. В фазе кодирования 15 из 55 дефектов вызвало вол-
н. >».,,! ..ффект й (положение ухудшается), что в целом приводит к эффекту 75. Общее
!.-.. нркчтво дефектов, которые перешли на фазу модульного тестирования, теперь со-
( : ишет 145 D0 + 75 + 30). Если в результате осуществления модульного тестирования
\д н'тся ■ юнаружить и исправить половину из этих дефектов, тогда в фазу системного
гнроп.шия перейдет 72 дефекта. Если в фазе системного тестирования будет обна-
] .-кона половина из этого числа дефектов, тогда в фазу приемочных испытаний поль-
- п..» гелем перейдет 36 дефектов. Если в фазе приемочного испытания пользователем
п\ ,ег обнаружена и исправлена еще половина дефектов, заказчик получит
программный продукте 18 дефектами (весьма приемлемый уровень).
Сравните этот же сценарий с тем, в котором обзоры проводятся на протяжении ка-
жд' )й и.» фаз. I la рис. 23.4 на фазе исследования концепции и системы было допущено те
же <} ошибок. Но на этот раз вместо того чтобы пройти незамеченными, в результате
выполненного обзора была обнаружена и исправлена половина ошибок, поэтому лишь
три ошибки превратились в дефекты и перешли на следующую фазу. На фазе
определения требований два из трех дефектов вызвали волновой эффект и привели к
повторному появлению тех же девяти ошибок. Поскольку половина из них была обнаружена во
время обзора, на следующую фазу перешло только шесть дефектов. На фазе разработки
проекта 2 из 6 поступивших дефектов вызвали аналогичный волновой эффект 3,5
и и шикли те же 20 ошибок. Однако поскольку был проведен обзор, в результате
ком.рого была обнаружена приблизительно половина из имеющихся проблем, на
л tsc.hill. af.mil/CrossTalk/199e/dec/oneil.asp. Don O'Neill. "National Software
Qu;ili!y Experiment, 1998. A Lesson In Measurement. CrossTalk: Journal of Defense Software
Engineering, December, 1992-1997,
'См. сноску 6.

Аттестация и верификация 859
этап кодирования перешло только 15 дефектов. Применяя те же математические
действия по отношению к такому же количеству ошибок, как и прежде, придем к
выводу, что на фазу тестирования переходит 28 дефектов. На каждой из трех фаз
тестирования была обнаружена половина перешедших на них дефектов, в результате чего
клиент получает продукт с количеством дефектов, равным 8,5. Это не идеальный
результат, но он лучше, чем 18 дефектов, полученных в предыдущем сценарии.
Дефекты
Дефекты
с волновым эффектом
Перехваченные
и скорректированные
дефекты
SRS
/ 2
f 4x1
9
SDD
тестирование
Системное
тестирование
Приемочные
пользовательские
тесты
50%
■ 18
Код
/ 40
П5х5
30
145
Рис. 23.3. Волновой аффект без учета обзоров
■ Дефекты
Дефекты
' с волновым эффектом
Новые ошибки
тестирование
50%
, Системное
[тестирование
Приемочные
пользовательские
15/ тесты
50%
50%
• 3.5
50% 28
Рис. 23.4. Волновой аффект с учетом обзоров и тестирования

ЯвС? Глава 23
Большое количество других исследований было проведено не только с целью
определения необходимости выполнения обзоров, но также и для того, чтобы устано-
иить, каким образом приступить к их проведению. Например, некоторые
организации сообщают, что для успешного проведения обзора важно иметь компоненты
продукта "нужного размера". Если подвергаемый обзору объект невелик, происходит
nai фасная трата времени, а если он слишком велик, страдает эффективность процес-
■ л предотвращения дефектов. На понятийной диаграмме на рис. 23.5 показано, что
наличия 150 строк кода как раз достаточно, чтобы приступить к выполнению обзора.
В ходе изучения статистических данных Рэйтэон (Raytheon) обнаружил, что
коэффициенты идеальной подготовки и просмотра для инспекционных проверок проекта
«оставляет менее чем 250 строк исходного кода (Source lines of code, SLOC) в час,
:< идеальный коэффициент обзора в случае инспекционных проверок кода составляет
менее 300 SLOC в час. С уменьшением коэффициента обзора наблюдалась тенденция
i- увеличению количества обнаруженных ошибок при инспекционной проверке как
I !,1.)работки проекта, так и кода. При уменьшении скорости подготовки, наблюдалась
тенденция к увеличению количества обнаруженных ошибок при инспекционных
проверках проекта7. Подобное исследования, выполненное компанией IBM, также
показало, что чрезмерный размер материалов, предназначенных для инспектирова-
тн1я, ведет к высокому коэффициенту подготовки, что провоцирует рост
коэффициент инспектирования. Последний, в свою очередь, приводит к обнаружению мень-
что количества дефектов и ведет к необходимости выполнения переработки кода.
' >м> исследование указывает на то, что среднее число, выведенное из 125 не заком-
'нтироканимх строк LOC в час, является рациональным коэффициентом, мотиви-
>.. Ю1ЦИМ проведение собрания, посвященного проведению обзора .
Положительные результаты проведения обзоров мы рассмотрим позже, в разделе
"PsH ки, связанные с отсутствием обзоров".
100 200 300 400
Строки просмотренного кода
Рис. 23.5. Влияние корректно
определенного размера просматриваемою
материала
Неэкономические преимущества при выполнении обзоров
На самом ли деле разработчики допускают возникновение такого большого коли-
м ч ; на дефектов в своих продуктах? Да, это действительно так. Даже учитывая чувст-
гордости, которое присуще творческой работе, разработка ПО— это сложный
' Haley Tom и др. "Raytheon Electronic Systems Experience in Software Process Improvement".
S,fiware Engineering Institute Technical Report. CMU/SEI-95-TR-017, November, 1995.
" Buck F.O. "Indicators of Quality Inspections". IBM Corporation Technical Report IBM TR21, 802,
Si-utember, 1981.

Аттестация и верификация 861
процесс, и осуществляется он обыкновенными людьми. Даже самый прославленный и
опытный программист допускает ошибки. Некоторые исследования показывают, что
плотность распределения дефектов находится в диапазоне от 49,5 до 94,6 на тысячу
строк кода, в то время как в результате других исследований были выявлены еще
более высокие показатели.
Благодаря выполнению обзоров можно нейтрализовать Действие человеческого
фактора при выполнении поставленной задачи.
■ Обзоры позволяют обнаружить посторонние элементы, чего нельзя сделать в ходе
традиционного тестирования. Обзоры могут следовать по всем выполняемым ветвям
разрабатываемого ПО. С помощью тестирования невозможно проверить все ветви,
в результате чего редко проходимые ветви часто приводят к появлению ошибок.
■ Разные точки зрения, личностные качества и жизненный опыт помогают при
обнаружении всех видов проблем, которые незаметны при поверхностном взгляде.
■ Разработчики могут больше внимания уделять творческому аспекту процесса
разработки, зная, что их эксперты участвуют в проекте и действуют в качестве
"подстраховки", они могут увидеть реальную картину тогда, когда рожденные
вдохновением мысли выйдут из-под контроля.
■ Происходит разделение труда, благодаря чему рецензенты могут
сконцентрироваться на этапе обнаружения проблем.
■ Поскольку подходящая "часть" работы должна подвергаться обзору, разработчики
начинают мыслить по принципу модульности и руководствуются своими знаниями
о низкой или высокой степени связности (см. главу 22).
■ Распространение информации и обучение происходят тогда, когда разработчики
встречаются при проведении обзора. Люди быстро воспринимают и
распространяют хорошие идеи, которые они замечают в работе других пользователей. По
словам некоторых экспертов в этой области, таких как Геральд Уайнберг (Gerald
Weinberg), — это самый важный результат выполнения обзора .
■ Возрастает степень согласованности работы между членами команды и при
выполнении всех проектов. Происходит установление фактических групповых норм,
что облегчает понимание сути программных продуктов и их сопровождение.
■ Менеджеры проекта могут получить представление о действительном состоянии
разрабатываемых продуктов. Иногда разработчики сами решают, над чем важно
поработать (хотя, как правило, такое поведение может подорвать проект).
■ Все допускают ошибки и бессознательно вызывают возникновение дефектов в
продуктах. Когда за обнаружение ошибок эксперты получают вознаграждение,
процесс их выявления является "безопасным", а значит, это приведет к обнаружению
большего количества дефектов.
В конечном счете, в результате обзора программные продукты улучшаются в силу
следующих причин.
■ Проблемы обнаруживаются тогда, когда их можно относительно легко исправить
без значительных понесенных затрат, причем легко принимаются те части
продукта, которые не являются проблемными.
' Freeman Daniel, and Gerald Weinberg. Handbook of Walkthroughs, Inspections and Technical
Reviews, 3-е падание. NY: Dorset House, 1990.

862 Глава 23
■ Локализация проблем происходит практически в месте их возникновения.
■ Инспектируются исходные данные какой-либо фазы с целью проверки их
соответствия исходным требованиям или критериям выхода.
■ Предотвращается возникновение дальнейших проблем с помощью оглашения
решений часто происходящих затруднений.
■ Распространяются сведения о проекте, что способствует повышению его
управляемости.
■ Распространяются полезные организационные процедуры и практические
методы, что позволяют обеспечивать унифицированную форму технической
деятельности.
■ Разработчики обучаются тому, каким образом избежать возникновения дефектов
при дальнейшей работе.
■ Предотвращается возникновение дефектов в текущем продукте, поскольку
процесс подготовки материалов для инспекционной проверки способствует
уточнению требований и проекта.
■ Обучаются новые участники проекта.
■ Менеджерам проекта предоставляются надежные опорные точки и
предварительные оценки.
■ Облегчается поддержка установленного порядка выполнения проекта и
обеспечивается объективная, измеримая обратная связь.
'"■реди других преимуществ, обзоры обеспечивают еще одно положительное
свойство, прошедшие проверку временем. Оно заключается в том, что в этом случае
п> черживяется обучающая платформа для вновь набранного персонала, новичков
и д той области и неопытных специалистов. Все, что можно сделать для увеличения
1 и I u га (от рудников в текущей предметной области, полезно, поскольку почти все
связанные с ГЮ проблемы начинаются с формулирования требований. Билл Куртис (Bill
Curtis) отмечал, что до 70% продвижения требуемого процесса разработки зависит
от опыта, который имеют разработчики в данной прикладной области, а также от
практического опыта в применении средств разработки . Как обычно, если при
выполнении обзора задействованы члены других организаций, возникает эффект
"перекрестного опыления". С целью достижения второго уровня зрелости (согласно
системе, разработанной Институтом программного инжиниринга) —
повторяющегося уровня, обзоры обеспечивают коммуникационное средство, позволяющее
реализовать поддержку (или повторяемость), когда к обзору материала допускается, по
меньше мере, еще один человек. Некоторые компании, включая фирму Motorola,
настаивают, чтобы демонстратор, представляющий ПО на сеансе обзора, должен быть
кем угодно, но не разработчиком данной программы. При этом они настойчиво
советуют, чтобы демонстратор полностью ознакомился с продуктом, что обеспечивает
повышение качества повторяемости.
Полученные в период разработки результаты обзоров важны для обеспечения
качества системы и достижения удовлетворенности ее функционированием со
стороны заказчика. В этом случае будет видно, какой компонент требует настройки,
а также понятен порядок выполнения этого действия. Обнаруженным проблемам
Curtis Bill. Personal Communication, 1996.

Аттестация и верификация 863
можно уделить первостепенное внимание, оценить степень их серьезности,
отследить их статус и использовать в качестве "наглядных пособий" для специалистов,
выполняющих текущее техническое обслуживание системы, и разработчиков будущих
систем. Исправление простых ошибок можно доверить автору, в то время как ошибки
высокой степени серьезности можно предать огласке, и в дальнейшем выполнять их
поиск в других местах разрабатываемой системы.
Опыт показал, что инспекционные проверки незначительно повышают степень
вовлечения человеческих ресурсов в процесс рпгработки, акцентируя внимание на
требованиях и проекте. Значительно уменьшая объем работы, отводимой на
тестирование, а также на переработку проекта и кода, обзоры приводят к общему конечному
уменьшению необходимых для разработки ресурсов, а зачастую и к сокращению
сроков, определенных в графике1.
Цели обзора
Природа и формат продуктов, получаемых по мере выполнения проекта,
изменяются на каждой фазе разработки программного продукта. Несмотря на имеющиеся
отличия, каждый полученный продукт подвергаются просмотру во время
стандартного сеанса обзора. Каждый промежуточный продукт становится источником исходных
данных или "критериев выхода" для соответствующей фазы. Подвергаемые
просмотру элементы включают в себя следующие:
■ любой компонент ПО (продукт, полученный по мере выполнения проекта);
■ все, что можно спроектировать и описать;
■ программный продукт, который имеет особо сложную структуру;
■ продукт, обладающий смешанными функциями;
■ программные продукты, обращению с которыми следует обучить кого-нибудь еще.
Потенциальные объекты, предназначенные для обзора, перечислены в
примечании 23.1.
Продукты, получаемые по мере выполнения некоторых современных
программных проектов отличаются от тех, которые производились в прошлом. Фазы
каскадной модели зачастую заменяются жизненными циклами объектно-ориентированного
ускоренного прототипирования, содержащими такие фазы, как "определение
предварительных требований, "разработка проекта/прототипа требований",
"выполнение итерации, уточнение определения и прототипа требований" и "настройка
процесса выполнения, приемочное испытание и сопровождение". Однако в любом случае
продолжают применяться стандартные "роли" и "правила" просмотров.
Отличительной чертой прототипирования и объектно-ориентированного проекта могут быть
документы анализа/проекта (например, классовые модели типа ERD-диаграмм),
а также стандарты, которые служат критериями просмотра (стандарты для DDF-
диаграмм отличаются от тех, которые используются для дейтаграммы применения
тестов). Независимо от методологии разработки и полученной в результате
формулировки планов и моделей, все компоненты проекта, внутренние и внешние, могут
подвергаться просмотру.
Fagan Michael E. "Advances in Software Inspections". IEEE Transactions on Software Engineering,
12G): 744-751, 1986.

!4fl Глава 23
• имечамие 23.1. Потенциальные объекты обзора
;>i,
предложение;
кон гракт:
график:
•~>1«>джег;
план менеджмента программных,nppcjp'pfc(^fi^ai
SOAP). " '"" '"*' '
обоснование;
'■•-'• V \:л
шин обеспечения качестваПО: (Software Д**!^
спецификация требований к nO^Softiran^t^um!^
и.'ын менеджмента конфигурации ПС) (Software configuration
ач.ш тестирования проекта; '- ' r-'U ''W^^^^-^^^.-^'^'^
Л01 ические модели — DCD, DFD, ERD, мо^елмраф^о]^^
диаграмма действий, варианты использо]
словарь данных; > ^M^sfcnj
матрица возможности трассировки!^ . .^->.-t&£f
документ, определяющий разработке-ЛГрКёййЙЙРП
с тр\ ктурная диаграмма;
ттт ; * - ■"* Л''^ёШш^
шаграммаЧешшна(Несси4Днайдермана7г ^j <7г*"**^^™-'Т?*>-;- ■ • . ч^4
ли.я-рамма переходов между состояния*^, сценарии атестовых испьттани
чнаграмма взаимодействий; * -"'^у* &' '^ЩтЬ&Штф1*^^^*^
псевдокод, таблица решений, дерево'^^ЩЩЩ^Щ^^^^^^^^^1^::^^^-:
и тли интегрированного тестирования; <
план преобразования;
и тли системного тестирования; \ •»!
б.иовая линия ПО; i, „;
план лдкунок;
:iлай системных переходов;
\л ководство/инструкция пользователя";";
оперативная документация; '\,
и- четы по тестам;
чеоныи план; „.,,.- ** ч ч
контрольный список для предварительного одЩр^нШ;^> ' .^><»-> rrf^ *=<"""
план установки; - "• '':'^ ;- '^"">w^-*,^; •^^>^« - ;«;
-• •',.''"-';-;■'г- ■'•"•'^ir'i^'. vt - '■>.■ -. у...,
-1 чего приемке тестов;
мчан' юнровождеиия. г
u.'iaif одобрения тестирования;
|>\'мкци(>начыгая система;
iT'v^^-Я **

Аттестация и верификация 865
Когда выполняется обзор?
Обзор выполняется на ранних фазах разработки, причем достаточно регулярно!
Эти действия могут и должны проводиться на каждой фазе выполнения проекта до
момента ее завершения и по завершению создания программного продукта проекта.
Неформальные обзоры могут производиться в любое время, а их организация
осуществляется довольно быстро, так как для проведения такого собрания нет
необходимости в обязательной повестке дня или документации. Внимание участников
сосредоточено на общем направлении и вопросах реализации.
Формальные обзоры проводятся тогда, когда автор считает, что продукт не содержит
ошибки. Их выполняют в соответствии с установленным процессом, а обнаруженные
в результате проведения данные документируются. Внимание сосредоточено на
утверждении конечного продукта.
Кто принимает участие в проведении обзоров?
При выполнении обзоров задействованы менеджеры программных проектов в той
степени, в которой они оказывают поддержку в процессе разработки. Они
обеспечивают такие условия, как залы для проведения собраний и средства обеспечения
глобального сотрудничества. Менеджеры также выполняют просмотр результатов
измерений и принимают на их основании определенные решения. Что самое важное —
менеджеры проектов позволяют процессу протекать своим ходом. В графике на
проведение обзора отводится достаточное количество времени, и процессу их
осуществления обучают всех членов команды разработчиков. Как только создан фундамент и
определены ожидаемые руководством результаты (главным принципом является
убеждение: "мы верим в результативность обзоров"), менеджеры будут располагать
всем набором средств, необходимых для передачи работы команде. Экспертные
оценки — это те же обзоры, которые осуществляются только экспертами команды
разработчиков, а менеджеры не принимают в них участие.
Эксперты выбираются на основе всех категорий задействованных в проекте
участников: заказчики и спонсоры, выполняющие экспертную оценку полученных в начале
разработки высокоуровневых элементов, таких как контракты; составители
требований; аналитики спецификаций; разработчики моделей; проектировщики; специалисты
по SQA и SQE; программисты; сетевые эксперты; администраторы баз данных; и т.д.
Каждый эксперт выполняет определенную роль, которая обуславливает
специфический характер поведения, навыки и знания, необходимые для достижения
высококвалифицированного выполнения просмотров кода программ. Ниже перечислены эти роли:
■ автор;
■ координатор (организатор, руководитель просмотра);
■ демонстратор (чтец);
■ переписчик (регистратор);
■ инспектор/рецензент.
Более детально эти роли будут обсуждаться в разделе "Роли участников собрания
по проведению обзора". Ниже приведено их обобщенное описание.
Автор в конечном счете несет ответственность за изменение рабочего продукта
после его обзора. Это, как правило, человек, который первоначально создал рабочий
продукт.

866 Глава 23
Координатор (организатор или руководитель процесса обзора) призван создать
условия, при которых другие члены команды исполняют свои роли наилучшим
образом, исходя из собственных возможностей. Он руководит собранием и следит за
ходом его проведения, в то же время сохраняя нейтральное отношение к процессу
(лично не заинтересован в его исходе).
Регистратор обеспечивает фиксацию в документации результатов обзора (места
нахождения ошибки или дефекта), а также гарантирует, что каждой ошибке или
дефекту была присвоена степень серьезности, категория и тип. Все данные об
ошибках/дефектах регистрируются на бланке обзора ПО, включая поступившие
предложения. Регистратор составляет отчет по результатам проведения просмотра.
Каждый член команды выступает в качестве рецензента независимо от
назначенных ему других ролей. Роль рецензента заключается в ответственности за
обнаружение ошибок/дефектов в рамках рабочего продукта. Они фиксируют проблемы,
предлагают внести незначительные усовершенствования (не находя решения самой
проблемы) и придерживаются профессиональной манеры поведения по отношению
к другим членам команды.
Как выполняется обзор? Что представляет
собой процесс обзора?
Как показано на рис. 23.6, процесс обзора включает планирование, подготовку,
организацию и выполнение поставленных целей. В случае, если продукт представлен
для обзора, но на самом деле не подготовлен для его проведения, или если
просматриваемый продукт отклонен или принят условно, может возникнуть необходимость
в его переработке. С целью упрощения рассмотрим этот процесс как совокупность
предварительного, основного и завершающего обзора.
Предварительный обзор
При подготовке к проведению обзора выбранный командой координатор
отвечает за приглашение, доступность и распределение ролей, а также за то, что на
проведение обзора приглашены только эксперты со стороны автора, но не менеджеры.
А почему не менеджеры? Они могут не полностью осознавать, что целью проведения
обзора является обнаружение ошибок. Возможно, они понимают, сознательно или
нет, что обнаружение большого количества ошибок — это своего рода обвинение
автору. Известно, что менеджеры используют обзоры как средство, с помощью
которого можно составить мнение о привилегированных/непривилегированных
сотрудниках. Возможно, самым важным является то, что мнение менеджера может отпугнуть
участников процесса обзора.
Помимо приглашения рецензентов, координатор резервирует место для
проведения собрания, если позволяют условия, или обеспечивает сотрудничество с помощью
средства проведения дискуссий либо другого автоматического средства,
предназначенного для обеспечения взаимодействия между удаленными рецензентами.
Координатор обеспечивает соответствие предназначенного для обзора материала
входным критериям:
■ автор не может обнаружить другие проблемы;
■ автор изучил упорядоченное распределение типов дефектов;
■ автор соблюдал установленные стандарты.

Аттестация и верификация 867
Рабочий
продукт"
Подготовлено для обзора
Диспозиция - повторный обзор
Верифицированный
рабочий продукт
Рис. 23.6. Процесс обзора
Если входные критерии не обеспечиваются, рабочий продукт не готов к обзору
и возвращается автору на переработку. Стандартные входные критерии перечислены
в примечании 23.2.
Координатор распространяет материал заранее, как правило, за 14-72 часа до
начала собрания по проведению обзора:
■ распространяется также необходимая вводная информация;
■ распространяются матрицы возможности трассировки, если это требуется.
Координатор производит сверку с рецензентами, чтобы убедиться в том, что они
готовы к проведению просмотра и согласны с тем, что продукт готов к обзору.
Примечание 23.2. Стандартные входные критерии для рабочего продукта,
подвергаемого обзору
• Леность— все ли требования являются понятными^йоднозначными? ' ^ *
• Стандарты— соб тюдены ли все требования, *шеюдцие4>таошение к стандартам?* *
• Завершенность— все ли требования являкт^ завершенными?» v,*fi^ *•* <-J
• Уровень детализации— связаны ли требования с npoejkroj# vw oft,*1 * ^ - •"*-< *
• Совместимость — все ли требования совместимы? Не^являк^ся^чя/^рсайво&ечи-
выми имена и методы применения структур данных й фунога^пй? v ' л *" *>г^ **
Набор функциональных свойств— указаны ли кобректно*все греоуёмые функции?
Четко ли определены все требуемые вхо,
ски независимы и в высшей степени коге
зходы >^вь^оды?>Ву. джф^йсции лргиче-
>ге&нтны?Л ЖЗД^ГГ* -* %

868 Глава 23
Собрание по проведению обзора
На собрании по проведению обзора присутствуют координатор, переписчик,
демонстратор, автор и рецензенты.
Роли, исполняемые на собрании по проведению обзора
Координатор (организатор, руководитель обзора) возглавляет собрание и способствует
его результативности. Он следит за ходом проведения собрания и обеспечивает, чтобы
оно не затянулось больше, чем на два часа. Выбор координатора важен, потому что им
должен быть человек, который способен объективно вести собрание, не отклоняясь
от заданной темы. Цель проведения обзора заключается в обнаружении ошибки на
вступительной фазе (ошибки в требованиях обнаруживается на фазе
формулирования требований), а также в ускорении обнаружения дефектов после вводной фазы
(ошибка в требованиях обнаруживается на фазе предварительной разработки
проекта, а не при поэлементном тестировании фазы эксплуатации). Координатор должен быть
квалифицированным и доверенным лицом, чтобы отстаивать философский принцип
предельной важности: просмотру подвергается именно продукт, а автор — никогда.
Координатор также должен проявлять находчивость, чтобы найти способ достижения
консенсуса, и успешно выполнит работу в том случае, если имеет хорошие навыки в областях
удачного ведения переговоров и проведения результативных собраний. Важные вопросы,
ответственность за которые несет координатор, включают в себя подтверждение
готовности рабочего продукта к обзору, подтверждение обеспечения входных критериев,
набор эффективной команды для проведения просмотра, наблюдение за ходом собрания по
проведению обзора и подтверждения обеспечения входных критериев.
Переписчик (регистратор) регистрирует ошибки и дефекты, степень серьезности,
классификацию ошибок и дефектов, предложения, рабочие элементы и настрой
собрания по проведению обзора (Следует ли провести еще один обзор? Получено
условное или полное одобрение?).
Демонстратор излагает и резюмирует каждый раздел материала, описывая его
функциональные возможности в наилучшей по своим способностям форме. По возможности
он не должен быть автором. В литературе по этому поводу ведется дискуссия, но на
наш взгляд, в разделении ролей есть преимущества, если такую роскошь позволяет

Аттестация и верификация 869
обеспечение проектными ресурсами. Если кто-либо другой, а не автор, должен
демонстрировать продукт, этот человек вынужден его тщательно изучить (это может
подтвердить любой, кто когда-нибудь обучался на основе материалов, подготовленных кем-
либо другим). Более того, когда по крайней мере два человека знают готовый продукт
в деталях, значительно возрастают шансы получить повторяемый процесс. И наконец,
когда кто-то, отличный от автора, демонстрирует работу, автор может "расслабиться" и
не отстаивать продукт, а сконцентрироваться на том, чтобы привести требуемые
объяснения. Таким образом, уменьшается риск того, что автор, который также может
оказаться хорошим продавцом, может повлиять на мнение рецензентов.
Автор поясняет материал, отвечает на вопросы, используя факты. Этот человек
рассматривает определенные вопросы, которые возникают касательно содержания
рабочего продукта, и использует свои особые знания, чтобы помочь установить и
выявить ошибки/дефекты в рабочем продукте.
Таблица 23.1. Роли рецензентов и обозреваемый продукт
Примеры анализируемых рабочих продуктов
is & a i i iS Is
a-™ ? a & sisbe^g
С4.&СЯ его) и ксакйо
is? 18 § si 3 8 H
Руководитель проекта
Спонсор
Аналитик
Проектант
Администратор базы данных
Сетевой администратор
Специалист по SQA
Тестеры
Пользователи
Программисты
да
да
да
Да
да
Да
Да
Да
да
да
Да
да
Да
да
Да
да
Да
Да
да
Да
Да
да
да
да
Да
Да
да
да
Рецензенты (инспекторы) обнаруживают проблемы. Они могут исполнять
следующие роли в работающей над проектом команде или могут брать на себя одну из
перечисленных ролей при выполнении просмотра: клиент, заказчик, спонсор,
функциональный аналитик, разработчик прототипов, высокоуровневый
проектировщик, низкоуровневый проектировщик, испытатель, выполняющий текущее
сопровождение специалист, администратор базы данных, сетевой аналитик, инженер
по качеству программного обеспечения, SQA (гарантирует соблюдение стандартов)
или другие участники проекта. В табл. 23.1 приведены примеры разных обзоров

870 Глава 23
различных рабочих продуктов. Рецензентом может быть любой, кто располагает
хорошими знаниями в данной предметной области или обладает превосходными
техническими навыками. Создатель продукта на предыдущем уровне абстракции и
получатель продукта на этом же уровне являются отличными кандидатами для
присутствия при обзоре. Например, если подвергаемый просмотру продукт
представляет собой проект какой-либо службы (метода), присутствие разработчика модели
данного объекта повысит результативность обзора (Была ли правильно
преобразована целенаправленность требований или модели объекта проектирования в
рабочую конструкцию?). Точно также результативность повысит и присутствие
кодировщика (Является ли рабочая конструкция достаточно точной для ее
истолкования и преобразования в эксплуатационную программу без дальнейшего уточнения
проектировщиком?).
Для обзора больших, сложных или критически важных продуктов может
потребоваться большее количество рецензентов. Управляемое количество участников
процесса обзора находится в диапазоне от трех до семи. В небольших командах
может возникнуть потребность в дублировании ролей. Переписчик может также быть
рецензентом, например, отвечать за гарантию качества QA; демонстратор может
также быть координатором. Возможны и другие комбинации, но, как правило,
предпочтительно, чтобы рецензент был привлечен к просмотру из другого проекта
(затем оказать обратную услугу), вместо того, чтобы чересчур уменьшать объем
процесса просмотра.
Правила проведения обзорных собраний
Как и на любом собрании, следует руководствоваться заранее определенной
повесткой дня, чтобы целесообразно использовать время и распределить объем работы.
Ниже приведена рекомендуемая повестка дня.
■ Открыть собрание по проведению обзора.
■ Установить степень подготовленности инспекторов.
■ Выполнить обзор рабочего продукта, определить ошибки и дефекты
(демонстратор, автор, рецензенты).
■ Зарегистрировать ошибки и дефекты (переписчик). Для сбора данных может быть
использована форма, представленная на рис. 23.7.
■ Определить состояние рабочего продукта:
- принять (без изменений);
- условно принять (доверить автору внесение предложенных изменений);
- выполнить переработку и повторный обзор.
Существуют дополнительные «правила», которые, по мнению многих
публикуемых приверженцев этого процесса, нельзя нарушать.
■ Рецензенты подвергают обзору продукт, а не представляющего его человека.
■ Рецензенты обнаруживают проблемы, но не решают их (это может сделать автор,
который сам не заметил проблему).
■ Рецензенты ищут возможные отвлечения от спецификаций продукта, а также
отклонения от необходимых показателей качества на основании оглашенных
требований к продукту (выходных данных из предыдущей фазы), экспертной оценки
рецензента и принятых в организации стандартах.

Аттестация и верификация 871
■ Рецензенты определяют:
- какие элементы содержат ошибки;
- какие элементы содержат дефекты;
- на какой фазе возник дефект;
- какую степень серьезности имеет каждая ошибка или дефект;
- исправить легко — рецензент просто внесет исправление;
- исправить не так легко — рецензенту поручат подтвердить внесенное исправление;
- исправить тяжело — следить за внесением исправлений поручат другому
рецензенту;
- есть ли какие либо предложения, которые: усовершенствуют результативность
и эффективность продукта; облегчат его понимание и сопровождение;
уменьшат объем потребляемой им памяти; создадут более удобный для пользователя
продукт; будут соответствовать ожидаемым в будущем стандартам;
- существуют ли какие-либо другие элементы, помимо тех, которые трудно настроить
или подвергнуть исследовательскому анализу, которые нужно обозреть еще раз.
■ Если в дальнейших обзорах нет необходимости, к рецензентам переходит право
собственности на продукт как и ко всей команде в целом. Таким образом, они
приобретают право требовать доверия к качеству и ответственность за рассмотрение
любых необнаруженных проблем.
■ Ограничить время, отведенное на сеанс обзора, до одного-двух часов.
■ Составить и утвердить повестку дня.
■ Ограничить дискуссии и контр-доказательства.
■ Сформулировать предметные области проблем, но не предпринимать попытки
разрешить каждую отмеченную проблему.
■ Выполнять письменные записи.
■ Ограничить количество участников и настаивать на их предварительной подготовке.
■ Распределить ресурсы и график для предстоящих собраний, посвященных
рассмотрению обнаруженных проблемных вопросов.
■ Провести целевое обучение всех рецензентов.
■ Подвергнуть критическому анализу сам процесс обзора.
■ Не допускать участия в собрании менеджеров.
■ Использовать контрольные списки по подготовке к обзору, что облегчит поиск
ошибок и дефектов.
■ Выделить два дня на подготовку.
■ Подвергнуть обзору рациональный объем материала (например, 20 страниц
текста, или максимум 150-250 SLOC).
■ Разрешить автору присутствовать на сеансе обзора только для пояснений.
■ Никогда и ни в коем случае не использовать метрические показатели обзора или
другой аспект процесса просмотра для оценивания работы отдельных лиц.
■ Назначить проведение исследования, если невозможно прийти к согласию.
■ Рецензенты могут вносить предложения, которые не играют решающей роли
(например, стилевые решения).

872 Глава 23
Если роль рецензентов в процессе либо слишком мала, либо велика, сделайте все
зависящее от вас для исправления этой ситуации.
Все участники оценивают время подготовки и время посещения собрания
согласно соответствующему коду оценки объема работы в структуре WBS.
Автор оценивает объем работы по внесению исправлений.
Обзоры — это не сеансы "мозгового штурма".
Журнал дефектов, обнаруженных экспертами
Дата обзора:
Элемент
Модуль
И
Описание
дефекта
Отклик
(включая
основную
причину)
Категория дефектов: данные, документация, интерфейс, логика, контролепригодность, производственная деятельность, стандарты,
незавершенность, несовместимость, неверифицируемость
Сложность дефектов: основная, второстепенная
Тип дефектов: пропуск, некорректность, что-то лишнее
Происхождение дефектов: требования, разработка проекта, кодирование, поэлементное тестирование, интеграция, сопровождение
Пожалуйста, укажите ошибку (позаимствовано на текущей фазе) или дефект (унаследован с предыдущей фазы)
Рис. 23.7. Форма сбора данных, подходящая для процесса обзора
Завершающие обзоры
После завершения собрания по проведению обзора, координатор реализует все
полученные результаты. Автор устраняет возникшие проблемы (ошибки и дефекты)
и рассматривает общие предложения. Повторные обзоры, осуществляемые автором
на стадии переработки, должны быть формально верифицированы (ведь
исправления автора могли вызвать появление новых дефектов), поэтому координатор должен
обеспечить устранение проблем и зафиксировать в графике любые последующие
просмотры. Если состояние продукта было принято условно, тогда координатор
подтверждает пересмотры. Если состояние продукта было определено как требующее
переработки и повторного обзора, в таком случае выполняется полный процесс
просмотра, но он сфокусирован по направлению к пересмотрам и
взаимозависимости между ними. Руководитель просмотра (координатор) получает одобрение
и предоставляет документ на рассмотрение конфигурационному управлению.
Переписчик регистрирует действия по выполнению завершающего просмотра и оглашает

Аттестация и верификация 873
замечания, сделанные во время собрания по проведению обзора, всем его участникам
(возможно, всем членам команды разработчиков), а также оглашает отчет-резюме
руководству и объединяет данные собрания в метрический архив.
Метрические показатели обзора
В главе 21 описано, каким образом метрические показатели обзора вместе с
сопутствующими этому процессу данными и информацией по изменению требований
(переработке) могут сформировать информационный базис, опираясь на который
менеджер программного проекта сможет принимать решения. Если данные,
полученные на собрании по проведению обзора, включают в себя данные, собранные в
базах данных (рис. 23.7), в таком случае можно создать много полезных
управленческих отчетов. Посмотрите на рисунки в главе 21, чтобы увидеть, каким образом
результативность содержимого фазы можно схематически изобразить с помощью
диаграмм Парето. Такие диаграммы демонстрируют типы ошибок, требующих
повышенного внимания.
Данные для обзора могут основываться на продукте или на процессе. Информация о
продукте включает количество, типы/степень серьезности и фаза прохождения
ошибок/дефектов в каждом рабочем продукте, подвергаемом обзору. Информация о
процессе обзора может включать количество часов, потраченных на подготовку, а также
количество обнаруженных дефектов, то есть данные, необходимые для вычисления
коэффициента возврата инвестиций (Return on Investment, КОИ). Используются также и
метрические показатели персонала: руководители могут изъявить желание
вознаградить членов команды, которые постоянно вносят вклад в разработку, добровольно
соглашаясь выполнять роли координаторов процесса обзора или рецензентов.
Метрические показатели, сбор которых происходит во время обзора, можно зарегистрировать
на простом бланке, например на бланке, изображенном на рис. 23.7, или на более
тщательно оформленном бланке, если требуется указание дополнительных данных. Более
глубокое представление о том, каким образом следует управлять процессом выполнения
проекта, могут предоставить следующие элементы данных, которые, следовательно,
принадлежат к метрическим показателям просмотра:
■ предварительные данные по инспектированию, если количество обзоров больше
одного;
■ имена и роли инспекторов, исключая автора;
■ время, потраченное автором и координатором на планирование;
■ продолжительность обзора (часы/минуты);
■ время, потраченное планирование каждым рецензентом;
■ время, потраченное на переработку;
■ время, потраченное на внедрение полученных результатов;
■ состояние продукта (принять, условно принять, выполнить обзор);
■ целевые данные для обзора;
■ количество и тип основных обнаруженных дефектов;
■ количество и тип незначительных обнаруженных дефектов;
■ количество основных дефектов, которые были исправлены со времени
проведения последнего обзора;

874 Глава 23
■ количество незначительных дефектов, которые были исправлены со времени
проведения последнего обзора;
■ список авторизированных отклонений;
■ данные по закрытию инспектирования.
Обзоры и анализ тенденций
Графики и диаграммы являются мощными средствами управления, поскольку
позволяют быстро определить наметившиеся тенденции. Менеджеры программных
проектов, как правило, хотят иметь достоверную информацию об изменении
следующих параметров:
■ дефекты, распределенные по фазам;
■ общие дефекты (основные/незначительные) по идентификатору поставки/
выпуска;
■ общие дефекты (основные/незначительные) по идентификатору поставки/
выпуска по типу;
■ плотность распределения дефектов в продуктах (количество основных/
незначительных дефектов построчно/постранично);
■ плотность дефектов для каждого типа в отдельности, а также для каждого типа и
области применения;
■ рабочее время (планирование, подготовка, обзор, реализация полученных
результатов и переработка) по отношению к количеству обнаруженных дефектов,
просмотренных строк/страниц;
■ эффективные коэффициенты подготовки, инспектирования, количества
проверенных строк/страниц из расчета на одно инспектирование;
■ количество проведенных инспекционных проверок по отношению к числу
проверок, запланированных для каждого продукта.
И в данном случае потребуется реальный график управления, в котором сбор
данных происходит на основе проведения обзоров, и который сконцентрирован на
результативности содержимого этапов (Phase containment effectiveness, РСЕ), как это
было описано в главе 21.
Риски, связанные с невыполнением обзоров
Когда Филлип Косби (Phillip Crosby) сказал: "Качество — это свобода", он вовсе не
имел в виду, что в данном случае не потребуется капиталовложений. Его утверждение
в большей степени означало: "У вас может быть все", т.е. качество, ограниченные
затраты и разумно составленный график, но лишь при условии тщательного
планирования и строгого соблюдения эффективных процессов. Нам известно, что обзоры —
это дорогостоящий процесс, особенно когда за один раз столько усилий
разработчиков сконцентрировано на одном рабочем продукте. Расходы на свертывание
процесса, а также эксплутационные расходы, связанные с обзором программных продуктов,
включают первоначальное обучение специалистов-практиков и менеджеров,
непрерывную подготовку и проведение сеансов просмотра, непрерывный менеджмент и
использование управленческих данных для предотвращения дефектов и вычисления
прибыли на инвестированный капитал.

Аттестация и верификация 875
Рассмотрение подготовки и проведения каждого отдельного сеанса обзора
кажется обескураживающим в плане финансовых затрат. Как правило, в сеансе просмотра
принимают участие пять человек, каждый из которых тратит от одного до двух часов
на подготовку и от одного до двух часов на проведение самого сеанса. Это составляет
от 10 до 20 часов от общего объема работы на один сеанс! Однако проведение сеанса
просмотра приводит к обнаружению на раннем этапе от 5 до 10 дефектов на 250-500
строк нового кода или на 1000-1500 строк наследственного кода. Может ли менеджер
программного проекта позволить себе не проводить обзоры? Едва ли. Давайте
рассмотрим подверженность рискам, которая детально изучалась в главе 18.
Подверженность рискам определяется следующим соотношением:
RE = P(UO)xL(UO)
где RE — это подверженность рискам, P(UO) — вероятность неблагоприятного исхода
и L(UO) — это убытки, понесенные сторонами в случае неблагоприятного исхода.
"Неблагоприятный" в отношении к программным продуктам означает
перерасходы бюджета и перебои в графике, неправильно функционирующие продукты,
непродуманность пользовательского интерфейса, недостаточные рабочие характеристики,
недостаточный уровень надежности, низкое качество структуры и т.д.
Пример, приведенный на рис. 23.8, представляет собой потенциально рискованную
ситуацию, в которой разработку ПО выполняет имеющая представление о предметной
области, но не опытная команда, которая допускает известную долю риска в процессе
разработки. В результате по предварительной оценке менеджера проекта существует
вероятность P(UO), равная 0,4, свидетельствующая о том, что в программном продукте
разработчиков будет допущена критическая ошибка, которая приведет к провалу всего
эксперимента и вызовет соответствующие убытки L(UO), составляющие в целом 20
миллионов долларов инвестированных в эксперимент средств.
Для снижения риска потерь в результате эксперимента менеджер проекта выбрал
для рассмотрения два основных альтернативных варианта.
1. Выполнить процесс IV&V. Нанять подрядчика, который отдельно выполнит
аттестацию и верификацию (IV&V) ПО. На реализацию этого процесса будет
дополнительно израсходовано 500000 долларов. Основываясь на результатах
аналогичных процессов IV&V, руководитель приблизительно подсчитывает, что снижение
вероятности возникновения ошибок P(UO) составит до 0,04.
2. Не выполнять процесс IV&V. Помочь команде разработчиков применить более
эффективные методы разработки. Это не влечет за собой никаких
дополнительных затрат, поэтому исходя из ранее полученного опыта, менеджер проекта по
приблизительным подсчетам приходит к выводу, что в данном случае снижение
вероятности возникновения ошибок P(UO) составит до 0,01.
На дереве решений, изображенном на рис. 23.8, для каждого из двух основных
альтернативных вариантов решений показаны возможные результаты
относительно критической ошибки (Critical error, СЕ), которая может быть уже существующей,
обнаруживаемой или устраненной, а также такие результаты, как коэффициенты
вероятности, убытки, связанные с каждым исходом, подверженность рискам,
связанная с каждым исходом, а также общая подверженность рискам (или ожидаемые
убытки), связанная с каждым альтернативным вариантом решения. В этом случае
общая подверженность рискам, связанная с вариантом решения в пользу проведения

876 Глава 23
эксперимента командой, составляет всего лишь 2 млн долларов. Для варианта
решения в пользу IV&V общая подверженность рискам составляет всего лишь 1,3 млн
долларов, а значит, это и есть более привлекательный вариант решения.
Вероятность(Р)
Поиск критической ошибки
Р = 0.36
Потери (L)
L=$0.5M
Выявление риска=Р х Е
Выполнять IV&V
■ Не искать критическую ошибку |_=$20.5 М
Р = 0.04 /^\
Нет критических ошибок
Р = 0.6 L=$0.5M
L=$0
Поиск критической ошибки
Не выполнять IV&V р = аз
• Не искать критическую ошибку L=$20 М
Р^СУ Q
Нет критических ошибок
Р = 0.6 L=$o
$0.18 М
$0.82 М
$0.3 М
$0.0 М
$2.0 М
$0.0 М
Комбинированное
выявление риска
$1.3 М
$2.0 М
Рис. 23.8. Оценивание рисков при выполнении независимой аттестации и верификации
Источник: адаптированный вариант труда Барри В. Боэма. "Software Risk Management:
Principles and Practices". IEEE Software, January, 1991.
Аналогичный оценочный анализ рисков менеджер программного проекта может
выполнить в том случае, если существуют сомнения, что обзоры, тщательное
тестирование и действия по выполнению IV&V стоят вложенных в них средств в любом
выполняемом проекте.
Оценка качества инспекционной проверки ПО
Фэйгэн разработал процесс инспектирования ПО в компании IBM и опубликовал
результаты своих исследований в IBM Systems Journal . Он определяет "качество
инспектирования" как присущее ему свойство обнаруживать все случаи, когда продукт
не отвечает предъявленным к нему требованиям. Исследования, оценки и
наблюдения, выполненные большим количеством людей, принимающих участие в
инспекционных проверках за последнее десятилетие, дают представление о факторах,
повышающих качество инспектирования. Взаимосвязи между этими факторами должны
рассматриваться как определяющие и рассматривающие первоначальные коренные
причины проблемы. Эти основные факторы, повышающие качество
инспектирования, показаны на диаграмме причины/следствия Ишикава или Фишбоуна,
изображенной на рис. 23.9 '.
' См. сноску 4.
Ishikawa К. Guide to Quality Control. Tokyo, Japan: Asian Productivity Organization. 1976.

Аттестация и верификация 877
Возможность выполнить инспектирование продукта (Готов ли продукт к проведению
обзора? Было ли выбрано для обзора подмножество продукта нужного размера? и т.д.).
Процесс инспектирования (Оглашен ли он, понимают ли его и руководствуются
ли им разработчики? Прошли ли разработчики обучение для выполнения
отведенных им ролей? и т.д.).
Менеджеры (Понимают ли они суть процесса? Поддерживают ли его? Позволяют
ли потратить время на его проведение? Считают ли, что он приводит к
уменьшению объема работы и повышает уровень качества? и т.д.).
Программисты (Работают ли они как одна команда? Если у них стимул для того,
чтобы беспокоиться о качестве? и т.д.).
Хорошо определенный процесс контроля
Менеджеры,
вовлеченные
в определение
процесса
Выполнение'
ролей
Рис. 23.9. Диаграмма Иишкава, применяемая инспекторами по обеспечению качества
Вопросы, рассматриваемые
при осуществлении обзоров
Теперь, когда мы как можно более полно описали во всех красках преимущества
просмотров, справедливо было бы вспомнить о том, что Брукс сказал по поводу
отсутствия панацеи от всех бед" . Не все связанные с качеством проблемы можно
решить с помощью обзоров, и даже при их выполнении существуют разногласия
относительно того, каким образом следует использовать их результаты.
Должен ли быть автор демонстратором? Какой должна быть степень формализма?
Является ли организация любого обзора более лучшим решением, чем отсутствие ка-
" Brooks Fredrick P. "No Silver Bullet: Essence and Accidents of Software Engineering". IEEE
Computer, 20D):10-19, 1987.

878 Глава 23
кого-либо обзора вообще? Какова степень эрудиции рецензентов, работающих над
небольшим проектом и выполняющих несколько ролей? Все эти вопросы
продолжают вызывать активные дискуссии специалистов. Стоит лишь приравнять "сквозной
контроль" к инспекционной проверке, и этого будет вполне достаточно, чтобы
заставить "забурлить кровь" некоторых разработчиков программного обеспечения.
Сообразительный менеджер проекта может свести такие разногласия до минимума,
определив значения терминов и выполняемые в процессе роли, основываясь на принятых
в организации стандартах. В прошлом одна из самых трудных задач относительно
утверждения процесса просмотра была связана с понятием обезличенного
программирования. Критический отзыв на рабочий продукт какого-нибудь автора может
вызвать определенные затруднения. С какой стати кто-либо должен подвергать себя
такого рода критике? К счастью, во многих современных организациях этот вопрос
перестал быть проблемным. Хорошо проинформированная организация
руководствуется принципами на основе стандартов SEI СММ и ШЕЕ. Если члены команды
единогласно поддерживают стратегию, согласно которой "просмотру подвергается
продукт, а не его производитель", эгоизм отходит на задний план.
Относящийся к этой же проблеме вопрос, который действительно продолжает
возникать во многих организациях, — это вопрос о способе обработки результатов
обзора. Иногда менеджеры используют их для принятия решений, но забывают передать
полученные результаты обратно членам команды. Иногда они используют их в
качестве исходных данных для выполнения оценок рабочей характеристики продукта. В
первом случае работающая над проектом команда пренебрежительно отнесется к
точности данных, предполагая, что до этого никому нет никакого дела. Во втором
случае, члены команды создадут видимость качественных данных. Или же, "честный"
автор, который отложил в сторону свое самолюбие и позволил выполнить обзор
рабочего продукта, не получит полезной обратной связи, ведь эксперты будут неохотно
обнаруживать дефекты, если им известно, что эта информация будет использована
против их сотрудника. Поскольку менеджер программного проекта стремится
использовать метрические показатели экспертной оценки для улучшения качества
разрабатываемой системы, а также будущих систем, точность данных представляет
особую важность. Эти вопросы можно разрешить с помощью постоянной обратной связи
и при наличии прав собственности на каждый продукт. Эти действия реализуются
после фазы приемки, следующей за обзором продукта.
Единственный способ использования данных обзора при составлении оценки
рабочей характеристики — это вознаградить того, кто добровольно участвует в процессе
обзора. Взять на себя любую роль в проведении просмотра — это связанное с тратой
времени предложение, и те, которые добровольно вызываются быть координаторами
или переписчиками, особенно для других проектов, оказывают организации услугу,
которая заслуживает должного признания.
Резюме по статическому тестированию
с применением обзоров
Ни один процесс тестирования не выявит все дефекты в ПО, но экспертные
оценки (обзоры) представляют собой самое эффективное из всех известных средств.
В процессе обзора из рабочего программного продукта устраняются возможные
ошибки и упущения. Но обзоры позволяют достигнуть намного большего, чем просто
разработать качественный продукт. На макроуровне благодаря просмотрам можно

Аттестация и верификация 879
получить информацию, необходимую для усовершенствования процесса. А это уже
приведет к тому, что со временем в программных продуктах будет допускаться
меньшее количество ошибок.
Для проведения формальных обзоров необходимы поддержка, обеспечение
ресурсами и проведения обучения членов команды со стороны руководства, но они
стоят потраченных на них усилий, поскольку генерируют высокий коэффициент
прибыли на инвестированный капитал. Они являются частью процессов V&V,
поддерживаемых организациями ISO и IEEE, представляют собой ключевую область процесса
в рамках модели SEI СММ и играют важнейшую роль для выполнения программы
метрических показателей.
Существует разные типы обзоров, но наилучшие результаты приносит
формальное собрание, в котором участники берут на себя особые роли, изучение
подвергаемого просмотру материала происходит заранее, правила собрания (например, обзору
должен подвергаться продукт, а не человек; в обзоре не принимают участие
менеджеры) устанавливаются предварительно, выполняется сбор данных обзора и т.д. С
целью выполнения задач, стоящих перед командой, привлекаются рецензенты из числа
различных участников проекта. Каждый рецензент привносит в сам процесс свою
уникальную точку зрения. Так, специалист, отвечающий за качество программного
обеспечения, может обнаружить ошибку или дефект, не замеченные сетевым
администратором, и наоборот. В табл. 23.1 изображено, каким образом выполняемые
участниками проекта роли могут включаться в результаты обзора разнообразных
документов, полученных на различных фазах жизненного цикла разработки ПО.
Метрические показатели обзоров, например, количество обнаруженных
ошибок/дефектов, их тип и степень серьезности, а также место их возникновения и
локализации, обеспечивают ценную информацию для менеджера проекта. Исходя из
этих показателей, можно принимать решения относительно необходимости
обучения, усовершенствований процесса, организации, а также способа составления
предварительной оценки и планирования будущих проектов.
Прежде чем приступить к процессу обзора, следует учесть вероятность
возникновения нескольких непростых вопросов. Как убедить менеджеров верхнего звена
в том, что просмотры положительно влияют на итоговый результат? Как убедить
разработчиков, что в обзорах скрыты огромные возможности для получения новых
знаний?
Динамическое тестирование
Эта глава начиналась с определения: процесс V&V состоит из двух основных
действий — обзора программного проекта и его тестирования. Первое действие является
статическим и означает, что для его выполнения не требуется компьютер и оно
может применяться к любому компоненту проекта. Последнее является
динамическим и означает, что его обязательно необходимо выполнять на компьютере, а значит,
его применимость ограничивается определенными компонентами проекта.
Благодаря современным средствам анализа и разработки проекта динамическое
тестирование осуществляется уже в начале жизненного цикла, причем в самых первых его
фазах. Следовательно, теперь аналитик может "протестировать" модель объекта или
диаграмму потока данных. Однако большинство разработчиков рассматривают
тестирование как процесс выполнения программного кода с целью наблюдения за
качеством его функционирования.

880 Глава 23
Цель тестирования
Цель тестирования — обнаружить и устранить максимально возможное количество
ошибок в условиях уменьшающейся отдачи на инвестированный капитал. Этот
процесс можно рассматривать в качестве фильтра, предназначенного для устранения
некачественных характеристик. Тестирование направлено на обнаружение проблем,
которые становятся причиной неустойчивости системы. Такие проблемы можно
устранить еще до того, как продукт будет выпущен, ведь после выпуска на устранение
проблем требуется намного больше затрат, и их наличие вызывает намного большую
неприязнь у заказчиков. Цель тестирования заключается не в том, чтобы "проверить
качество", а в том, чтобы подтвердить присвоенные продукту качественные
характеристики. Будет ли ПО выполнять предусмотренные для него операции без сбоев,
надежно и точно на протяжении длительного срока эксплуатации? Согласно Гленфорду
Майерсу (Glenford Myers), "удачный" тест — это тест, в результате выполнения
которого обнаруживается еще не выявленная на текущий момент ошибка . Прессман
(Pressman) напоминает нам, что несмотря на то, что тестирование не может
продемонстрировать отсутствие дефектов, оно может показать наличие дефектов . Мы не
можем в достаточной степени долго или усердно проводить тестирование, чтобы на
100% быть уверенным в том, что в поставленном заказчику продукте будут
отсутствовать дефекты. Поэтому нам остается только вариант так называемого "разумного"
тестирования, чтобы наилучшим образом воспользоваться этим требующим больших
затрат этапом в жизненном цикле разработки программного продукта. Один из
примеров "разумного" тестирования предполагает определение связанных с особым
риском областей продукта, к примеру, таких областей, которые являются самыми
сложными или используются с наибольшей интенсивностью, и акцентируется внимания
на обнаружении дефектов в этих областях.
Разработчики и процесс разрушения
Тестирование — это процесс разрушения, фактор, который может послужить
причиной возникновения ощутимого количества препятствий психологического
характера для тех разработчиков, которые привыкли только к творческому режиму работы.
Создание программного продукта — это высшее блаженство для плодотворного
разума, поэтому "изобретатели" ПО гордятся плодами своего труда и хотят верить, что
созданный ими продукт имеет высокое качество (т.е. в нем нет ошибок). Однако цель
тестирования заключается не в том, чтобы доказать пригодность продукта к
эксплуатации, и не в том, чтобы продемонстрировать отсутствие ошибок. ПО создается
людьми, которым свойственны недостатки, а значит, предрасположено к наличию
ошибок. Если бы мы знали, что представляют собой эти ошибки, мы бы их исправили.
Цель тестирования заключается в том, чтобы обнаружить ошибки, которые были
допущены в продукте на этапе его построения.
Разработчикам весьма затруднительно тестировать свои собственные продукты,
поскольку они вынуждены изменить свою точку зрения или отношение, перейдя из
роли создателя в роль критика. Разработчик фундаментально понимает принцип
работы ПО, что усложняет поиск ситуаций, в которых оно не будет функционировать.
15 Myers Glenford J. The Art of Software Testing. New York, NY: John Wiley & Sons, 1979.
'" Pressman Roger S. Software Engineering: A Practitioner's Approach, 5-е
издание. Boston, NA: McGraw-Hill. 2001.

Аттестация и верификация 881
Специалисты обращают внимание на тот факт, что в своем собственном коде
обнаружить ошибки гораздо труднее, чем в программе, созданной кем-либо другим.
Причина этого называется когнитивным диссонансом. Этот феномен затрудняет
сознательное признание собственных ошибок. Более того, разработчик программного
продукта может иметь абсолютно ошибочное представление о постановке задачи или
ее определении. Это означает, что сколько он бы не искал, ему не удастся обнаружить
источник ошибки. В силу этих причин рекомендуется, чтобы разработчики не
тестировали свои собственные продукты.
Конечно, каждый разработчик должен самостоятельно тестировать свои
"произведения" с максимальной тщательностью, прежде чем передать рабочий продукт
независимому испытателю, как правило, эксперту. В процессе тестирования
потребуется смириться с человеческим фактором, присущим специалистам-практикам. Многие
разработчики ПО на самом деле не любят тщательно тестировать свои программные
продукты, так как считают скучным и даже угнетающим наблюдать за тем, как
прикладная программа справляется с возложенными на нее нагрузками. Другие не имеют
ничего против подобного подхода и прекрасно выполняют такого рода работу. Мы
имеем основания заявлять, что между тщательностью проведения процесса
тестирования и количеством ошибок, которые остались неустраненными в уже поставленном
заказчикO программном продукте, существует очень большая зависимость.
Отладка
Процессы тестирования и отладки программного продукта не являются
эквивалентными. Отладку программы можно описать как процесс, который производится
после выполнения удачного тестового случая. (Напомним, что удачный тестовый
случай — это такой пример, в результате выполнения которого обнаруживается ошибка.)
Если описать это явление более конкретно, то отладка — это процесс, состоящий из
двух частей. Он начинается на основе некоторого указания на наличие ошибки
(например, выявленной в результате выполнения удачного контрольного примера) и
переходит к определению точной сущности и местонахождения предполагаемой
ошибки в рамках программы, а затем к налаживанию или исправлению этой ошибки .
Тестирование и отладка играют важную роль в процессе обеспечения
качественных характеристик системы, поскольку во всех программных продуктах есть ошибки,
независимо от того, сколько обзоров мы осуществляем или как усердно мы пытаемся
избежать. Причина появления ошибок и их вредоносности в достаточной степени
обоснована фактами, приведенными в этой книге и во многих других. В основном эти
причины представляют собой общераспространенные факторы риска, обсуждение
которых производилось в главе 18. Обобщенно причины обычно допускаемых
ошибок кроются в следующем:
■ неполные или неправильно сформулированные спецификации требований, по
большей части в результате плохо налаженной взаимосвязи между
разработчиками и заказчиками. Требования, которые носят слишком обобщенный характер,
туманны, тяжелы для понимания или непригодны для тестирования;
■ изменчивость требований;
■ облагораживание или "приукрашивание";
' См. сноску 15.

882 Глава 23
■ степень сложности современной среды, включая интерфейсы в стиле Windows,
прикладные программы типа клиент/сервер и распределенные приложения,
каналы передачи данных, большие реляционные базы данных и большие
прикладные программы;
■ человеческая ошибка, допущенная в спецификации требований, проекте и коде;
■ графики, рассчитанные на слишком краткий период времени из-за неправильных
подсчетов или давления со стороны рынка/клиента; неподходящее время для
планирования тестирования и его проведения, отладки и повторного
выполнения; в результате того, что слишком большой объем работы "втиснут" в узкие
временные рамки, возникают дополнительные человеческие ошибки;
■ желание "задобрить", чрезмерный оптимизм или самолюбие со стороны
разработчика.
■ плохо подготовленные документы (особенно в коде) или их недостаточное
количество.
■ чрезмерная зависимость от инструментальных средств (наглядных пособий,
библиотек классов, компиляторов, и т.д.), которые сами по себе плохо описаны или
неадекватно протестированы.
Непрерывный процесс тестирования
Каждая программа выполняется на основе ограниченного набора входных
данных. Полный функциональный тест предполагает, что программа подвергается
воздействию всех возможных входных потоков. Для каждого элемента входных данных
программа либо принимает поток и генерирует правильный элемент исходных
данных, принимает поток и генерирует ошибочный элемент исходных данных или
отклоняет его. Рассмотрим состоящий из 10 символов входной поток (каждый символ
состоит из 8 битов, каждый из которых может равняться 0 или 1). Существует 2
возможных входных потоков и соответствующих им исходных данных. Полное
функциональное тестирование является нереальным (фактически невозможным),
поскольку, учитывая выполнение одного теста за микросекунду, потребуется время,
в два раза превышающее предполагаемый возраст Вселенной . Поскольку
невозможно протестировать каждую отдельную комбинацию и перестановку входных данных и
интерфейсов, которые вызывают реакцию системы, у нас появляется еще одно
основание в пользу того, чтобы проводить тестирование, руководствуясь разумом, а не
упорством. Следуя этому принципу, необходимо определить методы, с помощью
которых, по всей вероятности, будет использоваться система, вычислить вероятность
применения каждого типа и разработать тесты, направленные на обеспечение
целесообразного выполнения системы.
Выполнение тестирования в рамках V-образного
жизненного цикла разработки ПО
В главе 4 описывался ряд методов, с помощью которых можно улучшить
организацию фаз разработки ПО, действий и промежуточных продуктов. Нами
подчеркивалось, что самое важное — избрать "правильный" подход для выполняемого проекта,
Beizer Boris. Software Testing Techniques, 2-е издание. NY: Van Nostrand Reinhold, 1990.

Аттестация и верификация 883
даже если он предполагает разработку полностью нового жизненного цикла или
комбинацию уже существующих циклов. Один из жизненных циклов, V-образная модель, был
признан особо практичным для проектов, в которых требуется обеспечение высокой степени
надежности. V-образная модель может выполняться обособленно или применяться в
комбинации с другими моделями, например, с методом инкрементной разработки.
Как уже было сказано в главе 4, в V-образной модели особое внимание уделяется
действиям процесса аттестации и верификации продукта. В модели демонстрируется,
что обсуждение, разработка проекта и планирование тестирования продукта
происходит на ранних этапах жизненного цикла. План приемочного испытания заказчиком
разрабатывается на этапе планирования, разработка плана интеграционного
тестирования системы происходит на этапе анализа и разработки проекта, и т.д. Этот
метод разработки плана тестирования представлен пунктирными линиями,
соединяющими прямоугольники V-образной модели.
Рис. 23.10. V-образная модель для жизненного цикла V(sV
В V-образной модели, воспроизведенной на рис. 23.10, акцент делается на
взаимосвязи между фазой разработки проекта и аналитической фазой, которые
предшествуют кодированию и после которых следуют фазы тестирования. Пунктирными
линиями обозначено, что эти фазы необходимо рассматривать параллельно.
Ниже перечислены фазы V-образной модели:
■ планирование проекта и требований;
■ анализ требований к продукту и спецификации;

884 Глава 23
■ архитектура или разработка проекта на высшем уровне;
■ детализированная разработка проекта;
■ кодирование;
■ поэлементное тестирование— проверка каждого спроектированного модуля на
наличие ошибок;
■ интеграция и тестирование — межкомпонентное соединение ранее
протестированных поэлементно модулей с целью доказательства того, что полученные
наборы функционируют так же хорошо, как и отдельно протестированные модули на
фазе поэлементного тестирования;
■ системное тестирование — позволяет проверить, функционирует ли полная
программная система (полностью интегрированная) в условиях реального
аппаратного окружения в соответствии со спецификацией требований к программному
продукту;
■ производство, запуск в эксплуатацию и сопровождение — запуск ПО в
производство и обеспечение модернизации и внесения поправок;
■ приемочное испытание — обеспечение возможности тестирования
функциональных возможностей системы по отношению к исходным требованиям;
после завершающего тестирования ПО и окружающие его аппаратные средства
становятся пригодными к эксплуатации; далее следует фаза сопровождения
системы.
В результате применения модели в проекте, для которого она не подходит в
достаточной степени, особое внимание уделяется планированию процесса V&V для
продукта на ранних стадиях разработки ПО. При этом делается акцент на
тестировании посредством сопоставления фазы или процесса тестирования с процессом
разработки. На фазе поэлементного тестирования подтверждается детализированная
разработка проекта. Архитектурная или высокоуровневая разработка проекта
подтверждается на фазе аттестации и интеграции. Этап определения и спецификации
требований к продукту подтверждается на этапе системного тестирования. Модель
поддерживает выполнения процесса V&V по отношению ко всем внутренним и
внешним продуктам, а не только по отношению к программным продуктам. V-образная
модель определяет продукты, которые генерируются в процессе разработки. Ведь
каждый продукт должен быть пригодным для тестирования, поэтому это отличный
выбор для систем, в которых требуется обеспечение высокого уровня надежности,
например для прикладных программ по контролю за стационарными больными,
а также для встроенного программного обеспечения для устройств управления
надувными спасательными подушками в автомобилях.
Определения, применяемые в процессе
динамического тестирования
Как и в случае статического тестирования, динамическое тестирование включает
несколько определений и многочисленные термины.
Приемочное испытание - это завершающее тестирование, основанное на
технических требованиях конечных пользователей/заказчиков, либо основанное на
применении продукта конечными пользователями/заказчиками на протяжении некоторого
ограниченного периода времени.

Аттестация и верификация 885
Тестирование по принципу "заглушек "аналогично исследовательскому тестированию,
но этот термин зачастую применяют в тех случаях, когда испытатели уже имеют
достаточное представление о программном продукте до начала его тестирования. к
Альфа-тестирование обозначает тестирование прикладной программы, когда
процесс разработки приближается к завершению. В результате проведения такого
тестирования в проект могут вноситься незначительные изменения. Как правило, этот
процесс выполняется конечными пользователями или другими лицами, но не
программистами или тестерами.
Бета-тестирование означает тестирование, при котором разработка и
тестирование по существу завершены и до окончательного выпуска продукта необходимо
обнаружить оставшиеся ошибки и проблемы. Как правило, этот процесс выполняется
конечными пользователями или другими лицами, но не программистами или тестерами.
Тестирование методом "черного ящика" не основывается на каких-либо знаниях о
внутреннем проекте или коде. Тесты производятся на основе требований и
функциональных возможностей.
Ошибка означает дефект, проблему или неисправность.
Сертификация распространяет рамки процесса верификации и аттестации на
операционную среду. Она подтверждает, что система является эффективной в
эксплуатации и способна выполнять определенные требования при заданных условиях
работы, а также гарантирует ее соответствие письменно оформленным требованиям.
Сертификация обычно предполагает существование независимой группы по
контролю за качеством, которая выполняет приемочное испытание системы в целом.
Подобное испытание может выполняться посредством проведения
эксплуатационного/лабораторного тестирования либо путем помещения системы в искусственные
условия эксплуатации. Сертификация — это официальная демонстрация приемлемости
системы с целью получения разрешения на ее эксплуатацию.
Код обозначает модульный исходный код. Он должен соответствовать
утвержденным требованиям, быть технически точным и полным с учетом
поставленных задач, реализовывать ранее созданный детальный проект, отвечать всем
требуемым/применимым стандартам.
Сравнительное тестирование сравнивает недостатки и преимущества ПО с
однотипными продуктами.
Тестирование на совместимость означает тестирование качества
функционирования ПО в определенном аппаратном/программном/операционном
системном/сетевом окружении.
Проект обозначает проект компонента или модуля ПО либо на высшем, либо на
детальном уровне. Он должен соответствовать утвержденным требованиям, быть
полным и содержать все необходимые логические алгоритмы, структуры данных
и информационные вызовы, восходить к утвержденным требованиям и
руководствоваться всеми требуемыми и применимыми стандартами.
Сквозное тестирование аналогично системному тестированию и находится на конце
"макрошкалы" тестирования. Оно включает в себя тестирование полного
прикладного окружения в ситуации, которая имитирует использование в реальной среде,
например взаимодействие с базой данных, использование сетевых средств связи или
взаимодействие, в случае необходимости, с другим аппаратным обеспечением,
прикладными программами или системами.
Инициализация ошибок (или неисправностей), как это было описано в 1970-х годах
Харланом Миллзом (Harlan Mills), предполагала следующий подход: во-первых,

886 Глава 23
необходимо вызвать появление в программе X типичных ошибок и запустить на
выполнение тестовый комплекс. В результате вы, вероятно, обнаружите X-Y ошибок, но
не все число ошибок X. Возможно, вы также обнаружили приблизительно такую же
пропорцию "собственных" ошибок. Предполагаемая эффективность выражается
в виде соотношения (X-Y)/X. Вызывать ошибки не так легко, как кажется, поскольку
для этого необходима таксономия типов сбоев, знание относительной вероятности
их возникновения, а также представление о том, каким образом их возникновение
оказывает влияние на обнаружение ошибок. Неправильные соотношения
некорректных видов ошибок, внесенных методом инициализации, в неподходящих местах
может спровоцировать неправильные подсчеты.
Исследовательское тестирование зачастую принимается как творческое
неформальное тестирование ПО, которое не основывается на формально составленных планах
тестирования или тестовых случаях. Испытатели могут изучать ПО во время
выполнения тестирования.
Сбой — это поведение ПО или компонента системы, при котором они
наталкиваются на какую-либо ошибку, что приводит к некорректному или нежелательному
результату определенной степени серьезности.
Неисправность— это проявление ошибки ПО, что может вызвать сбой.
Функциональное тестирование — это тип тестирования методом "черного ящика",
имеющий отношение к функциональным требованиям прикладной программы. Этот
тип тестирования должен выполняться тестерами. Это не означает, что
программисты не должны проверять работоспособность своего кода до его выпуска (что,
конечно, относится к любой стадии тестирования).
В достаточной степени оптимальное тестирование означает умение чувствовать
момент, когда следует остановиться. Большинство ошибок возникает в результате
нелогичных решений, принимаемых программным алгоритмом на основе встречающихся
ему входных значений. Полный функциональный тест заключается в том, чтобы
подвергнуть программу всем возможным входным потокам. Полное функциональное
тестирование является нереальным из-за большого количества возможных перестановок
входных данных. Невозможно протестировать каждую отдельную комбинацию и
перестановку входных данных и интерфейсов, которые вызывают ответную реакцию
системы. Самый практичный метод тестирования заключается в том, чтобы
определить методы, с помощью которых можно, по всей вероятности, использовать
системы, вычислив вероятность каждого типа применения, а затем разработать тесты,
направленные на применение системы в рамках этих сценариев.
"Партизанское" тестирование— это самые неприятные из всех мыслимых тестовых
случаев, так как они выполняются "на лету". Этот тест может касаться границ,
обработки ошибок, проблем при межмодульном взаимодействии — то есть всего того,
что но мнению тестера может привести к обнаружению ошибки и на что стоит
обратить внимание.
Инкрементное интеграционное тестирование означает непрерывное тестирование
прикладной программы при внесении в нее новых функциональных возможностей.
Для него необходимо, чтобы различные аспекты свойств прикладной программы
были в достаточной мере независимы для обособленной работы, прежде чем будет
завершена разработка всех частей системы, или же чтобы при необходимости были
разработаны тестовые драйверы. Это тестирование выполняется программистами
или тестерами.

Аттестация и верификация 887
Тестирование по принципу установки/удаления программы— это проверка полных,
частичных или модернизированных процессов установки/удаления программы.
Интеграционное тестирование- это проверка скомбинированных компонентов
прикладной программы с целью определения корректности их совместного
функционирования. Компоненты могут представлять собой модели кода, отдельные
прикладные программы, клиентские и серверные приложения в какой-либо сети и т.д.
Этот тип тестирования особенно подходит для систем типа клиент/сервер, а также
распределенных систем.
Тестирование под нагрузкой означает тестирование приложения под большими
нагрузками, например тестирование узла WWW под рядом нагрузок с целью
определения того, в какой точке время реакции системы возрастает либо система дает сбой.
Модуль - см. программа.
Мутационное тестирование— это метод, помогающий определить, является ли
пригодным набор тестовых данных или случаев. Это осуществляется путем сознательного
внесения различных изменений в программу (ошибок) и повторного ее тестирования
с применением исходных тестовых данных/контрольных примеров с целью
установления того, были ли обнаружены внесенные ошибки. Для правильной реализации
этого вида тестирования необходимы большие вычислительные ресурсы.
Тестирование рабочих характеристик - это термин, часто взаимозаменяемый с
термином "тестирование под напряжением и нагрузкой". В идеале тестирование рабочих
характеристик (или любой другой тип тестирования) определяется в документах по
требованиям к продукту, в гарантии качества или планах по проведению тестирования.
Программа, элемент или модуль — описывается как поддающаяся вызову, выполнимая
часть кода с одной точкой входа и одной точкой выхода, которая выполняет одну
функцию (эти определения образуют одно целое).
Тестирование способности к восстановлению означает проверку того, насколько
хорошо система восстанавливается после аварийных отказов, сбоев в аппаратном
обеспечении или других проблем катастрофического характера.
Регрессионное тестирование означает повторное тестирование после налаживание или
внесения изменений в программное обеспечение или его окружение. Установление
необходимого объема регрессионного тестирования может быть затруднительным,
особенно на этапах, приближенных к завершению жизненного цикла. Для этого типа
тестирования могут особенно пригодиться автоматические средства тестирования.
Тестирование работоспособности — это, как правило, первоначальный процесс
тестирования с целью определения того, в достаточной ли степени работоспособна
новая версия ПО, чтобы принять ее для проведения основного тестирования.
Например, если новый программный продукт вызывает аварийные отказы в системах
каждые пять минут, замедляя их работу, или разрушает базы данных, этот продукт может
являться в недостаточной степени работоспособным для выполнения тестирования
в текущем состоянии.
Тестирование безопасности — это проверка того, насколько хорошо данная система
защищает против неавторизированного внутреннего или внешнего доступа,
умышленных повреждений и т.д. Для его проведения могут понадобиться сложные методы
тестирования.
Тестирование под напряжением — термин, взаимозаменяемый с терминами
"тестирование под нагрузкой" и "тестирование рабочих характеристик". Этот термин также
используется для описание тестов, таких как системное функциональное тестирование,

888 Глава 23
но проводимых при нестандартно больших нагрузках, частом повторении
определенных действий или входных данных, введении большого количества числовых
значений, объемных сложных запросов к базе данных, и т.д.
Тестирование подсистем — см. интеграционное тестирование.
Системное тестирование означает тип тестирования методом "черного ящика", которое
основывается на спецификациях общих требований и которому подвергаются все
скомпонованные части системы. Системные тесты предполагают запуск системы в окружении,
в котором она должна выполняться, а также поиск факторов окружения или входных
данных, которые могут вызвать сбой системы или ее неожиданную реакцию. Системное
тестирование может начаться до того, как разработка компонентов будут завершена.
Контрольный случай описывает элемент входных данных либо действие, либо
событие и неожиданную реакцию с целью определения корректности реализации какого-
либо свойства прикладной программы. Контрольный случай должен содержать такие
детали, как идентификатор контрольного примера, имя контрольного случая, целевую
функцию, условия/запуск теста, требования к входным данным, стадии и ожидаемые
результаты. Спецификация контрольного случая может включать в себя идентификатор
спецификации контрольного случая, элементы теста, входные/исходные
спецификации (значения, допуски, таблицы констант, файлы транзакции, базы данных,
терминальные сообпдения, флажки операционной системы), требования к окружению и
процедурные требования.
План тестирования — это документ, в котором описан метод проведения действий
но тестированию. План тестирования программного проекта описывает цели, рамки,
метод и область, на которой сосредоточено тестирование программного продукта.
Такой план, как правило, определяет элементы, предназначенные для тестирования,
подлежащее выполнению тестирование, графики проведения тестирования,
требования к персоналу, требования к отчетности, критерии оценки, уровень приемлемых
рисков и планирование любых связанных с рисками чрезвычайных обстоятельств.
Процесс подготовки плана тестирования помогает определить усилия, которые
необходимо предпринять, чтобы подтвердить приемлемость программного продукта.
В конечном счете, такой план должен обеспечивать, что все новые и
модифицированные программные функции работают корректно в рамках предусмотренного для
программного продукта окружения и в соответствии с утвержденными
требованиями, что все новые и модифицированные интерфейсы будут верифицированы. В нем
также может понадобиться определение отношений между контрольными
примерами, т.е. определение того, какие контрольные случаи должны предшествовать
выполнению данного контрольного случая. Ниже приведены некоторые вопросы,
которые должны задать себе руководители программных проектов при составлении
плана тестирования программного продукта.
■ Были ли основные этапы тестирования идентифицированы и последовательно
размещены должным образом?
■ Была ли определена трассировка согласно критериям аттестации как часть
анализа программных требований?
■ Выполняется ли демонстрация основных функций на более ранних этапах?
■ Является ли план тестирования совместимым с обпдим планом выполнения проекта?
■ Был ли четко сформулирован график проведения тестирования?
■ Определены и доступны ли ресурсы и средства тестирования?

Аттестация и верификация 889
■ Был ли создан механизм ведения записей по ходу тестирования?
■ Были ли идентифицированы тестовые драйверы и заглушки, была ли отмечена в
графике необходимость их проектирования?
Процедура тестирования— это детальные инструкции по запуску, выполнению и
оценке результатов данного теста. Набор связанных с этим процедур часто объединяют в
документ процедуры тестирования. Причем она должна включать полное и точное
описание цели, для которой она предназначена, описание способа ее выполнения и все
ожидаемые результаты. Каждая процедура тестирования должна определять тестируемое
требование, а также нужные аппаратные и программные конфигурации.
Элемент — см. программа.
Поэлементное тестирование— это тестирование наименьшего масштаба. Благодаря ему
выполняется проверка внутренних рабочих характеристик программы, элемента или
модуля независимо от способа их вызова. Этот тип тестирования, как правило,
осуществляется программистом, а не тестером, поскольку для его проведения необходимы
доскональные знания внутренней структуры и кода программы. Такое тестирование не
всегда выполняется просто, например, в случае, если прикладная программа не имеет
четко определенной архитектуры с компактным кодом, и для его проведения может
понадобиться разработка модулей тестовых драйверов или средств тестирования.
Тестирование практичной пригодности— это проверка "удобств для пользователя" с
точки зрения самого пользователя. Этот тип тестирования является субъективным и
зависит от целевого конечного пользователя или заказчика. В этом случае могут
использоваться опросы пользователей, обзоры, запись на видео сеансов пользователей,
а также другие методы. Сюда может включаться эргономический анализ,
проектирование экранов и т.д.
Приемочное испытание пользователем— это тестирование с целью определения того,
соответствует ли ПО требования конечного пользователя или заказчика.
Тестирование методом "белого ящика" основывается на знании внутреннего
логического построения кода приложения. Таким тестам подвергаются операторы кода,
ветви, цепи и условия.
Многие из перечисленных определений компонентов проекта (т.е. план
тестирования, код) могут использоваться в качестве контрольного списка при проведении
экспертной оценки продукта.
Типы тестов
Хронологический порядок выполнения тестов соответствует следующему сценарию.
1. Создаются и тестируются отдельные элементы программы (тесты методом "белого
ящика").
2. Эти элементы объединяются в одно целое как подсистемы и подвергаются
тестированию (методом "черного ящика").
3. Затем подсистемы объединяются в полную систему и подвергаются тестированию
(интеграционные тесты).
4. Полученная система помещается в реальное окружение и подвергается
тестированию (системные тесты).
5. Эти системные тесты сохраняются для повторного выполнения в случае внесения
изменений (регрессионные тесты).

890 Глава 23
Существуют другие виды тестов, но перечисленные виды тестирования составляют
минимальный набор из возможных. А сейчас опишем более детально тестирование
методом "белого ящика", "черного ящика", системное и регрессионное тестирование.
Тестирования методом "белого ящика"
Согласно на V-образной модели, изображенной на рис. 23.10, тестирование
начинается с проверки элементов (следуя очертаниям буквы V вдоль левого ребра по
направлению вниз, а затем вдоль правого ребра по направлению вверх). В таком случае
мы начнем наши несколько более детальные обсуждения основных видов тестов с
обсуждения тестирования методом "белого ящика", которое известно также под
названием тестирования методом "чистого ящика", поэлементного, модульного,
восходящего и структурного тестирования. С помощью этого метода тестированию
подвергается внутренние рабочие части программы, элемента или модуля независимо от
способа их вызова. Программа, элемент или модуль часто описывается как
поддающаяся вызову, выполнимая, ограниченная часть кода с одной точкой входа и одной
точкой выхода, которая выполняет одну и только одну первичную функцию. Иногда
чтобы вызвать выполнение модуля тестирования методом поэлементного ящика,
возникает необходимость в построении тестовых драйверов.
Наличие проекта модуля играет решающую роль для проведения удачного
поэлементного тестирования. В качестве примеров подобного проекта можно привести
следующие:
■ блок-схема;
■ псевдокод;
■ диаграмма Чейпина (Несси-Шнайдермана);
■ PSPEC;
■ CSPEC;
■ таблица решений;
■ диаграмма перехода состояний;
■ иерархические диаграммы "вход-процесс-выход" (диаграммы HIPO);
■ содержание;
■ потоковые графы.
К вопросу рассмотрения диаграмм Чейпина мы еще вернемся в этой главе
повторно (они были описаны в главе 22), а описание потоковых графов будет выполняться
здесь впервые. Тестирование проекта (тестирование методом "белого ящика") — это
процесс, в ходе осуществления которого тестер внимательно изучает внутренние
рабочие элементы кода. Тестирование, управляемое проектом, осуществляется путем
выборки входных данных и других параметров, основанных на внутренних
логических путях, которые необходимо проверить. Задачи тестирования проекта включают
в себя подтверждение правильности следующих аспектов:
■ всех путей выполняемого кода (для большинства программных продуктов, это
можно реально осуществить только на уровне поэлементного тестирования);
■ функционирования интерфейсов;
■ размера и синхронизации критических элементов кода.

Аттестация и верификация 891
Как показано на рис. 23.11, для обеспечения входных данных, необходимых для
выполнения тестирования программных модулей методом "белого" ящика,
необходима соответствующая "сбруя".
Обычно чтобы вызвать выполнение теста методом "белого" ящика, необходимо
спроектировать тестовые драйверы или "сбрую".
Сразу за поэлементным тестированием, на правом ребре буквы V на рис. 23.10,
следует интеграционное тестирование. Этот тип тестирования также известен под
названием тестирования методом "черного ящика".
/
/
* л
/
Е
/
/
/
V
F
/
/
Рис. 23.11. "Сбруя"управляет методом тестирования "черным ящиком"
Тестирование методом "черного ящика"
Этот метод также известен как интерфейсное тестирование, тестирование "сверху
вниз" или как функциональное тестирование. Он предполагает, что отдельные элементы
могут рассматриваться как "черные ящики" или как функционирующие должным образом
компоненты. Ожидается, что элемент перерабатывает или преобразовывает входные
данные в правильные и ожидаемые исходные данные. В этом случае тестирование
направлено на обнаружение ошибок во входных данных, которые используются в "черных
ящиках", с целью проверки передаваемых параметров или интерфейсов между "ящиками".
Чтобы протестировать подсистемы, потребуется схема, согласно которой
ожидается сопряжение и совместное функционирование отдельных элементов в подсистеме.
Такая схема должна входить в хорошо сформулированную спецификацию проекта. Для
объектно-ориентированного ПО она может представлять собой комбинацию
объектных классовых моделей и объектных диаграмм взаимодействия для какой-либо
предметной области или набора объектов. Тестирование подсистем часто
рассматривается как интеграционное тестирование. В объектно-ориентированной парадигме
несколько объектов, имеющих отношение к данному тематическому разделу
(предметной области) группируются вместе и подвергаются тестированию.

892 Глава 23
Неформальное тестирование может управляться требованиями или проектами.
Управляемое требованиями тестирование или тестирование методом "черного
ящика" выполняется путем выборки входных данных и других параметров, основанных
требований к программному обеспечению, и путем наблюдения за входными
данными и реакциями программного обеспечения. Подобное тестирование может
выполняться на любом уровне интеграции. Помимо тестирования в плане соответствия
требованиям, некоторые из целей управляемого требованиями тестирования
заключается в том, чтобы подтвердить:
■ правильность вычислений;
■ должное оперирование граничными условиями, в том числе внешними входными
данными и условиями, которые являются причиной возникновения
экстремальных исходных данных;
■ процесс перехода состояний согласно ожидаемым результатам;
■ надлежащее поведение продукта при напряжении или большой нагрузке;
■ адекватное обнаружение ошибок, их обработка и восстановление.
Наличие схемы, согласно которой прогнозируется совместимость отдельных
элементов, играет решающую для проведения успешного интерфейсного тестирования.
Широко используемый метод для установки соответствия между компонентами и их
интерфейсами представляет собой структурную диаграмму (описанную в главе 22).
/ /
.1*1
/ 71
>
г
/ (
с
/ У
Рис. 23.12. Заглушки, применяемые в процессе тестирования методом
"черного ящика"
Как показано на рис. 23.12, иногда возникает необходимость в применении
заглушек или "холостых команд", либо реагирующих элементов ("внутренних заглушек"),
чтобы сделать возможным проведение тестирования методом "черного ящика".
Исследователи строят скелет программного продукта, чтобы обеспечить возможность

Аттестация и верификация 893
составления оценки всех функций. Реагирующие элементы просто указывают, что
тест находится на пути, ведущем к месту приложения данной способности.
Как только завершилось тестирование отдельных модулей с применением тестов
методом "белого ящика", их можно сгруппировать в подсистемы, которые затем
подвергаются другим видам тестирования.
Разбиение эквивалентности и анализ граничных значений, описанные ниже,
используются во время проведения тестирования методом "белого ящика", но они
зачастую применяются в качестве тестов подсистем, обладающих высокой степенью
эффективности. Особые элементы, которые считаются обособленно
функционирующими как "черные ящики" (нам больше нет надобности знать, что происходит
внутри этих модулей), помещаются в логические группы и подвергаются
тестированию методом "черного ящика". В этой главе будут рассмотрены четыре самых
известных теста этого типа.
Разбиение эквивалентности
Область входных данных программы или подсистемы можно разбить на конечное
число классов эквивалентности. Можно предположить (хотя без полной
уверенности), что тестирование репрезентативного значения каждого класса является
эквивалентным тестированию любого другого значения. Анализ крови — это пример теста
эквивалентности: для многих тестов капля крови из пальца эквивалентна
тестированию любой капли крови в теле. Разбиение эквивалентности — это определение того,
каким образом все возможные состояния ввода можно разбить на значительно
меньшее количество классов эквивалентности.
Разбиение эквивалентности — это полезный метод, который может повысить
результативность тестирования. Суть этого метода в том, что многие состояния ввода
очень похожи друг на друга и отличаются только в нескольких аспектах. Например,
две транзакции по депонированию в банковской программе могут отличаться друг от
друга только суммой депонирования. Если одна из этих транзакций выполняется
хорошо, существует высокая (но не абсолютная!) вероятность того, что точно также
будет функционировать и другая транзакция. Вы можете выполнить группировку или
разбиение эквивалентности пространства входов. Для этого вам нужно выбрать
только одно состояние входа из каждой группы с вероятностью, равной общей
вероятности возникновения всех состояний в данной группе. Это радикально уменьшает
количество состояний входа, среди которых требуется выбирать, и ускоряет процесс
тестирования, поскольку не выполняются те состояния входа, которые, по всей
вероятности, могут выявить новые сбои '. Ниже приведен контрольный список для
выполнения простого разбиения классовой эквивалентности.
1. Разделите любое пространство входных данных по меньшей мере на два класса:
действительные значения и недействительные значения. Убедитесь, что по крайней
мере одно недействительное значение является входным для каждого теста
(зачастую, в качестве входных данных для каждого теста будет использоваться
несколько действительных значений).
2. Если пространство входных данных покрывает восходящую или нисходящую область
значений (например, 2, 3, 4, 5, 6), выделите среди действительных входных значений
первое значение из этой области B), последнее значение из этой области F)
См. сноску 15.

894 Глава 23
и "номинальное" значение из центра этой области C или 4) в качестве входных
значений для данного теста. Выберите среди недействительных входных
значений значение, расположенное внизу (или вверху) от первого значения, которое
выпадает из области действительных значений (скажем, 0), а также значение,
расположенное вверху (внизу) от последнего значения, которое выпадает из
области действительных значений (скажем, 10).
3. Если пространство входных данных покрывает определенное число или перебор
знамений (напр. 2, 4, 12, 17, 19), укажите среди действительных входных значений
минимальное значение B), максимальное значение A9) и номинальное значение A7).
Выберите из недействительных входных значений значение расположенное ниже
заданной области (скажем, 0), выше заданной области (скажем, 25) и значение
в пределах заданной области, но не являющееся членом этой области (скажем, 8).
4. Если пространство входных данных покрывает множество входных значений,
таких как (B, 3, 4, 5), (В, С, D, Е), G3, 106)), выберите из входных значений
действительного подмножества минимальное, максимальное E, Е, 106) и номинальное
значение C, С, 73). Выберите из входных значений недействительного
подмножества значение, расположенные относительно целого множества внизу @, А),
вверху (скажем, 17, Q), в рамках, но не принадлежащее ему значение A00),
значение внизу @) и вверху A10).
5. Если пространство входных данных содержит обязательное значение ("первый
символ должен быть X или Z"), выберите одно действительное множество для
правильных символов (скажем, Zoo — зоопарк), и одно недействительное
множество для представления всех остальных символов (Apple — яблоко).
Анализ граничных значений
Анализ граничных значений отличается от разбиения эквивалентности в двух
аспектах
1. Вместо выбора произвольного элемента в классе эквивалентности в качестве
репрезентативного элемента, при анализе граничных значений требуется выбрать
один или несколько элементов, чтобы каждое крайнее значение класса
эквивалентности было подвержено тестированию.
2. Вместо того чтобы просто сконцентрировать внимание на условиях входа
(пространство входных данных), контрольные случаи также получают путем
рассмотрения пространства результатов (т.е. исходных классов эквивалентности).
Общие принципы выполнения анализа граничных значений перечислены ниже.
1. Если входное условие определяет область значений (т.е. 2, 3, 4, 5, 6), напишите
контрольные случаи для конечных значений данной области B, 6), а также
подберите контрольные случаи недействительных входных значений для ситуаций,
которые возникают сразу же за пределами конечных значений A,7).
2. Если входное условие определяет число значений (т.е. 2, 4, 12, 17, 19), подберите
контрольные случаи для минимального B) и максимального A9) значений, а
также для одного нижнего A) и одного верхнего B0) значения.
3. Используйте руководящий принцип 1 для каждого выходного условия. Если это
возможно, подберите контрольные случаи, которые приведут к значениям,
расположенным вне ожидаемой области. Например, если программа вычисляет

Аттестация и верификация 895
ежемесячные вычеты FICA на минимальную сумму $0,00 и максимальную $3
055,37, напишите контрольные случаи, ведущие к удержаниям на сумму $0.00 и $3
055,37. Также выясните, возможно ли создание таких контрольных примеров,
которые могли бы привести к отрицательному удержанию или к удержаниям на
сумму $0.00, превышающую $3 055,37.
4. Используйте руководящий принцип 1 для каждого выходного условия. Например,
если информационно-поисковая система выводит на экран наиболее релевантные
абстракты на основе входного запроса но ни в коем случае не больше четырех), подберите
контрольные случаи таким образом, чтобы программа вывела на экран ноль, единицу
или четыре абстракта, а также напишите контрольный пример, который мог бы
привести к ошибочному выводу программой на экран пяти абстрактов.
5. Если входные или выходные значения программы представляют собой
упорядоченную последовательность, сосредоточьте внимание на первой и последнем
элементах данного множества .
Интеграционные тесты
Интеграционные тесты также относятся к тестам методом "черного ящика", но
размер "ящиков", как правило, превышает размер только одного элемента. Часто
элементы группируют в компоненты (интегрированные агрегаты) или программы
в совокупности с несколькими подпрограммами или даже подсистемами. В объектно-
ориентированной парадигме несколько объектов, относящихся к данному
тематическому разделу (подсистеме), можно сгруппировать в одно целое и подвергнуть
тестированию методом черного ящика. Затем полученное тематическое группирование
объединяется с другими тематическими группированиями (подсистемами), в
результате чего получают полную систему, которая впоследствии подвергается
интеграционному тестированию (см. рис. 23.13).
Рис. 23.13. Интеграционное тестирование
Boehm Barry и др. Characteristics of Software Quality. Amsterdam: North-Holland;, NY: American
Elsevier, 1978.

896 Глава 23
Структурные диаграммы, описанные в главе 22, также могут пригодиться при
интеграционном тестировании. На этом уровне тестирования исходная структура
пооперационного перечня работ (Work breakdown structure, WBS), созданная на фазе
планирования, может также предоставить информацию о том, каким образом
основные компоненты подсистемы совмещаются друг с другом.
Системные тесты
Системные тесты предполагают помещение системы в среду (см. рис. 23.14), в
которой ожидается ее выполнение, а также поиск всех факторов среды или входных
данных, которые могут вызвать сбой системы (возникновение неожиданной
ответной реакции). Поместить программный продукт в среду означает
продемонстрировать его заказчику. Системное тестирование — это аттестация и верификация всех
системных требований, полученных от заказчика в ходе переговоров с ним о
предстоящем проектировании продукта.
Рис. 23.14. Системное тестирование
Системное тестирование зачастую начинается до того, как будут определены все
компоненты системы. Некоторые из основных функций системы, которые зачастую
также называют "стержневыми", создаются, объединяются и подвергаются
тестированию методом "дымного следа". Зная, что системное тестирование будет и должно
происходить до разработки полной системы, разработчики должны планировать
проведения тестов этого типа. Шаблон подобного плана тестирования можно найти
в приложении F.

Аттестация и верификация 897
Профиль
заказчика
Профиль
пользователя
Одним из методов планирования и системного тестирования является разработка
профилей. Джон Мьюза (John Musa), один из самых известных экспертов в области
тестирования, описывает использование таких профилей в контексте инжиниринга
надежности программного обеспечения .
Операционный профиль
Использование профилей должно начинаться еще на этапе сбора требований.
Разработка профилей начинается с "профиля заказчика", который определяется
отделом сбыта/продажи и выполняется на протяжении всего
процесса выбора сценария фактического тестирования,
используемого для поддержки тестирования методом "черного/
белого ящика". Особенности процесса разработки профилей
изображены на рис. 23.15.
Как показано на рис. 23.15, разработка операционного
профиля для управления системным тестированием
предполагает, по меньшей мере, пять стадий. В табл. 23.2 показаны
относящиеся к операционному профилю фазы, указано
ответственное лицо, ракурс, а также этап разработки проекта,
на котором изначально возникает профиль. Каждый профиль,
предшествующий операционному, разработан с учетом
особенностей его эксплуатации пользователем или заказчиком,
в то время как операционный профиль спроектирован с учетом
системного аспекта, который может рассматриваться как
представление по принципу "изнутри-наружу" относительно того,
каким образом должен функционировать продукт. Используя
операционный профиль как парадигму для системного
тестирования, можно получить сценарии фактического использования,
точные входные данные, предоставляемые пользователем,
точные результативные исходные данные или ответные реакции
системы, внутреннее разбиение пространства обработки, а
также вероятности возникновения подобных сценариев.
Профиль
системного
режима
Функциональный
профиль
Операционный
профиль
Выбор
теста
э
Рис. 23.15.
Операционный профиль
Таблица 23.2. Операционный профиль/ответственность/перспектива/фаза
проекта
Этап Профиль
Ответственность
Перспектива Фаза проекта
1 Заказчик Маркетинг
2 Пользователь Маркетинг/аналитики
3 Системный режим Пользователь/маркетинг
/аналитики
Л Функциональный Пользователь/аналитики
/проектанты
5 Операционный Проектанты/тестеры
Пользователь Сбор требований
Пользователь Сбор требований
Пользователь Сбор требований
Пользователь Анализ требований
Система Проектирование
Musa John D. Software Reliability Engineering: More Reliable Software, Faster Development and Testing.
NY: McGraw-Hill, 1999.

898 Глава 23
Регрессионные тесты
Регрессионное тестирование— это повторное выполнение уже реализованного
ранее подмножества тестов с целью гарантирования того, что последние внесенные
в программный продукт изменения не вызовут непредусмотренные побочные
эффекты. Регрессионные тесты повторяют входное состояние или контрольные случаи,
используемые в системных тестах. Такое повторение необходимо, поскольку системы
весьма редко являются стабильными. Измененный код так же далек от совершенства,
как и только что разработанная программа. Изменения могут неумышленно вызвать
ошибочное функционирование или дополнительные ошибки. Каждый раз при
внесении изменений в ПО проводится ряд регрессионных тестов с целью гарантирования
бесперебойного функционирования (за исключением внесенных изменений).
Как только система начала эксплуатироваться, она может послужить базой для
тестирования дальнейших модификаций. Благодаря регрессионным тестам можно
доказать, что в производственных системах отсутствуют ошибки, допущенные на
этапе сопровождения при модернизации или устранении дефектов. Регрессионное
тестирование выполняется при разработке системы. Сюда включается фиксированный
тестовый стенд известных данных, необходимый для выполнения ограничений
программного продукта ограничений, пороговых величин и правил. При выполнении
комплекта регрессионного тестирования и получении ожидаемых выходных данных,
возрастает степень уверенности в надежности системы. При значительной
модернизации может возникнуть необходимость в модификации самого комплекта
регрессионного тестирования, чтобы правильно и в полном объеме протестировать все
функциональные возможности продукта (как новые, так и старые).
Альфа- и бета-тестирование
Альфа-тестирование, как правило, относится к тому моменту, когда система
запускается в действие первый раз на территории разработчика с целью ее тестирования
пользователем. За тестами практически несомненно последует необходимость
внесения определенных изменений в программирование— возможно, несколько
изменений в проект, но, будем надеяться, никаких изменений в требования.
Бета-тестирование следует за альфа-тестированием и также осуществляется
"благоприятствующими пользователями", но уже на территории заказчика. Заказчики
подтверждают использование продукта посредством его использования в обычных
каждодневных условиях. В этот момент система должна стабилизироваться, но может
возникнуть необходимость во внесении нескольких изменений в программу.
Альфа- и бета-тестирование повысят степень уверенности в продукте и в
надежности его эксплуатации, а также помогут извлечь определенные уроки и
усовершенствовать разработанные системы. Выполнение этих тестов обеспечивает естественный
переход к проведению приемочного испытания пользователем.
Рекс Блэк (Rex Black) сообщает нам о том, что системное тестирование может
начаться при соблюдении следующих условий:
" доступность систем отслеживания тестов/программы;
" все компоненты находятся под официальным административным контролем
относительно конфигурации и выпуска продукта;
" завершена конфигурация целевых аппаратных компонентов и подсистем;
" команда разработчиков поэлементно протестировала все свойства,
предусмотренные графиком выпуска;

Аттестация и верификация 899
" минимальное количество (согласованное службами сбыта, маркетинга и работы с
покупателями) ошибок высокого ранга все еще открыто, и установлена предельная
дата их исправления;
" команда разработчиков завершает тесты методом "дымного следа";
" команда менеджеров проекта соглашается перейти на этап системного
тестирования (соблюдены все условия и критерии входа).
Системное тестирование продолжается до тех пор, пока делаются заметки по
выпуску продукта, все изменения сопровождаются отчетами об ошибках,
незавершенной работы по устранению ошибок (недостатки по качеству) гораздо ниже, чем
минимальный объем ошибок высокого ранга, а на ежедневные и текущие периоды
закрытия требуется меньше двух недель. Системное тестирование завершается при
выполнении следующих условий: за последние три недели не произошло никаких
изменений и аварийных ситуаций; команда разработчиков исправила все ошибки
высокого ранга; команда тестеров закрыла или отложила рассмотрение всех вопросов
в системе отслеживания ошибок, верифицированной регрессивным тестированием;
незамкнутая/замкнутая кривая указывает на стабильность и надежность продукта .
Теперь, когда мы перечислили стандартные тесты и дали им краткое определение,
возвратимся к тестированию методом "белого ящика".
Тестирование методом "белого ящика" с применением
диаграмм Чейпина и ориентированных потоковых графов
Существует много способов описания проекта программного элемента,
позволяющих упростить структурное тестирование. Графический дизайн программы
обычно разрабатывается в результате проведении статической экспертной оценки
перед кодированием.
После одобрения проекта выполняется написание, компиляция, а иногда
инспектирование кода путем выполнения дополнительной экспертной оценки. В этот
момент проект подтверждает, что элемент является модульным, структурным,
восстанавливаемым (устранение ошибок не составляет особого труда), модифицируемым
(внесение изменений не представляет собой трудности), читаемым, а также
указывает на места, где необходимо провести структурное тестирование.
Диаграммы Чейпина, которые также известны под названием диаграмм Несси-
Шнайдермана, были описаны в главе 22. Они представляют собой отличное средство
проектирования, в ходе которого устраняются произвольные переходы контроля,
которые приводят к построению сложного "макаронного" кода, а также
обеспечивается получение представления о том, сколько контрольных промеров необходимо и
где именно их необходимо применить.
Основной принцип заключается в том, что программный элемент могут
образовать только пять базовых конструкций независимо от типа прикладной программы,
и применяемого языка программирования. Эти конструкции могут быть следующими:
простая последовательность, if-then-else, do-while, do-until и do-case.
Рисунок 23.16 — это простой пример того, каким образом структуры
компилируются в проект программы, который можно подвергнуть обзору, на базе которого можно
выполнить кодирование и который можно использовать для составления
контрольных случаев.
" Black Rex. Managingthe Testing Process. Redmond, WA: Microsoft Press, 1999.

900 Глава 23
Получить первую запись из платежной ведомости
Выполнять, пока имеются дополнительные данные для обработки
Установка
дедукции FICA,
равной нулю
Вычисление дедукции FICA
Значение year-to-date FICA плюс дедукция > максимума?
Установка дедукции таким образом,
что показатель year-to-date не превышает максимума
Добавить дедукцию к значению year-to-date FICA
Установить чистый платеж, равным зарплате до вычетов минус FICA-дедукция
Выходное имя, зарплата до вычетов, FICA-дедукция, сообщение year-to-date, чистый платеж
Получить следующую запись платежной ведомости
Рис. 23.16. Пример диаграммы Чейпина, применяемой для локализации тестов
Обратите внимание, что каждый блок имеет одну точку входа и одну точку выхода,
в результате чего в структуре всей программы отсутствует ненужное разветвление
(условный переход или "GOTO"), а также снижается сложность структуры. До тех
пор, пока проект программы следует принципу компоновки из стандартных блоков,
вложенный цикл и символы решения будут вызывать дальнейшее уменьшение блоков.
Для того чтобы обработать "часть" нужного размера, которая затем сформирует один
элемент программы, следует разместить диаграмму Чейпина на одной странице
размером 8x11 дюймов.
У программистов, которые впервые учатся проектировать программы с
применением подобных символов, не вырабатываются плохие привычки, которые могут
возникнуть при работе в других системах обозначений блочно-схематического типа. На
одном листе бумаги можно начертить не более пятнадцати или двадцати символов,
поэтому программист должен придать программе модульный вид. Устраняется
соблазн использовать соединители за пределами страницы, которые приводят только
к путанице. В конечном счете, приятно удивляет простота, с которой можно
преобразовать структурную блок-схему в структурную программу .
Диаграмма, построенная по принципу N-S, может применяться в качестве
руководства при тестировании модуля. Количество контрольных примеров, которые
понадобиться выполнить, можно сразу определить путем подсчета блоков
принятия решений (два блока из расчета на одно решение) и итерационных блоков (два
или три блока на один цикл, в зависимости от граничных условий цикла). Точные
контрольные примеры, которые необходимы, а также требуемые данные можно
Yoder Cornelia М. и Marylirl L. Schrag. "Nassi-Schneiderman Charts: An Alternative to
Flowcharts for Design". White Paper, IBM Corporation, System Products Division, Endi-
coti, NY, 1983.

Аттестация и верификация 901
вывести непосредственно из диаграмм, а тестируемые пути можно отмечать на са-
мих диаграммах в процессе выполнения тестов .
Если модуль усложнен, для него может потребоваться выполнение еще одного
этапа, направленного на уточнение проекта программы. Диаграмма Чейпина,
использованная на рис. 23.16, вполне достаточна для проведения просмотра проекта,
составления документа, на основе которого будет выполняться кодирование, а также
документа, на основе которого будут генерироваться контрольные примеры. Если
сложность реализуется в качестве фактора, тогда более точная диаграмма Чейпина
в большей степени подойдет для выполнения процессов кодирования и
тестирования. Сложность диаграммы, как правило, напрямую связана с рисками,
предполагаемыми при разработке программного продукта, то есть надежность ответственных
систем, требующих безотказного функционирования, в которых на карту поставлены
человеческие жизни, создает необходимость в более высоком уровне сложности.
Направленный потоковый граф: анализ
цикломатической сложности Мак-Кейба
Томас Мак-Кейб (Thomas McCabe) изобрел еще один широко используемый метод
графического отображения проекта модуля, позволяющий установить точки
тестирования. В то время как Несси, Шнайдерман и Чейпин основное внимание уделяли
рассмотрению базовых конструкций, Мак-Кейб рассматривал свои графы как
конструкции, состоящие из ребер (соединительных звеньев) между узлами (выполнимыми
инструкциями или псевдокодом). Подобно Чейпину, Мак-Кейб применяет следующие
конструкции: if-then-else, if-then, do-while, case и repeat-until.
Эти конструкции изображены на рис. 23.17.
Томас Мак-Кейб изобрел метод графического отображения проекта модуля,
благодаря которому устанавливаются точки тестирования. Подобно диаграмме Чейпина,
в методе Мак-Кейба используется пять базовых конструкций, продемонстрированных
в главе 22.
Мак-Кейб называет свой критерий метрическим показателем сложности, который
выполняет функцию определения отображающего сложность значения для
отдельного элемента. Организации могут установить приемлемый пороговый показатель
сложности, оценить уровень сложности каждого элемента и определить самые
сложные из элементов, которые следует подвергнуть дополнительному просмотру и
которым необходимо уделить дополнительное внимание. Например, если организацией
установлено, что метрический показатель сложности для каждого элемента в
определенном проекте с использованием языка Java, должен быть равен 30 (для доступной
поддерживаемой системы Java), и если существует пять сценариев, созданных на
основе языка Java, в которых значение метрического показателя превышает 90, в таком
случае эти пять сценариев можно разбить на меньшие модули, создать для них
больший объем документации или подвергнуть их дополнительным экспертным оценкам.
Метрика, разработанная Мак-Кейбом для всей системы, часто изображается в виде,
похожем на диаграмму Парето, что позволяет построить монотонно возрастающую
гистограмму значений сложности модулей. Это облегчает процесс определения тех
Nassi I. и Ben Schneiderman. "Flowchart Techniques for Structured Programming". SIGPLAN
Notices of Ike ACM, 8(8):12-26, 1973.

902 Глава 23
20% частей системы, которые представляют собой наибольшую сложность и
которые, вероятно, послужат причиной возникновения 80% всех проблем, а также
облегчает введение поправок. Исследования показали, что между сложностью системы и
затратами на сопровождение и модернизацию такой системы существует
взаимосвязь, что обосновывает необходимость потратить время на идентификацию и вне-
сенне поправок .
Последовательное
выполнение
Конструкция
If-Then-Else
Конструкция
If-Then
Конструкция
Do-While
Переключение
Конструкция
Repeat-Until
Рис. 23.17. Конструкции, позаимствованные из теории графов
Хотя метрика установления сложности используется при определении
проблемных областей, она также может пригодиться при построении контрольных
примеров. Чтобы посчитать параметры этого объекта требуется создать потоковый граф.
Как только этот граф построен, становятся очевидными пути, ведущие через
программу. Эти пути обеспечивают информацию о переменных параметрах настройки,
необходимых для их выполнения. В этой главе будет представлена теория потоковых
графов, а также будут обсуждены методы вычисления метрики сложности вручную.
Разумеется, это всего лишь упрощенные примеры. При больших проектах для
выполнения таких вычислительных операций существуют автоматические средства. При
небольших проектах, вручную исследуется, возможно, только небольшое количество
модулей, которые рассматриваются как сложные. Тщательность проведения
тестирования зависит от требований к качеству и надежности системы. Простой потоковый
граф изображен на рис. 23.18.
Существует три способа определения коэффициента или метрического показателя
сложности потокового графа.
McCabc Thomas J. "A Complexity Measure". IEEE Transactions on Software Engineerings SE-
2(-l):308-320, 1976.

Аттестация и верификация 903
1. Ребра — узлы + 2.
2. Количество зон.
3. Предикативные узлы + 1.
Чтобы вычислить этот коэффициент вручную для большой программы,
потребуется немало усилий. К счастью, существуют автоматические средства, которые
вычисляют метрический показатель сложности Мак-Кейба путем анализа
существующего исходного кода.
Метрический показатель сложности не только может пригодиться при
установлении проблемных областей, но также может использоваться при создании
контрольных примеров. Как только потоковый граф создан, очевидными становятся пути,
ведущие через программу, которые предоставляют информацию, необходимую для их
выполнения в тесте.
Ребра — узлы + 2
Количество ребер представлено векторами или стрелками на рис. 23.19. Таких
ребер — 9. К схеме добавляется пунктирная линия, разветвляющаяся назад к началу
программы или узлу входа, поскольку сама структура графа построена по принципу
связующих звеньев. Каждую пару произвольных отдельных вершин соединяет путь.
Другими словами, вход в программу можно возобновить и всегда начать ее с самого
начала. В основной подсчет это десятое ребро не включено.
Применяя процесс Мак-Кейба к рис. 23.19, получаем:
С (сложность) = ребра — узлы + 2
Количество узлов — это количество кругов, то есть 6 (а, Ь, с, d, e, f).
Рис. 23.18. Простой потоковый граф Рис. 23.19. Сложность — узлы и ребра
(МакгКейб)
Число 2 прибавляется потому, что граф размещен на плоскости (в двухмерном
пространстве).
Тогда уровень сложности можно подсчитать по формуле 9 — 6 + 2 =5.
Подсчет ограниченных зон
На рис. 23.20 подсчитываются ограниченные зоны. Зона представляет собой
ограниченную область, которая включает в себя десятый вектор. И опять метрический
показатель сложности равен 5.

904 Глава 23
Рис. 23.20. Сложность — зоны (Мак-Кейб)
Предикативные узлы + 1
Как изображено на рис. 23.21, предикативный узел определяется как узел,
имеющим две ли несколько точек выхода. Сумма (количества точек выхода минус 1) для
каждого предикативного узла, плюс 1, также приводит к получению метрического
показателя сложности. В данном примере узлы а и е— это предикативные узлы, каждый
из которых имеет три точки выхода. Точки выхода минус 1 — получаем значение 2 как
для а. так и с. Таким образом, С =2 + 2 + 1 =5.
f >
Переменные а и е имеют значение 2
С=2+2+1=5
Рис. 23.21. Сложность —предикативные узлы (Мак-Кейб)
Что же предполагают такие расчеты для процесса тестирования? Полученные
данные весьма ценны, поскольку метрический показатель сложности, С, который
можно получить любым из трех возможных способов, указывает на количество
контрольных примеров, которые позволять протестировать все пути, ведущие через
модуль. Все возможные пути, ведущие через модуль, необходимо протестировать для
того, чтобы обнаружить ошибки или неожиданные результаты для сложных модулей
или модулей высокой степени важности (возможно, в тех случаях, когда на карту
поставлена человеческая жизнь, например, в случае наличия управляемого
программным обеспечением медицинского оборудования). Значение С можно получить из
существующего на любом языке кода, или же его можно вычислить на основе
проектного документа, например диаграммы Чейпина или потокового графа.

Аттестация и верификация 905
Проектирование модуля по диаграммам Чейпина или потоковым графам
обеспечивает и некоторые преимущества, которые заключаются в выявлении
неструктурированных модулей. Для неструктурированных элементов значение С можно
вычислить по формуле "ребра — узлы + 2" (это, как правило, высокое число), но их уже
нельзя разместить па плоскости и нельзя оценить методом подсчета зон. На рис. 23.22
изображен неструктурированный потоковый граф. Труд Мак-Кейба основывается на
"необходимом коэффициенте сложности, который разбивает зоны на узлы и ребра,
имеющие одну точку входа и одну точку выхода, на боле крупные абстрактные узлы.
В конечном счете, как следует структурированный модуль можно разбить на один
гигантский узел" '. Такой модуль изображен на рис. 23.23.
На рис. 23.23 изображен структурированный модуль, который является
сложным (С = 20), но необходимый коэффициент сложности (ЕС) = 1. На рис. 23.24
показан модуль меньшего размера с более низким метрическим показателем
сложности (С = 18), с меньшим количеством узлов и ребер, но с высоким необходимым
коэффициентом сложности (ЕС= 17). Понятно, что модуль на рис. 23.24 будет не
только легче полностью протестировать, но и легче модифицировать при исправ
лснии ошибок или модернизации.
Рис. 23.22. Неструктурированная потоковая диаграмма
Если каждый ведущий через программы путь пройти хотя бы раз, можно достичь
определенного уровня качества ПО. Но этим минимальным количеством
независимых путей не исчерпываются все возможные сценарии тестирования. Их
тестирование ни в коем случае не гарантирует и не подтверждает качество программного
продукта, по с его с помощью можно выявить большее количество дефектов и улучшить
качественные характеристики.
McCabe Thomas. "Quality Metrics, Reverse Engineering, Client Server — the Synergy".
Presentation at the Quality Assurance Association of Maryland, Baltimore, MD,
April 19, 1994.

906 Глава 23
Рис. 23.23. Структурированная потоковая диаграмма с ЕС = 1
Рис. 23.24. Неструктурированная
потоковая диаграмма с ЕС > 1
Данные тестирования можно использовать с различными значениями, которые,
которые заставят программу пройти но каждому пути, по меньшей мере, один раз
при условии, что может быть достигнут приемлемый уровень минимальной
гарантии качества.
На рис. 23.18 представлены следующие пути, ведущие через модуль:
a,c,f,a (кратчайший путь)
a,d,c,f,a
a,b,e,f,a
a,b,e,b,e,f,a
a,b,e,a,c,f,a

Аттестация и верификация 907
Объединенные, эти пути известны под названием "базисного набора". Такой
набор можно легко построить путем переключения на предикативные узлы. Во-первых,
следуйте по кратчайшему пути, ведущему через программу. Затем, начиная снизу,
работайте в обратном направлении к ближайшему предикативному узлу и
воспользуйтесь другим выходом. Продолжайте до тех пор, пока не будут выбраны все точки
выхода. И наконец, повторите весь процесс, переключив внимание с управляющей
логики на поток данных.
Теперь внимание переключается с вопроса управляющей логики на поток данных,
то есть именно поведение данных либо предотвращает, либо реализует выполнение
любого отдельного управляющего пути.
Зачастую тяжело или вообще невозможно пройти все пути на 100% во всех
модулях. Если существует множество модулей с большим количеством путей, на
проведенное таким образом тестирование потребуется слишком много времени. К другим
типам тестирования методом прозрачного ящика или структурированного
тестирования, которые выполняют модуль не так жестко, но все же предоставляют некоторую
уверенность в надежности системы, относятся описание утверждений, принятие
решений, условий, решений/условий и множественных условий.
Описание утверждений
Каждое утверждение в модуле выполняется в среде тестирования, по меньшей
мере, один раз.
Ниже приводится краткий пример сегмента псевдокода
IF A AND В
Then GO TO 10
ENDIF
5 X = Y + Z
IF С = 3
Он должен тестироваться следующим образом:
1. (А и В) оцениваются как верные, по меньшей мере, один раз: А = верно, В = верно,
и
2. (А и В) оцениваются как неверные, по меньшей мере, один раз: имеет место одно
из следующих выражений: А = верно, В = неверно или А = неверно, В = верно.
Выбор решений
Описание утверждений является выполненным и каждая ветвь каждого решения
берется, по меньшей мере, один раз.
Этот краткий образец сегмента псевдокода
IF A OR В THEN
X = Y + Z
ELSE
X = U + V
ENDIF

908 Глава 23
Он должен тестироваться следующим образом:
1. (А и В) оцениваются как верные, по меньшей мере, один раз: А = верно, В = верно
или А = верно, В = не верно или А = не верно, В = верно.
2. (А и В) оцениваются как неверные, по меньшей мере, один раз: справедливо одно
из следующих выражений: А = не верно, В = не верно.
Проверка условий
Решения выполняются таким образом, чтобы в каждом условии использовалось
каждое возможное значение по меньшей мере, один раз.
Этот краткий образец сегмента псевдокода
IF A AND В AND С THEN
X = Y + Z
ELSE
X = U + V
ENDIF
должен тестироваться с учетом того, что каждое условие (А,В,С) один раз является
верным и один раз неверным:
А верно один раз и А не верно один раз
В верно один раз и В не верно один раз
С верно один раз и С не верно один раз.
Любой из следующих четверых наборов тестов будет достаточным:
А = верно, В = верно, С = верно
А = не верно, В = не верно, С = не верно
А = верно, В = верно, С = не верно
А = не верно, В = не верно, С = верно
А = верно, В = не верно, С = верно
А = не верно, В = верно, С = не верно
А = верно, В = не верно, С = не верно
А = не верно, В = верно, С = верно
Проверка и принятие решений/условий
Описание условий считается выполненным, и при каждом решении используются
все возможные результаты, по меньшей мере, один раз.
Этот же образец сегмента псевдокода
IF A AND В AND С THEN
X = Y + Z
ELSE
X = U + V
ENDIF
должен тестироваться следующим образом:

Аттестация и верификация 909
1. (А и В и С) оцениваются как верные, по меньшее мере, один раз: А = верно, В =
верно, С = верно
2. (А и В и С) оцениваются как неверные, по меньшее мере, один раз. Имеет место
одно из следующих выражений:
А = верно, В = верно, С = не верно
А = верно, В = не верно, С = верно
А = верно, В = не верно, С = не верно
А = не верно, В = верно, С = верно
А = не верно, В = верно, С = не верно
А = верно, В = не верно, С = верно
А = не верно, В = не верно, С = не верно
Обратите внимание, что в этом простом примере только два теста — А = верно,
В = верно, С = верно и А = не верно, В = не верно, С = не верно — соответствует
описанию утверждений, принятию решений, условиям и принятию условий/решений.
Проверка множественных условий
Принятие решений считается удовлетворительным, и каждое решение
выполняется таким образом, чтобы тестировались все возможные комбинации условий.
Этот же образец сегмента псевдокода
IF A AND В AND С THEN
X = Y + Z
ELSE
X = U + V
ENDIF
должен тестироваться следующим образом:
А = верно, В = верно, С = верно
А = верно, В = верно, С = не верно
А = верно, В = не верно, С = верно
А = верно, В = не верно, С = не верно
А = не верно, В = верно, С = верно
А = не верно, В = верно, С = не верно
А = не верно, В = не верно, С = верно
А = не верно, В = не верно, С = не верно
В итоге предположим, что наш пример имел следующий вид:
IF (A AND В AND С) GO TO 110
X = Y + Z
DO CASE . . .
В табл. 23.3 показано отличие в количестве и типе контрольных примеров,
направленных на достижение разных уровней описания в зависимости от требований
к качеству.

910 Глава 23
Таблица 23.3. Типы тестирования, предназначенные для достижения уровней
приемки
100 IF (A AND В AND С) GO TO 110
X = Y + Z
ПО DO CASE...
Тип описания Указания по достижению описанной
ситуации
Контрольные примеры,
позволяющие реализовать
описанную ситуацию
Утверждение
Условие
Все утверждения выполняются, как
минимум, один раз.
1. Принимается утверждение
2. Как минимум один раз реализуются все
возможные следствия утверждения
Простое условие Условия формулируются на основе всех
возможных значений, как минимум, один раз
Решение/условие 1. Удовлетворены простые условия
2. Условия сформированы по отношению
ко всем возможным значениям, как
минимум, один раз
3. Как минимум, один раз реализуются
все возможные следствия решений
Множественные Удовлетворены условия/решения
^° ° Условия предполагают все возможные
комбинации
А = true, В = true, С = false
1. А = true, В = true, С = true
2. А = true, В = true, С = false
1. А = false, В = true, С = true
2. А = true, В = false, С = false
1. А = true, В = true, С = true
2. А = false, В = false, С = false
1. А = true, В = true, С = true
2. А = true, В = true, С = false.
3. А = true, В = false, С = true.
4. А = true, В = false, С = false
5. А = false, В = true, С = true
6. А = false, В = true, С = false
7. А = false, В = false, С = true
8. А = false, В = false, С = false
Приемочное испытание пользователем
и тестирование практической пригодности
Приемочное испытание пользователем (User acceptance testing, UAT), которое
считается самым последним этапом, предшествующим выпуску конечного продукта,
используется в процессе разработки уже много лет. Иногда оно становится синонимом
бета-тестирования, которое также проводится на территории пользователя. Процесс
UAT затрагивает широкую аудиторию пользователей, позволяя команде
разработчиков наладить обратную связь, благодаря чему они получают информацию о том, на
самом ли деле данная система соответствует ожиданиям пользователей и с какой
готовностью пользователи признают это.

Аттестация и верификация 911
Тестирование практической пригодности, которое зачастую предшествует UAT,
представляет собой действительно новое понятие. Впервые оно было введено как
официальная процедура в конце 80-х и начало широко использоваться в средине 90-х
годов прошлого столетия. Тестирование практической пригодности, как правило,
проводится в лаборатории, в которой пользователи выполняют стандартные тесты, а
специалисты в этой области записывают результаты наблюдений. Это метод,
основанный на технологии, при которой создаются видеоизображения прикладной
программы, подвергаемой оценочной процедуре. Пользователи также обеспечивают
обратную связь в форме рейтингов удовлетворенности и комментариев/предложений,
которые регистрируются в формуляре составления оценки.
Один из самых трудных аспектов тестирования практической пригодности
заключается в ответе на вопрос о том, каким образом следует определить и оценить понятие
"практической пригодности". Приемлемое определение заключается в следующем:
пользователь должен воспринимать прикладную программу с легкостью, быстро и с
удовольствием. Легкость обозначает простоту при обучении и использовании; быстрота означает,
что у пользователей не возникает ощущение, что они теряют время попусту, ожидая от
программы ответа. Что касается приятности, то ее можно представить следующим
образом: если какой-либо инструмент возникает попутно или вызывает чувство
разочарования, тогда опыт его использования не очень приятен. Даже если ПО имеет
множество характеристик высокого качества, низкий уровень практичной пригодности
поставит его под сомнение. Аналогичным образом, ПО с низкими показателями практичности
снижает продуктивность работы пользователя и провоцирует допущение им ошибок.
Разумеется, мы не можем просто сказать: "ПО должно иметь высокие показатели
практичности", поскольку такое требование не является тестируемым. Если мы
конкретизируем этот термин, чтобы знать, что и как тестировать, атрибуты, которые превращают
ПО в "пригодное на практике" представляют собой следующее: пользователи чувствуют,
что их действия естественны; процесс диалога наглядный и быстрый, обеспечивающий
адекватную обратную связь; отображение содержимого на экране и организация
хорошо спланированы, включая внимание, проявленное к компоновке и названиям в меню; а
пользовательская документация без труда доступна и тщательно разработана.
Следующий этап в тестировании практической пригодности заключается в определении еще
больше конкретизированных целей. Термин быстрый в приведенном выше
качественном описании может предполагать следующее: "среднее время, требуемое
пользователям на завершение <название задачи>, не должно превышать 30 секунд".
Как только цели определены, разрабатываются тесты практической
пригодности — сценарии тестирования, которыми должны руководствоваться пользователи.
Для проведения систематического исследования взаимодействия человека с
компьютером подготавливается испытательная лаборатория. В ней есть секция для
тестирования, в которой находятся пользователи, секция управления для специалистов-
практиков, которые могут смешивать видеоизбражения, полученные из различных
источников, а также секция для наблюдений, в которой специалисты-практики и,
возможно, другие наблюдатели, например, члены команды разработчиков,
наблюдают за ходом тестирования, как правило, через поляризованное стекло.
Требования практической пригодности
Некоторые требования практической пригодности, на которых выполняющая
тестирование команда, возможно захочет акцентировать внимание, могут быть
сформулированы следующим образом:

912 Глава 23
■ поддержка осведомленности пользователей о ходе процесса тестирования с
помощью использования соответствующей и своевременной обратной связи;
■ беседа на знакомом пользователям языке;
■ обеспечение способа выхода из нежелательного состояния, достигнутого
ошибочно; поддерживать действия по аннулированию и повторному выполнению;
■ исключение отображения на экране редко используемыми функциями;
■ руководствоваться соглашениями относительно названий для операционной
системы, выполняемой на данной платформе;
■ отображение объектов, действий и опций;
■ проектирование диалоговых окон, обеспечение их практичности и простоты выбора;
■ разработка инструкции по использованию видимой или легко восстанавливаемой
системы;
■ адаптация часто повторяющиеся действия с помощью "акселераторов" для
квалифицированного пользователя;
■ лаконичность всех диалогов;
■ сообщения об ошибках на понятном языке, отсутствие кодов, которые ничего не
значат для пользователей;
■ при возникновении проблемы конструктивные предложения по ее решению.
Обратная связь с пользователями
Следующие утверждения иллюстрируют реальную обратную связь,
поддерживаемую пользователями при оценке практической пригодности продукта.
■ "Когда тестовое приложение дает сбой, появляется красное окошко, требующее
закрытия программы для продолжения функционирования системы. В этом окне в
верхнем правом углу отображается лишь значок закрытия программы.
Следовательно, я закрываю окно, но не успел я передвинуть курсор, как открывается еще
одно окно такого же типа, поэтому в этот раз я должен закрыть и это окно. Я
пришел к выводу, что единственный способ продолжить работу с программой —
применить функцию "мертвой хватки" (Ctrl-Alt-Del)."
■ "Пожалуйста, расскажите, для чего это все предназначено! Установите стандарт,
согласно которому сведения о программе указываются в справочной системе и в
разделе О программе... Здесь всегда дается множество инструкций о том, каким образом
следует установить ПО, и иногда адекватные инструкции по его использованию,
но практически всегда отсутствует описание того, что собой представляет то или
иное действие и почему оно может тебе помочь в данной ситуации".
■ "Недавно выпущенная версия прикладной программы имеет намного больше
функций. Однако создается впечатление, что более новые функции просто
прикрепили к предыдущей версии программы не задумываясь над растущей
путаницей, которая в результате возникает в пользовательском интерфейсе".
О том, как предотвратить негативную реакцию пользователя, написано немало
книг. Большинство из них перечислено в конце главы.
Тестирование практической пригодности прекрасно подходит при разработке
ПО методом прототипирования (описан в главе 4). Этот метод способствует началу

Аттестация и верификация 913
тестирования на довольно ранних фазах жизненного цикла. Это позволяет
обнаружить и исправить проблемы задолго до наступления фаз системного тестирования
или приемочного испытания пользователем UAT.
Выполнение идеального тестирования
Если в программном проекте представляется возможным выполнить процесс V&V,
тогда можно достичь гарантии качества всех технических характеристик. Это
означает, что каждую из этих характеристик можно определить в плане тестируемости и
измеримости (что, как мы убедились, представляет собой непростую задачу).
Таблица 23.4. Характеристики качества ПО
Характеристики ка-
Стандарт Стандарт
ISO/IEC 9126-1991 IEEE 1061-1992
FURPSI(Kpaniep
[1999]/Грэйди[1992])
X
Эффе ктивность
Поведение во времени X
Использование ресурсов X
Функциональные
свойства
Точность X
Адекватность
Совместимость
Завершенность
Одобрение
Корректность
Возможность настройки
Способность к развитию
Расширяемость
Взаимодействие между
операциями
Безопасность
Приемлемость
Цена/удовлетворение
Способность к
интеграции
Применимость
Совместимость
Способность к развитию
Способность к
выражению
11нтегрирование
X (экономия времени)
X (экономия ресурсов)
X
X
X
X
X
X
X
X
X
X
X
X
X

914 Глава 23
Характеристики ка- Стандарт
честна ISO/IEC 9126-1991
Способность к
интеграции
Открытость
Качество составных
частей
Включение требований
Специальные темы
Способность к
сопровождению
Возможность анализа X
Изменяемость X
Способность к коррекции
Расширяемость
Стабильность X
Тестируемость X
Выполнение
Ограничение по времени
Ограничение по ресурсам
Переносимость
Способность к адаптации X
Способность к установке X
Приспосабливаемость X
Независимость от
аппаратуры
Независимость от ПО
Повторное применение
Способность к переме- X
щению
Надежность
Доступность
Частота сбоев X
Устойчивость к сбоям X
Зрелость
Отсутствие дефектов
Восстанавливаемость X
Продолжение табл. 23.4
Стандарт FURPSI (Крашер
IEEE 1061-1992 [1999]/Грэйди[1992])
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X X
X X
X
X
X

Аттестация и верификация 915
Окончание табл. 23.4
Характеристики ка- Стандарт Стандарт FURPSI (Крашер
чества ISO/IEC 9126-1991 IEEE 1061-1992 [1999]/Грэйди [1992])
Возможность
поддержки
Поддержка X
Повторное применение X
Отклики на поддержку X
Тестируемость X
Применяемость
Доступность для пони- XX X
мания
Возможность изучения XX X (простота изучения
и применения)
Способность к коммуни- X X
кациям
Способность к выпол- XX X (простота опериро-
нению операций вания)
Рассматриваемые факторы качества, которые мы хотели бы протестировать,
представляя их как жестко установленные требования, включают в себя ISO 9126,
Стандарт IEEE 1061 и FURPS (Functionality, Usability, Reliability, Performance,
Supportability и Integratability — функциональность, практическая пригодность,
надежность, рабочая характеристика, возможность поддержки и
интегрируемость), разработанные Робертом Грейди (Grady) и позже расширенные Крейснером
(Krasner) в аббревиатуру FURPSI (была добавлена интегрируемость). По существу
они основаны на модели качества, разработанной в 1977 году Мак Коллом (McCall) ',
которая была построена на основе трех типов качественных характеристик:
■ факторы (для определения) — они описывают внешний вид ПО с точки зрения
пользователей;
■ критерии (для построения) — они описывают внутренний вид ПО с точки зрения
разработчика;
■ метрические показатели (для управления) — они определяются и используются с
целью обеспечения шкалы и метода измерения.
С ростом потребности иметь одну признанную стандартную модель качества,
многие начали отдавать предпочтение стандарту ISO/IEC 9126. Подобно модели Мак
Колла, этот стандарт основан на трех уровнях:
27 Grady Robert. Practical Software Metrics for Project Management and Process Improvement, NY:
Prentice Hall, 1992.
28 Krasher Herb. "Implementing Software Quality", Session 32, Software Project Management
Certificate Program Sequence XI, Software Quality Institute, The University of Texas at Austin, 2001.
29 McCall James А. и др. "Metrics for Software Quality Evaluation and Prediction", Proceedings of
Second Summer Software Engineering Workshop, Greenbelt, Maryland, September 19, 1977.

916 Глава 23
■ характеристики (функциональность, надежность, практическая пригодность,
эффективность, способность к поддержке, переносимость);
■ подразделы характеристик;
■ метрические показатели.
Каждая характеристика уточняется в подразделах характеристик, а каждый
подраздел оценивается по совокупности метрических показателей. Хэлстэд (Halstead)'
и Мак Кейб также сделали свой вклад в разработки по оценке ПО, и многие из
метрических показателей, используемых для анализа кода, берут свое начало из
проведенных ими исследований.
Ниже приведены примеры подразделов характеристик и соответствующих
метрических показателей.
■ Возможность анализа— значение цикломатической сложности, определяющее
количество утверждений; коэффициент комментариев; количество вызовов.
■ Изменяемость — количество алгоритмов GOTO; количество уровней факторов,
сгруппированных внутри уровней другого фактора; средний размер утверждения;
количество переменных.
■ Стабильность — количество параметров, на которые устанавливается ссылка;
количество глобальных переменных; количество измененных параметров;
количество вызванных взаимосвязей
■ Способность к тестированию — количество нециклических путей; количество
уровней факторов, сгруппированных внутри уровней другого фактора;
коэффициент цикломатической сложности; количество путей вызова модулей.
Исследование, выполненное Шейфером (Shafer) и Коннеллом (Connell) в
национальной лаборатории г. Лос-Аламоса, показало, что сложность программы имеет
непосредственно отношение к высоким эксплутационным расходам и что самые
дорогостоящие характеристики, определяющие сложность, включают алгоритмы GOTO,
количество вызовов, не несущие никакого смысла имена переменных .
В результате выполнения проекта под названием "Программа по оценке и
сертификации ПО в Европе" ("Software Assessment and Certification Programme in Europe"
или SCOPE) был определен процесс оценки, составляющие которого были использо-
в;шы в стандарте ISO 14598. Были отобраны уровни оценки рисков, связанных с ПО,
но четырем основным типам: уровень D (небольшие имущественные убытки,
отсутствует риск для людей); уровень С (имущественные убытки, несколько человек
покалечено); и уровень А (погибло много людей). С увеличением степени риска в результате
несоответствия продукта качественной характеристике, выбирается более жесткий
уровень. Уровни выбираются независимо для каждой релевантной качественной
характеристики, а также демонстрируют, какие механизмы тестирования можно
применить для каждой их этих характеристик. В табл. 23.5 приведено множество
методов, о которых следует знать менеджеру проекта, но существует еще много других
методов, тип которых жестко определен' .
" Halslcad Maurice II. Elements ofSoftware Science. NY: Elsevier, 1977.
Shafer L. and John Connell. "Deriving Metrics for Relating Complexity Measures to Software
Maintenance Costs". Proceedings of the 1982 Computer Measurement Group International Conference, cc. 134-
141, 1982.
4 Barhc Richard and Gvialteiro Bazzana. Software Metrics for Product Assessment. NY: McGraw-Hill, 1994.

Аттестация и верификация 917
Таблица 23.5. Эволюция SCOPE

Функциональность

Надежность

Полезность

Эффективность

Способность к
поддержке

Переносимость
Уровень D
Функциональное
тестирование
("черный ящик")
Средства языка
программирования
Инспекция
интерфейса пользователя
Измерение
времени выполнения
Инспекция
документов
(контрольные списки)
Анализ установки
Уровень С
Обзор
(контрольные списки)
Анализ
устойчивости к сбоям
Адаптация к
стандартам интерфейса
Тестирование по
контрольным
точкам
Статический
анализ
Адаптация к
правилам
программирования
Уровень В
Покомпонентное
тестирование
("белый ящик")
Модель роста
надежности
Лабораторное
тестирование
Алгоритмическая
сложность
Анализ процесса
разработки
Оценивание
ограничений
среды
Уровень А
Формальная
проверка
Формальная
проверка
Ментальная
пользовательская
модель
Анализ
производственных
профилей
Оценивание
трассировки
Оценивание
проекта программы
В идеальном мире можно выполнять все тесты. В реальном мире менеджер
проекта должен отобрать среди них самые подходящие, то есть провести "разумное
тести ро ван ие".
Процесс тестирования
Тестирование должно начинаться только тогда, когда выполнены определенные
действия и для реализации тестирования заложен определенный фундамент.
Подготовка к тестированию
Приведенные ниже аспекты являются индикаторами готовности начала
тестирования.
■ Требования (SRS), функциональный проект (SDD) и спецификации
внутреннего проекта (диаграммы Чейпина, потоковые графы) завершены,
утверждены и доступны.
■ Требования к бюджету и графику оглашены; заданы предположения относительно
выполнения графика, временные шкалы и контрольные точки.
■ План тестирования написан, просмотрен и утвержден.
■ Стандарты и процессы (такие как процессы выпуска и внесения изменений)
задокументированы.
■ Работающая над проектом команда укомплектована, ответственность членов
команды определена, а также завершено их обучение, в результате чего
обеспечивается соблюдение стандартов и процессов.
■ Определены связанные с высокой степенью риска аспекты системы.
■ Осознаны приоритеты, рамки и ограничения тестов.

918 Глава 23
■ Установлены принципы и методы тестирования, а именно: каким образом будет
производиться тестирование, кем и когда — для поэлементного (методом "белого
ящика"), интеграционного (методом "черного ящика"), функционального,
системного тестирования, а также тестирования практической пригодности, и т.д.
■ Удовлетворены требования к среде тестирования (аппаратное обеспечение,
операционные системы, конфигурационный менеджмент, каналы передачи, и т.д.)
■ Определены требования к ПО (т.е. анализаторы рабочей зоны, отслеживание
проблем, инструментальные средства записи/воспроизведения).
■ Определены входные данные тестирования; получены входные данные
тестирования.
■ Определены входные классы эквивалентности, анализ граничных значений и
классы ошибок.
■ Написаны, проверены и утверждены контрольные случаи.
При подготовке к проведению динамического тестирования может
использоваться статическое тестирование (обзоры). Например, процедура тестирования ПО
может подвергаться обзору, реализуемому с помощью следующих вопросов, которые
формируют контрольный список.
■ Были ли определены тесты методом "белого и черного ящиков"?
■ Было ли выполнено тестирование всех независимых логических путей?
■ Были ли установлены контрольные примеры и перечислены с ожидаемыми от их
проведения результатами?
■ Необходимо ли подвергнуть тестированию обработку ошибок?
■ Необходимо ли подвергнуть тестированию граничные значения?
■ Необходимо ли подвергнуть тестированию синхронизацию и рабочую
характеристику?
■ Была ли определена степень приемлемого отклонения от ожидаемых результатов?
Тестирование
На протяжении собственно процесса тестирования выполняются тесты,
оцениваются и оглашаются полученные результаты, осуществляется отслеживание
контрольных примеров, дефектов и отладок, а также управление ими, составляется
характеристика выявленных дефектов и выполняется их изоляция, утверждается
документация (планы тестирования, контрольные случаи, среда тестирования, ПО для
проведения тестирования). Устанавливается график выполнение тестирования и
выпуска продукта, документируются процессы для установки новой конструкции и
удаления неверной конструкции.
Когда в процессе тестирования обнаруживается какой-либо дефект, начинается
отладочный процесс. Определенная в результате тестирования проблема должна
быть зарегистрирована и передана (назначена) разработчикам, чтобы ее можно было
удалить из ПО. Разработчик определяет местонахождение проблемы, изолирует ее,
находит ей разрешение и предоставляет ее на рассмотрение команде испытателей
с целью проведения повторного тестирования. Повторное тестирование позволяет
исключить вероятность того, что обнаруженная ошибка вызывает возникновение
проблемы в какой-нибудь другой части программного продукта. (Не забывайте, что

Аттестация и верификация 919
низкая связность и высокое сцепление уменьшают волновой эффект или так
называемый "эффект домино".)
На каждом этапе должно быть организовано внимательное ведение учетных
записей с помощью системы отчетности проблем.
Зарегистрированная информация, как правило, включает данные о том, когда был
обнаружен дефект, где и как он был обнаружен (при выполнении какого
контрольного примера) и каким образом его можно воспроизвести. Степень серьезности дефекта
регистрируется испытателем. Эти данные, как правило, записываются в
автоматической системе отслеживания дефектов и включают в себя следующие компоненты:
идентификатор; статус (недавно обнаруженный дефект, выпущенный для повторного
тестирования, и т.д.); имя, идентификатор и версия системы/приложения;
подсистема/модуль, в котором была обнаружена проблема; описание окружения; имя, номер
и идентификатор контрольного примера; полное описание; способ его
воспроизведения; дополнительная информация, которая может помочь разработчику, например
снимки экрана и сообщения об ошибке; оценка степени сложности; а также имя
испытателя, данные тестирования и отчетные сведения.
Заключительное тестирование
Информация, зарегистрированная при разрешении проблемы, включает в себя
имя разработчика, причину проблемы, описание отладки, компонент системы, в
который были внесены изменения, данные и версию системы.
Сведения, зарегистрированная при повторном тестировании проблемы, включает
в себя имя исследователя, данные повторного тестирования, результаты повторного
тестирования, регрессионные тесты и результаты регрессионного тестирования.
Команды тестеров
Организация тестирования — это еще одна область, в которой менеджер
программного проекта должен принимать решения. Некоторые эксперты настаивают на
том, что функции IV&V должна выполнять независимая группа тестеров, в состав
которой включены сотрудники. Другие считают, что тестеры должны включаться в
команду разработчиков проекта.
При выборе модели организации тестирования можно воспользоваться методом,
основанном на навыках. Этот метод предполагает, что имеющий особые навыки
тестер работает под руководством менеджера по тестированию, который назначает его
на выполнение одного или нескольких проектов в матричной организации. Такой
подход имеет свое преимущество, т.к. тестер имеет возможность стать настоящим
специалистом в одной области и применяет полученный опыт при выполнении всех
проектов. Недостатки этого подхода заключаются в том, что испытатель может быть
неуверен, где именно ему нужно приложить усилия, а менеджеры проекта будут
волноваться по поводу получения "своей доли" ресурса.
Еще в одной организационной модели для выполнения каждого проекта
назначается своя команда тестеров. Этот подход позволяет тестерам совместно работать над
версией продукта. В плане построения команды это самый оптимальный выбор.
Потенциальный риск, связанный с применением основанной на проекте модели,
заключается в том, что тестеры могут слишком приблизиться к разработчикам и уступить
компромиссным жестким принципам тестирования.
Существует даже анекдот о команде тестеров компании IBM, которая приобрела
известность как "Черная команда", поскольку они носили кепки черного цвета,

920 Глава 23
отращивали усы (которые лихо закручивали) и наслаждались своей репутацией
злостных разрушителей программ. От всего этого они очень веселились, но
конкуренция между ними и разработчиками благоприятно сказывалась на качественных
характеристиках проекта. Разработчики стремились создать продукт, который
"Черная команда" не смогла бы "взломать", а команда была нацелена на поддержание
своего статуса. Было бы прекрасно, если бы все команды смогли превратиться в
такие "исполнительные" группы.
Несомненно, совместное видение предстоящей работы — это основа построения
команды.
При выборе специалистов-тестеров менеджер проекта должен определять
наличие следующих характеристик: базовые навыки в проведении тестирования,
внимательность к деталям, любознательный склад ума. Менеджер проекта поступит
правильно, если будет руководствоваться принципом, согласно которому удачное
тестирование — это такое тестирование, которое приводит к обнаружению
дефекта, причем это никого не разочаровывает и не вызывает раздражения по
отношению к "вестнику" таких новостей. Неисправности, которые не удалось ранее
обнаружить, все еще находятся в безопасном окружении и действительно являются
"хорошими новостями" в том отношении, что они еще не успели попасть к заказчику.
Тестовая документация
В этой главе были рассмотрены примеры широко используемых методов
проведения тестирования. Также могут выполняться и другие типы тестирования, включая
определение причин и следствий, угадывание ошибок, преобразование,
безопасность, восстановление, определение рабочих характеристик (под нагрузкой), и
многое другое. Все элементы тестирования также являются элементами конфигурации,
управление которыми должно осуществляться под конфигурационным контролем.
I Ьшример. контрольные случаи для регрессионного тестирования необходимо
архивировать вместе с версией программы, которая предназначена для тестирования.
Кроме того, должен существовать полный набор тестовой документации, которая
должна поддерживаться синхронно с программным обеспечением. Каким же образом
выполняются тесты? Где они хранятся? Каким образом задается тестовое окружение?
Институтом IEEE предложены стандарты для составления документации по
тестированию ПО, согласно которым основные документы должны включать в себя следую-
щую информацию .
■ План тестирования, в котором указаны рамки, подход, ресурсы и график процесса
тестирования, направленный на установление подлежащих тестированию
элементов, свойств, предназначенных для выполнения задач тестирования,
персонала, несущего ответственность за выполнение каждой задачи, а также рисков,
связанных с данным планом.
■ Спецификация проекта тестирования с целью определения деталей метода
тестирования и установления свойств, которые необходимо протестировать в рамках
проекта и связанных с ним задач.
■ Спецификация контрольного случая.
" IEEE 829-1983, "IEEE Standard for Software Test Documentation". NY: The Institute of Electri-
< ;il and Electronics Engineers, 1983.

Аттестация и верификация 921
■ Спецификация процедуры тестирования с целью определения шагов, которые
необходимо предпринять для выполнения набора контрольных примеров или, более
обобщенно, шаги, используемые для анализа программного элемента с целью
составления оценки набора свойств.
■ Отчет о передаче элементов тестирования с целью установления передаваемых
для тестирования элементов.
■ Журнал тестирования для регистрации в хронологическом порядке релевантных
деталей о выполнении тестов.
■ Отчет происшествий во время тестирования для фиксации любого события,
которое происходит на протяжении всего процесса тестирования и которое требует
научного исследования.
■ Отчет о результатах тестирования для подведения итогов и обеспечения
оценочного анализа.
Динамическое тестирование: оценка,
составление отчетов и принятие решений
Некоторые из отчетов, которые предоставляются менеджеру программного
проекта на фазе тестирования, включают следующее:
■ еженедельные коэффициенты обнаружения и закрытия дефектов,
нормированные по отношению к уровню выполненной работы (Обнаруживаются ли сбои и
могут ли разработчики справляться с количеством обнаруженных ошибок и
дефектов, требующих исправления?);
■ количество запланированных, проведенных и выполненных еженедельно тестов
(Знаем ли мы, что именно нужно подвергнуть тестированию, и можем ли мы это
сделать?);
■ дефекты, обнаруженные при выполнении каждого действия процесса
тестирования, по сравнению с общим количеством обнаруженных дефектов (В результате
каких действий было обнаружено наибольшее количество дефектов?);
■ оценки относительно соблюдения графика по отношению к реальным фактам
(удастся ли нам соблюсти отмеченные в графике даты, и насколько результативны
наши предварительные подсчеты?);
■ понедельное или помесячное планирование задействованных к проекте лиц по
отношению к реальной ситуации (Если ли у нас нужные люди тогда, когда они нам
действительно нужны?);
■ существенные и незначительные изменения в требованиях (Знаем ли мы, что мы
должны сделать, и подвержены ли такие целевые задачи изменениям?).
На ходе тестирования менеджер проекта должен принять пару особенно
жестких решений: как поступать, если на проведение тщательного тестирования
времени недостаточно, и каким образом можно узнать о том, когда следует прекратить
тестирование.
Кажется, что на выполнение тестирование с желаемой тщательностью времени
никогда не хватает. Возвращаясь к понятию "разумного, а не усердного
тестирования", можно сказать, что моменты, в которых следует продлить время тестирования,

922 Глава 23
можно наилучшим образом определить с помощью анализа рисков. Менеджер
проекта принимает во внимание то, какая функциональная характеристика является самой
важной для достижения поставленной цели проекта, обладает самой высокой
степенью очевидности для пользователя, оказывает самое большое влияние на
безопасность, а также наиболее ощутимо воздействует на пользователей в финансовом
отношении. Должны присутствовать все аспекты прикладной программы, которые
можно протестировать в начале цикла разработки с помощью применения прототи-
пирования, просмотров или тестирования практической пригодности. Основное
внимание должно быть сфокусировано на тех частях системы, которые имеют самую
высокую степень сложности (имеют самые сложные интерфейсы или алгоритмы).
Если какие-либо части системы были разработаны в спешке, существует вероятность
того, что в них были допущены ошибки, и их необходимо подвергнуть тестированию.
Опираясь на анализ по методу диаграмм Парето предыдущих проектов,
сосредоточьте тестирование на проблемных областях. В соответствии с журналами учета
ремонтных работ (необходимости внесения изменений), необходимо установить, на
текущий ремонт каких аспектов аналогичных или имеющих отношение к данному случаю
проектов потребовались большие расходы, а затем сосредоточить внимание на этих
областях. Попросите разработчиков высказать свое мнение по поводу возможных
областей с высокой степенью риска. Используйте тесты, которые результативны
вдвойне, благодаря возможности проверки нескольких функциональных характеристик.
Определить момент, когда следует прекратить тестирование, может оказаться
нелегким. Разумеется, принятие такого решения может основываться на установленных ,
предельных сроках или исходя из выделенного на тестирование бюджета. Но
тестирование лучше всего прекратить лишь тогда, когда достигнуты стандарты
надежности, функциональности и качества.
Метрические показатели тестирования
Как обсуждалось в главе 21, оценочный анализ ПО— это ключ к отслеживанию и
управлению для руководства проекта. Ниже приведены некоторые данные, в
отслеживании которых, скорее всего, будет заинтересован менеджер проекта.
■ Сколько дефектов было обнаружено на каждом этапе?
■ К каким тинам относятся эти дефекты? Каковы ошибки?
■ Какое количество отчетов об обнаруженных дефектов было открыто по
отношению к количеству закрытых? Кумулятивная открытая кривая выравнивается, а
кумулятивная закрытая кривая стремится к кумулятивной открытой кривой в
процессе стабилизации тестируемой системы, система тестирования обнаруживает
опознаваемые дефекты, и качественный "пробел" закрывается.
■ Что было обнаружено о допущенных дефектах в результате анализа основных
причин? Что вызвало их появление, и каким образом можно изменить процесс?
Когда в результате тестирования не достигаются намеченные цели, проблема может
заключаться в самом тесте, а не в ПО. Обзоры планов тестирования, контрольных
примеров и сценариев тестирования также важны в качестве обзоров проектных документов.
Как и в случае результатов обзора, информация тестирования собирается в ходе
выполнения самого процесса. Регистрируются степени серьезности и первосте-
пенности, точно так же, как это происходит для ошибок и дефектов, обнаруженных )
в процессе обзора. |

Аттестация и верификация 923
Понятие степени серьезности означает влияние, оказываемое на тестируемую
систему. Ниже приведен характерный пронумерованный набор данных для
определения степени серьезности:
1. потеря данных, повреждения аппаратного обеспечения и угроза безопасности;
2. потеря функциональности в случае "очистки программы" с целью максимального
устранения недостатков;
3. потеря функциональности с "очисткой программы";
4. частичная потеря функций или набора функциональных возможностей;
5. "косметическая" ошибка.
Первостепенное внимание уделяется маркетинговой важности, такой как потеря
дохода. Ниже приведен характерный пронумерованный набор данных для
определения степени первостепенности:
1. система, неиспользуемая на практике/не пользующаяся спросом;
2. существенное влияние на возможность продажи, ремонтопригодность;
3. дата выпуска может быть важнее, чем срок устранения;
4. дата выпуска важнее, чем срок устранения;
5. устранение ошибок осуществляется по возможности.
Решения, связанные с необходимостью
проведения тестирования
Зачастую менеджер проекта принимает решение о том, превышает ли риск,
связанный с исправлением дефекта, риск его доставки конечному пользователю. При
этом возникают следующие вопросы.
■ Что подразумевает исправление дефекта в плане тестирования? Нужно ли данный
дефект изолировать и произвести его исправление отдельно?
■ Сколько затрат повлечет за собой одно исправление? Какие затраты понадобятся
на его тестирование?
■ Доступны ли для осуществления этого процесса необходимые ресурсы?
■ Какие регрессионные тесты будет необходимо провести повторно, и сколько
времени на это понадобится?
■ Возникнет ли необходимость в написании каких-либо новых тестов?
■ Какой коэффициент достижения успеха при исправлении дефектов существует в
данной системе (подсистеме)?
Объектно-ориентированное тестирование
В главе 4 уже рассматривалось, каким образом выполняется большинство
проектов прототипирования и объектно-ориентированных проектов в соответствии с
жизненным циклом, который достаточно отличается от водопадной модели. В главе
22 мы рассмотрели методы объектно-ориентированного моделирования, которые
отличаются от более традиционных методов структурного анализа/разработки
проекта. Это влечет за собой только то, что при таких отличиях тестирование будет также
предполагать другие характеристики.

924 Глава 23
С традиционной точки зрения наименьший контролепригодный элемент— это
элемент или модуль, который можно протестировать методом "белого ящика". При
объектно-ориентированном тестировании этот функциональный элемент не
отделяется от своего класса, в котором он инкапсулирован со своими методами. Это
означает, что поэлементное тестирование по существу заменяется классовым
тестированием. Однако мы не отклоняемся слишком далеко от наших корневых принципов
относительно того, что каждый метод класса объектов (операция или служба) можно
рассматривать как "небольшой элемент", тестирование которого можно выполнять
обособленно, перед тестовыми последовательностями, применяя для этого методы
"белого и черного ящика". В отдельных классах объектов могут также продолжать
использоваться принципы метода "черного ящика".
Классы объектов необходимо протестировать во всех возможных состояниях. Это
означает, что необходимо сымитировать все события, вызывающие изменения
состояния объекта.
В традиционном отношении элементы компилируются в подсистемы и
подвергаются интеграционным тестам. При объектно-ориентированном подходе не
применяется тестирование структурной схемы сверху вниз, поскольку мы никогда точно не
.«наем, "кто именно контролирует" или какой класс будет вызван пользователем за
слсдуюгцим. Интеграционные тесты заменяются тестированием функциональных
возможностей, при котором тестируется набор классов, которые должны
реагировать на один входной сигнал или системное событие, или же эксплуатационным
тестированием, при котором описывается один способ применения системы,
основанный на сценариях случаев эксплуатации.
Тестирование взаимодействия объектов следует по путям "сообщения метода" с
целью отследить последовательность взаимодействий объектов, которая
заканчивается только тогда, когда был вызван последний объект (при этом не посылается
сообщение и не вызываются службы любого другого объекта.)
Системное, альфа-, бета-тестирование, тестирование практической пригодности и
приемочное испытание пользователем изменяются незначительно, поскольку
объектно-ориентированная система проходит эксплуатационные тесты точно также, как
и разработанные традиционным способом системы. Это означает, что процесс V&V
но существу не изменяется.
Сводка по динамическому тестированию
Управление процессом тестирования включает в себя предварительную оценку
объема тестирования, трассировку дефектов, оглашение результатов, формирование
команды тестеров и руководство ею, а также обеспечение служебного продвижения
тестеров данной организации. Планирование тестирования включает подбор всех
необходимых ресурсов, таких как сети, средства тестирования, информационные
липни н специалисты по тестированию. В плане тестирования установлены рамки,
метод, ресурсы и график процесса тестирования. В нем определены риски, подлежащие
тестированию свойства, предназначенные для выполнения задачи тестирования, а
также тестеры, несущие ответственность за выполнение каждой задачи. Тестовая
документация относится к конфигурационному менеджменту и поддерживается в
синхронном состоянии с программным обеспечением. Контрольные случаи
регрессионного тестирования архивируются с той версией программы, тестирование которой
выполняется в данный момент времени.

Аттестация и верификация 925
В отчетах по проведению тестирования в хронологическом порядке
регистрируются релевантные детали о выполнении тестов, которые документируют событие,
требующие научного исследования.
Тестирование, имеющее отношение к качественным характеристикам,— это
единственный способ дать оценку качеству продукта, выразив его через следующие
характеристики:
■ работоспособность;
■ наблюдаемость;
■ возможность контроля;
■ "разложимость";
■ простота;
■ стабильность;
■ доступность для понимания.
Резюме
Верификация — это процесс проверки правильности созданной конструкции
согласно внутренним спецификациям. Аттестация— это процесс обоснования
удовлетворения поставленных пользователем требований через внутренние спецификации.
На профессиональном жаргоне верификация гарантирует, что мы строим систему
в правильном направлении, в то время как аттестация гарантирует, что мы строим
нужную систему. Хотя зачастую считают, что статическое тестирование формирует
верификацию, а динамическое тестирование представляет собой аттестацию, на
самом деле процесс V&V (аттестация и верификация) имеет место на протяжении всего
жизненного цикла разработки программного продукта. Верификация, относящаяся
к набору действий, которые гарантируют корректную реализацию в ПО отдельной
функции, может происходить как в процессе статического, так и динамического
тестирования. Аттестация, относящаяся к набору действия, которые гарантируют
возможность трассировки программного продукта по отношению к требованиям
заказчика, также может происходить как в процессе статического, так и динамического
тестирования.
Статическое тестирование (выполнение экспертных оценок) представляет одно из
самых эффективных средств, применяемых для повышения качества программного
продукта. Для его проведения нет необходимости в приобретении каких либо
автоматических средств, его легко понять и применить. Требуется выполнить обзор всех
компонентов проекта, начиная с тех, которые были произведены на ранних фазах
жизненного цикла разработки ПО (например, план менеджмента программного проекта).
Экспертные оценки признаются Институтом SEI СММ как необходимые на
определенном уровне обеспечения функциональных возможностей. Преимущества проведения
обзоров огромны и подтверждены достаточным количеством документации. К ним
относятся финансовые преимущества, а также возможность многостороннего обучения.
Экспертные оценки проводятся согласно определенным строгим правилам.
Динамическое тестирование охватывает набор тестовых процедур и контрольных
случаев, которые выполняются для рассматриваемого программного кода. Когда
тестирование системы выполняется "снизу вверх", элементы (программные модули)
тестируются в соответствии с принципами метода "белого ящика", элементы соединяются

926 Глава 23
в компоненты подсистемы и тестируются в соответствии с принципами метода
черного ящика". Затем подсистемы объединяются в системы и подвергаются различным
тестам. Для объектно-ориентированных систем изначально требуется другой подход,
но с точки зрения пользователя они подвергаются таким же системным тестам.
Даже небольшой проект, в котором руководитель проекта выполняет двойные
обязанности менеджера проекта и менеджера по тестированию, требует выполнения
определенных минимальных действий.
В этой главе многие важные вопросы рассмотрены лишь частично, поскольку
о формальных методах, тестировании под нагрузкой, обеспечении качества и
оценочном анализе, а также многих других аспектах написано достаточно много книг. Задача
этой главы — дать руководителю программного проекта представление о сложности
задач, выполняемых командой испытателей, побудить менеджера проекта оказывать
поддержку процессу обзора, помочь ему понять, насколько важно нанять и обучить
квалифицированных специалистов по тестированию и способствовать их
продуктивной работе, а также планировать проведение всего процесса тестирования, основы-
иаясь на перманентных критериях качества, а затем следовать этому плану.
Контрольные вопросы
1. Почему многие программы нельзя протестировать всесторонне?
2. Почему разработчик ПО не должен брать на себя ответственность за
обнаружение и исправление своих собственных ошибок?
3. Почем)' тестирование занимает такое большое процентное соотношение от
общего объема технической работы в процессе разработки ПО? Правильно ли это?
Что можно сделать, чтобы изменить эту ситуацию?
4. В чем заключается цель тестирования?
5. Почему управление конфигурацией играет такую большую роль для тестирования?
6. Какая разновидность обзора и метрических показателей тестирования
необходима менеджеру проекта для управления ходом тестирования?
Практическое занятие
Программа XTRemeObjectMaker предназначена для генерирования завершенной
матрицы трассировки требований, используемых в качестве основы для проведения
аттестации и приемочного испытания. К сожалению, в процессе выполнения
аттестации инструментальных выходных данных, вы сразу же обнаружили, что
корректная матрица трассировки требований так и не была спроектирована. Существует
некое несоответствие между компьютером Java, используемой версией библиотеки Java
Swing и процессом построения, реализуемым на основе EJB. Основываясь на
документе SRS для полного продукта, вы должны разработать комплексную матрицу
трассировки для выполнения аттестации. В ходе прототипирования г-н Лу упоминал, что
полный план приемочного испытания не потребуется до тех пор, пока окончательно
не будет выбран поставщик. Мисс Пайтель добилась отмены для прототипа всего
процесса составления плана тестирования, поэтому д-р Харита и не предпринимал
никаких действия в этом отношении. Из-за проблем с CASE-инструментом, вам
больше не импонирует выполненная в рамках процесса аттестация. Необходимо повторно

Аттестация и верификация 927
предпринять оценку всего процесса тестирования ARRS и составить план. Мисс Пай-
тель ушла в ежегодный отпуск и будет отсутствовать еще две недели. Сейчас самое
подходящее время выполнить эти планы и получить результаты к ее приезду.
Литература
Baber Robert Laurence. Error-Free Software: Know-how and Know-why of Program Correctness. NY: Wiley,
1991.
Beizer Boris. Software System Testing and Quality Assurance. NY: Van Nostrand Reinhold, 1984.
Beizer Boris. Black Box Testing: Techniques for Functional Testing of Software and Systems. NY: Wiley, 1995.
Berard E.V. Essays on Object-Oriented Software Engineering, vol.1. Reading, MA: Addison-Wesley, 1993.
Bias Randolph G. and Deborah J. mayhew, eds. Costjustifying Usability. Boston, MA: Academic Press,
1994.
Binder Robert. "Scenario-based Testing for Client/Server Systems". The Software Testing Forum, 1B): 12-17,
1993.
Binder Robert V. Testing Object-oriented Systems: Models, Patterns and Tools. Reading, MA: Addison-Wesley,
1999.
Bush Marilyn. "Improving Software Quality: The Use of Formal Inspections at the Jet Propulsion
Laboratory". Proceedigs, 12th International Conference on Software Engineering, Nice, France, march 26-30,
pp. 196-199. 1990.
Carmel E. "Cycle Time in Packaged Software Firms". Journal of Product Innovation Management, 12B): 110-
123, 1995.
DeMacro Tom. Why Does Software Cost So MuchtAnd Other Puzzles of the Information Age. NY: Dorset House,
1995.
Devor Richard E. и др. Statistical Quality Design and Control NY: Prentice Hall, 1992.
Dumas Joseph S. and Janice C. Redish. A Practical Guide to Usability Testing, rev. ed. Portland, OR:
Intellect Books, 1999.
Dyer Michael. The Cleanroom Approach to Quality Software Development. NY: Wiley, 1992.
Ebanau Robert G. and Susan H. Strauss. Software Inspection Process. NY: McGraw-Hill, 1994.
Florae William A. "Software Quality Measuremebt: A Framework for Counting Problems and Defects".
CMU/SEI-92-Tr-22. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1992.
Florae William A, et al. "Practical Software Measurement: Measuring for Process Management and
Improvement", CMU/SEI-97-HB-003. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon
University, 1996.
Friedman Michael A. and Jeffery M. Voas. Software Assessment: Reliability, Safety, Teastabiilty. NY: Wiley,
1995.
Gilb Tom, and Dorothy Graham. Software Inspection. Reading, MA: Addison-Wesley, 1993.
Grady Robert. Successful Software Process Improvement. Englewood Cliffs, NJ: Prentice Hall, 1997.
Grady Robert B. and Deborah L Caswell. Software Metrics: Establishing a Company-wide Program. Englewood
Cliffs, NJ: Prentice Hall, 1987.
Hetzel William C. The Complete Guide to Software Testing, 2°d ed. Wellesley, MA: QED Information
Sciences, 1988.
Hetzel William C. Making Software Measurement Work: Building an Effective Measurement Program. Boston,
MA: QED Pub. Group, 1993.
Humphrey Watts S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989.
IEEE 1008-1987. 'IEEE standard for Software Unit Testing". NY: The Institute of Electrical and
Electronic Engineers, 1987.
IEEEE 729-1983, "IEEE standard Glossary of Software Engineering Terminology". NY: The Institute of
Electrical and Electronic Engineers, 1983.

928 Глава 23
IEEE 982.1-1988, "IEEE Standard Dictionary of measures to Produce Reliable Software". NY: The
Institute of Electrical and Electronic Engineers, 1988.
Jones T. Capers. Programming Productivity. NY: McGraw-Hill, 1986.
Kan Stephen H. Metrics and Models in Software Quality Engineering. Reading, MA: Addison-Wesley, 1995.
Karner Cem и др. Testing Computer Software, 2"J ed. NY: Van Nostrand Reinhold. 1993
Knight J.C. and E.A. Meyers. "An Improved Inspection Technique". Communications of the ACM, 36A1):
51-61, 1993.
Lyu Michael R, ed. Handbook of Software Reliability Engineering, NY: McGraw-Hill, 1996.
Marick Brian. The Craft of Software Testing. Engelwood Cliffs, NJ: Prentice Hall, 1995.
Martin James and Carina McClure. Software Maintenance: The Problem and Its Solution. Engelwood Cliffs,
NJ: Prentice Hall, 1983.
McConnel Steve. Rapid Development: Taming Wild Software Schedules. 1" ed. Redmond, WA: Microsoft
Press. 1996.
Miller Ann. Engineering Quality Software: Defect Detection and Prevention. Reading, MA: Addison-Wesley,
Motorola University Press Six Sigma Reseach lnsttute Publications, 1992.
Mosley Daniel J. The Yandwork of MIS Application Software Testing: Methods, Techniques, and Tools for Assuring
Quality through testing. Engelwood Cliffs, NJ: Prentice Hall, 1993.
Musa John D. и др. Software Reliability: Measurement, Prediction, Application. NY: McGraw-Hill, 1987.
MusaJohn D. "Operational Profiles in Software Reliability Engineering". IEEE Software, 10B):14-32,
1993.
Nielsen Jakob. Usability Engineering, Boston, MA: Academic Press, 1993.
Nielsen, Jakob, and Robert L. Mack, eds. Usability Inspection Methods. NY: John Wiley&Sons, 1994.
Offut A. Jefferson. "Investigations of the Software Testing Coupling Effect". ACM Transactions on Software
Engineering and Methodology, 1A), 1992.
O'Neil Don. "Setting Up a Software Inspection Program". CrossTalk, The Journal of Defense Software
Engineering. 10B). 1997.
Perry William E. How to Test Software Packages. NY: Jonh Wiley & Sons, 1986.
Potter A.A., и др. "An Experiment to Assess the Cost-Benefits of Code Inspection In Large Scale
Software Delelopment". IEEE transactions of Software Engineering, 23F):329-346, 1997.
RaeA.K., и др., eds. Software Evaluation for Certification: Principles, Practice and Legal Liability. NY: McGraw-
Hill, 1995.
Royer Thomas C. Software Testing Management: Life on the Critical Path. Engelwood Cliffs, NJ: Prentice
Hall. 1993.
Shneidcrman Ben. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Reading,
МЛ: Addison-Wesley. 1997.
Shooman Martin L. Software Engineering Design, Reliability, and Management. NY: McGraw-Hill, 1983.
Sommcrville Ian. Software Engineering, 6-е издание. Reading, MA: Addison-Wesley, 2001.
Voas Jeffrey M. and Gary McGraw. Software Fault Injection: Inoculating programs Against Errors. NY: Wiley,
1998.
Watson Arthur H. and Thomas J. McCabe. "Structured Testing: A Testing Methodology Using the
Cyclomatic Complexity Metric". National Institute of Standards and Technology Special Publication 500-253.
Gaitltersburg. MD: NIST, 1996.
Weinberg Gerald M. The Psychology of Computer Programming. NY: Van Nostrand Reinhold, 1971.
Weinberg, Gerald M. Quality Software Management, voL I, Systems Thinking. NY: Dorset House, 1992.
Weinberg Gerald M. Quality Software Management, vol. 4, Anticipating Change. NY: Dorset House, 1992.
Weller E..F. "Lessons Learned from Two Years of Inspection Data". IEEE Software, 10E):38-45, 1993.
Wheller David A., Bill Brykczynski and Reginald N. Meeson, Jr., eds. Software Inspetion, An Industry Best
Ptacticr. NY: IEEE Computer Society Press, 1996.

Аттестация и верификация 929
Wiklund Michael E., ed. Usability in Practice: How Companies Develop User-Friendly Products. Boston, MA:
Academic Press, 1994.
Yamaura Tsuneo. "How to Design Practical Test Cases". IEEE Software, 15F): 30-36, 1998.
Yourdon Edward. Modern Structured Analysis. Engelwood Cliffs, NJ: Prentice Hall, 1989.
Yourdon Edward. "Metrics for Death-March Projects". Proceedings of Symposium: Eight International
Conference On Applications of Software Measurement, Atlanta, GA, October, 1997.
Дополнительные сведения в Internet
sate .gsfc.nasa. gov/fi /fipage. html. Процесс формальной инспекции, принятый в NASA.
world. std.com/~jr/Papers/QW96.html. Rothman, Johanna. "Measurements to Reduce Risk
in Product Ship Decisions". Proceedings of the Ninth International Quality Week, Software Research, San
Francisco, CA, 1996.
www. chasmgroup. com/.
www. cse. dcu. ie/. Центр программного инжиниринга, Ltd., Dublin City University Campus,
Дублин. Ирландия.
www. geraldmweinberg. com. Начальная страница Геральда М. Вайнберга.
www.geraldmweinberg.com/shape.html. Форум SHAPE (ПО как род человеческой
активности, планируемой эффективным образом).
www. ics -hawan . edu/-Johnson/'FTE/. Архив формальных технических обозрений.
www. ics.hawaii. edu/~siro/. Организация, выполняющая обзоры и инспекции программного
обеспечения.
www. io. com/ -wazmo /qa /. Горячий перечень по тестированию ПО, под редакцией Бретта Пет-
тичорда (Brett Petichord).
www. iso.ch/iso/en/ISOOnline.openerpage. Международная организация по разработке
стандартов (ISO).
www. jrothman. com.
www. kaner. com/. Д-р Канер (Kaner) является ведущим автором журнала Testing Computer Software.
www. kaner. com/coverage.htm. Kaner, Cem A996). "Software Negligence and Testing Coverage",
STAR У6 Proceedings, May.
www.mtsu. edu/~storm/. Интерактивные ресурсы, включающие сведения по тестированию ПО.
www. nist. gov/. Национальный Институт стандартов и технологий (NIST).
www.nstl. com/. Национальная лаборатория по тестированию ПО.
www. softwareqa test. сот/ТОР. Центр Software QA/Test Resource, поддерживаемый Риком Хо-
вером (Rick Hower).
www. onda web. com/s ti /. Институт по тестированию ПО.
www. onda web. com/sti/s tivend. h tm. Руководство по ресурсам профессионального тестера ПО.
www.qaiusa. com/. Институт качества ПО.
www. satisfice. com/articles/good_enouch_quality.pdf. James Bach. "Good Enough
Quality: Beyond the Buzzword" (Software Realities Column). IEEE Computer, August, 1999.
www.satisfice.com/articles/software_reality.pdf.James Bach. "What Software Reality is
Really About" (Software Realities Column). IEEE Computer, August, 1999.
www.satisfice.com/articles/test_automation_snake_oil.pdf.Ja.mes Bach. "Test
Automation Snake Oil". Windows Tech Journal, October, 1996.
www. sof twareqatest. com/WEB_SECURITY. Тестирование общемировых Web-узлов.
www. spmn. com. Сеть менеджеров по разработке ПО.
www. sqe. com/index. asp. Инжиниринг качества ПО.
www.stlabs.com/-ma rick/root.htm.

930 Глава 23
www.stqemagazine.com/featured.asp?stamp=1129l235440. James Bach. "Risk-Based Testing".
Software Testing and Quality Engineering Magazine, 1F).
www. stqemagazine. com/webinfodetail .asp?id=102. Brian Marick. "Web Watch: Automating
Testing". Software Testing and Quality Engineering Magazine, 1E), Sep/Oct, 1999.
www.stsc.hill.af.mil/CrossTaIk/1998/dec/oneill.asp.
www.stsc.hill.af.mil/SWTesting/gilb.html. Документы Тома Гильба (Tom Gilb).
www. testing, com/writings/automate.pdf. Brian Marick. "When Should a Test be Automated?"
Proceedings of International Quality Week, May, 1988.
www.testing.com/writings/classic/inistaices.htiTil. Brian Marick. "Classic Testing
Mistakes". Proceedings of STAR 97, Software Quality Engineering, Jacksonville. FL, 1997.
www.testing.com/writings/coveiage.pdf. Brian Marick. "How to Misuse Code Coverage".
International Conference and Exposition on Testing Computer Software, June, 1999.
www. testing, com/writings /effective .pdf. Brian Marick. "Working Effectively With
Developers". STAR West Conference, October, 1999.
www. testing.com. writings/experience.pdf. Brian Marick. "Experience with the Cost of
Different Coverage Goals of Testing". Pacific Northwest Software Quality Conference, October, 1991.
www.testing.com/writings/parpose-of-testing.htm. Brian Marick. "The Testing Team's
Motto".
www. testingcraft. com/explora tory -pett ichord. html. Brett. "An Exploratory Testing
Workshop Report",July, 1999.
www. use it. com/.
www. zdnett. com/pcmag/pctech/content/17/17/tul717. 001. html. Neil Randall, "Making
Software Easier Through Usability Testing: софтверные компании применяют тщательно
продуманные подходы с целью определения простоты/сложности применения их продуктов". PC Magazine
Online.

Использование
инструментов
В деятельности проектных менеджеров обычно выделяются две основные области
применения инструментов: жизненный цикл разработки ПО и модель улучшения
процессов. Как упоминалось в главе 19, Организация по разработке стандартов IEEE
в области вычислительной техники (IEEE Computer Society) и Координационный
комитет по разработке АСМ (АСМ Software Engineering Coordinating Committee) создали
совместный документ Основы знаний в области ПО (SWEBOOK, Software Engineering
Body of Knowledge). В нем перечислены инструментальные средства,
предназначенные для проектирования и разработки ПО на протяжении всего жизненного цикла.
В табл. 24.1 приведены SWEBOK-инструменты, а также дополнительные инструменты
проектирования, предназначенные для выполнения оптимизации и верификации
программ.
Таблица 24.1. Категории инструментов по разработке ПО
Класс инструментов
Специфический тип инструментов
Инструменты по разработке программных
требований
Инструменты по разработке проекта ПО
Инструменты по конструированию ПО
Инструменты по тестированию ПО
Моделирование требований
Трассировка
Верификация проекта
Оптимизация проекта
Редакторы программного кода
Компиляторы
Интерпретаторы
Отладчики
Генераторы тестов
Схемы выполнения тестов
Оценка тестов
Управление тестами
Анализ производительности

932 Глава 24
Окончание табл. 24.1
Класс инструментов
Специфический тип инструментов
Инструменты по сопровождению ПО
Инструменты, предназначенные для
поддержки процесса разработки ПО
11нструменггы по обеспечению качества ПО
Инструменты но управлению
конфигурацией ПО
Инструменты по управлению
разработкой ПО
Инструменты, реализующие поддержку
инфраструктуры
Дополнительные вопросы, связанные
с применением инструментов
Понимание сути разработанных программ
Доработка существующих программ
Моделирование процесса
Управление процессами
Интегрированные CASE-среды
Среды разработки программного обеспечения,
ориентированные на процессы
Проверка
Статический анализ
Отслеживание дефектов, расширений, проблем
и различных вопросов
Управление версиями
Выпуски и подверсии
Планирование и отслеживание проектов
Управление рисками
Измерение
Межличностное взаимодействие
Система выборки информации
Администрирование и поддержка
Инструментальные интеграционные методики
Мета-инструменты
Инструментальная оценка
В табл. 24.2 демонстрируется взаимосвязь между пятью уровнями зрелости
процессов, которая имеет прямое отношение к модели зрелости возможностей,
спроектированной коллективом Института программного инжиниринга (Software
Engineering Institute). В этой же таблице перечислены отдельные инструменты,
идентифицированные в документе SWEBOK, а также представлены категории
каждого инструмента, позволяющие идентифицировать уровень зрелости организации по
разработке ПО, для которой и предназначены данные инструменты. Менеджеры
программных проектов должны уметь оценивать уровень зрелости организации,
в которой ведется разработка программного продукта. Применение перечисленных
в таблице инструментов в незрелой организации может привести к быстрой
разработке некачественного программного продукта, т.е. степень эффективности мощных
инструментов напрямую связана с уровнем зрелости организации.
Таблица 24.2. SWEBOK-инструменты и уровни модели СММ
Уровень Основная цель Ключевые области процесса SWEBOK-инструменты
применения
5

Оптимизация
Непрерывное 1. Предотвращение дефектов 1. Всеобъемлющий охват
улучшение про- 2. Управление технологиче- 2. Повторная разработка
цесса скими изменениями д. Среды разработки ПО,
3. Управление изменениями ориентированные на про-

Использование инструментов 933
Окончание табл. 24.2
Уровень Основная цель Ключевые области процесса SWEBOK-инструменты
применения
4 Обеспечение
Управ- качестаа ПР°"
цесса и про-
ляемыи г
граммного
продукта
3 Определенный
Опреде- провес разра-
„ ботки
ленный
2

Повторяемый
Процесс
осуществления
менеджмента про-
1 Персонал
Началь-
1. Управление
количественными процессами
2. Менеджмент качества ПО
1. Верификация проекта
2. Оптимизация проекта
3. Управление процессами
4. Интегрированные CASE-
среды
5. Статический анализ
1. Моделирование проекта
2. Анализ производительности
3. Моделирование процесса
4. Проверка
1. Выделение
организационного процесса
2. Определение
организационного процесса
S. Интегрированное управле- 5 Инструментальные инте.
ние грационные методики
4. Разработка программного
продукта
5. Координация групповых
действий
6. Учебная программа
7. Экспертные оценки
1. Управление требованиями 1. Моделирование требований
2. Планирование программ- 2. Трассировка
6. Инструментальные оценки
ного проекта
3. Оценка тестов
3. Отслеживание программно- 4. Управление тестами
го проекта
Управление деятельностью
субподрядчиков по
разработке ПО
Обеспечение качества ПО
6. Менеджмент
конфигурации ПО
5. Отслеживание дефектов,
расширений, возможных
вопросов и проблем
6. Управление версиями
7. Выпуски и подверсии
8. Планирование и
отслеживание проекта
9. Управление рисками
10. Измерения
11. Системы выборки
информации
12. Администрирование и
поддержка
1. Редакторы программного кода
2. Компиляторы
3. Интерпретаторы
4. Отладчики
5. Генераторы тестов
6. Схемы выполнения тестов
7. Межличностные взаимодействия
8. Мета-инструменты

934 Глава 24
Стадии жизненного цикла
разработки продукта
Инструменты необходимы на всех стадиях жизненного цикла разработки ПО
(см. рис. 24.1). Не существует четко выраженной корреляции между инструментами
и фазами жизненного цикла разработки программного продукта. Например,
инструменты по определению требований необходимы в самом начале выполнения проекта.
Способность к легкой выборке и записи информации нужна уже на этапе
исследования концепции, а также ближе к концу этапа определения требований. Инструменты
Исследование
концепции
Исследование
системы
Требования
Инструменты по
определению требований
Разработка
проекта
Внедрение
Инструменты
по разработке
проекта }
Установка
Конструкторские
инструменты
Эксплуатация
и поддержка
Сопровождение
i i i !
Инструменты по проведению тестирования
Вывод из
эксплуатации
|-*-
Менеджмент конфигурации
Инструменты по сопровождению
Процесс инжиниринга, обеспечение качества, поддержка инфраструктуры, управление инжинирингом
Рис. 24.1. Использование инструментов в жизненном цикле разработки программного продукта

Использование инструментов 935
по разработке проекта требуются на фазах формулирования требований и
реализации программного продукта. Инструменты по разработке перекрывают фазы
разработки проекта и установки. Концепция тестирования корректности и приемлемости
зависит от выбранного набора требований и согласуется с клиентом. Тестирование
с помощью метода "черны и белых" ящиков зависит от общих концепций, связанных
с разработкой проекта. Все тесты, выполняющие верификацию, зависят от проекта,
а также от инструментов, применяемых для разработки конечного продукта.
Инструменты, предназначенные для выполнения сопровождения, представляют
собой комбинацию всех ранее используемых в жизненном цикле разработки ПО
инструментов. Наиболее реальный метод, применяемый при организации сопровождения,
заключается в распределении жизненного цикла разработки ПО таким образом, чтобы
методики и инструменты, имеющие отношение к ранним стадиям разработки,
использовались отдельно. А необходимость в инструментах по управлению конфигурацией
возникают уже с момента создания первого продукта, имеющего отношение к проекту.
Процессы поддержки инфраструктуры, обеспечения качества и разработки ПО
используются на всех фазах жизненного цикла разработки программного продукта.
Эти инструменты имеют отношение к проектам и программным продуктам.
Благодаря им и объединяются организации, выполняющие разработку ПО.
Учебные цели главы 24
После изучения материала главы читатель должен уметь выполнять следующее:
■ описывать классы и типы инструментов для каждого уровня зрелости модели СММ;
■ планировать инструменты, используемые в проекте разработки ПО;
■ выбирать специфичные инструменты, основываясь на повторяющемся процессе.
Последующее рассмотрение инструментов, применяемых в жизненном цикле
разработки ПО, может соотноситься с уровнем модели СММ (см. рис. 24.2). Этот подход
удобен при рассмотрении определенных инструментов. Применяемые в этом случае
инструменты обеспечивают проектирование высококачественных систем. Вернее,
эти инструменты не предназначены для создания некорректно работающих систем.
Хаотичная автоматизация деятельности на уровне 1, а также привлеченные извне
организации могут быть причиной деструктивных, беспорядочных процессов. Поэтому
перед выбором инструментов следует оценить уровень зрелости организации. Не
существует универсального решения относительно приобретения инструментов,
предназначенных для восполнения какого-либо отсутствующего процесса .
Приведенные описания не содержат перечня рекомендованных инструментов. По
причине изменчивости рынка программных инструментальных средств подобные
перечни просто бесполезны. Поиск существующих инструментов и их поставщиков
может производиться с помощью поискового механизма в Internet, типа Copernic
(www.copernic.com). Например, если в качестве ключевой фразы задать "software
requirements modeling" (моделирование требований к ПО), отобразятся 106
действующих Web-страниц. Начальный автоматизированный процесс исследования и
выбора инструментов обеспечивается с помощью подобной предварительной
информации для поиска, а также методики оценки инструментов, представленной далее.
Brooks Fred P. "No Silver Bullet: Essence and Accidents of Software Engineering". Information
Processing, pp. 1069-1076, 1986.

936 Глава 24
Инструменты по определению
требований к ПО
Инструменты, выполняющие выборку, использование и сопровождение
программных требований, образуют две общие категории: моделирование и трассировку.
Существует и более детальная классификация, которая может применяться с целью описания
категорий. Однако подобная детализация может оказаться излишней, поскольку
большинство инструментов можно отнести к одной из двух указанных выше категорий.
На рис. 24.2 показаны фазы жизненного цикла разработки ПО, на которых
применяются инструменты по определению требований к программам. Эти инструменты
применяются не только на фазе формулирования требований, но также и на
предварительных фазах исследования концепции и системы. Подобный инструментарий
может применяться при разработке функциональных требований, которые обычно
перечислятся в спецификации требований к ПО (Software Requirements Specification, SRS).
Этот документ подробно рассматривается в главе 17.
Исследование
концепции
Исследование
системы
Требования
Инструменты по
определению требований
Рис. 24.2. Инструменты описания
требований и их положение в жизненном цикле
разработки ПО
Моделирование требований — модель СММ,
второй уровень и выше
В данную категорию попадают инструменты, предназначенные для сбора, записи,
анализа и проверки требований, предъявляемых к ПО. Традиционная классификация
будет следующей: структурированное либо классическое моделирование требований,
анализ и моделирование объектно-ориентированных требований. Подобные
инструменты состоят из трех базовых компонентов. Первый компонент по своей сути
является механизмом правил. Он содержит правила моделирования для применяемой
методологии. Второй компонент является механизмом, ориентированным на работу
с графикой. Этот компонент поддерживает пиктограммы, которые допускаются
методологией, описанной с помощью правил. Здесь также определяются допустимые
методы подключения к пиктограммам. Последний компонент выполняет функции
инструмента описания структурных требований. Он используется при описании
функциональных требований, необходимых элементов данных, а также другой
информации, специфичной для требований.
Наиболее простым набором инструментов моделирования требований,
предназначенным для среды Microsoft Windows, является Visio (графический инструмент)
и Access (захват структурной информации). Несмотря на то, что для Visio существует

Использование инструментов 937
множество подключаемых модулей, реализующих поддержку различных методик по
разработке ПО, это приложение не относится к разряду CASE-инструментов. Большая
часть "механизма правил" все же должна храниться в голове у пользователя.
Трассировка — модель СММ, второй уровень и выше
По мере роста сложности программных систем инструменты, обеспечивающие
трассировку требований, становятся критично важными для представления
требований на всем протяжении жизненного цикла разработки ПО. Процесс трассировки
начинается с получения требований к программному продукту с помощью
инструмента структурного описания. Результат применения этого инструмента представляет
собой уникальным образом нумерованное требование наряду с кратким описанием.
Подобная, разбитая на две части информация, может выступать в роли входных
данных для электронной таблицы, такой как Excel. Причем в этом случае данные
вводятся в правые столбцы таблицы. Затем в верхней строке таблицы могут отображаться
данные, подлежащие трассировке. В качестве этих данных может быть перечень
тестов на пригодность, объекты проекта, модули кода либо области риска. Важность
подобного минимального уровня автоматизации заключается в том, что требования
могут устанавливаться и поддерживаться в одном месте, а использоваться — на всем
протяжении жизненного цикла разработки ПО.
Инструменты по разработке проекта ПО
Разнообразные инструменты по разработке проекта ПО делятся на категории
верификации и оптимизации. Причина подобного разделения заключается в
разнообразии используемой записи и методов. Подобное разнообразие определяется
эволюцией от классических структурных методов моделирования до методов,
основанным на применении унифицированного языка моделирования (Unified Modeling
Language, UML). На рис. 24.3 продемонстрированы инструменты по разработке
проектов программ, которые изначально использовались в средних точках фазы
определения требований. Применение этих инструментов завершается в средних точках
фазы реализации. Подобное перекрытие объясняется тем, что некоторые свойства
программного продукта перемещаются с фазы определения требований на фазу
проектирования прежде, чем фаза будет завершена. Некоторые действия по
проектированию выполняются на фазе реализации. Поэтому инструменты по проектированию
используются на нескольких фазах, а не только на фазе проектирования.
Требования
Разработка
проекта
Внедрение
Инструменты
по разработке
проекта
-* *~
Рис. 24.3. Место инструментов
разработки проекта в жизненном цикле
разработки ПО

938 Глава 24
Моделирование проекта — модель СММ,
третий уровень и выше
Инструменты, применяемые во время моделирования проекта, тесно связаны
с адаптированной методологией разработки программного продукта. Наборы
инструментов, применяемые при реальном моделировании и моделировании требований,
являются идентичными. Основное различие состоит в том, что механизмы графики
и правил расширяются с целью учета объектов и правил проекта при их совместном
связывании.
Верификация проекта — модель СММ,
четвертый уровень и выше
Верификация проекта выполняется после завершения разработки проекта ПО.
В ходе выполнения задач по верификации (трассировка, оценка и анализ интерфейса)
гарантируется правильная интерпретация и реализация требований к разработке
ПО. В ходе верификации проекта определяется соответствие программного проекта
требованиям к ПО. До того, как будет завершена верификация системы в целом,
может формулироваться несколько вариантов требований к ПО, а также производиться
несколько промежуточных верификаций проекта. Верификация проекта
значительно облегчается благодаря применению матриц трассировки и некоторых
автоматизированных инструментальных компонентов.
Оптимизация проекта — модель СММ,
четвертый уровень и выше
Специфика инструментов оптимизации проекта определяется не только
методологией, но и применяемой предметной областью. Некоторые CASE-инструменты
могут выполнять оптимизацию проекта первого порядка. Они просто оценивают
атрибуты проекта в виде нагрузочных коэффициентов по входу/выходу, коэффициентов
сцепления и соединения, основываясь на модульной структуре. При работе с
объектно-ориентированными проектами сложность проекта рассматривается в связи с
наследованием, полиморфизмом и инкапсуляцией, характерным для модели проекта.
При выполнении всесторонней оптимизации следует изучить предметную область
продукта, а также определить оптимум для топологий проекта. Подобные типы
инструментов присущи зрелым организациям и являются частью "секретного соуса",
придающего "остроту" всему программному продукту.
Инструменты по конструированию ПО
Инструменты по конструированию ПО предназначены для преобразования моделей
требований и проекта в язык программирования, предназначенный для выполнения
набора аппаратных инструкций. На рис. 24.4 показано, какое место в жизненном цикле
разработки ПО занимают подобные инструменты. Они инструменты начинают
применяться в середине фазы разработки проекта. Их использование диктуется тем, что
некоторые возможности программного продукта должны быть реализованы прежде, чем
будет завершена фаза разработки проекта. Вызов некоторых свойств инструментов по
конструированию ПО необходим также для того, чтобы убедиться в возможности
совместного применения инструментов по проектированию и конструированию ПО.

Использование инструментов 939
Момент завершения работы с инструментами по конструированию ПО определяется
окончанием фазы установки, поскольку с их помощью устраняются возможные ошибки,
выполняются изменения и простые настройки. На практике эти инструменты
применяются после завершения фазы установки программного продукта. Если организация
несет ответственность за сопровождение установленного ПО, она также применяет
набор инструментов по его конструированию.
V \
Разработка
проекта
j
■ .
к
^
Внедрение
i
V
1<
N
Установка
Рис. 24.4. Место инструментов
Конструкторские по конструированию ПО в жил-
я инструменты ненном цикле разработки
Редакторы программного кода — модель СММ,
первый уровень и выше
Эти инструменты применяются при создании и изменении компьютерных
программ и связанной с ними документации. Редакторы могут носить универсальный
характер либо настраиваться на применение того либо иного языка программирования.
Их работа контролируется человеком-оператором. По характеру они являются
"мощными" инструментами, применяемыми на первом уровне модели СММ для
организации. Персоналу любых организаций, независимо от уровня их зрелости, время от
времени требуется просмотр исходного кода программного продукта. В
организациях, относящихся к первому уровню, подобный инструментарий представляется в
качестве требуемого набора инструментов. В организациях, относящихся к пятому
уровню, этот набор инструментов выбирается в условиях отсутствия альтернативы.
Компиляторы — модель СММ, первый уровень и выше
Традиционно компиляторы рассматриваются в качестве неинтерактивных
трансляторов, предназначенных для обработки потока исходного кода. Прослеживается
тенденция интеграции редакторов исходного кода и специфических компиляторов
языка, в результате чего обеспечивается поддержка базовой среды разработки. В
категорию компиляторов также попадают препроцессоры, компоновщики/загрузчики
и генераторы кода.
Интерпретаторы — модель СММ,
первый уровень и выше
Инструменты из этой категории предназначены для имитации среды выполнения.
Скорость их выполнения меньше, чем скорость выполнения скомпилированного
кода, однако, интерпретаторы поддерживают в лучшей степени контролируемую и
наблюдаемую среду выполнения программ.

940 Глава 24
При осуществлении выбора в пользу компилятора либо интерпретатора следует
учитывать следующие сравнительные показатели .
1. Написание "некоторых" программ с помощью языков сценариев (Perl, Python,
Rexx, Tel) требует в полтора раза больше времени, чем посредством языков
программирования C/C++ или Java. Размер программ также зависит от того,
применяется ли компилятор либо интерпретатор.
2. Надежность создаваемых программ практически не зависит от применяемого
языка программирования.
3. Типичная программа-сценарий требует в два раза больший объем памяти, чем
программа, написанная на языках C/C++. При выполнении Java-апплета объем
требуемой памяти увеличивается в 3-4 раза.
4. При считывании 1-мегабайтного файла и создании входной внутренней таблицы
(размером в 70 Кбайт) на этапе инициализации программа, написанная на C/C++,
оказывается в два раза быстрее, чем Java-апплет, и в 5-10 раз быстрее любого сценария.
5. При осуществлении поиска во внутренней структуре данных программы,
написанные на C/C++, выполняются в два раза быстрее, чем Java-апплеты.
Быстродействие сценариев, в свою очередь, превышает быстродействие Java-апплетов.
Отладчики — модель СММ, первый уровень и выше
Инструменты из этой категории применяются совместно с другими
инструментами по разработке программного обеспечения с целью облегчения поиска и
исправления ошибок в сложных системах. Отладчики представляют собой расширения
времени выполнения для инструментов по разработке ПО. С их помощью обеспечивается
включение точек прерывания (здесь же помещаются простые операторы печати).
Точки прерывания позволяют отслеживать процесс выполнения программы.
Инструменты по выполнению тестирования
А теперь приступим к рассмотрению категорий инструментов по выполнению
тестирования ПО в рамках жизненного цикла разработки. Как показано на рис. 24.5,
инструменты по выполнению тестирования должны использоваться, начиная с
самого начала жизненного цикла разработки с целью формулирования тестовых
предположений. Также с помощью этих инструментов осуществляется воплощение
сформулированных требований в наборе тестовых случаев, выполняется тестирование кода,
а также осуществляются изменения в ходе возвратного сопровождения. Среды
тестирования с высокой степенью интеграции приводят к повышению качества
создаваемого программного продукта.
Генераторы тестов — модель СММ,
первый уровень и выше
Инструменты из этой категории применяются при разработке и генерировании
тестовых случаев, а также связанных с ними наборов данных в процессе
тестирования. Методики проектирования тестовых случаев применяются для идентификации
* Prechelt Lutz. "An Empirical Comparison of Seven Programming Languages". IEEE Software, Ok-
tober, pp. 23-29, 2000.

Использование инструментов 941
значений тестовых данных, которые образуют основу генераторов тестов. Разработка
модулей тестирования для тестовых случаев осуществляется самими разработчиками.
Команда тестеров предоставляет помощь разработчикам в применении на практике
разработанных методик. Тестеры также могут самостоятельно применять эти методики в целях
тестирования интеграции, системы, а также для выполнения регрессионного
тестирования. Описания тестовых случаев могут документироваться вручную либо сохраняться в
репозитории тестов для набора автоматизированных инструментов по выполнению
тестирования. Если тестовые случаи документируются в автоматическом режиме,
применяемый формат и содержимое могут ограничиваться формами ввода и тестовым репозитори-
ем. Каждая фирма-разработчик инструментальных средств может хранить различный
набор описательных элементов. Независимо от того, применяется ручной либо
автоматический режим создания документации, описание тестового случая должно, как минимум,
включать элементы, приведенные в примере выходного документа. В состав тестовых
данных необходимо включать описание ожидаемого поведения каждого тестового случая.
Исследование
системы
Требования
Разработка
проекта
Внедрение
Установка
Эксплуатация
и поддержка
Сопровождение
Вывод из
эксплуатации
Инструменты по проведению тестирования
Рис. 24.5. Место инструментов по выполнению тестирования в жизненном цикле
разработки ПО
На первом уровне модели СММ разработчики вручную генерируют тестовые случаи
и наборы данных, предназначенные для тестирования. По мере повышения степени
зрелости организации растет степень автоматизации. Простейший набор начальной

942 Глава 24
автоматизации представляет собой простое приложение базы данных, такое как
Access, реализующее генерирование тестовых случаев. При этом используются
наборы данных и требования, сформулированные на базе случайных наборов данных,
сгенерированных на основе требований из словаря данных модели.
Схемы выполнения тестов — модель СММ,
первый уровень и выше
Схема выполнения тестовых случаев представляет собой контролируемую среду,
которая является критичной к обсервации тестируемого объекта. Если такая схема
отсутствует, внедрение концепции тестируемого программного модуля вряд ли
возможно. Благодаря схеме выполнения тестов разрабатываются средства тестирования,
позволяющие выполнять различные уровни тестирования. К этим уровням
относятся: тестирование модулей с применением интеграции, тестирование системы, а также
финальное тестирование корректности и пригодности к эксплуатации. При
инициализации нового проекта выполняются несколько действий, связанных с созданием
программного обеспечения. Первое действие связано с продуцированием кода,
формирующего конечный программный продукт. Другие действия связаны с наборами
"рычагов" тестирования, используемых в ходе демонстрации выполнения
корректных операций. Также обязательным условием разработки любой функции является
изначальное встраивание способности к выполнению тестирования.
Степень сложности схемы тестирования растет с повышением уровня зрелости
организации, определяемого с помощью модели СММ. На ранних стадиях зрелости схема
может привязываться к сценариям, выполняющим проверку данных в средах Access,
Excel и простых программах, выполняющих сбор данных и генерирование тестовых случаев.
На протяжении фазы сопровождения программного проекта любая версия
функции, оптимизированная во время выполнения, может быть повторно протестирована
с помощью набора оригинальных средств тестирования. В этом случае любые
незначительные ошибки могут отслеживаться прежде, чем будет выполнена повторная
установка основного программного обеспечения. Издержки любого нового
программного проекта связаны с созданием присущих ему средств тестирования. Прежде, чем в
состав разрабатываемого программного обеспечения будет добавлена какая-либо
новая функция, следует воспользоваться всеми доступными средствами тестирования.
В результате функция должна быть помечена как корректная, а в системную
документацию добавляются необходимые документы.
Оценка тестов — модель СММ, второй уровень и выше
Инструменты по оценке тестов позволяют получить ответ на следующий вопрос:
"Совпадает ли наблюдаемое и ожидаемое поведение программного продукта?" До тех
пор, пока процесс не будет автоматизирован в целом, ответ на этом вопрос может
быть получен только ручным способом. В качестве вспомогательного средства,
облегчающего проведение анализа в целом, может применяться Excel. В зависимости от
места нахождения проекта в жизненном цикле разработки программного
обеспечения, процесс оценки может заключаться в выполнении проверки, верификации,
тестировании пригодности системы либо отдельного модуля, а также интегрированного
тестирования. Следует учитывать любые потребности в автоматизированных
инструментах с целью временного позиционирования в жизненном цикле разработки
программного обеспечения и определения выполняемых действий.

Использование инструментов 943
Управление процессом тестирования — модель СММ,
второй уровень и выше
Инструменты из этой категории обеспечивают управление всеми подпроцессами
общего процесса тестирования. Важнейшая цель процесса управления
тестированием заключается в сопровождении всех объектов, подвергаемых регрессионному
тестированию. Основная цель регрессионного тестирования заключается в проверке
устранения всех ошибок, обнаруженных на предыдущих этапах тестирования. Более
общее утверждение гласит, что в процессе регрессионного тестирования
осуществляется ссылка на процесс выполнения набора тестовых случаев, разработанных с
целью максимально полной проверки функциональных свойств приложения. Во время
прогона определенных тестовых случаев может осуществляться привязка к новым
функциональным свойствам либо осуществляться устранение определенных ошибок.
Это происходит в том случае, если тесты были реструктуризированы с целью
выделения только этих элементов, причем процесс в данной ситуации будет правильнее
называть функциональным либо модульным тестированием. Регрессионное
тестирование должно охватывать максимально возможное количество программных модулей,
а также не приводить к противоречивым результатам (результаты различных
прогонов не должны сильно отличаться). Основным инструментом, применяемым для
управления тестами, является система управления конфигурацией.
Анализ производительности — модель СММ,
третий уровень и выше
Как показано на рис. 24.6, анализ производительности представляет собой лишь одну
из составляющих управления программной системой. Процесс анализа начинается с
соглашения на уровне обслуживания (Service-level agreement, SLA), образующего верхний
уровень. Сюда также можно включить "справочный стол", действия по составлению
отчетов и изменению процессов, а также все взаимодействия с пользователем. На нижнем
уровне находится лаборатория, выполняющая оценку производительности ПО, системы
мониторинга, а также действия, выполняемые в ходе анализа и оптимизации. Все это
образует внутренние и технологические действия. Сразу же после начала
функционирования "справочного стола" либо систем мониторинга любой пользователь может
просмотреть полученные результаты. Если не выполнить просмотр сразу же, большая часть
результатов может быть утеряна. В процессе осуществления анализа и создания отчетов не
требуется применение дорогостоящих инструментов либо сложных процедур. И что
самое важное, любой пользователь может просматривать данные на регулярной основе и
вовремя замечать проявляющиеся тенденции либо чрезвычайные условия.
В качестве инструмента, предназначенного для осуществления простого анализа,
может рассматриваться встроенный отчет "справочного стола", диаграмма сетевого
монитора, специальный инструмент по созданию отчетов либо даже просто Excel сам
по себе. Преследуемая в этом случае цель заключается в исследовании тенденций в
поведении данных, а также в установлении причин проявления подобных тенденций.
Если на протяжении последней недели была зафиксирована высокая степень загрузки
центрального процессора, в ходе анализа необходимо определить основную причину
сложившейся ситуации. Связана ли высокая загрузка с некоторым деловым циклом,
происходящим в данный момент времени, либо мы имеем дело с одиночным
событием? Была ли загрузка высокой в момент выполнения последнего делового цикла?

944 Глава 24
Отличать нормальные показатели от аномальных можно путем выбора методов
измерения и организации наблюдений на регулярной основе. В некоторых случаях
достаточно выбрать методы измерения, генерирующие отчеты для пользователей. В случае
более сложных систем могут потребоваться специальные отчеты, с помощью
которых облегчается обработка данных.
Рис. 24.6. Цикл управления выполнением программ
Источник: stealthis.athensgroup.com/presentations.
Athens Group, Inc. The Business Case and Methodology for Performance
Management, 2001.
Если конструктор тестов производительности хочет выполнить всеобъемлющее
тестирование, в качестве тестов может использоваться набор сценариев,
добавляющих Web-серверы в базу данных до тех пор, пока не будет достигнут предел,
обусловленный применяемой базой данных (например, база данных может поддерживать до
1500 пользователей). Известно, что не более шести Web-серверов могут
функционировать на уровне сервера базы данных. При проведении другого тестового измерения
сетевой активности было получено среднее значение трафика, равное 10 Кбайт/с из
расчета па одного пользователя. Теперь, когда согласно заявлению менеджеров,
некоторые из пользователей переходят в другую организацию, в нашем распоряжении
оказалась модель, применяемая для определения требуемой пропускной способности
сетевого канала, — в данном случае идет речь о линии Т1 A500 Кбайт/с), способную
обслуживать до 150 пользователей одновременно.
В распоряжении предусмотрительного менеджера проекта имеются модели,
пригодные для всех вариантов загрузки критических ресурсов, когда описываются случаи
применения системных требований. При выполнении этих тестовых случаев
требуется управление машинным временем процессора, скоростью передачи данных в
глобальной сети, а также размером дискового пространства базы данных. В каждой

Использование инструментов 945
модели демонстрируется использование того либо иного ресурса в зависимости
важнейших двух либо трех факторов, имеющих значение в этом случае. В модели
сетевого канала следует учитывать размер канала, количество удаленных пользователей, а
также, возможно, объем и виды выполняемых действий.
Помимо проверки выбранных в ходе осуществления проекта целей, связанных с
измерением производительности, и генерации отчетов о методах измерения, в ходе
анализа производительности системы пользователи могут видеть эффект
воздействия системных требований прежде, чем система будет введена в эксплуатацию.
Анализ также позволяет указать циклы и тенденции, которые в противном случае могут
быть не замечены. Если пользователям известно, что система сильно перегружена в
последний день каждого месяца, они вполне могут выполнять второстепенную работу
в другое время либо отказаться от порочной практики повторного выполнения
огромных отчетов с целью изменения единственного числа. Даже если пользователи не
откажутся от своих привычек, они все равно будут осведомлены о возможных
последствиях, что, в свою очередь позволит избежать обращений в службу технической
поддержки. По крайней мере, в результате регулярного выполнения анализа
производительности системы, пользователи смогут лишний раз убедиться в том, что один
замедленный отклик не является нормой. Также демонстрируется, что в самом проекте
запланировано выполнение перечисленных ранее вопросов.
Инструменты по сопровождению ПО
Сопровождение программ может представляться в виде модифицированной
версии цикла разработки программного обеспечения для данной организации. Для
действий, выполняемых на различных фазах цикла разработки программного
обеспечения, могут различаться расставленные акценты. Сопровождение может быть
связанно со всеми фазами цикла разработки, а все инструменты, изначально примененные
для создания программного продукта, могут использоваться на этапе сопровождения
этого продукта. Ценность применяемых инструментов заключается в количестве
информации о разработке, которая поддерживается и может применяться повторно на
фазе сопровождения. Повторное применение информации о разработке особо важно
при тестировании. В этом случае требуется выполнение регрессионного
тестирования, в ходе которого проверяется отсутствие дополнительных ошибок, которые мо-
гут появляться во время устранения предыдущих ошибок.
На рис. 24.7 изображена часть жизненного цикла разработки ПО, имеющая
отношения к инструментам по выполнению сопровождения. Использование всесторонних
инструментов, обеспечивающих выполнение повторного инжиниринга, начинается на
фазе установки и продолжается на фазах эксплуатации, поддержки, сопровождения,
завершаясь на фазе вывода из эксплуатации. Обратите внимание, что составляющие
компоненты других инструментов, описанные в главе, могут использоваться в процессе
сопровождения существующих наследственных программных систем.
Обеспечение понимания — модель СММ,
пятый уровень
В этом разделе рассматриваются инструменты, позволяющие специалисту понять
принцип функционирования программы. При рассмотрении вопроса понимания
работы выполняющих систем, находящихся на этапе сопровождения, одними из первых

946 Глава 24
должны рассматриваться инструменты, между которыми возможна установка
перекрестных взаимоотношений. На этапе применения этих инструментов
просматривается и выбирается информация, имеющая отношение к исходному коду, а также
создается программная база данных. В то же самое время поддерживается интерфейс
запросов, с помощью которого программист может получать доступ к выбираемой
информации. Подобные инструменты встроены в среде разработки фирмы Microsoft,
которая называется Visual Studio. Перекрестные инструменты облегчают понимание
некоторых глобальных аспектов исходного кода, а также облегчают трассировку
потоков, имеющих отношение к интерактивному взаимодействию. Ограничение в этом
случае связано с тем, что не производится обзор структурных интерактивных
взаимодействий. В результате становится невозможным осознать смысл проекта. Также
уменьшается объем отображаемой избыточной информации, характерной для
перекрестных ссылок.
Установка
,
,
■ n
Эксплуатация
и поддержка
,
, .
ч
v
Сопровождение
1
N.
Вывод из
эксплуатации
Инструменты по проведению тестирования
Рис. 24.7. Место инструментов
сопровождения в жизненном цикле
разработки ПО
Следующий набор инструментов, способствующих лучшему пониманию сути
программ, обеспечивает визуализацию ПО. Благодаря применению этих
инструментов анализируется динамика поведения программ, а также предоставляется
возможность пользователю отображать все данные программы с помощью
интегрированного интерфейса пользователя. Инструменты визуализации
автоматизируют выполнение задач по анализу кода, обеспечивают выбор методов анализа
кода. Также выполняется поиск минимального тестового набора, отладка,
идентификация компонентов ПО, ответственных за реализацию того либо иного свойства,
строится профиль, обеспечивающий анализ производительности программ, а
также осуществляется поиск статических взаимосвязей внутри программы. В
результате применения подобных инструментов обеспечивается обзор структурной
информации, которая может "перекрывать" различные структурные отношения, а также
обеспечивать "непосредственный и точный" просмотр исходной информации. Как
и в случае с инструментами, между которыми установлены перекрестные ссылки,
выходные результаты могут быть объемными, а их анализ затруднен вследствие
отсутствия абстрагированных уровней обзора. Также проявляются затруднения при
создании соответствующего программного проекта.

Использование инструментов 947
Повторный инжиниринг — модель СММ,
пятый уровень
Инструменты повторного инжиниринга обеспечивают выполнение трансляции
существующих программ на новый язык программирования либо в базу данных,
имеющую новый формат. Инструменты реверсивного инжиниринга содействуют
протеканию обратного рабочего процесса, основанного на базе существующего
программного продукта. При этом преследуется цель, заключающаяся в создании
абстрактных компонентов, таких как описание проекта и спецификации. Эти
компоненты в дальнейшем могут трансформироваться. При этом на основе предыдущей версии
продукта разрабатывается новый продукт. Комбинация обратного инжиниринга
проекта и прямого либо повторного инжиниринга нового программного продукта,
многими производителями инструментальных средств обозначается как возвратно-
поступательный инжиниринг.
Цель применения инструментов реверсивного (обратного) инжиниринга
заключается в создании системных моделей высокого уровня на основе исходной
информации. Исходная информация может быть получена из программной базы данных,
созданной с помощью инструментальных средств визуализации ПО. Преимущества,
обеспечиваемые инструментами повторного инжиниринга, заключаются в
возможности проведения обзора системной структуры благодаря тому, что инструменты
выполнения повторного инжиниринга обычно поддерживают весьма точный обзор на
основе присущей им внутренней методологии интерпретации и создания
соответствующего проекта на основе исходного кода. Имеющиеся в этом случае ограничения
будут такими же, как и в случае с инструментами, способствующими лучшему
пониманию сути программ. И в этом случае создается избыточный объем информации,
вследствие чего инструмент не может применяться для создания отображения,
которое реально может использоваться инженером-программистом.
Инструменты по управлению конфигурацией
программ — модель СММ, второй уровень и выше
Минимум свойств SCM-инструментов (инструменты по управлению
конфигурацией ПО) тесно связаны с задачей обработки различных промежуточных продуктов,
создаваемых в процессе инжиниринга программного проекта. Инструментальные
требования и критерии выбора основываются на наборе свойств, обеспечивающие
формирование современной среды разработки ПО. Для SCM-инструментов должна
обеспечиваться многопользовательская поддержка, интуитивный графический
интерфейс пользователя, согласованность со средой разработки организации,
масштабируемость, гибкость при интегрировании с другими средствами разработки
программ, легкость установки, наличие изменяемых моделей, возможность управления
процессом, расширенная поддержка фазы разработки, а также возможность
управления объектами, не имеющими отношения к процессу разработки. На рис. 24.8
показано место SCM-инструментов в жизненном цикле разработки ПО.
Категории конфигурация могут быть представлены следующим образом.
1. Отслеживание дефектов, расширений, возникающих вопросов и проблем;
2. Управление версиями;
3. Разработка выпусков и подверсий.

948 Глава 24
Требования
Разработка
проекта
Внедрение
Установка
Эксплуатация
и поддержка
Сопровождение
Вывод из
эксплуатации
Менеджмент конфигурации
Рис. 24.8. Место инструментов управления конфигурацией в жизненном
цикле разработки ПО
Инструменты, применяемые в процессе
программного инжиниринга в жизненном
цикле разработки ПО
Как показано на рис. 24.9, инструменты, применяемые в процессе программного
инжиниринга в жизненном цикле разработки ПО, используются для выполнения
задач, связанных с реализацией процесса программного инжиниринга, обеспечением
качества, управлением инжинирингом, а также инфраструктурой. Эти инструменты
применяются на всех фазах жизненного цикла.
Инструменты, связанные с процессом
программного инжиниринга
Модель инструментария программного инжиниринга поддерживает среду, в
которой производится разработка программного продукта. В среде программного
инжиниринга, в которой центральное место занимают процессы, распознается важность
процесса разработки ПО, а также его динамическая природа. Поддерживаются
действия по определению процесса разработки проекта, последовательному
процессу мониторинга, а также поддержке выполнения программ. Некоторые наборы

Использование инструментов 949
инструментов поддерживают динамическое изменение выполняемого процесса.
Подобный тип изменения процесса, происходящий во время выполнения проекта,
похож на "смену колеса в быстро перемещающемся автомобиле". Все это может быть,
конечно, сделано, но контроль над процессом весьма затруднен.
Исследование
концепции
Исследование
системы
Требования
Разработка
проекта
Внедрение
Установка
Эксплуатация
и поддержка
Сопровождение
Вывод из
эксплуатации
Процесс инжиниринга, обеспечение качестаа, поддержка инфраструктуры, управление инжинирингом
~+ *.
Рис. 24.9. Место инструментов программного инжиниринга в жизненном цикле разработки ПО
Управление процессом — модель СММ,
четвертый уровень и выше
Управление процессом реализуется в виде действий, предпринимаемых
менеджерами проектов еще до начала выполнения любого проекта. Подобная деятельность
может описываться с помощью схемы, позволяющей выполнять количественную и
качественную оценку хода выполнения проекта. В ходе управления процессами
гарантируется корректное выполнение процедур и политик, принятых в организации,
а также модели жизненного цикла разработки ПО. При этом также контролируются
действия по разработке ПО. К примеру, может осуществляться проверка с целью

950 Глава 24
проверки имеющего место изменения запроса, причем получено одобрение на его
изменение, а соответствующий проект, документация, а также действия по обзору
были завершены прежде, чем была разрешена повторная "проверка" кода.
Инструменты по управлению процессом включают модель процесса и инструменты
обеспечения межличностного взаимодействия (описываются далее).
Моделирование процесса — модель СММ,
третий уровень
Управляемая модель процесса разрабатывается и документируется с помощью
инструментов, специально предназначенных для моделирования этих процессов. В
настоящее время вполне доступно множество инструментов моделирования процессов, а
начинать их поиск лучше всего в Internet. Если организация-разработчик не относится к
третьему уровню, моделирование процессов не приводит к заметному повышению
качества конечного продукта. Это действие также не может быть начато до тех пор, пока
существует определенный жизненный цикл разработки с четко проработанными и
задокументированными входными и выходными критериями. Все это может быть легко
задокументировано с помощью таких инструментов, как Visio. Процесс выбора
инструментов должен следовать строгим деловым принципам обеспечения прибыльности на
вложенный капитал. Причем все это должно происходить еще до этапа приобретения
дорогостоящего полнофункционального коммерческого инструмента.
Интегрированные CASE-среды — модель СММ,
четвертый уровень
Инструменты либо автоматизированного проектирования программ (Computer-
aided software engineering, CASE) охватывают несколько фаз цикла разработки
программного обеспечения, имеющих отношение к данной категории. Подобные
инструменты являются многоцелевыми и в принципе могут взаимодействовать с
процессом разработки программ, придавая ему способность к моделированию и управлению.
CASE-инструменты могут далее подразделяться на верхние CASE-инструменты,
применяемые для моделирования на фазах формулирования требований и
проектирования, и нижние CASE-инструменты, используемые в основном в качестве генераторов
кода на фазе реализации. В мире сред разработки фирмы Microsoft среда Visual Studio
классифицируется в качестве одновременно нижней и верхней CASE-среды
разработки. По мере того, как программный продукт позиционируется в качестве среды,
поддерживаемой Visual Studio, инструменты становятся полностью интегрированными.
В среде разработки Linux такие инструменты как AnyJ и ArgoUML поддерживают тот
же самый уровень покрытия, что и в случае их интеграции с помощью организаций-
разработчиков.
Некоторые CASE-инструменты предлагают возможности по моделированию
процесса и выполнению менеджмента. Эти интегрированные инструменты
фокусируются на специфичной методологии, такой как информационный инжиниринг, либо
объектно-ориентированной технологии. В большинстве сред менеджер проекта
должен уметь успешно адаптировать модель внутреннего процесса инструмента. При
выборе этих инструментов необходимо проявлять осторожность и заботиться
относительно возврата вложенных средств. С момента своего появления в начале 1980-х
годов, наборы и пакеты CASE-инструментов стали весьма популярными.

Использование инструментов 951
Среды программного инжиниринга с центрированными
процессами — модель СММ, пятый уровень
Менеджер, управляющий средами разработки, может представлять себе
подобный тип среды в виде комбинации всех описанных ранее инструментов. Модель
процесса программной разработки и интегрированные CASE-среды комбинируются
вместе с функциями управления процессом, выполняющими создание отчетов,
анализ, сопровождение и выделение. При этом обеспечивается автоматизация
непрерывного процесса усовершенствования пятого уровня модели СММ. В этом наборе
инструментов поддерживается обратная связь между процессом улучшения и тем,
что может быть получено и реализовано самим процессом. Сложность подобного
типа процесса разработки программного обеспечения ("конечный продукт—
конечный продукт") может быть недооценена со стороны менеджера. Подобный тип
инструментов лучше применять в организации, достигшей пятого уровня зрелости.
В организации подобного рода возможен всесторонний анализ и лучшая практика
проведения интервью (по сравнению с другими организациями, использующими
подобные типы инструментов).
Инструменты по обеспечению качества ПО
Инструменты, обеспечивающие выполнение контроля и проведение статического
анализа, могут применяться в организациях, соответствующих третьему уровню и
выше модели СММ. Качество программного обеспечения может быть в значительной
степени улучшено при использовании инструментов в зрелых организациях.
Контроль — модель СММ, третий уровень и выше
Контроль и различного рода обзоры относятся к наиболее важным составляющим
процесса разработки ПО. К счастью, в этом случае требуются лишь наиболее простые
инструменты: электронная почта, тестовые процессоры и электронные таблицы.
Извещение и отслеживание результатов, относящихся к действиям обзора и контроля,
может быть частью тщательно проработанного процесса, ориентированного на
использование потоков, но при этом не требуются какие-либо "экзотические"
инструменты. К основным инструментам, применяемых в этом случае, можно отнести
извещения членам команды относительно выполняемых действий, сбор результатов с
целью их оценки, а также публикация набросков, имеющих отношение к сеансам.
Статический анализ — модель СММ, четвертый
уровень и выше
В качестве основного инструмента, который может применяться в средах Windows
и Linux с целью осуществления базового статического анализа исходного кода, может
рассматриваться инструмент RSM (Resource Standard Metrics). Этот инструмент
предназначен для оценки исходного кода и выполнения анализа качества при исследовании
приложений ANSI С, ANSI C++ и Java в операционных системах Windows и Linux.
Инструмент RSM поддерживает синтаксис языков ANSI С, ANSI C++ и Java, а также
предназначен для осуществления анализа скомпилированного исходного кода. Исходный код,
который не был скомпилирован, не может быть корректно разобран с помощью RSM-
анализатора. Инструмент RSM может пропускать функции или конструкции кода, если

952 Глава 24
исходный код не был скомпилирован в соответствии со специфичной грамматикой
исходного языка. Инструмент RSM основан на применении оболочки, благодаря чему
пользователь может воспользоваться командной строкой либо строкой UNIX, либо
Xtcrm. если требуется запустить на выполнение инструмент RSM. Благодаря этому RSM
может быть интегрирован в состав Visual Studio, Kawa и другие интегрированные среды
разработки. С помощью этого инструмента можно создавать HTML-отчеты по
результатам измерений, которые связаны с гиперссылками исходного кода и форматом,
предусматривающим значения, разделенные запятыми, и применяемым для
непосредственного ввода данных в Excel и других электронных таблицах.
Инструменты по управлению разработкой ПО
Инструменты но управлению разработкой ПО обеспечивают фундаментальные
процессы по планированию проектов, управлению рисками и выполнению
измерений. Эти процессы являются критически важными, но необходимые для его
реализации инструменты либо затруднительно использовать, либо их просто трудно найти.
Важной составляющей этих инструментов является план, который является
обязательным для выполнения.
Планирование и отслеживание проекта — модель
СММ, второй уровень и выше
Основным инструментом, предназначенным для планирования и отслеживания
проектов, является электронная таблица. До тех пор пока в состав проекта включено
менее 100 отслеживаемых подзадач, а команда разработчиков проекта насчитывает
менее 5 человек, а также отсутствуют другие зависимости для задач, использование
инструментов управления коммерческими проектами является излишним. Менеджер
проекта должен иметь в виду, что конечная цель заключается в поставке успешно
завершенного качественного программного продукта в пределах выделенного бюджета
и графика работ. Вряд ли когда-либо потребуется создавать лучший в мире драйвер
мыши для инструмента управления программными проектами.
Управление рисками — модель СММ, второй уровень
и выше
В главе 18 рассматривалось управление рисками и поддержка применяемых
шаблонов. Эти шаблоны легко реализуются с помощью электронных таблиц. Для
управления рисками необходимы план и электронная таблица.
www.m2tech.net/rsm/default.htm. Инструмент Resource Standard Metrics, известный
под названием RSM, предназначен для осуществления оценок исходного кода и проведения
анализа качества ПО. Этот инструмент существенно отличается от инструментов,
представленных на современном рынке программного обеспечения. Инструмент RSM поддерживает
стандартные методы анализа исходного кода на С, ANSI C++ и Java в различных операционных
системах. Уникальным свойством RSM является поддержка практически любой операционной
системы. Благодаря этому у вас появляется возможность стандартизации измерений качества
исходного кода, а также методов измерений во всех подразделениях своей организации.
Инструмент RSM является быстродействующим, гибким и простым в применении средством, обес-
нечинающим методы измерения и оценку качества исходного кода.

Использование инструментов 953
Измерение — модель СММ, второй уровень и выше
В главе 21 рассматривались методы измерения, применяемые при планировании и
анализе программного проекта. Необходимыми в этом случае инструментами
являются план использования методов измерения и электронная таблица.
Инструменты поддержки инфраструктуры
В разделе рассматриваются инструменты, необходимые для реализации
межличностного взаимодействия, выборки информации, системного администрирования и
поддержки. Такие инструменты, как электронная почта, базы данных, Web-браузеры
и инструменты резервирования файлов, в общем случае не являются специфичными
ни для конкретной стадии жизненного цикла, ни для конкретного метода разработки.
Межличностные взаимодействия — модель СММ,
первый уровень и выше
Успешная деятельность менеджера проекта немыслима без организации
взаимодействия между членами команды разработчиков. Процесс разработки программ
требует усилий многих специалистов, с помощью которых обеспечивается понимание
сути всего продукта во время его создания. Ключ к этому взаимодействию — это
обеспечение его надежности. Почтовые программы, Web-ориентированные схемы,
образующие совместное использование документов, комнаты чата и приложения по
организации интерактивных встреч должны быть абсолютно надежными. Без
организации надежного общения проект обречен на неудачу.
Выборка информации — модель СММ, второй уровень
и выше
По мере роста степени зрелости организаций, выполняющих разработку ПО,
наблюдается увеличение количества данных, относящихся к процессу создания
программного продукта. В результате требуется организация хранения данных о процессе и
продукте, имеющих вид результатов измерений. И хотя использование электронных
таблиц является одним их простейших решений, через короткий промежуток времени
возможностей Excel будет совершенно недостаточно. Поэтому приходится переходить
к использованию простейших инструментов управления базами данных. Возможностей
Microsoft Access более чем достаточно для выполнения сбора данных, анализа и
составления отчетов. Такого рода информация может применяться для заполнения сведений
и управления инструментами, используемыми в средах разработки ПО, центральную
роль в которых выполняют процессы. Этот инструмент может применяться для
организации ключевого организационного репозитария, предназначенного для хранения
информации относительно улучшения процесса и действий процесса. При описании
процесса достижения зрелости организации уже упоминалось о том, что этот инструмент
способствует ускорению процесса достижения высших уровней зрелости.
Системное администрирование и поддержка — модель
СММ, второй уровень и выше
Для этой категории инструментов в качестве определяющего можно использовать
слово формальный. Это определение справедливо даже в том случае, если сам разработчик

954 Глава 24
выполняет администрирование операционной системы, а также поддерживает сетевые
соединения. Перемещение на высшие уровни зрелости процесса требует выполнения
формального процесса в рамках организации, ответственной за разработку, для
обеспечения системного администрирования и поддержки. Благодаря стандартизации типов
операционных систем, выпусков, установке сервисных пакетов, принятию мер
предосторожности, а также использованию базовых инструментов экономится время и трудозатраты
благодаря интефации разработчиков в стандартную производственную среду. Поддержка
постоянного и предсказуемого уровня поддержки является весьма важной, поскольку
в этом случае не требуется отладка и устранение одних и тех же системных ошибок силами
программистов. Благодаря наличию совместимого набора инструментов уменьшаются
затраты времени и возрастает производительность отдельных профаммистов.
Дополнительные вопросы применения
инструментов
Последняя категория инструментов по разработке профаммного обеспечения
называется "дополнительной". Здесь находятся инструменты, обеспечивающие
поддержку интеграции с другими инструментами, инструменты, предназначенные для
создания других инструментов, а также описываются методики оценки инструментов.
Методики интеграции инструментов — модель СММ,
третий уровень и выше
Интеграция инструментов применяется с целью объединения отдельных
инструментов в среде разработки ПО. Эта категория перекрывает среды разработки ПО,
в которых интеграционные методики являются частью набора инструментов.
Пригодность инструмента для использования в современной среде разработки ПО
определяется наличием некоторых определенных интерфейсов программирования
приложений (Application programming interface, API). Если не существует метода
взаимодействия и тем самым интегрирования с инструментом, вся информация и выходные
данные инструмента являются малоценными в плане получения каких-то новых
данных в среде. Не существует инструментов, которые могут трактоваться в качестве
"черных ящиков". Для перехода на пятый уровень модели СММ все инструменты
должны быть открыты для непрерывного процесса улучшения.
Интеграция инструментов достигается благодаря использованию языка написания
сценариев во всей среде. Если среда разработки основана на программных продуктах
фирмы Microsoft, в качестве языка написания сценариев может выбираться Visual
Basic. Если среда основана на применении Web-технологий, в качестве языка написания
сценариев может выбираться Perl. В средах со специфичной предметной областью,
например, в промышленности полупроводников, в качестве интегрированного языка
написания сценариев может использоваться Tcl/Tk.
Мета-инструменты — модель СММ,
первый уровень и выше
Как правило, разработчики используют инструменты с целью облегчению
процесса создания программного продукта, придания ему более устойчивого характера,
а также повторяемости. Инструменты могут приобретаться и создаваться на всем

Использование инструментов 955
протяжении жизненного цикла разработки программного обеспечения. Причем в
данном случае речь идет о намного более широком классе инструментов, чем
известный любителям компилятор UNIX YACC (Yet Another Compiler Compiler).
Любой инструмент, настройка которого связана с применением API, может
преобразовываться из инструмента общего назначения в инструмент специального
назначения. В качестве некоторых примеров можно рассматривать диспетчеры
презентаций, а также разработка демонстрации интерактивного графического
интерфейса пользователя, либо создание электронной таблицы и ее преобразование в
коллекцию данных измерений и инструментов анализа. Всем приложениям систем
управления базами данных присущи настраиваемые интерфейсы, реализующие
сбор данных, а также выходные отчеты. Они могут быть настроены в качестве
платформ для прототипирования и инструментов обеспечения интеграции
процессов. На ранних стадиях зрелости организации проще выполнить настройку
инструментов общего назначения с целью их использования в качестве новых
инструментов и процессов. В зрелых организациях могут выполняться инвестиции с
целью развития применяемых инструментов либо могут определяться спецификации
с целью приобретения коммерческих инструментов.
Инструментальная оценка — модель СММ, третий
уровень и выше
При выполнении инструментальной оценки необходимы лишь электронные
таблицы, перечень требований к инструментам, весовой фактор для каждого
требования, а также некоторые потенциальные поставщики. Поставщики
ответственны за то, чтобы каждое требование было введено в электронную таблицу. В
качестве вводимых данных могут использоваться двоичные 0 и 1 (указывающие на
наличие либо отсутствие того, либо иного требования). Когда поставщики практически
соответствуют всем требованиям либо превосходят их, может быть применена
шкала, которая ранжируется от 0 до 5. Здесь 0 указывает, что требование не
удовлетворено, 3 — удовлетворение требования, а 4 и 5 — уровни превышения требований.
Показатели 1 и 2 применяются для определения градаций приблизительного
удовлетворения требований.
В табл. 24.3 приводится пример работы инструмента, предназначенного для
оценки сложности кода. Раздел формулирования требований начинается фразой "Must
Have Requirements." ("Должны иметься требования".) Если эта фраза не применима
для оцениваемого инструмента, он не может быть выбран. В случае с инструментом В,
фраза "Must Have Result" ("Должен быть результат") также умножается на
взвешенный показатель. В ячейке со значением 0 значение величины будет равно 0. И
наконец, в ячейке "Nice to Have Requirements" ("Хорошо иметь требования") перечислены
все весовые факторы.
Как только в электронной таблице появятся результаты всех вычислений,
обычным будет максимальное значение в столбце Vendor D (Поставщик D). Этот
инструмент может использоваться для выполнения повторной оценки и изменения
показателей и весовых коэффициентов. Если была совершена ошибка при определении
обязательных требований, изменение 0 на 1 либо 1 на 0 приводит к изменению
показателя для поставщика. Этот тип оценки может применяться для любого типа
инструмента по разработке программного обеспечения.

956 Глава 24
Минимальные наборы инструментов
В табл. 24.4 содержится коллекция минимальных наборов инструментов,
применяемых по отношению к описаниям предыдущей категории инструментов.
Существует всего лишь две категории, Microsoft Windows и Linux. Большинство из Linux-
инструментов могут применяться в среде UNIX. Благодаря этому повышается
ценность минимального набора инструментов и расширяется спектр присущих им
свойств. Всем упомянутым инструментам присущи ограничения, которые делают
невозможным их применение для разработки программного обеспечения, критичного к
миссии либо имеющего промышленное назначение. Менеджер проекта должен
учитывать степень зрелости организации и устойчивость инструментов при уменьшении
степени риска. Упомянутые в этой главе инструменты являются всего лишь "точками
отсчета". Также приводится пример планирования и составления графика проекта.
В этом справочнике также описываются другие инструменты промышленного
масштаба. Но если менеджер проекта не владеет основами разработки пооперационного
перечня работ либо выполнения оценки, либо если его организация относится к
первому уровню модели СММ, автоматизация будет невозможной, а попытки ее
внедрения могут привести к хаосу.
Таблица 24.3. Оценка сложности инструментов
Требование
Должен иметь требования
Выполнение в Linux-среде
API для извлечения данных
Условное депонирование исходного
кода
и S
° Ё
и щ
0) я
1
1
1

Поставщик А
1за-
Покг
тель
1
1
1
шен-
Взве
ный
1
1
1

Поставщик
1за-
2 *
о S
0
1
0
в
шен-
Взве
ный
0
1
0

Поставщик

Показатель
1
1
1
С
шен-
Взве
ный
1
1
1

Поставщик
t3a-
Пока
тель
1
1
1
D
шен-
Взве
ный
1
1
1
Должен иметь результат
Следует формировать требования
Результаты оценки функции
из расчета на функцию
Количество строк кода (LOC)
eLOC (эффективный показатель LOC)
ILOC (логические операторы LOC)
Строки комментария
Пустые строки
Физические строки
Количество входных параметров
Количество точек возврата
5
5
5
5
5
5
4
4
3
3
2
4
5
2
1
1
15
15
10
20
25
10
4
4
5
5
5
5
5
5
4
4
0
0
0
0
0
0
0
0
3
2
1
1
2
3
2
1
15
10
5
5
10
15
8
4
3
4
4
4
5
5
5
3
15
20
20
20
25
25
20
12

Использование инструментов 957
Продолжение табл. 24.3
Требование

Поставщик А

Поставщик В

Поставщике

Поставщик D
О О- я £
я о 2 Э
5JL £ 3
.о S й *
IS
Н CQ
Я
и
В
£'5
в д
° 5
II
a
n 3
BQ SB
Сложность интерфейса
(параметры + возвраты)
Цикломатическая сложность
логического ветвления
Функциональная сложность
(интерфейс + цикломатика)
Качество из расчета на функцию
Функциональные параметры
Цикломатическая сложность
Функциональная сложность
Общин профиль качества
Класс методов измерения
Тип шаблона
Наследование
Глубина дерева наследования
Количество производных дочерних
классов из расчета на базовый класс
Сложность интерфейса (параметры
+ возвращаемые результаты)
Сложность класса
(интерфейс + цикломатика)
Информация об всех классах
Общее количество классов
Дерево наследования
Количество базовых классов
Соотношение
производный/базовый класс
Максимальная и средняя глубина
наследования
Максимальное и среднее количество
дочерних классов
Полностью соответствовать
требованиям
О
12
12
12
12
12
4
5
5
4
3
3
5
5
2
2
2
1
5
2
5
5
3
3
3
3
0
2
4
25
10
20
15
9
15
15
6
0
4
3
3
3
5
5
5
5
4
4
4
4
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
2
3
1
1
2
2
3
4
5
5
4
6
9
5
5
4
4
6
5
5
5
5
4
4
4
4
4
5
5
20
25
25
20
12
12
20
20
8
10
10
3
3
3
3
3
3
3
3
3
3
3
3
9
9
9
9
9
9
5
3
4
5
4
5
0
0
0
0
0
0
3
3
3
2
1
1
9
9
9
6
3
3
5
5
5
5
5
5
15
15
15
15
15
15

958 Глава 24
Окончание табл. 24.3
Требование
о е-
и 2
II

Поставщик
а
Показ
тель
5
5
5
5
5
5
5
5
5
А
ш
и
В
Взве
ный
5
5
5
5
5
5
5
5
5

Поставщик
я
Показ
тель
2
3
1
3
2
1
2
2
4
В
я
и
В
Взве
ный
0
0
0
0
0
0
0
0
0

Поставщик
а
к
1
1
1
2
2
2
2
2
2
С
£
<и
Е
Взве
вый
1
1
1
2
2
2
2
2
2

Поставщик
а
к
3
4
3
4
3
3
3
4
4
D
£
V
Е
Взве
ный
3
4
3
4
3
3
3
3
4
Пространство имей либо пакетная
метрика
Из расчета на пространство имен
Количество классов
Количество функций
Среднее количество функций
в классе
Количество общедоступных, частных
и защищенных атрибутов данных
Количество общедоступных,
частных и защищенных методов
Количество входных параметров
Количество точек возврата
Сложность интерфейса
(параметры + возвраты)
Итого
342
217
511
Все перечисленные Linux-инструменты являются либо бесплатными либо условно
бесплатными. И несмотря на наличие бесплатных и условно бесплатных версий для
платформы Windows, большинство пользователей не склонны применять открытые
источники ресурсов, как это принято у пользователей Linux.
Таблица 24.4. Минимальные наборы инструментов
Класс инструмента
Специфический тип Инструменты Win-
инструмента dows-платформы
Инструменты
Linux-платформы
Инструменты по
определению
требований к программе
Инструменты по
проектированию
программного
обеспечения
Инструменты по
конструированию
программ
Моделирование
требований
Трассировка
Моделирование
проекта
Верификация проекта
Оптимизация проекта
Редакторы
программного кода
Visio Access
Excel
Visio
Access
Visio Excel
Visual Studio
Visual Studio
Dia
QuickList
abs
ArgoUML
ArgoUML
abs
ArgoUML
Emacs

Использование инструментов 959
Класс инструмента
Инструменты по
тестированию программ
11нструменты по
сопровождению ПО
Инструменты,
относящиеся к процессу
разработки программ
Инструменты по
обеспечению
качества ПО
Инструменты по
управлению
конфигурацией ПО
Инструменты по
управлению
разработкой ПО
Специфический тип
инструмента
Компиляторы
Интерпретаторы
Отладчики
Генераторы тестов
Схемы выполнения
тестов
Оценка тестов
Управление тестами
Анализ
производительности
Понимание сути
созданных программ
Повторный
инжиниринг
Управление
процессом
Моделирование
процесса
Интегрированные
CASE-среды
Среды разработки
программного
обеспечения, в центре
которых находятся
процессы
Проверка
Статический анализ
Отслеживание
дефектов, расширение,
контроль различных
вопросов и проблем
Управление версиями
Выпуски и подверсии
Планирование и
отслеживание проектов
Управление рисками
Измерение
Инструменты
Windows-платформы
Visual Studio
Visual Studio
Visual Studio
Access
Visual Studio
Excel
Visual Source Safe
Excel
Visual Studio
Visual Studio
email, Web, текстовый
процессор
Visio
Visual Studio
email, текстовый
процессор, Excel
RSM
Visual Source Safe
Visual Source Safe
Visual Source Safe
Excel
Excel
Excel
Продолжение табл. 24.4
Инструменты
Linux-платформы
AnyJ
Perl
AnyJ
QuickList
ArgoUML
Perl
abs
CVS
abs
Cxref
ArgoUML
email, Web, текстовый
процессор
Dia
AnyJ
email, текстовый
процессор, abs
RSM
CVS
CVS
CVS
abs
abs
abs

960 Глава 24
Класс инструмента
Инструменты по
поддержке
инфраструктуры
Дополнительные
вопросы применения
инструментов
Специфический тип
инструмента
Межличностные
взаимодействия
Системы выборки
информации
Администрирование и
поддержка
Интеграционные
инструментальные
методики
Мета-инструменты
Инструментальные
оценки
Инструменты
Windows-платформы
email, Web-чат
Access, Web
email, Web
Visual Basic, Perl,
Tcl/Tk
Access, Excel
Excel
Окончание табл. 24.4
Инструменты
Linux-платформы
email, Web-чат
QuickList, Web
email, Web
Perl, Tcl/Tk
Dia, abs
abs
Резюме
В целях создания схемы выбора инструментов менеджеры проектов могут
воспользоваться жизненным циклом проекта и моделью улучшения процесса,
разработанной на базе организации. Ранее уже упоминалось о том, что инструменты по
разработке и инжинирингу программ, поддерживающие жизненный цикл разработки
программного обеспечения, описаны в документе SWEBOK. В табл. 24.1 приводятся
SWEBOK-инструменты наравне с дополнительными инструментами, применяемыми в
целях верификации и оптимизации.
Установленная взаимосвязь между процессами пяти уровней модели зрелости
возможностей, предложенной Институтом программного инжиниринга (Software
Engineering Institute), и отдельными инструментами, перечисленными в документе
SWEBOK, гарантирует, что не будет происходить автоматическое инвестирование
средств без учета степени зрелости организации. Использование инструментов в
недостаточно зрелых организациях часто приводит к созданию некорректных продуктов.
Изменчивость рынка инструментов по работе с ПО обуславливает полезность
создания перечней специфических инструментов. Для организации поиска
существующих инструментов и поставщиков воспользуйтесь поисковым механизмом в Internet,
например, Copernic (www.copernic.com). Так, в результате задания строки поиска
"software requirement modeling" возвращается перечень из 106 активных Web-
страниц. Благодаря применению этой предварительной поисковой информации,
наравне с представленными методиками инструментальных оценок, обеспечивается
автоматизированный поиск и выбор инструментов.
Контрольные вопросы
Возьмите программу на языке C/C++ или Java, исходный код которой содержит
менее 500 строк. Загрузите инструмент RSM с Web-узла www.m2tech.net/rsm/
default, htm и установите его в вашей компьютерной системе. Предоставьте
следующую информацию, касающуюся вашего исходного кода.

Использование инструментов 961
A. Общее количество LOC, eLOC, ILOC, комментариев, пробелов, строк.
B. Общее количество функциональных показателей измерений.
C. Общее количество классов показателей измерений.
D. Общее количество пространств имен для показателей измерений.
E. Дерево наследования и показатели измерений.
F. Ключевые слова, конструкции и показатели измерений для языка.
G. Профиль качества.
Н. Факторы оценки показателей измерений для оценок программного
обеспечения.
I. Итого по С, C++ и заголовочным файлам.
J. Итого по файлам Java.
К. Общее количество файлов.
2. Для среды разработки C++ в операционной системе Microsoft Windows NT
требуется инструмент по управлению конфигурацией. Постройте инструментальную
оценку и воспользуйтесь ею для ранжирования четырех инструментов управления
конфигурацией.
3. Установите соответствие между категориями SWEBOK-инструмента и спиральной
моделью разработки программного обеспечения, принадлежащей Боэму (Boehm).
4. Опишите процесс и специфические инструменты, которые могут быть полезны
для того, чтобы сделать доступной систему анализа портфеля акций, работающую
в режиме командной строки и написанную на С, и преобразовать ее с учетом
применения языка Java для выполнения в окне Web-броузера.
Практическое занятие
20 марта 2001 года правительство Китая заявило о намерении выделить средства
фирме Red Flag Software, являющейся крупнейшим разработчиком ПО под Linux.
Подобное решение было принято с целью преодоления засилья программных
продуктов Microsoft на рынке программного обеспечения. Правительственные
учреждения Китая и бюджетные организации обязали к переходу на использование
продукции фирмы Red Flag Software. В силу этого мистер Лу указал на необходимость
развертывания программного обеспечения ARRS в среде разработки и поддержки Linux.
Поскольку в данный момент вы ведете разработки на Java, мистер Лу вспомнил ваши
презентации, где Java описывался как средство для создания переносимых программ
("раз написал, везде используй").
Проект, создаваемый и развертываемый в среде разработки программного
обеспечения Java, должен отвечать следующим требованиям.
1. Выполнение на любой платформе Pentium I.
2. Объем жесткого диска не менее 4 Гбайт.
3. Загрузка с CD-ROM.
4. Компьютер должен иметь доступ к Internet.
5. Компьютер должен отвечать требованиям экологических стандартов.

962 Глава 24
6. Должна быть включена вся программная система.
7. Стоимость поставки системы для конечного пользователя не должна превышать
200 единиц в местной валюте.
8. В стоимость системы не включается стоимость оборудования.
9. Вся документация должна быть доступной для просмотра в окне браузера.
10. Все ПО должно быть лицензионным.
11. Обязательное использование инструментов, охватывающих все фазы жизненного
цикла.
12. Должны быть реализованы все процессы поддержки проекта.
13. Должна поддерживаться командная среда разработки.
14. Обязательная поставка полной системы в комплекте с документацией.
15. Для программы xTremeObjectMaker существует Linux-версия. Необходимо
включить ее в ваши планы, ибо она является основной для ваших промежуточных
продуктов и приемочных испытаний.
Инструменты
argouml .tigris.org/. Цель проекта ArgoUML заключается в построении объектно-
ориентированного инструмента по проектированию программного обеспечения, который
является простым в применении, оказывает реальную помощь дизайнерам в процессе принятия
решений, полностью поддерживает Open Resource Java, является современным (поддерживает
последние UML-спецификации), модульным, расширяемым и интегрированным в Web и с другими
инструментами Tigris.
cvshome. org/. Аббревиатура CVS расшифровывается как Concurrent Versions System (Система
параллельных версий), доминанта системы контроля версий, обладающая свойством сетевой
"прозрачности" и поддерживающая открытые ресурсы. Этот инструмент полезен как отдельным
пользователям, так и большим, распределенным командам разработчиков. Применяемые клиент-
серверные методы доступа позволяют разработчикам получить доступ к последнему коду в Internet.
Незарезервированная модель контроля версий позволяет избежать конфликтов, которые являются i
привычными для эксклюзивной модели проверки. Соответствующие клиентские инструменты дос- i
тупны для большинства платформ. i
sourceforge.net/foundry/tci-foundry/. Язык написания сценариев Foundry for Tel
(Tool Command Language, Инструментальный командный язык) является межплатформенным
(Unix/Windows/Macintosh и т.д.). Этот язык был создан Джоном Остерхутом (John Ousterhout) в
1988 году и использовался многими организациями и фирмами. Проект tel SF (SourceForge) имел
основной исходный код Tel, а проект tktoolkit располагал исходным кодом Tk ("tk" означает "too short"
(слишком коротко). В ходе неформального обзора выявляется более 100 проектов, которые тем или
иным образом связаны с Tel. Если ваш проект в этом перечне отсутствует, просмотрите одно из
руководств по Foundry.
www.gedanken.demon.co.uk/cxref/. Программа Cxref предназначена для продуцирования
документации (в LaTeX, HTML, RTF и SGML), включая перекрестные ссылки на исходный код
программ на языке С. Она предназначена для работы с ANSI С, включая K&R и наиболее популярные
расширения GNU. Документация к программе создается на основе комментариев к коду,
отформатированных соответствующим образом. Перекрестные ссылки позаимствованы из кода и не требуют
какой-либо дополнительной обработки.
www. gnu. org/software/emacs/. Редактор GNU Emacs является настраиваемым, расширяемым
и отображает информацию в реальном режиме времени. Он еще называется дисплейным
редактором, поскольку, как правило, редактируемый текст отображается на экране и по мере ввода команд

Использование инструментов 963
автоматически обновляется. Также эта программа называется редактором режима реального
времени, поскольку отображение обновляется очень быстро, обычно после ввода каждого символа.
Благодаря этому минимизируется объем информации, запоминаемой пользователем при вводе. Редактор
GNU Emacs обеспечивает свойства, выходящие за рамки простых операций вставки и удаления:
заполнение текстом; автоматическое создание отступов в тексте программы; просмотр нескольких
файлов одновременно; определение обработки текста в терминах символов, строк, слов, сентенций,
абзацев, страниц, а также в виде выражений и комментариев, написанных с применением
нескольких языков программирования.
www. lysator. liu.se/~alla/dia/dia.html. Программа Dia представляет собой средство
создания диаграмм, которое основано на gtk+, и выпуск которого регламентировался лицензией CPL.
Программа Dia спроектирована намного лучше, чем коммерческая Windows-программа Visio. Она
может использоваться для рисования различных диаграмм. В настоящее время в ее состав включены
объекты, облегчающие рисование диаграмм взаимосвязей между сущностями, UML-диаграмм. блок-
схем, сетевых диаграмм, а также простых схем. Также можно добавлять поддержку новых форм
путем написания простых XML-файлов, использующих поднабор SVC для рисования форм.
www.microsoft,com/ms.htm
www. netcomputing. de/html/main.html. Среда AnyJ является межплатформенной
интегрированной средой разработки Java, она также может обеспечивать разработку исходного кода. В ее
состав включены различные браузеры и инструменты осуществления анализа. Visual GUI-Builder,
совместимый с Java Beans (JFC, Swing), отладчик на уровне исходного кода, а также очень мощный,
"интеллектуальный" и быстрый редактор.
www. perl. com/pub. Интерпретирующий язык Perl оптимизирован с целью сканирования
произвольных текстовых файлов, выборки информации из этих файлов, а также для вывода на печать
отчетов, сформированных на базе этой информации. Этот язык хорошо подходит для решения
многих задач, реализующих управление системой. При его разработке учитывались практические
соображения (простота в применении, эффективность и завершенность), а ие красота (изящество,
элегантность, компактность). Он объединяет в себе (по мнению автора) некоторые из лучших свойств
языка С, sed, awk и sh, поэтому те, кто знаком с этими языками программирования, не будут
испытывать особых затруднений.
www.ping.be/bertin/abs. shtml. Приложение abs представляет собой автономную
современную электронную таблицу, способную работать на любой UNIX-платформе. Это приложение ведет
свое происхождение от макроязыка ABVisual (совместим с Microsoft Visual Basic). Программа abs
также может обмениваться данными с Microsoft Excel с помощью Visual Basic. Все данные, форматы,
рисунки, элементы управления и диаграммы экспортируются в Microsoft Excel. Распространение abs
вместе с исходным кодом осуществляется согласно лицензии General Public License. Сейчас эта
программа находится в стадии разработки, но промежуточный вариант уже достаточно устойчив и
может применяться в практических целях.
www.quicklist.org/. Программа QuickList представляет собой свободно распространяемую
gtk+-nporpaMMy (в рамках лицензии GPL). Она предназначена для применения вместе с системами
UNIX, в которых установлен gtk+ версии 1.2 и более поздние. Эта программа обеспечивает новичкам
и опытным пользователям возможность отслеживания "вещей" без какой-либо помощи со стороны
системного администратора. В роли "вещей" может применяться что угодно, например, перечни
ошибок, телефонные списки, рестораны, члены команды, календари, интересные ссылки URL,
флажки, рыболовные сети, CD-ROM, ссылки на интересные Web-сайты и т.д. Здесь проявляется
полная свобода выбора. Программа QuickList может перечислять "вещи" в колоночном формате,
почти в том же виде, в котором они отображаются в электронной таблице. Планируется
отображение "вещей" по одной на странице в формате "форм". Данные могут редактироваться либо в форме
списка, либо в форме "формы". Программа QuickList может сортировать списки "вещей",
осуществлять поиск среди них, а также выводить на печать соответствующие отчеты.

964 Глава 24
Литература
Gaig Pankaj К. and Mehdi Jazayeri. Process-Centered Software Engineering Environments. IEEE Computer
Society Press, 1999.
Дополнительные сведения в Internet
seaxch.kachinatech.com/index.shtml. Информационная коллекция SAL (Scientific
Applications on Linux, научные приложения на Linux) содержит сведения и ссылки на ПО, которое может
представлять интерес для ученых и инженеров. Благодаря широкому охвату Linux-приложений сайт
пользуется вполне заслуженной популярностью в сообществе приверженцев Linux/UNIX. В
настоящее время в коллекции SAL имеется 3017 записей.
www.construx.com/. На странице "Software Engineering Tools" перечислены ресурсы,
посвященные разработке ПО, которые поддерживаются Construx и другими организациями. Эта страница
обеспечивает доступ к свободно распространяемой программе, позволяющей выполнять
оценивание программных проектов. Здесь также поддерживаются ссылки на другие подобные программы и
ресурсы Internet, связанные с проведением оценок. Страница "Software Development Checklists"
содержит ссылки на несколько десятков контрольных списков, охватывающих все аспекты разработки
ПО, включая определение требований, архитектуры и проекта, кодирование, а также управление
договорами на разработку программ. На странице "Document Templates" обсуждается одна из
основных помех на пути к достижению большей эффективности в техническом и управленческом аспекте:
неизвестно, какие документы, связанные с ПО, могут выглядеть таким образом. На этой странице
содержатся образцы документов определения требований, документы по проектированию, описы-
ьаются стандарты кодирования, а также многие другие документы. Здесь также находится исходный
код на различных языках программирования. Страница "Survival Guide Web Site" указывает на книгу
Survival Guide Web Site, написанной ведущим программистом фирмы Construx Software, Стивом Мак
Коннелом (Steve McConnell). Страница "Links to Other Resources" поддерживает ссылки на ресурсы,
обеспечиваемые другими организациями.
www.cs.geensu.ca/Software-Engineering/. Здесь можно найти архивы групп новостей
USENET, сотр. software-eng, включая ответы на часто задаваемые вопросы (FAQJ. Зеркало этого
архива находится на Web-узле Венского технологического университета, Австрия; мастер-копия
находится в Отделе вычислений и информационных наук Королевского университета в Кингстоне,
Канада.
www. li . org/. Организация Linux International является неприбыльной и объединяет группы и
корпорации, а также другие структурные единицы, работающие в области развития операционной
среды Linux и способствующие росту сообщества Linux.
www.qucis. qeensu. ca/Softviare-Engineering/tools. html. Индекс CASE-инструмента
представляет собой неплохую стартовую точку отсчета для поиска в Web. По причине изменчивости
"природы компаний-разработчиков" большинство из Web-ссылок в настоящее время не активны.
www. spmn. сот/. Миссия SPMN заключается в поиске лучших методик проверенного в
промышленности и в правительственных учреждениях ПО с целью их передачи менеджерам
широкомасштабных программ для Министерства обороны США. Благодаря экстенсивному применению опыта
"нахлебника", SPMN позволяет менеджерам достигать успеха в рамках проекта при производстве
качественных систем точно в срок и в рамках выделенного бюджета.
www. swebok.org/, К досаде миллионов программистов во всем мире, несмотря на
повсеместность IIO, его разработка так и не получила статус легитимной инженерной дисциплины и почетной
профессии. Начиная с 1993 года общество IEEE Computer Society и ACM начали активно
позиционировать разработку ПО в качестве профессии. Успешному позиционированию способствовал
большой "вес" организаций IEEE Computer Society и ACM Software Engineering Coordinating Committee.

Отслеживание
и контроль в процессе
выполнения проекта
Несмотря на то, что на разработку некоторых проектов затрачивается очень много
усилий и времени, они, тем не менее, не находят своего применения. Мастерство
управления проектом заключается в умении отслеживать и анализировать реальный ход
выполнения, а не только затраченные усилия. В данной главе представлены методы и
инструментальные средства, с помощью которых осуществляется контроль в процессе
выполнения проекта. Также был использован анализ прибавочной стоимости для
оценки прогресса в достижении установленных стадий с учетом оценок времени.
Стадии жизненного цикла
разработки продукта
Вернемся к основной модели жизненного цикла разработки ПО, которая служит
нам своеобразной "дорожной картой". Как показано на рис.4.1 и 25.1, наша основная
цель — разделы, ориентированные на выполнение, а не относящиеся к планированию
жизненного цикла. Данные разделы включают все этапы разработки продукта, а
также его установку. При отслеживании хода выполнения требуется определенный план,
поэтому пока спонсорами не будет одобрен план разработки ПО, не может быть
начат реальный процесс измерений.
В терминах схемы процесса проектирования, изображенного на рис.25.2, мы
находимся на этапе выполнения: план SPMP одобрен, а трудозатраты команды теперь
соизмеряются с планом и графиком. При каждом обзоре проверяются все компоненты
тройного ограничения.
Связь главы 25 с 34 компетенциями
Отслеживание действий проекта требует навыков по производству продукта в
ходе менеджмента субподрядчика и отслеживание качества. Необходимые навыки
управления проектом подразумевают выбор и контроль над процессами разработки, а

Отслеживание и контроль в процессе выполнения проекта 967
Исследование
концепции
■ Формули-''
рование

потребности
Исследование
системы
' Спецификация
интерфейса
системы
Идентификация
циклов SLC
' Циклы SLC
Выбор
модели
' Модель SLC
Установка
соответствия
между
задачами и циклами
SIX с помощью
IEEE 1074
■SLC
Распределение
ресурсов
1 Бюджет
Требования
■ Спецификация
требований
к ПО
Разработка
проекта
■ Описание

разработки ПО
Внедрение
■ План

тации/верификации ПО
Выбор модели
жизненного цикла
разработки ПО
Установка
■Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
'
Пользовательская
документация
Сопровождение
' Документация''
по
сопровождению
Вывод из
эксплуатации
• Архивный
отчет
Рис. 25.1. Схема процесса разработки программного продукта
Почему ?
Коэффициент
КОИ
Что?
Техническое
задание
(на проект)
Как?
ПланБРМР
/
Выполнение
Жизненный
цикл
/
Отслеживание
Сделано
П
роцесс РРА
Рис. 25.2. Этапы программного проекта

968 Глава 25
также отслеживание процесса и хода выполнения проекта. Навыки менеджмента
персонала включают оценку рабочих характеристик членов команды, а также управление
изменениями в организации. На протяжении всего процесса разработки проекта
возникает необходимость взаимодействия и общения с разработчиками, руководством
высшего звена и другими командами. Ниже представлены данные компетенции.
Методики разработки продукта
1. Управление субподрядчиками— планирование, менеджмент и осуществление
контроля.
2. Отслеживание качества продукта— контроль качества в процессе разработки
продукта.
Навыки менеджмента проектов
3. Отслеживание процесса разработки — мониторинг процесса разработки ПО.
4. Выбор метрических показателей— выбор и использование соответствующих
метрических показателей.
5. Отслеживание процессов — мониторинг совместимости среди членов
проектной команды.
6. Отслеживание хода разработки проекта — отслеживание хода разработки
проекта с помощью выбранных метрических показателей.
Навыки менеджмента персонала
7. Оценка производительности— оценка действий команды, направленная на
улучшение ее производительности.
8. Взаимодействие и общение — взаимодействие с разработчиками, высшим
руководством и другими командами.
9. Управление изменениями — обеспечение эффективного управления изменениями.
Учебные цели главы 25
После изучения материала главы читатель должен уметь выполнять следующее:
ш описывать несколько различных способов отслеживания и управления
действиями в рамках проекта;
ш демонстрировать возможность нарушения графика проекта;
ш объяснить отличие между менеджментом прибавочной стоимости и менеджментом
буфера критической цепи;
ш выполнять оценку менеджмента прибавочной стоимости;
ш описывать требования, выдвигаемые при изменении системы контроля за проектом;
■ объяснять принцип использования матрицы гибкости.
Контролирующие системы
Для обеспечения эффективной работы менеджера проекта разработки ПО
необходимо создание системы контроля и управления проектом. Что представляет собой
эта система? Обычно это процесс, управляющий и контролирующий другие процессы.

Отслеживание и контроль в процессе выполнения проекта 969
Например, бытовой термостат представляет собой систему управления и контроля,
предназначенную для поддержания комнатной температуры, заданной в
определенном диапазоне. Все системы управления и контроля имеют однородную
структуру, как показано на рис. 25.3.
Выходы
Рис. 25.3. Обобщенная система контроля
Важной частью системы является цепь обратной связи, "проложенная" от выхода до
входа, благодаря чему обеспечивается возможность контроля и корректировки.
В процессе управления проектом это обычно означает сбор данных, проверку их
достоверности, анализ, подведение итогов и своевременный отчет.
Причем своевременность особенно важна. Как уже упоминалось ранее, управление
проектом посредством изучения месячных и квартальных отчетов сродни попытке вести
машину по желтой полосе, всматриваясь в зеркало заднего вида. Необходимо иметь такие
данные, с помощью которых можно предугадывать предстоящие действия и события,
чтобы вовремя отреагировать соответственным образом. Более современные бытовые
термостаты обладают такими характеристиками, с помощью которых обеспечивается
постепенная адаптация температуры к новой настройке до запрограммированного момента
времени. Проанализировав входные данные, имеющие отношение к параметрам проекта,
найдите индикаторы выходов, которые действительно прогнозируют то, что может
произойти, прежде чем будут собраны все данные. Примером индикатора, характерного для
проекта разработки ПО, могут служить проверочные метрические показатели, с помощью
которых ведется статистика израсходованного времени и количества обнаруженных
дефектов, оглашаемая на совещаниях, посвященных регистрации данных формальных
проверок. Эти данные можно получить сразу же по завершении встречи. На их базе может
быть сформирован хороший прогноз качества нисходящего потока результирующего
рабочего продукта, поскольку слишком малое количество дефектов, обнаруженных за время
проверки в фазе проекта (сравнительно с ожидаемым в распределении Рэлея), означает,
что члены команды не могут найти достаточное количество ошибок. В результате
настоящие ошибки обнаружатся позже (например, заказчиком), когда их исправление будет
стоить намного дороже. Другими индикаторами являются все более интенсивное
использование сверхурочного времени с целью завершения действий. Все описанные выше объекты
представляют собой элементами системы контроля.
Контроль, управление и составление отчетов
о процессе
Основным, но необязательно очевидным для любого проекта является
определение набора процессов, которых необходимо придерживаться при выполнении
проекта. Некоторые из этих процессов определяются в плане SPMP, другие же определя-

970 Глава 25
ются в планах риска, качества или взаимодействия. В ходе разработке в крупных
организациях проект обычно приспосабливается (по возможности) к стандартным и
хорошо известным процессам родительской организации, часто без явной ссылки на
последние (они просто являются частью культуры проекта). Важно, чтобы эти
процессы вводились в культуру проекта по следующим причинам.
■ Проектной организации не будет наноситься ущерб в случае увольнения ее членов
(нежелательно, чтобы с каким-либо увольняющимся членом команды от вас
"уплывало" его ноу-хау).
■ Организационная культура проекта является способом введения в процесс новых
членов. (Отношение определяет внимание к деталям и качеству).
■ Управляющий персонал обязан "воспитывать культуру". (Менеджер проекта
должен активно способствовать осознанию соблюдаемых процессов и процедур).
■ Культура выражается через ролевые модели и премии. (Организация
приспосабливается к характеру своего руководителя; вы получаете такой тип поведения,
которого заслуживаете).
В тех случаях, когда проект организовывается и начинается "с нуля", "чистые",
простые процессы (что делать) и процедуры (как их делать) должны соблюдаться
всеми. Они включают в себя следующие параметры (не ограничиваясь только ими):
■ управление конфигурацией и процедуры управления и контроля над
изменениями;
■ процедуры отчетности об информации;
■ процедуры контроля за качеством.
Итак, чтобы контролировать проект, необходимо определить набор процессов и
процедур. Но и это еще не все. Требуется также установить соответствующую систему
контроля, как описывалось выше. Более подробную информацию об управлении
процессами можно почерпнуть из главы 3 данной книги.
Информационная система управления проектами
При разработке любого проекта используются источники информации, к которым
должен иметь доступ менеджер проекта. Множество данных измерений об элементах,
связанных с кодом, доступны в большинстве сред менеджмента конфигурации и
инструментальных средств разработки. В результате проведения встречи, результаты
которой отражаются в памятных записках и замечаниях, часто фиксируются ценные
сведения. Журналы вывода содержат индикаторы проблем, возникающих в рамках проекта-
Журналы дефектов содержат информацию о качестве. Существует множество
способов создания полезной информационной системы управления проектом (Project
management information system, PMIS) на основе данных источников. Основная
система PMIS вашей организации может быть просто расширением инфраструктуры
управления ходом проектирования; в противном случае потребуется сконструировать
свою собственную систему. Какой бы ни была эта система, она должна обеспечивать
своевременную обратную связь, которая включает, как минимум, элементы
диаграммы тройных ограничений, как показано на рис. 1.4 (а также на рис. 25.4).
При каждом обзоре проекта его руководство и заказчик (а также и команда
разработчиков проекта) могут поинтересоваться, в каком месте согласуется проект с
параметрами тройных ограничений для области действия, графика, цены и качества.

Отслеживание и контроль в процессе выполнения проекта 971
Работа руководителя проекта и заключается в
том, чтобы определить местонахождение
подобных факторов и сообщить об этом как можно
точнее. В связи с этим в последующих разделах
освещаются вопросы и методы, относящиеся к этим
четырем параметрам. Некоторые другие главы,
например, 29, 26, 23, 30 и 31 содержат другую
специфичную информацию, полезную при
разработке информационной системы управления
проектом. Кроме того, во многих главах, освещающих
основные темы разработки ПО (требования, про- Рис 25.4. Тройные ограничения проекта
ект, анализ и т.д.) содержатся полезные методы и
инструменты, используемые для мониторинга производительности при разработке
программных проектов, проверки соответствия продукта техническим требованиям,
а также для достижения качества.
Менеджмент области действия проекта
Если допускается свободное изменение проекта, то темп изменений будет
превышать скорость выполнения проекта.
Неизвестный автор.
Разработка каждого проекта требует управления изменениями, иначе все
довольно быстро может выйти из-под контроля. Самое худшее, что может случиться с
проектом, — "раздувание" области действия, когда требования превышают возможности
контроля. В результате наступает критический момент, когда возможности команды
разработчиков и резервы времени становятся недостаточными для выполнения
требований. В связи с этим возникает потребность в системе управления областью
действия. Она представляет собой систему управления изменениями, нацеленную на
менеджмент области действия. Основными элементами системы управления
изменениями являются следующие:
■ средства идентификации и номенклатуры— разработка плана наименования во
избежание путаницы;
■ процесс управления основами и обработка изменений с целью сохранения версий
и идентификации владельцев;
■ способ сообщения о текущем статусе любого из всех существующих элементов для
обработки запросов или сводок;
■ периодический процесс аудита или обзора для обеспечения целостности
имеющихся данных.
Система менеджмента конфигурации разработки проекта состоит обычно из этих
основных частей системы управления и контроля (для получения сведений о системе
менеджмента конфигурации обратитесь к главе 31). Действительно, в документе IEEE
1042 неплохо описаны данные вопросы. Однако система управления областью
действия — это нечто больше, чем просто система управления конфигурацией. Система
менеджмента конфигурации (СМ) представляет собой подмножество системы управления
областью действия проекта. А СМ-инструмент просто представляет собой подмножество
СМ-системы, как показано на рис.25.5.

972 Глава 25
Рис. 25.5. Взаимосвязь между менеджментом
конфигурации и системой контроля за
выполнением проекта
Основная идея процесса, реализующего контроль изменений, заключается в том,
что все изменения начинаются как "запросы", которые должны пройти через
заданную контрольную точку, обычно это определенного рода группа контроля над
внесением изменений (Change control board, CCB). Данная группа может быть
представлена как одним человеком, частично занятым в разработке небольшого проекта, так и
крупным отделом, работающим над солидным контрактом на производство и
поставку военной продукции. При любой форме контроля всегда присутствует
определенный вид официального хранилища официальных версий того, что имеет важное
значение для проекта. Для программных продуктов СМ-система представляет собой
библиотеку рабочего продукта проекта. Никакие вносимые в нее изменения не
разрешены до тех пор, пока не установится степень влияния запроса на возможные
изменения других сторон продукта, таких как область действия, график, цена и
качество. Это и является функцией группы ССВ.
Версии отслеживаются в защищенном хранилище посредством определенного
процесса входного/выходного контроля, предотвращающего возникновение
случайностей при многочисленных синхронных изменениях рабочего продукта. Кроме
того, каждый рабочий продукт должен иметь идентифицированного владельца
(причем, должен выполняться процесс постоянного обновления версий). Очевидно,
первыми элементами, обычно подвергаемыми менеджменту изменений, являются
техническое задание и план SPMP. При наличии запроса на предложение он обычно также
подвергается менеджменту изменений.
Успешное управление проектом определяется хорошим контролем изменений. Ниже
приводятся некоторые соображения, которых следует придерживаться на практике.
■ Все контракты или соглашения, относящиеся к проекту, должны содержать
описание порядка выполнения изменений проекта.
■ Все приказы на внесение изменений должны быть подтверждены подписью
соответствующего должностного лица.
■ Все недостатки проекта должны устраняться путем воздействия одобренных
изменений.
■ Любое изменение, вносимое в ту или иную особенность проекта, требует
перехваченного запроса на контроль изменений или указания на изменения.

Отслеживание и контроль в процессе выполнения проекта 973
■ Для каждого указания на изменения необходимо:
- просмотреть все изменения на предмет влияния продукта или процесса;
- идентифицировать все действия в рамках рабочего пакета;
- транслировать воздействия на производительность, цену и график;
- оценивать преимущества и стоимость изменений;
- определить альтернативные решения;
- принять или отклонить заслуги;
- сообщать всем сторонам о вносимых изменениях;
- систематизировать все изменения в следующем отчетном периоде.
Матрица гибкости
Осуществляя контроль над менеджментом изменений, имеет смысл
заблаговременно подготовить матрицу принятия решений, чтобы можно было принимать
решения в зависимости от возникающих ситуаций. Матрица гибкости, как ее часто
называют, позволяет команде разработчиков довольно эффективно производить
необходимый выбор. Гораздо лучше определить те основные элементы тройного
ограничения, которые в зависимости от условий данного проекта могут быть более
или менее гибкими. Простой пример матрицы гибкости изображен на рис. 25.6.
Область
действия
График
Затраты
Наименьшая
X
Гибкость
Средняя
X
Наибольшая
X
Рис. 25.6. Пример матрицы гибкости
Обратите внимание, что допускается только один X в каждой строке и столбце.
В представленной на рисунке в качестве образца матрице наименее гибким
является параметр графика. Команда разработчиков должна придерживаться графика,
что может достигаться путем увеличения выделяемых ресурсов, если это
необходимо, и возможно, путем уменьшения области действия. Принятие решения
относительно того, каким образом решения по проекту в начале его осуществления могут
сказываться в дальнейшем при условии наличия меньшего количества аргументов.
Управление графиком
Контролирование графика, похоже, и есть то, в чем лежит суть управления
проектом. Команда старается выполнять намеченные обязательства. Однако достижения
промышленности в этой области пока еще незаметны. Рассмотрим некоторые
способы, с помощью которых можно проследить интересующие нас вопросы.

974 Глава 25
Перечни стадий
Перечни стадий представляют собой простые списки достижимых стадий, заданных
разработчиками проекта в качестве указателей продвижения к целям проекта. Стадии
были впервые упомянуты в главе 8. Списки стадий, обязанные своим происхождением
структуре WBS, образуют удобный контрольный список проекта. После загрузки данных
структуры WBS списки стадий легко генерируются с помощью многих инструментов
построения графика проекта. В табл. 25.1 приводится образец списков стадий.
Таблица 25.1. Образец списка стадий
Код WBS Стадия Ожидаемая дата Фактическая дата
3.5.1 Планирование и разработка архитектуры 11/19/2001 11/14/2001
среднего уровня
4.2.6 Разработка фазы 1 для системы 2/25/2002 2/12/2002
5.4.4 Построение компонента системного ме- 3/25/2002
ханизма
6.9.2 Завершенный компонент Web-интерфейса 3/25/2002
7.4.5 Завершенное изучение сетевого трафика 4/19/2002
Устранение и быстрое отслеживание
Иногда по независящим от команды причинам возникают обстоятельства,
требующие изменения хорошо разработанного плана. Очень часто причиной является
приближение сроков платежей. Становится почти невозможным придерживаться
плана, если цены и качества, имеющие отношение к параметрам тройного
ограничения, должны сохраняться в неизменном виде. Тем не менее, если такое ускорение
имеет определенную важность, благодаря чему в распоряжение команды
предоставляются дополнительные ресурсы, то существующий график может быть нарушен с
целью достижения более ранней, чем планировалось, даты завершения проекта. Этот
процесс именуется "устранением". Рассмотрим принцип его действия.
Устранение проекта означает свертывание графика и сокращение общего
количества времени, выделенного на проект. Этот процесс также известен как "быстрое
отслеживание". Вероятно, такие действия диктуются очень веской причиной,
например, получением премии за досрочную сдачу проекта или избежанием штрафов за
задержку сроков выполнения. Изначально рассматривается возможность "краха"
возможностей на критическом пути. Такие действия, как, например, оказание
помощи определенным командам в достижении ими прогресса ничего не значат, если эти
команды не работают над чем-нибудь на критическом пути. Ниже описывается
процесс, которого следует придерживаться для обнаружения действий, подлежащих
сокращению. Таблица 25.1 является образцом матричной проблемы, заданной с целью
решения вопросов устранения и быстрого отслеживания.
Четыре шага к устранению проекта
Несмотря на то, что свертывание графика представляется довольно сложной
задачей, для разрушения проекта достаточно четырех шагов.
1. Создайте сеть предшествования.

Отслеживание и контроль в процессе выполнения проекта 975
2. Найдите все действия на критическом пути (проверьте его на предмет изменений).
3. Найдите действие (или действия), для которых установлен наиболее
благоприятный компромисс типа "время-затраты".
4. Разрушайте действие по одной единице за заданный отрезок времени до тех пор, пока
проект больше не сможет быть нарушен.
Таблица 25.2. Пример формулирования проблемы
Информация по
структуре WBS
Действие
Предшествование
Начальная оценка
проекта
Время Затраты
(месяцы) ($К)
Параметры
Доп.
ресурсные затраты
в месяц ($К)
устранения проекта
Общее число месяцев,
сэкономленных при
добавлении ресурсов для
действия
60
120
160
80
60
140
Итого по
затратам: 620
30
20
50
10
15
40
Пример устранения проекта
Рассмотрим пример задачи со следующими установками.
По просьбе шефа, директора проекта по имени Джек, Хитер отправила ему
электронное письмо, в котором говорилось, что по расчетам команды для завершения
проекта потребуется 13 месяцев. Хитер понимает, что для заказчика это довольно-
таки большой срок. С целью удовлетворения требований "окон рынка" в условиях
контракта оговорена премия в размере $50000 за каждый месяц более ранней сдачи
проекта вплоть до шести месяцев общего проектного времени. Но Джек хотел бы
вложить в проект больше средств с целью получения большей прибыли. Хитер и ее
команда собрали информацию, представленную в таблице 25.3. Какое минимальное
количество месяцев предлагают они заказчику и какую чистую прибыль будет иметь
их компания?
Настройка рабочей области задачи
Решение данной задачи начните с шага 1 с целью первоначального начертания
сетевой диаграммы и нахождения критического пути. Соответствующий пример
показан в табл.25.1.
Далее представьте задачу в виде таблицы решения (табл. 25.2), которая содержит
пустые столбцы, предназначенные для заполнения.
Затем обратите внимание на сеть и введите первоначальную длительность
проекта в столбце "Длительность проекта" в качестве шага 0 (начальное состояние).
Укажите критический путь для данной длительности проекта (заданную изначально как
А — 3
В А 5
С А 5
D А 4
Е С, D 2
F В. Е 3

976 Глава 25
ACEF). Все остальные параметры в данной строке не указывайте, поскольку они не
имеют никакого значения до момента нарушения графика.
Процесс устранения
Затем обратитесь к столбцу "Стоимость сбоя" в таблице задач и выберите действие
с минимальными показателями на критическом пути. Это первое действие, которое
предстоит разрушить, поэтому его необходимо занести как устраняемое действие в
шаге 1. Зафиксируйте, сколько стоит устранение действия в столбце "Стоимость
сбоя", и пометьте его как используемое из столбца "Общее доступное время сбоя" в
таблице условия задачи. Потом подсчитайте величину экономии сетевого проекта,
получаемую в результате только этого этапа разрушения (прибыль минус стоимость
сбоя). В условии задачи говорится, что каждое разрушение приносит прибыль в
$50000. Процесс разрушения сокращает критический путь на величину общего
времени, допустимую для данного действия (вычислите новую продолжительность
проекта путем вычитания общего допустимого времени разрушения из длительности
проекта в предыдущем шаге (изначально шаг 0)). Затем убедитесь в том, что на
сетевой диаграмме изменен критический путь; это необходимо сделать, чтобы знать,
какое действие следует разрушать далее.
Удобно помечать значения сетевой диаграммы при внесении каждого изменения
(форма сети не изменится, изменяются только ее значения). Затем, чтобы проверить
критический путь, взгляните на каждый узел и сравните верхние числа с нижними.
Если они равны, то в этом месте нет спада и данное действие находится на
критическом пути. Необходимо разрушать действия только на критическом пути; в
противном случае появляются напрасные затраты средств.
Таблица 25.3. Пример решения проблемы
Шаг Устраняемое Стоимость Чистая эконо- Размер Критичес- Коммен-
действие устранения мия проекта проекта кий путь тарии
0 — — — 13 ACEF Начальное
состояние
1
2
3
Проверка готовности
Повторяйте процесс для каждого действия до тех пор, пока разрушение
приносит прибыль или пока на критическом пути не исчерпается общее время
разрушения, допустимое для условия задачи. Не забывайте при выборе разрушаемого
действия для следующего шага удостовериться в том, что вам известно, как будет
выглядеть критический путь. Критический путь на каждом шаге запишите как строку
из букв, например, ACER.
Пример решения задачи
Решение задачи представлено в табл. 25.4. Каждый шаг показывает время,
оставшееся для каждого узла, его остаточную стоимость и допустимое время для
устранения. Текущий критический путь и его длина показаны в окне курсивом. Обратите

Отслеживание и контроль в процессе выполнения проекта 977
внимание, что при переходе на шаг 8 все пути становятся критическими и можно
еще раз устранить действие D, поскольку для него еще есть допустимое время. Это
никак не скажется на сокращении общего времени, затрачиваемого на выполнение
проекта.
Процесс устранения представляет собой весьма сложное по вычислениям
упражнение, подобное построению сети, однако, этим умением должен владеть каждый
менеджер проекта.
Рис 25.7. Пример сетевой диаграммы, описывающей задачу
устранения проекта
Управление затратами
Управление затратами— один из наиболее важных аспектов любого проекта.
В проектах разработки ПО в основе стоимости почти всегда лежит затраченный труд,
поскольку речь идет об интеллектуальной деятельности. Затраты на рабочую силу
обычно контролируются путем сокращения часов, необходимых для совершения
каких-либо действий, и путем сокращения или избежания переделок.
Чтобы правильно рассчитывать проектные затраты, необходимо проследить
процесс их накопления в ходе жизненного цикла проекта. В главе 8 было представлено
отношение структуры WBS к управлению стоимостью на рис. 8.3. Если в рамках
проекта счета издержек устанавливаются и управляются согласно структуре WBS, они
обеспечат основу измерения издержек проекта. Если информация о затратах не была
непосредственно собрана при выполнении действия, возможно, показатель
измерения, такой как количество часов (либо даже дней) может быть оценен и
экстраполирован на затраты. При этом используются сведения о зарплате и издержках,
связанных с деятельностью среднего инженера. Такие цифры могут предоставить
специалисты по финансам или из отдела кадров.
Базовая линия стоимости
При разработке любого проекта, независимо от того, измеряется ли он
количеством часов или объемом денежных затрат, можно построить кривую базовой
линии стоимости, демонстрирующую расход ресурсов на протяжении жизненного
цикла проекта.

978 Глава 25
Базовой линией стоимости называется распределенный по времени бюджет,
используемый для контроля выполнения проекта. Обычно он бывает представлен в
виде S-образной кривой, демонстрирующей суммарные издержки проекта в течение
определенного времени. S-образная форма объясняет типичное распределение
средств проекта: меньше всего в начале и в конце, и больше всего в середине, как
показано на рис.25.8. Вместе они образуют знакомую всем S-образную кривую,
которая представляет базовую линию стоимости проекта, как показано на рис.25.9.
Базовая линия стоимости служит прогнозом издержек за определенный период
времени, в течение которого выполняется проект. Согласно данному прогнозу,
завершение проекта планируется в течение времени х, при затратах у долларов или
количества часов. На это указывает z на рис.25.9. Базовая линия стоимости является
весьма полезным представлением, в чем можно удостовериться при рассмотрении
вопроса о менеджменте прибавочной стоимости.
ACEF = 3+ 5 + 2 +3=13
D,8)
ABF = 3 + 5 + 3 = 11
ADEF = 3 + 4 + 2 + 3=12
Рис. 25.8. Затраты, понесенные за какой-то период времени
C,8)
ACEF = 3 + 5 + 2 + 3=13
D.8)
ABF = 3 + 5 + 3=11
ADEF = 3 + 4 + 2 + 3=12
Рис. 25.9. Кумулятивные затраты = базовая линия
стоимости

Таблица 25.4. Блокнот, описывающий пример устранения проекта
ШагО
Начальный
Действие
А
В
С
Предыдущие Остаток
времени
— 3
А 5
А 5
Остаток
средств
60
120
160
Добавленные средства Общее доступное
для устранения время устранения
30 1
20 1
50 2
Сетевой путь
ABF
ACEF
ADEF
Новая длина
И
13
12
620
Шаг1
стви
А
В
С
D
Е
F
е Предыдущие
—
А
А
А
CD
В,Е
Остаток
времени
3
5
5
4
1
3
Остаток
средств
60
120
160
80
45
140
Добавленные средства
для устранения
30
20
50
10
15
40
Общее
доступное
время устранения
1
1
2
2
0
2
Сетевой путь
ABF
ACEF
ADEF
Новая длина
11
12
11
605

Продолжение табл. 25.4
Шаг 2
Действие Предыдущие Остаток Остаток Добавленные средства Общее доступное
А
В
С
D
Е
F
—
А
А
А
C,D
В,Е
времени
2
5
5
4
1
3
средств
30
120
160
80
45
140
для \
странення
30
20
50
10
15
40
вре
мя устранения
0
1
2
2
0
2
515
Сетевой путь
ABF
ACEF
ADEF
Новая длина
10
и
10
ШагЗ
ств
А
В
С
D
Е
F
не Предыдущие
—
А
А
А
CD
В,Е
Остаток
времени
2
5
5
4
1
2
Остаток
средств
30
120
160
80
45
100
Добавленные средства
для устранения
30
20
50
10
15
40
Общее доступное
время устранения
0
1
2
2
0
1
Сетевой путь
ABF
ACEF
ADEF
Новая длина
9
10
9
535

Продолжение табл. 25.4
Шаг 4
Действие Предьщущие
А —
В А
С А
Остаток
времени
2
5
5
Остаток
средств
30
120
160
Добавленные средства Общее доступное
для устранения время устранения
30 0
20 1
50 2
Сетевой путь
ABF
ACEF
ADEF
Новая длина
8
9
8
2
0
0
495
Шаг 5
Действие Предыдущие Остаток Остаток Добавленные средства Общее доступное
А
В
С
D
Е
F
—
А
А
А
CD
В,Е
времени
2
5
4
4
;
;
средств
30
120
НО
80
45
100
для устранения
30
20
50
10
15
40
время устранения
0
1
/
2
0
0
Сетевой путь
ABF
ACEF
ADEF
Новая длина
8
8
8
485

Продолжение табл. 25.4
Шаг 6 Действие Предыдущие Остаток Остаток Добавленные средства Общее доступное
времени средств для устранения время устранения
30 30 0
120 20 1
ПО 50 1
70 10 /
45 15 0
100 40 О
А
В
С
D
Е
F
—
А
А
А
C.D
В,Е
2
5
4
3
1
1
Сетевой готь
ABF
ACEF
ADEF
Новая длина
475
Шаг 7
Действие Предыдущие Остаток Остаток Добавленные средства Общее доступное
А
В
С
D
Е
F
—
А
А
А
C.D
В,Е
времени
2
4
4
3
1
1
средств
30
100
ПО
70
45
100
для устранения
30
20
50
10
15
40
время устранения
0
0
1
1
0
0
Сетевой путь
ABF
ACEF
ADEF
Новая длина
7
с?
7
455

Окончание табл. 25.4
Шаг 8
Действие
А
В
С
D
Е
F
Предыдущие
—
А
А
А
С, D
В,Е
Остаток
времени
2
4
3
3
1
1
Остаток
средств
30
100
60
70
45
100
Добавленные средства
для устранения
30
20
50
10
15
40
Обще
время
е доступное
устранения
0
0
0
1
0
0
405
Сетевой путь Новая длина
ABF
ACEF
ADEF
Шаг 9
стви
А
В
С
D
Е
F
г Предыдущие
—
А
А
А
C,D
В,Е
Остаток
времени
2
4
3
2
1
1
Остаток
средств
30
100
60
60
45
100
Добавленные средства
для устранения
30
20
50
10
15
40
Общее
доступное
время устранения
0
0
0
0
0
0
Сетевой путь
ABF
ACEF
ADEF
Новая длина
7
7
6
395

984 Глава 25
Построение базовой линии стоимости
Завершив выравнивание, можно перейти к калькуляции себестоимости. На
этом этапе график становится реальным, в результате чего можно распределять
затраты в соответствии с различными необходимыми ресурсами. Суммируя
периоды, можно обнаружить, что необходим еще один цикл выравнивания, на этот
раз построенный на основе потока денежной наличности. Если это
действительно так, выполните еще раз те же действия.
Для каждого используемого ресурса распределите затраты по следующему
принципу:
■ обычные расценки — обычно $/час;
■ оценка сверхурочной работы — обычно $$/час;
■ затраты на каждый случай применения — обычно цена за использование элемента
(часто расходуемого).
Для более продолжительных действий затраты на ресурсы, пропорционально
распределенные на протяжении всего периода, можно сосредоточить либо в самом
начале действия, либо в конце.
Тот этап, на котором планируется регистрация ресурсных затрат при
отслеживании проекта, на самом деле служит показателем консервативности в вопросах
представления стоимости проекта. Если все ресурсные затраты распределяются в начале,
то затраты на этапе осуществления проекта проявляются быстрее. При
распределении затрат в конце совершаемого действия эти затраты носят более консервативный
характер. Пропорциональное распределение затрат может быть более реальным,
хотя и требует отслеживания большего объема административной работы.
После этого можно спроектировать бюджет поэлементно в соответствии со
структурой WBS, чтобы можно было проследить затраты при совершении каждого
основного действия, этапа или другой структурной единицы, имеющей отношение
к WBS. Затем их можно распределять по отделам или центрам затрат с целью
составления бюджета или отслеживания, соответственно. Обычно каждому центру
затрат присваивается свой номер списания. Собранная и суммированная
информация об издержках демонстрирует ход выполнения проекта в рамках
запланированного бюджета. Отображение элементов структуры WBS на затраты иллюстрируется
па рис.25.10.
Отобразив все издержки на ресурсы на счетах затрат, основанных на структуре
VVBS, можно создать базовую линию измерения производительности при
выполнении проекта (Performance measurement baseline, PMB), разделив издержки по
времени. Обычно получается кривая, аналогичная изображенной на рис.25.10. Что
касается объемных и продолжительных проектов, подробные счета издержек для
рабочих пакетов создаются только на несколько стадий вперед. Немного позднее
фонды объединяются в плановые пакеты больших групп WBS, показанных в центре
рис.25.10. Они будут выделены в центры затрат, отображающих ход выполнения
проекта.
Регулирование затрат проекта подразумевает управление активами и
человеческими ресурсами. Кроме того, подразумевается и отслеживание денежных потоков.
Менеджеру проекта вовсе не обязательно быть бухгалтером, однако, ему не
помешает освоить основные принципы бухучета. Обратите внимание на следующие
положения.

Отслеживание и контроль в процессе выполнения проекта 985
■ Ценность денег зависит от времени — концепция интереса; сегодняшний доллар
ценится больше, чем доллар завтрашний.
■ Две стороны каждой операции — двойная бухгалтерия; для каждого актива
существует возможный равный и противоположный пассив.
СГ1Г1 Начальная фаза Промежуточная фаза(ы) Финальная фаза
400
300
200
100
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
■ Затраты за период времени
Рис. 25.10. Затраты на базовой линии стоимости
Источник: Fleming, Quentin, and Joel Hoppelman. Earned Value Project
Management. PMI, 1996.
■ Таблица счетов — описание того, какие центры затрат могут собирать издержки и
прибыли.
■ Различие между финансовым счетоводством и исчислением себестоимости —
первый носит внешний характер, а второй — внутренний.
■ Различный взгляд на издержки различных групп —менеджеры проектов отвечают
за обязательства, бухгалтера — за счета, а кассиры — за денежный поток, объем
которого будет достаточным для уплаты по счетам.
Управление качеством
Любой проект разработки ПО должен иметь несколько качественных
метрических показателей, определенных как ключевые индикаторы качества производимого
командой продукта. В главах 20, 21 и 26 содержится большой объем информации
относительно измерения качества при разработке ПО. Большая часть данной книги
посвящена вопросам разработки и управления ПО, что может оказаться полезным при
оценке качества любого проекта.
Центральным аспектом успешного управления проектом является хороший набор
инструментальных средств. Многие из использующихся в настоящее время
инструментов, которые тесно связаны с контролем статистических процессов (Statistical
process control, SPC), в последние годы разрабатывались посредством действий по
всеобщему контролю качества (Total quality management, TQM). Часто эти инстру-
k_i

986 Глава 25
менты используются с целью обеспечения качества при отслеживании и улучшении
процессов разработки ПО (или любого другого организационного процесса, не
обязательно входящего в рамки проекта). Ваш проект может во многом выиграть, если
при его разработке будут использованы семь известных инструментов оценки
качества для мониторинга совместимости процесса и инкрементных улучшений. Как уже
говорилось, "если что-либо нельзя измерить, то этим невозможно управлять". Ниже
перечислены семь упомянутых инструментов менеджмента качества:
1. блок-схемы процесса;
2. причинный анализ;
3. массивы для сбора данных;
4. диаграмма Парето (Pareto);
5. гистограммы;
6. графики рассеяния;
7. диаграммы прогона.
Очень важно научиться использовать каждый из этих инструментов для
определения областей усовершенствования процесса, анализа собранных данных и создания
плана действий по усовершенствованию.
Менеджмент выполняемых работ
Вполне естественным будет вопрос относительно того, каким образом команда
разработчиков проекта выполняет запланированные действия. Однако как было
видно из главы 15, в силу некоторых проблем, возникающих с оценкой, создается
ложное представление о местонахождении на этапах проекта. Попытка оправдания
"студенческого синдрома" может привести к тому, что люди отчитываются о
состоянии выполнения действий как "90 % готовности". Рассмотрим два способа оценки
реального хода выполнения проекта. Первый метод, называемый менеджментом
прибавочной стоимости (Earned value management, EVM), используется начиная с 50-х
годов прошлого века. Второй метод, разработанный в 1997 г. Элияху Голдратом
(Eliyahu Goldratt), основывается на методе буферного менеджмента графика
критической цепи. Для оценки хода выполнения проекта оба метода могут использоваться
как отдельно, так и совместно.
Менеджмент прибавочной стоимости
Прибавочная стоимость— концепция контроля за уровнем издержек,
разработанная с целью измерения реального прогресса при разработке проекта, а не объема
понесенных трудозатрат. Ваш график PMIS должен определить порядок сбора и
отчета об издержках и количестве времени (затраты на рабочую силу). Но это — только
половина проблемы (трудозатраты). Кроме того, необходимо знать, что было
совершено благодаря этим трудозатратам (стадиям) с целью измерения прогресса проекта
(это то, что действительно важно знать).
Основной концепцией EVM является возможность объединения метрик
трудозатрат и оценку достигаемых стадий для измерения реального прогресса, как показано на
рис. 25.11. Из рисунка видно, что можно получить в результате того, что было
потрачено. С помощью данного метода можно вычислить расхождение между бюджетом и

Отслеживание и контроль в процессе выполнения проекта 987
графиком. При этом не имеет значения, что отслеживается — денежные затраты или
количество часов, здесь просто важно что-либо отслеживать. Системы EVM требуют
наличия ввода некоего вида табличной информации для отслеживания компонента
трудозатрат.
Понятие прибавочной стоимости произошло от понятий, разработанных
инженерами по организации производства в конце 19 века, которые применялись для
измерения производительности предприятий. Она была включена в PERT/Cost в
начале 60-х годов, и была определена Министерством обороны США (DOD) в виде
критерия контроля затрат графика (Cost/Schedule Control System Criteria, C/SCSC) в 1967
г. Первоначальный C/SCSC определял 35 критериев, которые были обязательны для
создания системы прибавочной стоимости. В 1995 г. Министерство обороны приняло
32 первоначальных критерия C/SCSC в качестве системы менеджмента прибавочной
стоимости (Earned Value Management System, EVMS). В настоящее время для
коммерческих целей необходимо только 5 критериев, квалифицируемых в качестве системы
управления прибавочной стоимостью в частном секторе. Вот эти пять критериев:
1. определение области действия проекта (с помощью структуры WBS);
2. составление плана и графика проекта (СРМ);
3. составление плана счетов затрат и присвоение им определенных функций (счета
затрат);
4. установка и поддержание (сохранение) базовой линии измерения
производительности (базовая линия стоимости);
5. контроль производительности при выполнении проекта и прогнозирование
конечных результатов (анализ прибавочной стоимости).
Базовая линия стоимости
Начальная фаза Промежуточная фаза(ы) Финальная фаза
500
Рис. 25.11. При осуществлении процесса EVM
объединяются процесс выполнения и трудозатрат с целью
вычисления реальной прибавочной стоимости
Ключ к пониманию EVM — понимание трех его основных компонентов, поскольку
почти все остальное вычисляется на основе этих компонентов. Ниже приводятся
соответствующие аббревиатуры, расшифровки и концепции:

988 Глава 25
■ BCWS— сметные расходы по запланированной работе ("желаемые");
■ BCWP— сметные расходы по выполненной работе ("заработанные");
■ ACWP— фактические затраты на выполненную работу ("сгоревшие").
Рассмотрим подробнее каждый из этих компонентов:
BCWS
Сметные расходы по запланированной работе определяют то, чего "желают" от
проекта. Как видно из рис.25.10, это базовая линия стоимости. Этот показатель
отвечает на вопрос "Какой объем работ должен быть выполнен?". Это запланированная
работа для проекта, предусмотренная для каждого периода времени.
BCWP
Сметные расходы по выполненной работе определяют то, что на самом деле
"заработал" проект на определенный момент времени в соответствии с базовой
линией стоимости. Этот показательотвечает на вопрос "Какой объем работ выполнен?"
Именно на этом этапе проект считается действительно завершенным.
ACWP
Фактические затраты на выполненную работу — затраты, понесенные в процессе
выполнения проекта, т.е. те, что "сгорели" для завершения начатого (в денежном
выражении либо в количестве затраченных часов).
На базе этих трех компонентов можно выполнить множество измерений. Два
наиболее полезные — отклонение от нормативных затрат и расхождение графика.
Отклонение от нормативных затрат вычисляется с помощью формулы:
CV = BCWP-ACWP
С помощью данной величины сравниваются фактические затраты со сметными
издержками с целью вычисления расхождений. Расхождение выражается в денежном
эквиваленте или количестве часов, но тем не менее при этом не выполняется
сравнение запланированной работы с выполненной. Данная величина применяется лишь с
целью определения отклонения от бюджета. Расхождения внутри графика
вычисляются по следующей формуле:
SV = BCWP - BCWS
С помощью этой величины сравнивается запланированная и выполненная работа
для вычисления расхождений. Расхождение выражается либо в денежном
выражении, либо в количестве часов, но не в датах. Поначалу данный факт немного смущает,
поскольку графики обычно рассматриваются в датах. Но здесь речь идет о работе, а
не о времени.
На основе этих трех величин и их производных можно вычислить некоторые
дополнительные величины. Бюджет, требуемый для завершения, — это
запланированные совокупные издержки проекта. На рис.25.9 этот факт обозначается
точкой Z.
Оценка затрат, требуемых для завершения (ЕСАС), — прогноз совокупных
издержек для завершения проекта. Эта величина вычисляется по формуле:
ЕСАС = ВАС х (ACWP/BCWP)
Это практически соответствует ВАС, определенному соотношением между
фактическими данными и завершенной работой. Если фактические затраты меньше, чем

Отслеживание и контроль в процессе выполнения проекта 989
бюджет на момент проведения измерений, коэффициент будет меньше 1, вследствие
чего уменьшится показатель ВАС. Если фактические затраты больше бюджетных,
коэффициент будет больше 1, что соответственно увеличит показатель ВАС.
Оцененное время завершения использует тот же принцип соотношения для
прогноза расчетной даты завершения проекта. Однако на этот раз сравнивается
запланированная работа с той, которая была включена в график. Эта величина
вычисляется по формуле:
ЕТАС = исходное время х (BCWP/BCWP)
Есть еще две полезные величины — индекс затрат на выполнение (Cost
performance index, CPI) и индекс выполнения графика (Schedule performance
index, SPI). Это пропорции, связывающие затраты и график в виде значения
соотношения, подходящего для рисования и отслеживания управляющей диаграммы.
Индекс затрат на выполнение сравнивает бюджет с фактическими затратами и
вычисляется по формуле:
CPI = (BCWP/ACWP)
Если коэффициент CPI меньше 1, то затраты на выполнение проекта превышают
бюджет, поскольку фактические затраты превышают сметные. Если коэффициент
CPI больше 1, то затраты на проект меньше запланированных, поскольку
фактические затраты ниже сметных.
Индекс выполнения графика используется при сравнении бюджета с планом и
вычисляется по формуле:
SPI = (BCWP/BCWS)
Если коэффициент SPI меньше 1, то проект выполняется с опережением графика,
поскольку завершенная бюджетная работа была меньше, чем работа
запланированная. Если коэффициент SPI больше 1, то выполнение проекта "выпадает" из графика,
поскольку бюджетная работа превышает запланированную.
С помощью коэффициентов CPI и SPI на контрольной диаграмме можно указать
единственное число, применяемое для представления выполнения целого проекта.
Это критический коэффициент, являющийся производным от коэффициентов CPI и
SPI. Формула критического коэффициента имеет следующий вид:
CR = SPI X CPI
Если оба индекса (графика и затрат) равны 1, то коэффициент CR также будет
равен 1, свидетельствуя о том, что все идет по плану. Но если значения коэффициентов
CPI либо SPI отклоняются от 1, то и значение коэффициента CR начинает
отклоняться от 1, что означает возникновение проблемы. Некоторые из эмпирических правил
заключаются в том, что если значение коэффициента CR находится между 0,9 и 1,2,
то проект выполняется нормально. Но если значение коэффициента CR заключено
между 0,8 и 0,9, либо 1,2 и 1,3, то проект требует вмешательства, поскольку либо
затраты, либо график отклоняются от оптимальных значений. Если значение
коэффициента CR меньше 0,8 или больше 1,3, то определенно существует проблема, в связи с
чем следует предпринять соответствующие действия. Точка, соответствующая
коэффициенту CR на контрольной диаграмме, становится хорошим способом
контролирования хода выполнения проекта. Это показано на рис. 25.12.

990 Глава 25
Проект
Сумма
(в долларах) Стадии д
100%
80%
60%
40%
20%
0%
Счет
затрат
(планируемые
пакеты)
Счет затрат
(рабочие пакеты)
«—rrff~
Г"*""""'1
Нераспределенный
бюджет (согласно
структуре WBS)
''
= РМВ
Время '
Рис. 25.12. Контрольная диаграмма проекта, в которой
применяется критический коэффициент
Необходимо признать, что для правильного вычисления метрических показателей
EVM требуются определенные трудозатраты. Если для вашего проекта установлены
всего лишь две стадии, то к моменту завершения проекта в вашем распоряжении на
самом деле не будут находиться слишком точные результаты измерений, даже если
точно отслеживается время, поскольку ничего нельзя будет "заработать" до
завершения прохождения стадий. Контрольная диаграмма CR будет иметь не совсем
приглядный вид до самого завершения проекта. Лучше устанавливать несколько небольших
стадий для измерения хода выполнения проекта. Благодаря этому кривые рисуются
более плавно. На рис.25.13 — 25.17 показана последовательность EVM вычислений и
графиков относительно базовой линии стоимости, иллюстрирующая то, как со
временем изменяются EVM-параметры.
Представленные на протяжении определенного периода времени в виде кривых,
эти EVM-измерения могут многое рассказать о состоянии проекта. На рис. 25.18 и
25.19 демонстрируется проект, "опережающий" график либо бюджет. Наклон
нарисованной кривой на момент вычислений указывает на то, каким образом обстоят
дела— лучше или хуже. На рис.25.20 и 25.21 показан проект, "отстающий" от графика
либо бюджета.

Отслеживание и контроль в процессе выполнения проекта 991
Проект А
Рис. 25.13. Пример проекта, датированный 1 января и
отображающий запланированную линию стоимости

992 Глава 25
Диаграмма критического коэффициента EVA (SPI * CPI)
от 06/04/99 для образца проекта А123
КлючСн
0.9>CR<1.1 OK
0.8>CR<1.2 Check
0.6 > CR < 1.4 Problem
О1О1О)О10)ОH)О)С1ОH}0)С10}0HH)ОH}(Я010H)О)ОH)О)
от от от от от от от от от от от от ототототототр>с>0>0>с)H)о>р> от
T-auinc<>in^adio^dmnO)dnoN4>-SS^<-dui^
ooooooooooooooooooooooooooo
Недели
от о> от от
oitfrio
I— I— 1^- Г—
о о о о
Рис. 25.14. Пример проекта, датированный 2 апреля и отображающий
вычисления отклонений затрат
Сводный график анализа прибавочной стоимости
»• от01/01/99дляпримерапроектаА123
■ ' ■ '
ототототототототототот
О) ОТ ОТ О) О)
ю от см со см _
т- г- N N П СО 4J- ■«■
ооооо - — —
отототототототототот
О CnJ О 1- О »- JO
u5 u5 3 JS ri ri i^.
oooooooooo
BCWS
ACWP
bcwp
ВАС
Запланированная
дата завершения: :05/Зр/99:
Сейчас: [Рано ]
BCWS = 5
ACWP= 5
BCWP = 0
ВАС = 750
CV= -5- превышает бюджет
SV= -5-отстаетотграфика
ЕСАС = 750 - точно в цель
ЕТАС = 21 - согласно целевой дате
Рис. 25.15. Пример проекта, датированный 2 апреля и отображающий вычисления
отклонения графика

Отслеживание и контроль в процессе выполнения проекта 993
Сводный график анализа прибавочной стоимости
от 04/02/99 для примера проекта А123
BCWS
ACWP
BCWP
• ■ •■ВАС
иии
900
800
700
600
500
400
300
200
100
п
-
-
j.
ACWP
BCWP /
mi: 11 11
/ cv
11 i 11 i
= BCWP-ACWP
= 220-450
= -230
I'l
ОТ
ОТ
О
О
en
ОТ
in
C^
О
ОТ
<D
ОТ
f\J
О
en
ОТ
Kl
Si
о
en
ОТ
to
C\J
Si
о
СП
en
Jn]
?5
О
от
СП
ей
Сч|
СО
о
ся
СП
СП
о
^
о
СП
СП
СЛ
Гч|
Tt
о
от
о
г-
о
1Л
о
от
СП
см
Й
о
О)
сп
^
о
со
о
о>
о>
00
«5
о
от
т
Si
о
г-
о
ся от
22 9J
со о
т- £0
о о
Запланированная
дата завершения: [ 05/30/9?]
Сейчас: ;.Рано j
BCWS= 380
ACWP= 450
BCWP = 220
ВАС = 750
CV= -230- превышает бюджет
SV = -160 - отстает от графика
ЕСАС = 1534 - превышает бюджет
ЕТАС = 28-после целевой даты
Рис. 25.16. Пример проекта, датированный 23 апреля и отображающий все
вычисления EVM
1000
900
800
700
600
500
400
300
200
100
°с
с
J
с
—
-
-
-
-
-
01/15/99
Сводный график анализа прибавочной стоимости
от 04/02/99 для примере проекта А123
BCWSN
BCWP ,у
rfrT- .l,l
01/29/99
02/12/99
02/26/99
03/12/99
J SV =BCWP-BCWS
/ =220-380
L =-160
I , I , I , I , I , I , I , I , I , I
OH)OHH)OIOI0)OH)
О) О) О) ОТ O) ОТ ОТ О) О) 0)
<B Si й г~ ^ * со сЗ со о
CAiCiCNipCVJpj-^T-CO
n*«iniO(SiDNNS
оооооооооо
BCWS
ACWP
BCWP
- --- ВАС
в^ввввППпвТввв^ввввЪ
ViH^B^BBBBBW
Запланированная.-
дата завершения:! 05/30/99:
Сейчас:! Рано!
BCWS= 380
ACWP = 450
BCWP = 220
ВАС = 750
CV= -230-превышает бюджет
SV = -160 - отстает от графика
ЕСАС= 1534-превышает бюджет
ЕТАС= 28-после целевой даты
Рис. 25.П. Завершенный пример проекта, который датирован 4 июня и
выполняется в соответствии с графиком, но превышает бюджет

994 Глава 25
1000
900 -
Сводный график анализа прибавочной стоимости
от 04/23/99 для примера проекта А123
BCWS
ACWP
BCWP
- -■•ВАС
Г i I i I i I i I i
= BCWP-ACWP
= 565-735
= -170
SV =BCWP-BCWS
= 565-605
=-40
i I i I i I i I i I i I i I i I
О OOOOO OOOOOOOOOO
^ Ю 3> C\] CO <?3 tOOCO^i-^COWtDO
О т-Wi-CJ»- CJOCVJOWOi-pi-CO
^ ^ »- сЭ с\] й ?5 ^ ^ in in iS ^ n n n
о ooooo oooooooooo
Запланированная.- .
дата завершения: 1.05/30/99]
Сейчас: |.Рано)
BCWS =605
ACWP= 735
BCWP = 565
BAC= 750
CV = -170 - превышает бюджет
SV= -40 -отстает от графика
ECAC = 976 - превышает бюджет
ЕТАС= 23-после целевой даты
Рис. 25.18. Опережение и получение прибыли для проекта
Сводный график анализа прибавочной стоимости
от 06/04/99 для примера проекта А123
BCWS
ACWP
BCWP
■ ■■■ВАС
OOOOO О000000H>00
ooooo oooooooooo
moc^tow йойРг^^сос^йо
ooooo oooooooooo
Запланированная
дата завершения:[05/30/99]
Сейчас: [Рано]
BCWS= 750
ACWP= 950
BCWP = 750
BAC= 750
CV= -200 -превышает бюджет
SV = 0 - отстает от графика
ECAC = 950-превышает бюджет
ЕТАС =23- после целевой даты
Рис. 25.19. Оперезкение с потерями для проекта

Отслеживание и контроль в процессе выполнения проекта 995
Опережение с прибылью Опережение с прибылью
Время —* Время —»■
Рис. 25.20. Отставание и потери Рис. 25.21. Отставание и получение
для проекта прибыли для проекта
В связи с вышеизложенным возникает вопрос: как определить понятие "сделано"?
То есть, каким правилом следует руководствоваться, чтобы определить, что что-то
"сделано" в вычислениях EVM? Флеминг (Fleming) и Хоппелмен (Hoppelman)
ссылаются на некоторые общеизвестные правила готовности двух видов: правила для
повторяющихся действий и правила для неповторяющихся действий. Используемые
обычно для неповторяющихся действий правила приведены ниже.
■ Взвешенная стадия— каждая стадия взвешивается согласно ее значимости для
проекта.
■ Фиксированная формула @/100, 25/75, 50/50) — первая цифра получается в
начале, а вторая в конце.
■ Оценка доли завершенной работы в процентах —субъективная оценка
выполненной работы.
■ Доля завершенной работы и пункт стадии — субъективная оценка плюс
завершение стадии.
■ Эквивалентные единицы— эквиваленты премий для всех единиц, необходимые
для частично завершенных коллекций.
■ Полученные стандарты — измеряются согласно хронологии стандартов.
■ Распределенная взаимосвязь, необходимая для дискретизации (процент
наибольших трудозатрат) — для распределения накладных расходов.
■ Уровень трудозатрат (не рекомендуется) — постоянные затраты, более
управляемые показателями времени, а не с помощью действия.
Консерваторы обычно выбирают правило типа фиксированной формулы 0/100.
В вычислениях EVM ничего не зарабатывается до его окончательного завершения.
В качестве примера в вычислениях величин EVM рассмотрим задачу,
позволяющую разобраться в том, как следует интерпретировать предоставленные вам как
менеджеру проекта данные. В частности, рассматривается описанная ниже ситуация.

996 Глава 25
Проект выполняется с 1 января, стадии А и В завершаются с опережением
графика при условии выполнения бюджета. Данные по затратам и графикам для каждой
стадии приведены в табл. 25.5.
Сегодня 1 мая. Выполнение проекта находится в такой точке, когда стадия D
должна была завершиться, но работа фактически выполнена на 50 процентов. При
выполнении данного проекта применяется такая процедура, когда при вычислениях
добавочной стоимости принимаются во внимание только завершенные стадии. Как
менеджера проекта вас просят предоставить EVA-параметры, представленные в табл.
25.5 для ежемесячного обзора проекта.
Таблица 25.5. Ежемесячный обзор EVA-параметров
Дата проекта:
Дата завершения
Затраты
Стадии структуры WBS Запланировано
А 2/1
В 3/1
С 4/1
D 5/1
Е 6/1
F 7/1
Итого
Фактически Запланировано Фактически
1/20
2/28
4/5
15000
20000
25000
20000
15000
5000
100000
10000
15000
25000
10000
60000
Стадия D еще не завершена, поэтому затраты на работу пока еще нельзя
вычислить в ACWP (по правилу в условии задачи). Потому нельзя также вычислить и
показатель BCWP для этой стадии. В точке 5/1 три основные EVA-параметра будут
следующими (для простоты все значения приведены в $К):
1. BCWS =15+ 20+ 25+ 20 = 80
2. BCWP - 15+ 20+ 25 = 60
3. ACWP =10+15+25 = 50
Выполнив три основные измерительных действия, довольно легко можно перейти
к реализации остальных измерений:
1. CV = BCWP - ACWP = 60 - 50 = 10 (благоприятный)
2. SV = BCWP - BCWS = 60 - 80 = -20 (неблагоприятный)
3. CPI = BCWP / ACWP = 60 / 50 = 1.2 (благоприятный)
4. SPI = BCWP / BCWS = 60 / 80 = 0.75 (неблагоприятный)
5. CR = CPI x SPI = 1.2 x 0.75 - 0.9 (критический)
Как это характеризует состояние проекта? Проект выполняется в критическом
режиме, поэтому к нему следует отнестись более внимательно. Начало, казалось,
было неплохим, однако, со временем проект начал "отставать". Такая тенденция
нежелательна.
Основная цель выполнения EVM в рамках проекта— помощь в понимании того,
когда и что следует узнать. Если вы можете распознать "желаемое", "заработанное"
или "израсходованное", то остальные вычисления выполняются довольно просто.

Отслеживание и контроль в процессе выполнения проекта 997
Оценка критической цепи
Напомним, что глава 15 в основном была посвящена рассмотрению метода
критического пути (СРМ) для действий, включенных в график в плане проекта. Кроме того,
были также рассмотрены менеджмент буфера и графики, управляемые ресурсами.
Для отслеживания хода выполнения проекта наряду с СРМ широко используется и
EVM. В данном разделе рассматривается вопрос менеджмента буфера для
отслеживания прогресса проекта при дальнейшем сравнении его с методом EVM.
Вспомните, что при использовании метода критического пути стараются
избавиться от неопределенности в оценке действий, перекладывая ее в набор буферов для
контролирования и управления на уровне проекта, как показано на рис. 25.22.
Желательно, чтобы оценка действий составляла 50 процентов вероятности достижения
предполагаемой продолжительности.
Менеджер проекта, наблюдая, что происходит с буфером по истечении времени
выполнения проекта, может в случае необходимости сделать соответствующие
изменения. Благодаря простым вычислениям видно, как быстро опорожняется буфер при
достижении соответствующих стадий. Для отслеживания прогресса можно построить
схему, аналогичную показанной на рис.25.23.
Отставание с потерями Отставание с потерями
Время —*■ Время —»-
Рис. 25.22. Пример буферного менедж- Рис 25.23. Пример менеджмента проек-
мента в графике проекта та с помощью буферного менеджмента
Процент завершенности стадий вычисляется в соответствии с буфером
неопределенности, задействованном с целью выполнения стадии. Если точки указываются в
зеленой зоне, то выполнение проекта проходит нормально. Если они перемещаются
в желтую зону, то необходимо предпринять какие-либо действия, например,
расширить штат исполнителей проекта или реорганизовать членов команды, с тем чтобы
помочь тем, кто выполняет действия на критической цепи. Если точки перемещаются
в красную зону, необходимо предпринять действия для корректировки проекта. Это
делается с целью завершения проекта где-нибудь в верхнем правом углу или под ним,
что будет означать своевременное либо досрочное завершение проекта.

998 Глава 25
Тот же прием довольно легко применим и к уровню портфеля заказов, на котором
отслеживаются многие проекты. С помощью той же схемы можно расставлять точки
там, где находится данный проект. В результате получается схема, аналогичная
изображенной на рис.25.24.
Рис. 25.24. Пример оценки хода выполнения проекта с помощью буферного менеджмента для
коллекции проектов
Использование буферного менеджмента критической цепи и отслеживания прогресса
проекта имеет некоторые преимущества. EVM бывает сложным в вопросах управления.
Критическая цепь в этом плане проще. EVM требует измерения трудозатрат,
выраженных, например, в количестве часов, в связи с чем у разработчика может возникнуть вопрос
о "проценте готовности". В критической цепи вопрос "процента готовности" неактуален,
поскольку более важен вопрос "Что еще необходимо сделать?" Критическая цепь делает
упор на постоянную переоценку на уровне действия, на котором выполняется работа. При
условии выполнения действия наполовину разработчик будет знать намного больше о
проблеме по сравнению с тем, что он знал при выполнении первой оценки и составлении
диаграммы Ганта. Это означает, что критическая цепь имеет в основном дальновидную
цель, в то время как EVM обычно ориентируется на прошлое
Это означает, что благодаря методу буферного менеджмента критической цепи
менеджер проекта может "смотреть на дорогу, а не просто вглядываться в зеркало
заднего вида".
Управление рисками
Отслеживание проекта подразумевает следование принципам менеджмента
рисков. Любой обзор проекта должен включать обработку рисков, возникающих в ходе
проекта из многих источников. За отчетный период должно быть представлено как

Отслеживание и контроль в процессе выполнения проекта 999
минимум 10 пунктов риска. Причем желательно использовать диаграмму
отслеживания рисков, демонстрирующую возникновение и исчезновение новых и старых
рисков.
В главе 18 представлено подробное описание всех вопросов, связанных с рисками.
Резюме
В главе были рассмотрены инструменты и техники отслеживания проекта
разработки ПО после завершения планирования и определения базовой линии. Были
подробно рассмотрены элементы тройного ограничения, используемые в качестве схемы
отслеживания. Были рассмотрены некоторые методы контроля и управления
областью действия, графиком, издержками, а также вкратце рассмотрено управление
качеством и рисками (эти вопросы подробнее рассматриваются в других главах).
Хороший менеджмент проекта разработки ПО делится на две части:
планирование и отслеживание. Большая часть данной книги посвящена планированию проекта,
однако в данной главе основной акцент делается на отслеживание процессов,
необходимых для любого проекта разработки.
Контрольные вопросы
1. Согласны ли вы с утверждением, что стоимость ускорения проекта увеличивается
по экспоненциальному закону, особенно по мере завершения проекта? Объясните
свой ответ.
2. Следует ли руководствоваться различными наборами графиков и схем для
составления отчетов как внутри организации, так и вне ее? Следует ли составлять
отдельные графики для различных уровней управления? Существует ли более
эффективный способ разрешения такого рода проблем? Объясните свой ответ.
3. Согласны ли вы с утверждением, что самая простая вещь (критический
коэффициент) может представить текущее состояние сложного проекта?
Практическое занятие
Экономический спад в отрасли по производству полупроводников повлиял на
деятельность вашей корпорации. Несмотря на то, что вы являетесь членом
подразделения, получающего прибыль при производстве ПО и систем, вам необходимо
сокращать свой бюджет на 10% в течение финансового года. В вашем распоряжении
остается только девять месяцев, поэтому придется предпринять довольно серьезное
сокращение, чтобы добиться общего сокращения на 10%. Ваш предварительный план
должен быть готов в течение двух дней. Если план будет одобрен, у вас есть 10 дней,
чтобы его выполнить. Подготовьте и представьте такой план как можно быстрее.
Литература
Ahuja H. Construction Performance Control by Network. John Wiley 8c Sons, 1976.
Burrill C.W., and LAV. Ellsworth. Modern Project Management Burrill-EUsworth Associates, 1980.
Cleland David I., and William R. King, Editors. Project Management Handbook, Van Nostrand, 1983.
Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 5-е издание.
Van Nostrand Reinhold, 1995.

1000 Глава 25
Lewis James P. Project Planning, Scheduling, and Control: A Hands-On Guide to Bringing Projects in on Time and
on Budget. McGraw-Hill, 1995.
Meredith Mantel Project Management: A Managerial Approach, 3-е издание. John Wiley 8c Sons, 1995.
Paulk Mark С, и др. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-
Wesley. Section 7.2, "Software Project Planning", and Section 7.3, "Software Project Tracking and
Oversight", 1994.
Pressman Roger S. Software Engineering: A Practitioner's Approach, 5-е издание. McGraw-Hill. Chapter 5,
"Software Project Planning", and Chapter 7, "Project Scheduling and Tracking", 2001.
Rea Kathryn P., and Bennet P. Lientz, Editors. Project Management for the 21st Century. Academic Press,
1998.
Snyder, James R. "How to Monitor and Evaluate Projects". Field Guide to Project Management. John Wiley
&Sons, 1998.
Stuckenbruck, LinnC. The Implementation of Project Management. Addison-Wesley, 1981.
Walpole, Ronald E. Introduction to Statistics, 2-rd ed. Macmillan, 1974.
Wysocki Robert K., et al. Effective Project Management, 2-rd ed. John Wiley 8c Sons, 2000.
Дополнительные сведения в Internet
stsc.hill.af.mil/crosstalk/1999/apr/smlth.asp. "Вычисление доверительных значений
коэффициентов возврата инвестиций и прибавочной стоимости," Ларри В. Смит (Larry W. Smith),
Software Technology Support Center A. Todd Steadman, TRW Avionics Systems Division.
stsc.hill,af.mil/crosstalk/199B/jul/value.asp. *PM GMT, мощный инструмент,
предназначенный для оценки прибавочной стоимости при управлении программными проектами",
Квентин В. Флеминг (Quentin W. Fleming) и Джоэл М. Коппельман (Joel M. Koppelman), Primavera
Systems, Inc.
www.pmi. org/publictn/pmboktoc.htm. Руководство Основы знаний в области менеджмента
проектов Института PMI (PMBOK® Guide), глава 10.

Непрерывное
совершенствование
процессов
разработки ПО
Глава в формате PDF находится на прилагаемом компакт-диске.

Прерывание
выполняемого проекта
Глава в формате PDF находится на прилагаемом компакт-диске.

Анализ эффективности
выполнения проекта
Глава в формате PDF находится на прилагаемом компакт-диске.

Отчетность
и общение
Глава в формате PDF находится на прилагаемом компакт-диске.

Обеспечение
качества ПО
Глава в формате PDF находится на прилагаемом компакт-диске.

Менедлсмент
конфигурации ПО
Глава в формате PDF находится на прилагаемом компакт-диске.

Правовые вопросы,
возникающие
при разработке ПО
Глава в формате PDF находится на прилагаемом компакт-диске.

щ
На ранних стадиях управления программными проектами на роль менеджеров
проектов назначают самых лучших программистов, поскольку они компетентны в
инструментальных средствах (языках программирования, компиляторах и т.д.) и часто
неплохо знают смежные области, например, прикладные научные программы,
бизнес-приложения или прикладные системы, выполняемые в режиме реального
времени. Однако иногда эти люди не справляются с новыми обязанностями, поскольку не
подготовлены к возникновению ситуаций, причины которых не связаны с
проблемами технического плана. В настоящей книге убедительно демонстрируется то, что
менеджеры, выполняющие разработку ПО, должны обладать навыками, выходящими
далеко за границы обычного программирования. Безусловно практические познания
в области программного инжиниринга необходимы для успешной работы в
дальнейшем, но хороший менеджер, руководящий работами по разработке ПО, обязан уметь
управлять людьми и программными проектами.
В настоящем пособии были рассмотрены 34 компетенции, которые применяли
в своей практике менеджеры проектов, достигшие наибольшего успеха в своей
деятельности. Этот перечень видов деятельности основан на опыте руководителей,
которые принимали участие в подготовке программы по сертификации управления
программными проектами (Software Project Management certificate program) в
Техасском университете города Остин A993 — 2001 гг). Эта программа представляет собой
итоговый документ Института качества ПО (Software Quality Institute),
предназначенный для обеспечения управления программными проектами.
В заключительной главе книги обобщается информация по всем методам и
инструментальным средствам, необходимым в процессе осуществления управления
программными проектами. Рассмотрение производится в контексте трех ранее
упомянутых категорий: программный продукт, проект и персонал.

Резюме 1009
Методики, применяемые при разработке
программных продуктов
1. Процессы оценивания — определение критериев, применяемых для оценок.
2. Знание стандартов процесса — понимание стандартов, применяемых в ходе
выполнения процесса.
3. Определение продукта— идентификация потребительской среды и требований,
предъявленных к программному продукту.
4. Оценка альтернативных процессов— оценивание различных применяемых
подходов.
5. Управление требованиями — мониторинг изменений технических требований.
6. Управление субподрядчиками— планирование работы, управление и
отслеживание выполнения.
7. Выполнение начальной оценки — оценивание трудностей, рисков, затрат и
графика (работ).
8. Отбор методов и инструментов — определение выбора процессов.
9. Подгонка процессов — модификация стандартных процессов с целью их
подгонки для определенного проекта.
10. Отслеживание качества продукта— мониторинг качества программного
продукта.
11. Понимание действий по разработке продукта— изучение полного цикла
разработки ПО.
Первые 11 компетенций, необходимые при разработке программного продукта,
касаются главным образом менеджера проекта, группы разработчиков и самой
организации-разработчика, обслуживающей внешнего заказчика. Стоимость и качество
определяются на основе мнения и опыта заказчика, имеющего дело с
разрабатываемым программным продуктом. Причем эти показатели формируются не только
организацией-разработчиком. При их определении учитывают степень учета требований
потребителя и производственные факторы, к которым относят конкретные методы и
инструментальные средства, используемые для поддержки всех компетенций,
необходимых при разработке программного продукта.
Процесс
При определении процесса, которого должна придерживаться группа
разработчиков и организация-разработчик ПО, менеджеру проекта необходим метод оценки
решений процесса и шаблон для получения структуры разрабатываемого продукта.
На рис. 33.1 показана внешняя модель процесса, используемая для оценивания его
параметров.
Основанная на классической модели процесса Деминга-Шухарта-Ишикава (Deming/
Shewhart/Ishikawa), внешняя модель ПО объединяет статистическую информацию и
опыт с конкретными задачами по разработке ПО. Модель полезна для
предварительной обработки данных проекта перед началом стадии исследования концепции, а
также во время выполнения проекта. При этом появляется возможность учета
влияния параметров, улучшающих выполняемый процесс.

1010 Глава 33
Рис. 33.1. Внешняя модель процесса разработки ПО
Вторая часть определения процесса заключается в выборе основного шаблона для
адаптации к конкретным проектам и организациям. На рис. 33.3 показана структура
модели процесса разработки ПО IEEE 1074.
Этот рисунок является исходной точкой для выбора фаз жизненного цикла
разработки программного продукта и вспомогательных процессов.
Жизненные циклы
Самый важный вывод, который можно сделать из дискуссии о жизненных циклах,
заключается в том, что рисунок 33.2 не демонстрирует способ разработки ПО.
Что неправильно в этом процессе?
Рис. 33.2. Это не жизненный цикл разработки продукта
Используйте эту иллюстрацию для представления относительно
функционирования типичного первого уровня зрелости модели СММ.
Выбор наиболее подходящего жизненного цикла зависит от технических
требований проекта, уровня подготовки группы разработчиков, опыта (искушенности)
конечного пользователя и присущего проекту риска. Матрицы являются мощным
инструментальным средством, позволяющим выполнить анализ и визуализации данных.

Резюме 1011
Исследование
концепции
■ Формули-''
рование

потребности
Исследование
системы
' Спецификация
интерфейса
системы
Требоввния
1 Спецификация''
требований
к ПО
Идентификация
циклов SLC
•iSLCs
_i
Выбор
модели
Базовая модель жизненного цикла разработки системы
Разработка
проекта
' Описание

разработки ПО
Модель SLC Выбор модели
жизненного цикла ПО
Установка
соответствия

междузадачами и циклами
SLC с помощью
IEEE 1074
iSLC
Распределение
ресурсов
! Бюджет
Установи среды проекта
■ Методологии
I ■ Стандарты
I ■ Инструментальные средства
Внедрение
■ План

тации/верификации ПО
Планирование и начало работ в рамках проекта
Управление планом проекта
. - Отчет об имеющихся проблемах и план их разрешении
! -План управления программным проектом J
I - План поддержки i i
I ■ План вывода из эксплуатации t I
Анализ рисков
- План по снижению рисков
. : 1 1
Планирование преодоления чрезвычайной ситуации
Установка
■Отчет об

тестации/верификации ПО
Эксплуатация
и поддержка
•
Пользовательская
документация
Сопровождение
' Документация
по
сопровождению
Вывод из
эксплуатации
• Архивный
отчет
- Чрезвычайный план (предопре- I
деленный план действий в
аварийных ситуациях, включающий
в себя процедуры резервного
копирования и подготовку резер- L
вного оборудования с целью прео- £
Контроль и отслеживание проекта
■ Отчеты по управлению проектом
Управление проектом
. вили цццрудивании i целью iyw |
I долени,чре»ычайнойситу»1ии) , . регистр.цМстаТ|Ютических данных проекта
Ведение журнала
Методы составления отчета по устранению проблем
■ Отчет по разрешенным проблемам
- Отчет по разрешению основной проблемы
- Отчет по анализу проблем [
Рис. 33.2. Структура процесса разработки ПО

1012 Глава 33
Планирование
обеспечения
качества
программного
оовспочония
'План по обеспечение
программного
Управление качеством программного обеспечения
Метрические показетели
Управление <ачвстаом11хгрв|»жвгоос«спвчвиия
!• Оценки качества проекта
Определение требований по улучшению качества
' Рекомендации по улучшению качества
Планирование аттестации и верификации
• План аттестации и верификации ПО
Аттестация и верификация
Выго/»<оние задач гю аттестации и верификации
■ Отчеты по результатам оценивания
Сбор и анализ метрически» данных
Анализ отчетов!
План тестирования
) • Плены тестов (испытаний, проверок)
(Разработка тестовой спецификации]
Тестовая спецификация
Выполнение
тестов
Планирование менеджмента конфигурации
Разработка схемы по идентификации конфигурации
'План менеджмента конфигурации программного обеспечения
1 Схема определения конфигурации
• Итоговый отчет по тестам j
' Тестированное программное обеспечение
I I
i i
Менеджмент конфигурации
программного обеспечения
Контроль конфигурации
• Изменение состояния
Выполнение проверки состояния
• Отчеты по состоянию
Планирование документации
Разработка документации
| • План по документации
I ■Документы i
Внедрение документирования
Разработка и рдсг<)оспт)анение документации
' Опубликованные документы
Планирование учебной программы
| -Учебныйплан |
Разработка
учебных
материалов
Обучение
•Учебное пособив
• Учебный (—
материал |
Проверка учебной программы
Обновление учебных материалов
Рис. 33.2. Структура процесса разработки ПО (окончание)
Выполнение учебной программы
i
• Подготовленный персонал

Резюме 1013
Приведенные ниже три матрицы дают представление о критериях выбора
жизненного цикла проекта. Категория требований (см. табл. 33.1) состоит из
вопросов, имеющих отношение к запросам пользователей. Их иногда называют
функциями или характеристиками системы, которая будет получена в результате
реализации проекта.
Таблица 33.1. Выбор жизненного цикла разработки ПО на основе
технических требований к системе
Требования
Каскад V- Прото- Спираль- БРП Инкре-
образный тип ный (RAD) ментный
Легко ли установить техниче- Да Да
ские требования и/или они
хорошо известны?
Можно ли определить техни- Да Да
ческие требования в начале
цикла?
Часто ли меняются техниче- Нет Нет
ские требования на
протяжении жизненного цикла?
Необходима ли для определе- Нет Нет
ния технических требований
их демонстрация?
Необходимо ли доказывать Нет Нет
концепцию, чтобы
продемонстрировать
работоспособность (системы)?
Указывают ли требования на Нет Нет
сложность системы?
Являются ли описанные Нет Нет
функциональные
возможности одним из требований?
Нет Нет Да Нет
Нет Нет Да Да
Да Да Нет Нет
Да Да Да Нет
Да Да Да Нет
Да Да Нет Да
Да Да Да Да
Прежде чем выбрать модель жизненного цикла, желательно по возможности
подобрать персонал, выполняющий разработку ПО. Характеристики группы (табл. 33.2)
важны при выборе процесса, поскольку разработчики несут ответственность за
успешное выполнение цикла и могут быть весьма полезны при выборе процесса.
Таблица 33.2. Выбор жизненного цикла разработки ПО на основе
информации о разработчиках проекта
Группа разработчиков
Каскад V- Прото- Спираль- БРП Инкре-
образный тип ный (RAD) ментный
Являются ли проблемы проек- Нет
та новыми для большинства
членов группы разработчиков?
Нет
Да
Да
Нет
Нет

1014 Глава 33
Окончание табл. 33.2
Группа разработчиков
Каскад V-
образный
Прото- Спираль-
тип ный
БРП Инкре-
(RAD) ментный
Является ли технология,
связанная с проектом, новой для
большинства членов группы
разработчиков?
Являются ли
инструментальные средства,
использованные в проекте, новыми для
большинства членов группы
разработчиков?
Меняются ли функции членов
группы разработчиков в
течение жизненного цикла?
Может ли группа
разработчиков в случае необходимости
пройти обучение?
Что предпочитают члены
группы разработчиков:
жесткую структуру или гибкую?
Внимательно ли менеджер
проекта отслеживает процесс
разработки?
Важна ли для группы легкость
перераспределения ресурсов?
Положительно ли
воспринимает группа разработчиков
проверки и контроль со
стороны специалистов равного с
ними уровня, проверки
руководства/потребителя и
проверку этапов?
Да
Да
Нет
Нет
Да
Да
Да
Да
Нет
Да
Да
Да
Нет Да
Нет Да
Нет Да
Нет Нет
Да
Нет
Нет
Нет
Да
Нет
Нет
Да
Нет
Да
Нет
Нет
Да
Да
Да
Да
Да
Да
Да
Да
Нет
Да
Нет
Да
Да
Нет
Да
Да
На ранних стадиях выполнения проекта следует наладить хорошее взаимпонима-
пис и связь группы разработчиков с коллективом пользователей (см. табл. 33.3). Это
поможет выбрать подходящую модель, так как некоторые из этих моделей зависят от
тесного привлечения пользователей и понимания ими сути самого проекта.
Таблица 33.3. Выбор жизненного цикла разработки ПО на основе
информации о персонале
Коллектив пользователей Каскад V- Прото- Спираль- БРП Инкре-
образный тип ный (RATJ) ментный
Будет ли ограничен доступ
представителей
пользователей к проекту в течение его
жизненного цикла?
Да
Да
Нет
Да
Нет
Да

Резюме 1015
Окончание табл. 33.3
Группа разработчиков Каскад V- Прото- Спираль- БРП Иикре-
образиый тип ный (RAD) ментный
Знакомы ли представители Нет Нет
пользователей с описанием
системы?
Являются ли представители Нет Нет
пользователей экспертами в
предметной области для
данной проблемы?
Хотят ли пользователи участ- Нет Нет
вовать во всех стадиях
жизненного цикла?
Хотел бы заказчик отслежи- Нет Нет
вать ход работы над проектом?
Да Да Нет Да
Да Нет Да Да
Да Нет Да Нет
Да Да Нет Нет
И наконец, проанализируйте тип проекта и степень риска (см. табл. 33.4),
который уже определен на этой стадии планирования. Некоторые модели разрабатывают
так, чтобы они позволяли управлять высокими степенями риска, другие — нет. Выбор
модели, которая позволяет управлять риском, еще не означает, что не следует
разрабатывать план действий для минимизации определенных рисков. Модель просто дает
структуру, в рамках которой можно реализовать этот план.
Таблица 33.4. Выбор жизненного цикла разработки ПО на основе типа
проекта и степени риска
Тип проекта и риск
Каскад V- Прото- Спираль- БРП Инкре-
образяый тип ный (RAD) ментиый
Разрабатывается ли в ходе Нет Нет
осуществления проекта
продукт, представляющий новое
направление для организации?
Относится ли данный проект к Нет Да
классу системной интеграции?
Является ли проект продук- Нет Да
том модернизации уже
существующей системы?
Ожидается ли, что финанси- Да Да
рование проекта будет
стабильным на протяжении всего
жизненного цикла разработки?
Ожидается ли, что данный Да Да
продукт будет иметь
продолжительный жизненный цикл
в организации?
Необходима ли высокая сте- Нет Да
пень надежности?
Да Да Нет Да
Да Да Да Да
Нет Нет Да Да
Да Нет Да Нет
Нет Да Нет Да
Нет Да Нет Да

1016 Глава 33
Окончание табл. 33А
Группа разработчиков
Каскад V- Прото- Спираль- БРП Инкре-
образный тип ный (RAD) ментный
Ожидается ли, что. возможно, Нет
после развертываниясистема
будет модифицирована
непредвиденными способами?
Ограничен ли график выпол- Нет
нения работ?
Являются ли интерфейсы мо- Да
дуля простыми для понимания?
Доступны ли повторно ис- Нет
пользуемые компоненты?
Достаточно ли ресурсов для Нет
выполнения проекта (время,
деньги, инструментальные
средства, персонал)?
Нет
Да
Да
Нет
Да
Нет
Да
Нет
Нет
Да
Нет
Да
Да
Да
Нет
Да
Да
Да
Нет
Да
Нет
Да
Да
Нет
Нет
Предметная область
Менеджеры проектов должны интересоваться некоторыми экономическими
проблемами (процессами предметной области), которые не относятся непосредственно
к сфере их деятельности, но именно здесь происходит "пересечение" проекта с
реальным миром. Для осуществления разработки проекта требуется поддержка со стороны
300
250
200
150
100
50
0
-50
-100
-150
-200
Спад
производства
Разработка
<Ч=г
1-~_
^£?£^щНРП
!<§>Еез
i ■««- 'л. -.;
j|^J;$2M
-*-
*-А
Рост
рынка
Насыщение (зрелость) рынка I Окончание
^^^^^^^^^^^^^^Шк
^^Ш: ЛИ
^7
г
г
S10M «i
1
; 1
| 1 1 | 1 1 | 1 1 | 1 1 | 1 1 | М | 1 1 | 1 1 | 1 1 | 1 1 | 1 1 | 1 1 | 1 1 | 1 1 | 1 1 | 1
22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67
^Ш Месяцы
Рис. 33.4. Жизненный цикл разработки программного продукта

Резюме 1017
маркетинговых и финансовых организаций. На рис. 33.4 показан полный жизненный
цикл разработки и поддержки продукта.
Сумма инвестиций (в долларах) с левой стороны графика ниже оси X — это
оцененные инвестиции, вложенные в разработку продукта. Сумма (в долларах) выше оси
X— это оцененный доход (прибыль), выраженный в долларах, который получен
благодаря разработанному продукту. Предоставление информации такого типа обычно
является прерогативой отдела маркетинга. На основе этих данных видно, какая часть
прибыли на инвестированный капитал будет получена от реализации продукта.
Процесс разработки ПО отображен в левой части графика, который отражает
инвестиции, направляемые в проект.
Менеджер проекта должен всегда помнить о существовании этой важной
взаимосвязи. В производственном мире жизненный цикл разработки программного
продукта определяет принятие решений и инвестиции. Именно инвестиционная часть
жизненного цикла разработки ПО имеет значение для менеджеров, планирующих
портфели заказов программных продуктов.
Также в обязанности менеджера входит знание принципов оценки портфеля
проектов относительно финансового обеспечения. Чаще всего используют
экономическую модель, где главными показателями являются: внутренняя норма прибыли,
чистая приведенная стоимость, предельная стоимость капитала, прибыль на
инвестированный капитал, активы и инвестированный капитал, а также средневзвешенная
стоимость капитала (weighted average cost of capital, WACC) (СВСК). На рис 33.5
показана наиболее простая форма экономической модели формирования прибыли.
VV ~/^ ^ Кривая, отражающая
N/ ' распределение
стоимости активов
КОИ - коэффициент окупаемости инвестиций
Рис. 33.5. Выбор экономической модели формирования прибыли для проекта
Постепенно линия, которая отражает распределение стоимости активов,
поднимается вверх и затем падает относительно средневзвешенной стоимости капитала.
Проекты, прибыль которых находится выше этой скользящей линии, приносят доход
(прибыль), который превышает средневзвешенную стоимость капитала. Если
прибыль проекта находится ниже этой линии, следует рассматривать возможность его
прекращения. Эту модель можно использовать как для отслеживания исторических
тенденций, так и для прогнозирования будущей стоимости распределения активов.
Менеджеры проектов должны постоянно следить за ходом выполнения проектов,
руководствуясь этим графиком.

1018 Глава 33
Спецификации требований к ПО
На рис. 3.3.6 продемонстрированы три аспекта проблемы разработки проекта,
которые следует учитывать группе проектантов при анализе и документировании
технических требований.
Классический процесс, данные и поведенческая
точка зрения— вот три аспекта проблемы разработки
продукта, которые работают для классически
структурированных методов и объектно-ориентированной
модели формулирования требований.
Одним из инструментов анализа, используемым при
разработке требований к ПО, является матрица
трассировки (см. табл. 33.5). Эту базовую матрицу
применяют в течение всего жизненного цикла разработки
ПО с целью установки соответствия модулей проекта
требованиям, тестам и элементам конфигурации. Это
единственный инструмент, используемый самое про-
Рис. 13.6. Три аспекта прог- должительно время, и поэтому необходимо особенно
раммиого продукта внимательно следить за его эволюцией на этапе
формулирования требований.
Таблица 33.5. Матрица трассировки требований
Поведение
Номер требования и описания
■в
R
fr
0
2
А
6"
0
2
<?
fr
0
2
<?
fr
0
2
А
6"
0
2
А
6"
0
2
■в
R
fr
0
2
3. 1 Функциональные технические требования
3.1.1 Функциональное требование 1
3.1.1.1 Введение X
3.1.1.2 Вводные данные
3.1.1.3 Обработка
3.1.1.4 Выходные данные
3.1.2 Функциональное требование 2
3.1.2.1 Введение
3.1.2.2 Вводные данные
3.1.2.3 Обработка
3.1.2.4 Выходные данные
3.1 .п Функциональные требования п
3.1.IT.1 Введение
3.1.п.2 Вводные данные
3.1.П.З Обработка X
X X
X
X
X
X
X X

Резюме 1019
Окончание табл. 33.5
Номер требования и описания
Л
R
£
0
S
X
X
X
Л
R
£
0
S
X
X
X
А
R
1?
0
S
X
X
■в
R
&
0
S
X
X
X
■в
R
&
0
S
X
R
&
0
S
R
&
0
2
X
3.1.п.4 Выходные данные
3.2 Требования к внешнему интерфейсу
3.2.1 Пользовательский интерфейс
3.2.2 Интерфейсы аппаратного обеспечения
3.2.3 Интерфейсы ПО
3.2.4 Интерфейсы коммуникаций
3.3 Выполнение (реализация) технических требований X
3.4 Ограничения проекта X
3.4.1 Соответствие стандартам X X
3.4.2 Ограничения аппаратного обеспечения X X
3.5 Качественные характеристики
3.5.1 Корректность X X
3.5.2 Однозначность X X
3.5.3 Законченность X X
3.5.4 Совместимость X
3.5.5 Ранги по важности или стабильности X X
3.5.6 Возможность осуществления контроля
3.5.7 Возможность изменений X X
3.5.8 Возможность трассировки х X X X X X X
3.6 Другие технические требования
3.6.1 База данных X X
3.6.2 Операции X
3.6.3 Адаптация узла X
Программный инжиниринг
С помощью модели зрелости возможностей, разработанной Институтом
программного инжиниринга (Software Engineering Institute's Capability Model),
определяют показатели, характеризующие степень выполнения проекта для всех
организаций, занимающихся разработкой ПО. Менеджеру проекта не нужно владеть иными
инструментами по оцениванию процесса (разработки). На рис. 33.7 показаны уровни
зрелости проекта и ключевые области процесса разработки.

1020 Глава 33
Рис. 33.7. Ключевые области (уровни) процесса разработки на
разных уровнях зрелости проекта в соответствии с моделью,
разработанной Институтом программного инжиниринга
Модель утверждена и используется с целью повышения качества и снижения
затрат организаций, повышающих уровни зрелости ПО.
Анализ и разработка проекта
В организациях, занимающихся разработкой ПО, возникают внутренние "войны"
относительно применения структурированных методов анализа и разработки или
объектно-ориентированных методов. Некоторые организации даже используют
комбинированный набор, включающий оба типа моделей. В табл. 33.6 и 33.7 описаны
модели, используемые для анализа и разработки как классических, так и объектно-
ориентированных методов.

Резюме 1021
Таблица 33.6. Модели структурного анализа/разработки проекта
Данные, Тип
функция, модели
поведение
Описание
Элементы
Фаза: структурный анализ
Функция
Функция
Функция
Диаграмма
контекста

(контекстных)
данных (ДКД)
Диаграммы
потока
данных (ДПД)

Спецификации
процесса (СП)
Изображение системы и ее интер
фейсов по отношению к внешним
элементам или системам. На нем
показана граница между системой
и окружающей средой в проекции
к реальному миру со всеми
идентифицированными сетевыми
входными и выходными данными.
При наличии только одного
процесса такая система является в
этой точке "черным ящиком", то
есть она отражает все
преобразования, выполненные системой
ДПД (диаграмма потока данных) —
это отображение системы в виде
сети функциональных процессов,
связанных друг с другом потоками
данных и хранилищами данных.
Эти процессы и преобразуют
данные. Диаграмма разделяет систему
на компоненты
Описание функции или процесса
на самом низком уровне
декомпозиции (разложения) — пишется для
каждого функционального
базисного (примитивного) процесса.
В описание входит
преобразование, выполняемое в каждом
процессе, т.е. преобразование
входных данных для получения
желаемых выходных данных
Элементы внешней системы
(прямоугольники), один
процесс (система — окруж-
иость/пузырек), потоки
данных (дугообразные стрелки)
Помеченные кружочками (на
схеме) процессы, потоки
данных, хранилища данных.
Следует отметить, что элементы
внешней системы не
показаны на диаграмме ДПД, а
хранилища данных не
отображены. Терминаторы из ДКД
удаляют; остается лишь
информация входящая и выходящая
в (из) системы (поток данных)
и один главный процесс
(окружность) разбивается на
несколько более мелких
процессов (пузырьков)
Спецификация процесса
может выступать в форме
структурированного языка
(псевдокода), таблиц
решений, уравнений, диаграмм,
математических уравнений,
блок-схем (структурных схем)
или других графических
компонентов

1022 Глава 33
Продолжение табл. 33.6
Данные, Тип
функция, модели
поведение
Описание
Элементы
Данные
Модель
взаимосвязи
объектов (эле-
ментов)/диа
грамма
(МВО)
Поведение
Диаграмма
управления
контекстом
(ДУК)
Поведение
Поведение
Диаграмма

управляющей логики
(ДУЛ)

Спецификации
функций
управления
(СФУ)
Позволяет разработчику ПО
идентифицировать объекты данных и их
взаимосвязи, используя графическое
представление. В контексте
структурного анализа модель взаимосвязи
объектов (элементов) определяет все
данные, которые вводят, хранят,
преобразуют и получают в пределах
приложения. Это изображение
данных, объединенных в определенные
группы, которое показывает
взаимосвязи между ними
Как и диаграмма потока данных
(ДПД), диаграмма управления
контекстом (ДУК) показывает ввод и
вывод данных из (в) внешние
объекты (элементы). ДУК разбита на
компоненты, которые
завершаются спецификациями. Различие
состоит в том, что данные, которые
появляются на ДУК или диаграмме
управляющей логики (ДУЛ),
являются управляющими данными, что
приводит к изменению состояния
системы и далее к активизации или
дезактивации преобразований
Модель управляющей логики, а не
потоков данных. Совместно
использует свойства диаграммы
потока данных (ДПД) по
присваиванию имен, нумерации,
ранжированию по уровням и
уравновешиванию (симметрированию)
Показаны в виде прямоугольника
на ДУЛ; могут изменять состояние
системы
Элементы (прямоугольники),
атрибуты, связи (прямые
линии), количество элементов
("елочка" « много,
прямоугольник » одна, пузырек =
ноль)
Элементы внешней системы
(окружающей среды), процесс
(система) относятся к области
управляющей логики.
Элементы и символы на ДУК
аналогичны элементам на
диаграмме контекста (контекстных)
данных (ДКД), за
исключением того, что управляющие
данные показаны пунктирной
линией, чтобы их можно было
отличить от всех других
данных и учесть лишь
поведенческое моделирование
Процессы, помеченные
кружками и относящиеся к области
управляющей логики
(пунктирные линии), хранилища
данных, панели управляющих
элементов для спецификации
функций управления
Диаграммы переходов
(конечного автомата из одних
состояний в другие) —
состояние, переход,
событие/действие (операция)
Этап (фаза): структурная разработка проекта
Данные
Диаграмма
взаимосвязи

расширенных
объектов
(элементов) (ДВРО)
Дальнейшая итерация диаграммы
взаимосвязи расширенных
объектов (ДВРО), основанная на
информации, полученной на этапе
разработки проекта
Объекты, свойства
(атрибуты), связи и
количество элементов (множества)

Резюме 1023
Окончание табл. 33.6
Данные, Тип
функция, модели
поведение
Описание
Элементы
Функция/
поведение
Диаграммы

архитектурного
контекста
(ДАК)
Функция/ Диаграммы
поведение
архитектурных потоков
(ДФП)
Функция/
поведение

Структурные схемы
Функция Диаграммы
Чейпина
(Chapin
charts)
Поведение Диаграммы

архитектурных

зависимостей
(межкомпонентных
соединений)
Устанавливает информационную
границу между системой и
окружающей средой. Показывает
физическое размещение
(распределение) требований к данным модели
(ДПД) и (ДУЛ) обработки
управляющих данных. Назначает
процессы требований модели к
физическим модулям, которые образуют
систему и устанавливают
взаимосвязи между ними
Пузырьки, определяющие процесс
на диаграмме потоков данных
(ДПД), перегруппировывают в
соответствии с физическими
характеристиками, например,
располагают вместе для создания
пользовательского интерфейса
Структурные схемы организуют
системы, которые разбиты на
темные прямоугольники. Структурные
схемы показывают временную
последовательность по вертикали, а
не по горизонтали
Диаграммы структурированных
потоков. Отдельный вход,
отдельный выход
Представление информационных
каналов (каналов связи), которые
существуют между
архитектурными модулями (модулями
архитектуры). Показывают физические
средства с помощью которых
связаны модули. В качестве примера
можно привести радиосигналы,
электрическую шину (магистраль),
механическую линию и
оптическую линию связи
Модуль = прямоугольник с
закругленными краями;
перегруппированные кружки,
обозначающие процесс; вектор
информационных потоков =
стрелка (данные)/пунктирная
стрелка (управление); пучки
(связки) данных и
управляющих потоков
Разложенные диаграммы
архитектурного контекста
(ДАК). Модули, входные
данные, выходные данные,
пользовательский интерфейс,
сопровождение (ПО) и
самопомощь
Модульные блоки,
управление, данные
Четыре конструктивных
элемента обработки: простая
последовательность, do while/
do until, if-then-else, do case
Аналогичны диаграммам
архитектурных потоков (ДФП)
с дополнением каналов связи.
Многоканальные (линии
связи) — это элементы (блоки)

1024 Глава 33
Таблица 33.7. Объектно-ориентированные модели
Данные, Тип
функция, модели Описание Элементы
поведение
Фаза: объектно-ориентированный анализ

Статические модели;
данные,
функция

Динамические
модели;
функция,
поведение
Диаграммы
классов
Объектные
диаграммы
Варианты

использования
Сценарий
Диаграмма

деятельности
(активности)
Диаграмма классов, связанных
статическими связями
Диаграмма примеров классов,
включая объекты и значения данных.
Показывает снимок состояния системы
в определенный момент времени
Модель способа, с помощью
которого актор взаимодействует с данной
системой
Пример ситуации использования;
отдельная ветвь выполнения в
случае использования, показывающая
действия (операции) и
взаимодействия объектов (но не классов)
Графическая модель ситуации
использования, показывающая
управляющую логику. Набор операций.
которые необходимо выполнить,
включая временное установление
последовательности (упорядочение
во времени) и режим (условия)
Классы (атрибуты,
операции), связи (ассоциации),
типы данных (операции
могут быть описаны
диаграммами потоков данных
(ДПД) или псевдокодом,
например, анализ SA/SD)
Объекты (атрибуты,
методы), связи, значения
Акторы (штриховые
цифры), системные функции
(овал) (эллипс), «uses».
«extends», стрелки
Акторы, системные
функции
Блок-схема, операции
(капсула), последовательность
(помеченная стрелками), режим
(условия) (ромбы), конец
последовательности действий
синхронизации строк
(параллельных операций)
Фаза: объектно-ориентированная разработка проекта

Статическая модель

Динамическая
модель
Диаграмма

расширенных классов
Диаграммы

взаимодействия —
диаграммы
участия
Уточнение по модели
Пространственные диаграммы с
акцентом на объектах и связях между
объектами
Объекты (прямоугольники).
связи (стрелки) с
последовательными логическими
блоками информации,
обратные ссылки или данные

Резюме 1025
Окончание табл. 33.7
Данные, Тип
функция, модели
поведение
Описание
Элементы
Диаграммы

взаимодействия —
диаграммы

следовательности
Диаграммы
перехода
(передачи)
состояния
Способ реализации ситуации
использования через взаимодействующие
объекты, определяемые классами
внутри элемента, можно
конкретизировать с помощью диаграммы
участия. Ситуацию использования
объекта можно уточнить по отношению
к набору ситуаций использования
элементов, содержащихся в объекте.
Способ взаимодействия этих
подчиненных ситуаций использования
можно выразить через диаграмму
участия
Графики, показывающие временное
установление последовательности
(упорядочивание во времени) с
акцентом на порядке сообщений
Связанные с одним классом —
состояние через которое может
проходить экземпляр класса (объект
данного класса)
Акторы, "линии жизни",
возглавляемые объектами,
связи (стрелки), сообщения,
позиционированные
вертикально
Событие, состояние,
переход, инициированный
событием
Инструментальные средства разработки ПО, включая
менеджмент конфигураций
Менеджеры проектов и члены группы разработчиков тратят много времени на
поиск, выбор и изучение инструментальных средств, применяемых для
осуществления программного инжиниринга. Жизненный цикл, выбранный для проекта,
наряду с программной поддержкой, образуют структуру, в рамках которой должны
функционировать инструментальные средства. В табл. 33.8 показан набор
инструментальных средств, которые охватывают полный жизненный цикл. Это базовый
набор инструментальных средств, которым должен уметь пользоваться опытный
разработчик ПО. Причем здесь подразумевается минимальный набор
инструментальных средств, но его более чем достаточно для того, чтобы начать работу над
проектом. Несмотря на то, что разработчикам необходимы инструментальные
средства для начала работы, не стоит акцентировать на них внимание, если проект
должен определить продукт.

1026 Глава 33
Таблица 33.8. Минимальный набор инструментальных средств
Класс инструментально- Определенный тип
го средства инструментального
средства

Инструментальные средства
Microsoft® Windows

Инструментальные
средства Linux
Инструментальные
средства по определению
технических требований к
программному обеспечению
Инструментальные
средства для разработки
(проектирования) ПО
Инструментальные
средства для построения
программного обеспечения
Инструментальные
средства для тестирования ПО
Инструментальные
средства, предназначенные для
сопровождения ПО
Инструментальные
средства, предназначенные для
процесса разработки
проекта ПО
Моделирование
технических требований
Способность к
отслеживанию (трассировке)
Моделирование процесса
разработки проекта
Проверка правильности
проектных решений
Оптимизация разработки
проекта
Редакторы программного
кода
Компиляторы
Интерпретаторы
Программы отладки
Генераторы теста
Условия выполнения теста
Оценивание теста
Управление тестом
Анализ эффективности
функционирования
Охват (обозримость
программы)
Восстановление
структурной схемы и алгоритма
работы по исходным
текстам (существующей
программы)
Управление процессом
Visio®
Access
Excel
Visio®
Access
Visio®
Access
Visual Studio
Visual Studio
Visual Studio
Visual Studio
Visual Studio
Access
Visual Studio
Excel
Visual Source Safe
Excel
Visual Studio
Visual Studio
Dia
Quicklist
abs
ArgoUML
ArgoUML
ArgoUML
Emacs
AnyJ
Perl
AnyJ
Quicklist
ArgoUML
Perl
abs
CVS
abs
Cxref
ArgoUML
Email, Web,
текстовый процессор
email, web
Моделирование процесса Visio®
Dia

Резюме 1027
Окончание табл. 33.8
Класс инструментально- Определенный тип
го средства инструментального
средства
Инструменталь- Инструмен-
ные средства Mic- тальные сред-
roeoft® Windows ства Linux
Интегрированные среды
(режимы работы) CASE
Visual Studio
AnyJ
Инструментальные
средства по обеспечению
качества (разрабатываемого) ПО
Инструментальные
средства по управлению
конфигурацией ПО
Инструментальные
средства по управлению
инжинирингом ПО
Инструментальные
средства но поддержке
инфраструктуры
Вопросы, связанные со
вспомогательными
инструментальными средствами
Проверка
Статический анализ
Отслеживание дефектов,
выполняемых
модернизаций, возникающих
вопросов и проблем
Менеджмент версии
Версия и подвертя
Планирование и
отслеживание проекта
Управление рисками
Измерение
Межличностные связи
Система поиска информации
Управление и поддержка
Методы интегрирования
инструментальных средств
Метаинструментальные
средства
Оценивание с помощью
инструментальных средств
Email, Web, тексто- email, web, abs
вый процессор
RSM RSM
Visual Source Safe CVS
Visual Source Safe
Visual Source Safe
Excel
Excel
Excel
Email, Web chat
Access, Web
Email, Web
Visual Basic, Perl,
Tcl/Tk
Access, Excel
Excel
CVS
CVS
abs
abs
abs
Email, Web
chat
Quicklist, Web
Email, Web
Perl, Tcl/Tk
Dia, abs
abs
Постоянное совершенствование процесса
разработки программ
Постоянное улучшение процесса разработки ПО является для организации тем
видом деятельности, которая больше всего ориентирована на заказчика.
Совершенствование описания и составных частей того элемента, который, согласно мнению
потребителя, определяет качество программного продукта, влияет на его стоимость.
В табл. 33.9 приведен метод классификации и вычисления стоимости продукта для
заказчика, исходя из стоимости разработки продукта.

1028 Глава 33
Таблица 33.9. Пример электронной таблицы, включающей данные о стоимости
Идентификатор проекта
Прибыльный
Проектирование
Документация
Внедрение
Установка
Требования
Отгрузка (отправка)
Модернизация (наращивание
возможностей системы)
Всего работ с полученной
прибылью:
Количество работ с
полученной прибылью
относительно всех видов работ:
Отношение существенных
видов работ к
несущественным:
Работы с добавленной
стоимостью, а также
отношение существенных видов
работ к общему числу работ:
0
0,0%
0,0%
0,0%
Неприбыльный
Существенные
Приемо-сдаточные
испытания
Передача данных
между этапами
Планирование
Наладка (Установка)
Некоторый процесс
Обучение
Всего
существенных видов работ:
0
Несущественные
"Узкие места"
Корректировка
Задержки (отсрочки)
Анализ ошибок
Контроль сроков
Дополнительное
оформление документации
Дополнительные
ненужные характеристики
Установка (инсталляция)
инструментальных
средств ПО
Управление (менеджмент)
Измерения
Модификация
Совершенствование
процесса
Отзыв процесса
Повторное тестирование
Доработка
Всего несущественных
видов работ:
Отношение
несущественных видов работ к общему
числу работ:
0
0,0%

Резюме 1029
Навыки по управлению проектом
12. Создание структуры пооперационного перечня работ (рабочей сметы
расходов проекта, WBS) — распределение расходов по статьям баланса.
13. Документирование планов — определение ключевых компонентов проекта.
14. Оценивание стоимости — определение издержек при выполнении проекта.
15. Оценка трудозатрат — определение мероприятий, необходимых для завершения
проекта.
16. Менеджмент рисков— идентификация и определение влияния рисков на
проект, а также управление ими.
17. Отслеживание процесса разработки — мониторинг производства ПО.
18. Составление графика— составление общего календарного плана и поэтапного
графика выполнения работ.
19. Выбор метрических показателей — выполнение отбора соответствующих
метрических показателей (метрик).
20. Отбор инструментов менеджмента проектов— критерии выбора
инструментальных средств управления проектом.
21. Отслеживание процессов— мониторинг степени согласованности работы
команды разработчиков
22. Отслеживание хода разработки проекта — мониторинг хода разработки проекта
с помощью ряда показателей
Указанные центральные 11 компетенций демонстрируют приемы управления,
которыми должны владеть менеджеры проектов. Ниже приведены конкретные методы
и инструментальные средства, используемые в процессе управления проектом.
Определение целей проекта
Определение целей проекта приводит к еще одной схеме процесса. Схема
процесса разработки проекта, показанная на рис. SS.8, дает представление об этапах
выполнения проекта и его целях.
Почему
Обоснование
Коэффициент
КОИ
Что
Техническое
задание
(на проект)
Процесс SOW
Как
ПланБРМР
Модель
жизненного
цикла
Выполнить
Выполнение
жизненного
цикла
Сделано
Процесс РРА
Рис. 33.8. Схема процесса выполнения проекта

1030 Глава 33
Полезным методом конкретизации целей и задач является метод S.M.A.R.T.
Аббревиатура S.M.A.R.T образована начальными буквами следующих слов: specific
(целевой), measurable (измеримый), achievable (достижимый), realistic (реальный)
и time-bound (срочный).
Очевидно, что при решении любой задачи сначала необходимо ответить на ряд
вопросов. Являются ли поставленные вами задачи достаточно конкретными? Можно ли
выразить полученные результаты количественно? Как вы узнаете, что уже достигли
желаемых результатов? Что означает "удовлетворение ожиданий" для вас и вашего
заказчика по каждой из поставленных задач? Являются ли ваши цели достижимыми? В какой
поддержке вы нуждаетесь? Отвечают ли поставленные цели требованиям заказчиков и
реальным нуждам? Согласуются ли они с ключевыми факторами успеха для
организации, с ее деловыми целями и стратегиями? Ограничены ли ваши цели во времени?
Обоснованы ли сроки выполнения каждой из задач? Какой движущий механизм
существует после установленных сроков (например, потребительские нужды вашего заказчика
относительно продукта после завершения сроков разработки проекта)?
Теперь, после уточнения и согласования масштабов проекта, пришло время
подготовить договор о его разработке. Обычно менеджер проекта отражает в договоре
все высшие цели проекта, его масштаб, включает в договор другую релевантную
информацию высокого уровня и подает проект на рассмотрение и утверждение
заказчику или потребителю. Если проект будет одобрен, то начнется его финансирование.
Структура пооперационного перечня работ
На некоторых стадиях жизненного цикла проекта менеджеры должны объяснить
работникам бухгалтерии методику отслеживания расходов. Во многих организациях
связь между плановой калькуляцией затрат, фактическими расходами и вычислением
себестоимости является достаточно произвольной. Рисунок 33.9 можно успешно
использовать на практике для установления связи менеджера программного проекта с
представителями бухгалтерии и финансового отдела.
Структура сметы
расходов
(пооперационного
перечня работ)
на проект
организации
Пооперационный
перечень
работ
График
выполнения работ
Рис. 33.9. Связь между структурой WBS и контролем
фактических затрат
Источник: Stuckenbruck, ed. The Implementation of Project
Management. Addison-Wesley, 1981.

Резюме 1031
Определение задач и действий
Для менеджера проекта, который следует советам данного пособия — начинать
процесс разработки и определение жизненного цикла в соответствии с IEEE 1074,
представляется возможность воспользоваться превосходным начальным материалом
для идентификации задач и действий. В табл. 33.10 приведен перечень действий,
которые выполняются на каждой фазе жизненного цикла разработки продукта в
соответствии с IEEE 1074.
Таблица 33.10. Процессы и действия для каждой фазы жизненного цикла
разработки программного продукта в соответствии с IEEE 1074
Фаза разработки
Процессы жизненного цикла
продукта
Действия
Планирование модели
жизненного цикла ПО
1. Подгонка модели жизненного
цикла согласно целям проекта
Управление проектом 2. Начало выполнения проекта
3. Управление и отслеживание
проекта
4. Управление качеством в
процессе разработки ПО
Предварительная
разработка проекта
5. Исследование концепции
1. Определение
моделей-кандидатов жизненного цикла
2. Выбор модели проекта
3. Адаптация действий к модели
жизненного цикла
4. Распределение ресурсов проекта
5. Создание среды проекта
6. Составление плана управления
проектом
7. Анализ рисков
8. Планирование действий на
случай непредвиденных
обстоятельств
9. Управление проектом
10. Ведение документации
11. Составление отчета о
возникших проблемах
12. Составление плана управления
качеством разработки ПО
13. Определение основных
показателей
14. Управление качеством
разработки ПО
15. Определение необходимых
мероприятий по улучшению
качества
16. Определение идей или
потребностей
17. Формулирование
потенциальных подходов

1032 Глава 33
Продолжение табл. 33.10
Фаза разработки
Процессы жизненного цикла Действия
продукта
Разработка
6. Распределение системы
7. Технические требования
8. Проектирование
9. Реализация (Внедрение)
После завершения
разработки (после-
проектный период)
10. Установка (инсталляция)
18. Оценка возможности
реализации проекта
19. Составление плана системного
перехода (в случае
необходимости)
20. Уточнение и окончательное
формулирование идей или
потребностей
21. Анализ функций
22. Разработка архитектуры системы
2S. Разбиение на составные части
системных требований
24. Определение и разработка
технических требований к ПО
25. Определение требований к
интерфейсу
26. Установка приоритетов и
интегрирование требований к ПО
27. Проектирование (на уровне
архитектуры)
28. Проектирование базы данных
(в случае необходимости)
29. Проектирование интерфейсов
50. Выбор или разработка
алгоритмов (в случае необходимости)
51. Выполнение
детализированного проектирования
52. Создание тестовых
(контрольных) данных
SS. Разработка исходного кода
54. Генерирование объектного кода
55. Создание рабочей документации
56. Планирование интеграции
57. Выполнение интеграции
58. Планирование установки
39. Дистрибуция ПО
40. Установка ПО

Резюме 1033
Окончание табл. 33.10
Фаза разработки
Процессы жизненного цикла Действия
продукта
11. Функционирование системы
и техническая поддержка
12. Эксплуатация
(сопровождение)
13. Вывод из эксплуатации
Интегральный период 14. Аттестация и верификация
15. Управление конфигурацией
ПО
16. Разработка документации
17. Обучение
41. Адаптация ПО к операционной
среде
42. Функционирование системы
43. Предоставление технической
помощи и консультирование
44. Поддержание журнала запросов
45. Повторное применение
жизненного цикла ПО
46. Оповещение пользователей
47. Осуществление параллельных
операций (в случае
необходимости)
48. Вывод системы из эксплуатации
49. Составление плана аттестации
и верификации
50. Выполнение задач по
аттестации и верификации
51. Сбор и анализ метрических
данных
52. Составление плана тестирования
53. Разработка тестовых требований
54. Тестирование
55. Составление плана
менеджмента (управления) конфигурацией
56. Разработка идентификации
конфигурации
57. Осуществление управления
конфигурацией
58. Учет состояния
59. Составление плана документации
60. Составление документации
61. Подготовка и передача
документации
62. Составление учебной программы
63. Разработка учебных материалов
64. Проверка эффективности
учебной программы
65. Реализация учебной программы

1034 Глава 33
Оценивание затрат и масштабов проекта
При оценивании затрат и мероприятий для разработки проекта менеджер проекта
может использовать два важных, подготовленных заранее метода: традиционную
кривую точности оценки (см. рис. 33.10) и функциональную оценку.
Группы людей, источники
поддерживаемых данных
Примеры источников неопределенности ПО,
определяющего машинный интерфейс
Методы буферной обработки
внутренних структур данных 1 Понимание
Детализированный алгоритм программистом спецификации
выполнения графика,обработка ошибок
0.25х
Осуществимость
Планы
и технические
требования
Разработка
проекта продукта
Детализованная
разработка проекта
Разработка
и тестирование
Рис. 33.10. Точность оценивания
Желательно, чтобы оценки располагались на центральной линии. Плохо, если вы
недооценили проект, но не менее плохо, если вы его переоценили. С опытом оценки
становятся точнее, но для проектов новых типов значения оценок обычно
располагаются по краям кривых, а не на центральной линии.
Для выполнения функциональной оценки необходима простая программа
электронных таблиц и хороший метод определения технических требований.
Использование этого метода улучшит оценки менеджера проекта и уточнит информацию о
проекте. Благодаря данному методу не придется тратить время на приблизительную
оценку "линий эквивалента кода" проекта, и можно будет выполнять оценивание
только на стадии планирования. На рис. 33.11 показан пример вычисления с
помощью электронной таблицы набора функциональных точек.
Риск, связанный с проектом, и обеспечение качества
В этом разделе мы ничего не можем добавить о риске, кроме того, что уже сказано
в табл. 33.11, которую можно применять в качестве шаблона, определяющего
связанные с проектом риски. Этот шаблон заставляет менеджера проекта действительно
думать о рисках, что очень важно! Если у проекта более семи высоких уровней рисков,
обязательно надо составить план обеспечения качества ПО. План позволит снизить
риск за счет обеспечения качества, что в свою очередь повысит вероятность
успешного завершения проекта.

Резюме 1035
Измеряемый параметр
111
И
II
1
Число пользовательских входных данных 16 3 0 4 0 6
Число пользовательских выходных данных 4 4 3 5 0 7
Количество запросов пользователей 13 3 0 4 0 6
Количество файлов 7 7 0 10 0 15
Количество внутренних интерфейсов 0 5 0 7 0 10
48
31
39
49
О
167
Поправки на сложность проекта
О до 5
1 Требует ли система надежного резервирования и восстановления?
2 Требуется ли передача данных?
3 Существуют ли (есть ли в наличии)
функции распределенной обработки данных?
4 Является ли решающим фактором производительность системы?
5 Будет ли работать система в существующей используемой
(на полную мощность) операционной среде?
6 Требует ли система ввода данных в интерактивном
режиме (Необходим ли системе информационный
вход режима реального времени)?
7 Требует ли информационный вход в интерактивном
режиме того, чтобы входная транзакция была построено
на множественных экранах или операциях?
8 Обновляются ли основные файлы в в интерактивном режиме?
9 Являются ли сложными входные,
выходные данные, файлы или запросы?
10 Сложна ли внутренняя обработка данных?
11 Допускается ли многократное использование
кода разработанной программы?
12 Включены ли в разработку преобразование и инсталляция?
13 Разработана ли система для установки во многих организациях?
14 Разработано ли приложение для облегчения внесения изменений
и является ли оно простым для пользователя?
Итого:
5
5
5
2
3
0
1
2
3
4
5
/слоеные обозначения
Не оказывает
никакого влияния
Второстепенное влияние
Умеренное влияние
Среднее (влияние)
Существенное влияние
Сильное
Функциональная точка =
Итого баллов х [0.65+0.01 х s FJ
5 Количество функциональных точек= 177.02
5
з
41
Рис. 33.11. Функциональная оценка (метод оценки слоокности и трудоемкости крупных
программных проектов)

Таблица 33.11. Классификация рисков
Факторы и ка- Н —Свидетельство (признак) С — Свидетельство
тегории риска небольшого риска (признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
болыного риска (ВСН) тарии
Факторы, связанные с миссией и целями организации
Соответствие
проекта
Технологический
процесс
Непосредственно
поддерживает миссию и цели
организации
Отсутствие каких-либо
изменений или незначительные
изменения, которые не
влияют на процесс
Оказывает непрямое влияние
на одну или более целей
Возможны некоторые
изменения, которые окажут небольшое
влияние на техпроцесс,
некоторые аспекты могут оказывать
небольшое влияние на процесс
Факторы, связанные с управлением организации
Стабильность
организации
Стабильность
группы
разработчиков
Политика и
стандарты
Поддержка
менеджмента
Ожидаются небольшие
изменения или их полное отсутствие в
менеджменте или структуре
Группа разработчиков
отобрана; в группе не ожидается
никаких изменений
Ожидается реорганизация или
некоторые изменения в
менеджменте
Группа разработчиков
отобрана, но члены группы могут
меняться
Политика и стандарты отно- Политика и стандарты относи-
сительно разработки продукта тельно разработки продукта ус-
определены, и их тщательно танавливаются в ходе работы,
придерживаются но они слабо определены и их
плохо придерживаются
Сильная и активная поддержка Небольшая поддержка, но не во
для успешного выполнения всех действиях
проекта
Не поддерживает или не
связан с миссией и целями
организации
Существенные изменения
технологического процесса или
метода организации
Менеджмент и
организационная структура постоянно и
быстро меняются
Группа разработчиков не
подобрана; отсутствует решение
относительно членов группы
Полное отсутствие политики
или стандартов или они плохо
определены и их не
придерживаются
Слабая поддержка или полное
ее отсутствие

Продолжение табл. 33.11
Факторы и ка- Н —Свидетельство (признак) С — Свидетельство
тегорин риска небольшого риска (признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
большого риска (ВСН) тарии
Выполнение задач Контролируемое выполнение
задач, разумные требования
Участие высшего
руководства
Большая поддержка
Факторы, связанные с заказчиками
Участие
заказчиков
Опыт заказчиков
Принятие
заказчиком
Конечные пользователи
привлечены к сотрудничеству с
группой разработчиков и
предоставляют важные входные
данные
Конечные пользователи
имеют большой опыт участия в
аналогичных проектах, у них
много идей в отношении
удовлетворения собственных
потребностей
Конечные пользователи
принимают общие идеи и детали
системы; процесс разработан
так, что получает одобрение со
стороны конечных
пользователей
Наличие некоторых
требований к исполнению задач,
однако контроль требований под
вопросом
Поддержка от случая к случаю,
помощь оказывается, только
когда за ней обращаются
Конечные пользователи
играют второстепенную роль,
оказывая незначительное влияние
на систему
Конечные пользователи имеют
некоторый опыт участия в
аналогичных проектах; они не
дают полной информации о
своих потребностях
Конечные пользователи
принимают большинство идей и
деталей системы; процесс
разработан таким образом, чтобы
получить одобрение со
стороны конечных пользователей
Не установлены требования к
выполнению задач или
требования нельзя измерить
Нет ощутимой поддержки;
помощь по неразрешенным
вопросам отсутствует
Минимальное привлечение
заказчиков к разработке или
полное их неучастие;
конечные пользователи
предоставляют мало входных данных
Конечные пользователи не
имеют опыта работы в
аналогичных проектах; они не
имеют четкого представления о
своих потребностях
Конечные пользователи не
принимают идеи и детали
системы

Продолжение mafh. 33.11
Факторы и ка- Н—Свидетельство (признак) С — Свидетельство
тегории риска небольшого риска (признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
большого риска (ВСН) тарни
Необходимость
обучения
заказчиков
Обоснование
технического
решения перед
заказчиком
Соответствие
контракту
Рассмотрен вопрос обучения
конечных пользователей; на
данный момент идет обучение
или планируется его
проведение на месте
Техническое решение
полностью обосновано и доведено
до конечного пользователя
Контракт, заключен с
заказчиком на выгодных условиях;
хорошая взаимосвязь с группой
разработчиков
Рассмотрен вопрос обучения
конечных пользователей; в
настоящий момент обучение не
проводится или план обучения
не разрабатывается
Техническое решение
обосновано, однако, не решены
некоторые вопросы относительно
применения
Контракт имеет некоторые
открытые вопросы, которые
могут мешать работе
разработчиков
Преимущества Преимущества очевидны, они Некоторые вопросы относи-
проекта имеют конкретные показатели тельно преимуществ остаются
и эталоны сравнения открытыми или наблюдается
изменение эталона сравнения
или показателей
Факторы, связанные с финансированием/затратами
Размер проекта
Небольшой, несложный или
легко разбиваемый на
составные части
Средний, умеренно сложный;
разбиваемый на составные
части
Требования к обучению не
определены или являются
безадресными
Удовлетворительное
обоснование технического решения
отсутствует
Контракт имеет
обременительные требования к
документации или влечет за собой
дополнительную работу по
выполнению требований к
документации
Преимущества не определены,
не принят эталон сравнения,
отсутствует система
показателей
Крупный, очень сложный или
не разбиваемый на составные
части

Продолжение табл. 33.11
Факторы и ка- Н —Свидетельство (признак) С — Свидетельство
тегории риска небольшого риска (признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
болъшого риска (ВСН) тарии
Ограничения,
связанные с
аппаратным
обеспечением
Технология
Небольшие ограничения,
связанные с аппаратным
обеспечением, или полное их
отсутствие или одна (единая)
платформа
Имеется в наличии хорошо
разработана; опыт
собственной разработки
Многократно ис- Компоненты доступные и со-
пользуемые ком- вместимые с (данным) мето-
поненты дом
Поставляемы Компоненты доступны и при-
компоненты годны к применению в любой
момент
Объем
финансирования
Ограничения
бюджета
(финансирования)
Существенные бюджетные
ассигнования
Средства ассигнуются без
ограничений
Несколько ограничений,
связанных с аппаратным
обеспечением; несколько платформ
Имеется в наличии опыт
собственной разработки
Обещана поставка
компонентов; дата поставки не
гарантирована
Компоненты работают в
большинстве обстоятельств
Бюджетные ассигнования
неясны
Решены не все вопросы
финансирования
Существенные ограничения,
вызванные аппаратным
обеспечением; множество
платформ
Новая технология или новое
использование для разработки;
отсутствие опыта собственной
разработки
Компоненты разработаны, но
не доступны
Известно, что в
определенных случаях компоненты
отказывают в работе (выходят
из строя) или являются
несовместимыми с другими
деталями разрабатываемого
продукта
Бюджет очень
неопределенный
Распределение средств
отличается неопределенностью
или изменяется без
предупреждения

Продолжение табл. 33.11
Факторы и ка- Н —Свидетельство (признак) С — Свидетельство
тегории риска небольшого риска (признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
болыпого риска (ВСН) тарии
Экономическое
обоснование
Проект полностью обоснован,
доказана его экономическая
эффективность
Контроль стоимо- Система контроля хорошо ор-
сти (расходов) ганизована в целом
Факторы, связанные с рабочим графиком
Обязательство о
поставке
График
разработки
Стабильная дата поставки
(своевременная поставка)
Группа разработчиков считает,
что план является
приемлемым и может быть выполнен
Обоснованность вызывает
вопросы или экономическая
эффективность полностью не
установлена
Система хорошо организована,
но в отдельных областях
контроль не достаточен
Некоторая неопределенность в
дате поставки
Разработчики считают, что
график выполнения одной
стадии плана является слишком
жестким
Содержание проекта
Стабильность Ожидаются небольшие
изменения или их полное
отсутствие в уже утвержденных
требованиях
Технические условия
полностью определены и четко
изложены
технических
требований
Четкость и
полнота технических
условий
Ожидаются некоторые
изменения в уже утвержденных
требованиях
Некоторые технические
условия определены не полностью
или нечетко изложены
Обоснование отсутствует или
не показана экономическая
эффективность
Система отсутствует или
вообще не существует
Нестабильные даты поставки
Группа разработчиков считает,
что две или более стадии
разработки, выполнить, не
нарушая график, будет почти
невозможно
Срочные или несогласованные
изменения
Некоторые технические
условия находятся пока только
в голове потребителя

Продолжение табл. 33,11
Факторы и
категории риска
Н —Свидетельство (признак)
небольшого риска
С — Свидетельство
(признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
болыпого риска (ВСН) тарии
Способность
к тестированию
(контролю)
системы
Сложности
проектирования
(разработки)
Сложность
выполнения
Системная
зависимость
(Зависимость системы)
Стабильность
документации
Системные требования легко
контролировать; есть планы
контроля
Хорошо определенные
интерфейсы и дизайн
Алгоритмы и план приемлемы
для выполнения этой группой
разработчиков
Четко определена взаимосвязь
объема работ по
программному обеспечению с другими
частями системы
Документы будут готовы
вовремя и практически без
ошибок
Части системы сложно
контролировать или планы контроля
разработаны на минимальном
уровне
Непонятно, каким образом
разрабатывать дизайн или по
каким аспектам дизайна еще не
принято решение
Алгоритмы или план имеют
элементы, которые вызывают
определенные сложности для
выполнения данной группой
разработчиков
Некоторые элементы системы
понятны и спланированы;
другие находятся в стадии
осмысления
Некоторые документы будут
подготовлены с опозданием и
могут содержать
незначительные ошибки
Большую часть системы
сложно контролировать или планы
контроля отсутствуют вообще
Интерфейсы определены
плохо или не контролируются;
подвержены изменению
Алгоритмы или план имеют
элементы, которые вызывают
большие сложности при
выполнении (по мнению группы
разработчиков)
Отсутствует четкий план или
график взаимодействий всех
элементов системы
Очень мало шансов получить
документы вовремя, кроме
того, потребуется корректировка
и внесение изменений
Факторы, касающиеся выполнения проектных работ
Возможность
контроля
Модульная конструкция
позволяет легко планировать
проверку и выполнение
Модульная конструкция помога- Модульный план отсутствует
ет разрабатывать тестовые зада- или сложно планировать
теснил для тестирования элементов тирование

Продолжение таИл. 3 >. i I
Факторы и ка- Н —Свидетельство (признак) С — Свидетельство
тегории риска небольшого риска (признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
большого риска (ВСН) тарии
Ожидаемый
объем работ по
тестированию
Функциональные
свойства
Внешние
аппаратные средства
или программные
интерфейсы
Имеются надежные оценки
процесса тестирования, на
основании которых легко сделать
вывод о принятии системы
Обширный набор
функциональных свойств,
соответствует всем требованиям
заказчиков
Необходима лишь небольшая
интеграция (или интерфейсы)
или она вообще не требуется
Приближенная оценка
тестирования может стать "узким
местом" в процессе
Хорошие функциональные
свойства, удовлетворяет
большинству требований
заказчиков
Необходима некоторая
интеграция или интерфейсы
Факторы, связанные с управлением проектами
Метод
Коммуникации
(связь)
Опыт менеджера
проекта
Планирование (разработки)
продукта и процесса, а также
мониторинг на месте
Четко определены цели и
статус между группой
разработчиков и всеми остальными
подразделениями организации
Менеджер проекта имеет
большой опыт работы с
аналогичными проектами
Планирование и мониторинг
необходимо улучшить
Лишь иногда сообщается
некоторая информация
Менеджер проекта имеет
небольшой опыт работы с
данным типом проекта или имеет
опыт по другим видам проектов
Неудовлетворительная
оценка тестирования или полное
ее отсутствие; возможны
проблемы
Недостаточные
функциональные свойства, не соответствует
требованиям заказчиков
Требуются новые интерфейсы
Слабое планирование и
мониторинг или они вообще
отсутствуют
Группа разработчиков или
другие сотрудники (в статусе
разработчиков) редко
получают информацию
Менеджер проекта не имеет
никакого опыта работы
с должным видом проекта или
является новичком в
управлении проектами

Продолжение табл. 33.11
Факторы и ка- Н—Свидетельство (признак) С — Свидетельство
тегории риска небольшого риска (признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
большого риска (ВСН) тарии
Позиция
(отношение)
менеджера проекта
Полномочия/
поддержка
менеджера проекта
Факторы, связанные с процессом разработки
Менеджер проекта нацелен на
успешное выполнение проекта
Полная поддержка группы
разработчиков и менеджмента
Анализ
альтернатив
Метод
обеспечения качества
Процесс
принятия обязательств
Подготовка
документации
Использование
определенного
технологического
процесса
Анализ альтернатив проведен;
все рассмотренные допущения
поддаются проверке
Принята система обеспечения
качества, которая является
эффективной и которой
строго придерживаются
Изменения обязательств по
объему (работ), содержанию,
графику рассматриваются и
утверждаются всеми
участниками проекта
Корректная и есть в наличии
Процесс разработки является
приемлемым, принятым и
эффективным; его
придерживается группа разработчиков
Готов сделать все, что
необходимо
Поддержка большинства
членов группы с некоторыми
оговорками
Анализ альтернатив проведен,
но некоторые допущения
сомнительны или альтернативы
рассмотрены не полностью
Приняты процедуры
обеспечения качества, но их не
придерживаются или они являются
неэффективными
Изменения обязательств
согласовывается со всеми
участниками проекта
Очень мало заботится о судьбе
проекта
Отсутствие видимой
поддержки; руководитель присутствует
лишь номинально
Анализ не выполнен,
рассмотрены не все альтернативы или
допущения являются
ошибочными
Отсутствует система
обеспечения качества или
установленных процедур
Изменения обязательств
производятся без участия в их
рассмотрении группы
разработчиков
Есть в наличии, но наблюдается Отсутствует
некоторый дефицит
Процесс принят, но его не Не используется ни один фор-
придерживаются или он явля- мальный процесс
ется неэффективным

Продолжение табл. ВЗ. 11
.'лкторы и
категории риска
Н —Свидетельство (признак)
небольшого риска
С — Свидетельство
(признак) среднего риска
В—Свидетельство (признак) Рейтинг Коммеп-
большого риска (ВСН) тарии
Определение
дефектов на ранней
стадии
Контроль
изменений для
рабочих продуктов
Отслеживание
дефектов
Экспертная оценка программы
предусмотрена на всем
протяжении (жизненного цикла)
Формальный процесс контроля
изменений в целом, который
является эффективным и
которого строго придерживаются
Отслеживание дефектов
определено, выполняется
последовательно и эффективно
Факторы, связанные со средой разработки
Физические
объекты
Платформа
аппаратного
обеспечения
Требуют небольшой
модификации или вообще ее не
требуют
Стабильная, не ожидается
никаких изменений,
производительность приемлема
Доступность Инструментальные средства
(Работоспособное и документация имеются
ть) инструмен- в наличии, надежность под-
тальных средств тверждена
Управление
конфигурацией
Полностью контролируется
Экспертную оценку программы
применяют спорадически
(случайным образом)
Формальный процесс контроля
изменений в целом, который
является или неэффективным,
или его не придерживаются
Отслеживание дефектов,
определено, но выполняется не
постоянно
Требуется некоторая
модификация
Необходимы некоторые
изменения в ходе разработки, но
они являются
контролируемыми
Инструментальные средства
имеются в наличии,
надежность подтверждена,
необходима некоторая доработка (или
минимальная документация)
Имеется некоторый контроль
Группа разработчиков
надеется выявить все дефекты при
тестировании
Контроль изменений вообще
не используется
На месте отсутствует процесс,
позволяющий отслеживать
дефекты
Требуется большая
модификация или объекты не
существуют
Необходимо разрабатывать
аппаратную платформу наряду
с созданием ПО
Надежность не подтверждена,
необходимо существенное
усовершенствование;
документация отсутствует
Контроль отсутствует

Продолжение табл. 33.11
Факторы и ка- Н—Свидетельство (признак) С—Свидетельство
тегории риска небольшого риска (признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
болыпого риска (ВСН) тарии
Безопасность
Поддержка
поставщика
Все области должны
придерживаться указаний по
безопасному ведению работ; данные
дублируются; имеется система
на случай чрезвычайных
ситуаций; установленные
процедуры выполняются
Полная поддержка по
приемлемой цене и в необходимых
временных рамках
Приняты определенные меры
безопасности; производится
дублирование данных; имеется
план на случай чрезвычайных
ситуаций, но недостаточно
процедур или их не выполняют
Адекватная поддержка по
договорной цене, приемлемое
время реагирования
Отсутствуют меры
безопасности; недостаточное
дублирование данных; не
рассматривается вероятность чрезвычайных
ситуаций
Недостаточная поддержка или
ее отсутствие, или
неудовлетворительное время реагиро-
Факторы, связанные с персоналом
Пригодность (ра- Ожидается незначительная
ботоспособность) текучесть кадров; мало отвле-
персонала чений на "горящие" дела
Ожидается не очень большая
текучесть кадров; наблюдается
отвлечение на "горящие" дела
Дисциплинирова Высокий уровень дисциплины Дисциплина не всегда адекватна
нность персонала
Знание продукта Есть опыт разработки такого Есть некоторый опыт разра-
вида продукта ботки такого вида продукта
Опыт разработки Большой опыт работы с такого Некоторый опыт работы с ана-
ПО рода проектами логичными проектами
Высокая текучесть кадров,
группа разработчиков
большую часть рабочего времени
тратит на "горящие" дела
Дисциплина вообще
отсутствует
Отсутствует всякий опыт
разработки такого вида
продукта
Небольшой опыт работы с
аналогичными проектами или
опыт отсутствует вовсе

Окончание табл. " / /
Факторы и ка- Н —Свидетельство (признак) С — Свидетельство
тегорин риска небольшого риска (признак) среднего риска
В — Свидетельство (признак) Рейтинг Коммен-
большого риска (ВСН) тарии
Имеется план обучения:
обучение проводится
Обучение
(подготовка) группы
разработчиков
Настроение н от- Сильно переживают за успех
ношение команды проекта; настроены на сотруд-
разработчиков ничество
Производительно Сроки всех этапов выдержи-
сть группы разра- ваются, комплектующие по-
ботчиков ставляются вовремя,
производительность высокая
Факторы, связанные с сопровождением ПО
Сложность
Выполнение
изменений
По своей структуре пригодно
для ремонта (небольшая
сложность)
Группа разработчиков может
реагировать на нужды
потребителей
Поддержка пер- Квалифицированный персо-
соиала
Поддержка
поставщика
нал; имеется в достаточном
количестве
Полная поддержка по
приемлемой цене и в необходимых
временных рамках
Обучение в некоторых
областях невозможно или обучение
запланировано на будущее
Желание делать только то, что
необходимо
Сроки этапов выдерживаются,
наблюдаются задержки в
поставке комплектующих,
производительность приемлемая
В некотором смысле трудно
поддается техническому
обслуживанию (средняя сложность)
Группа разработчиков
реагирует с запозданием, допустимым
для потребителя
Нет квалифицированных
сотрудников в некоторых
областях
Адекватная поддержка по
договорной цене, приемлемое
время реагирования
План обучения отсутствует
или обучение проводят
неохотно
Небольшая
заинтересованность в проекте или полное ее
отсутствие; коллектив
разработчиков недружный
Производительность низкая,
сроки этапов не
выдерживаются, наблюдаются задержки в
поставке комплектующих
Очень сложное техническое
обслуживание (большая
сложность)
Группа разработчиков не
способна реагировать на нужды
потребителей
Отсутствие дисциплины или
квалификации
Недостаточная поддержка или
ее отсутствие, или
неудовлетворительное время
реагирования

Резюме 1047
Надежность
Во всех главах этого учебного пособия обсуждались факторы качества,
приведенные на рис. 33.12.
Особое внимание разработчики уделяют обеспечению надежности ПО, поскольку
именно эта характеристика наиболее важна для конечного пользователя.
Руководителю проекта следует быть максимально осведомленным относительно факторов,
определяющих качество продукта.
Корректность Эффективность Целостность Надежность Применимость
Рис. 33.12. Факторы, влияющие на качество ПО
Аттестация и верификация
Проверки (инспекции) ПО, анализы незавершенных работ и формальные
анализы (оценки) конечного этапа проекта (документ, содержащий результаты
критического анализа результатов конкретной фазы разработки проекта), несомненно,
повышают качество продукта и уменьшают затраты в ходе жизненного цикла продукта.
В соответствующей литературе довольно часто упоминается, что использование
метода последовательного жизненного цикла при разработке ПО позволяет выявить
дефекты на разных стадиях разработки проекта. Действительно, это очень важно,
поскольку дефекты, обнаруженные после внедрения продукта могут обойтись в 100
раз дороже по сравнению с дефектами, обнаруживаемыми на ранних этапах
жизненного цикла разработки продукта. К факторам, повышающим качество ПО, относят:
кумулятивный анализ, проектирование, доработку программы плюс усиленный
волновой эффект по всей готовой системе. Анализ на стадии выработки технических
требований, разработки проекта и программирования является наиболее
эффективным способом сокращения времени тестирования, поскольку дефекты устраняются
еще до него. Теперь мы знаем, что утверждения о высокой стоимости дефектов, не
выявленных на ранних стадиях жизненного цикла, совершенно справедливы. В ходе
своих исследований Уотс Хамфри (Watts Humphrey) обнаружил, что раннее
выявление дефектов не только минимизирует время и понесенные издержки, но и является
решающим для проекта. Среднее время корректировки ошибки, равное одному часу,
на стадии формулирования технических требований превращается в 3-6 часов на
стадии разработки проекта, 10 часов на стадии программирования превращаются

1048 Глава 33
в 15-40 часов на стадии тестирования приемлемости, в 30-70 часов— в период
приемосдаточных испытаний и в 40-1000 часов— в период функционирования продукта! Более
того, исследование показало, что средние затраты на выявление одного дефекта при
контроле (инспектировании) составляют 90-120 долларов и при тестировании— до 10 000
долларов. Компании, которые использовали системы раннего контроля, заявили о
десятикратном уменьшении количества дефектов, обнаруженных при тестировании и о
сокращении до 80% издержек на проведение тестирования, включая стоимость проверки.
Завершение проекта
Менеджер обязан так организовать работу над проектом, чтобы все его участники
получили опыт разработки ПО. Все проекты в организациях, относящихся к 1-му
уровню зрелости, завершаются пивом и пиццей. Участники празднуют окончание еще
одного проекта в их жизни. Они могут участвовать в проекте, но не извлечь из него
никаких формальных уроков. Корпорация получает больше, чем просто программу —
практические профессиональные знания ее сотрудников. Формальный процесс
окончания проекта завершается заполнением контрольного списка (см. табл. 33.12).
Таблица 33.12. Пример контрольного списка завершения проекта
Описание Есть ли необхо- Дата вы- Ответст- Выпол-
димость? Да/Нет полнения венный нено
Сообщить решение (о завершении
проекта)
Определить оставшийся объем работы
Поставить (упрощенную) версию ПО
Получить одобрение потребителей
Опубликовать документацию по
данной версии программы
Оценить работу персонала
Выполнить послепроектный анализ
разработки
Провести мероприятия по завершению
проекта
Уволить или назначить (перевести) на
другую должность некоторых членов
группы разработчиков
Отменить невыполненные рабочие
приказы
Проанализировать окончательный
аудит управления конфигурацией
Возвратить или передать другому лицу
материалы поставщика или потребителя
Возвратить взятое в аренду оборудование
Опубликовать окончательный отчет

Резюме 1049
Помимо обычного контрольного списка, существует опросный лист для полного
анализа разработки проекта (заполняемый после его выполнения). Этот документ по-
.яюляст собрать наиболее полные данные относительно необходимых
усовершенствований проекта. Ниже приводится пример подобного опросного листа. Используйте
его для улучшения последующего проекта.
Опросный лист анализа выполнения проекта для членов группы разработчиков
Дайте общую информацию о проекте, оставив> n^p^HdefbAuckiiue проекта для членов
группы разработчиков, чтобы они смогли определит^^Щ<ш^лл*м<^та\к'проекта
требует доработки. ^ ' £ > _ „ ЩЩЩ»|•''**' ^* '*'
Информация о проекте. " ,* «**-У?-1|йвя»5да2** ,~."? * ч^
. .. v
S
Информация о проекте,
Название проекта:
Номер контракта*
Название фирмы-потребителя:
Начало работы: ,
Окончание работы:
Тип проекта (выберите один из следующих:.
прикладное ПО, ПО для тестирования, моде ~3-
Краткое описание проекта: Si r| £~£&
Фамилия представителя организации:, ;.»1<£
Телефон: I & ■#£
Представитель заказчика- > '# j^Hg^-j,
Телефон: ' . ' »| ; ^s*it!
.^систрмное ПО,
'Yte
'lM$$mf информацию
\6го,утобы вы могли
" ' выполняемой
Статус проекта:
Соберите информацию о респонденте для,тоео,'^1т
определить группы людей, обладающих итогдвЫ^
на листе бумаги отдельно от ответов на ни,
ее при необходимости удалить Ооратйпи^вНйна^
работе (позиции) дважды, чтобы вы смрШ, Ш^'
с учетом разновидности втой работы (п*озиции4
Информация об интересующем респонде:
Имя: ".-Л . *'dP3
Телефош'Щ; < , V'J^
Группа разработчиков или организация:
Адрес: ' *'"'' ■
Электронная почта*
Добавьте или удалите позиции, присущие вашему Окруженищ'' >■»*"•?'■*''
Позиция (позиции), которые я играл в этом проекте (выберите из предложенного).
Менеджер проекта -, V»^A«. (^t; r ,
Руководитель группы разработчиков j1 ^ "^ \iv*"^ .*£'*'' -* ' '
Инженер (технолог) "*&•?.. i** t* f '•'
Обеспечение качества - '

10Г*0 F'lai-.aT?
! 'nj),iH uhih- конфигурацией *' * ' "f's* ;
" J'.i-jMfioTb.i документации для пользователей ' ,'■ , ,з
! '-it.,- гехннчееких условий (требований) .-.•-;' ''.с/-, ч
■ pi' ■<:« >.< пструктор -. г .., г;- .,;' V
. "М' :i тестирование (испытание) и ,;..
П . Тн.'ДИН
И ыт.пше системы <? " ?* "\>4.
лифтер компоновщик (ведущий компоновщик) ' ' ">f-\K .'w*
,4|>vnic (перечислите) + у $
Оцепи re (ранжируйте) следующие характеристики среды для рассматриваемого
проекта в диапазоне от 1 до 5, где 1- самый низкий ранг И 5 — самый высокий "Для
пенс :.'«ль:*уемого элемента поставьте X. - *V <■ ,r4li_^ -» £г
! ,-V•«' ."»* w ил •.> удалите элементы, которые соответствуют вашей Среде. „^, .'f i S*i»* «f~L "*"
I Hi, i пени;: технических требований заказчика (потребителя) {^^^^^^<Щ^уЬ-
I П- лержкд доступности ПО ' ' *• ^l^'T^liSss^
1 П< чдержка доступности аппаратного обеспечения ~ ^> ^V^M^^W^f^reilS'S&ar;
j По социальные возможности группы разработчиков к анализу^?»^^?1?адК^Й?Я*
| V ■ ген у ильные возможности группы разработчиков к проектирова1ВДЮ^£з|ку$кУ
ii« геьциальные возможности группы разработчиков к реализации (внедрению) 2?*|
г нциальные возможности группы разработчиков к тестированию (проверке)' 1<
!■ :•'собность группы разработчиков к анализу j ■* ^-t'? ^ Т
!i юсобностыруппы разработчиков к проектированию г
i iiocooiiocTb группы разработчиков к реализации (внедрению)
люсоСшогп, группы разработчиков к тестированию (проверке) ' >•• «т —л1
• 'it.iT работы группы разработчиков с областью проекта ' '1»>
• • 'I. .п работы группы разработчиков с процессом проекта t ,^ щ
; fin.гг работы группы разработчиков с методами проекта -, -V.***!*?// 7
• •.,гс работы группы разработчиков с языком или физической средой1'^,-*' •• <
Способность к своевременной внешней доставке компонентов ПО * ■*• +
Качество внешней доставки компонентов ПО <
Степень многократного использования (на всех этапах) ' ' Т
Использования инструментальных средств ПО - > " V , f „ j л££?*>> t 'Д>Л
Использование соответствующих методов .,<, j», V'£ ^т!
I Ь пользование анализа рисков . * ~>T*cf$ir~~?Wi\Jt$L
( обильность организационной среды -"> -*'*," >»*'V tW^Vfc^fer^&k
Пригодность технологии, используемой для """ "■"" "" "''
Управление конфигурацией
' меспечение качества
Для нижеприведенных факторов используйте диапазон баллов от 1, ДО 5,*гдеD ука-
.»ы пает на низкий уровень фактора, а 5 — на высокий уровень л ""

Резюме 1051
Сложность продукта ' "" .it
Изменяемость требований
Требования надежности
Требования эффективности ,
Требования удобств эксплуатации
Требования мобильности
Требования к качеству функционирования (производительности)
Требования безопасности , • л.'~;
Международные требования1 '".. gj
Сложность организации проекта ? г -...- ■^■•-"- - >,,:^.
Жесткость графика выполнения работ ' « .
Количество и типы техническиханализов £> %
Количество и типы анализов управления
Степень интеграции и тестирования -b.mtl •*' v," ' . . ?■;•" ;>
Приемочные испытания у потребителя -
Позиция (позиции), которую я занималвэтомпроекте (выберите из предложенного).
Инженер (технолог) ; *•■"•' ''',• *>'■ -'••'"•'-: ■'•«- ' ;'"' "'-\™>' -*\ """"' '
Обеспечение качества
Управление конфигурацией ';;'»..?.7"'''гм*'^-: •'"*■:■'■■■'■■'"•'' ■
Разработка документации'дл^^п'ЬлЪзоват^ёй)-
Анализ технических условий >* г.
Проектирование
Внедрение/тестирование5' «^
Интеграция г"
Испытание системы
Компоновка (конструкция)
Руководитель группы разработчикоэ
Менеджер проекта
Другие (перечислите):
Внимание! Здесь достаточно места, чтобы ответить как можно полнее.
Назовите ключевые вопросы данного проекта, которые, на ваш взгляд, были
решены верно.
Назовите ключевые вопросы данного проекта, которые, на ваш взгляд, были
решены неверно.
О каких необычных эффектах среды (которые могли оказать как позитивное, так и
негативное влияние;на проект) следует помнить при анализе истории разработки
данного проекта? ,
Что бы вы сделали иначе в ходе работы над этим проектом, если бы вы могли
начать все сначала?
Опишите одну проблему, которую вы могли бы решить лично для улучшения
качества продукта, который разрабатывался в ходе данного проекта.

1052 Глава 33
Навыки по управлению персоналом
23. Оценивание производительности— оценивание групп разработчиков с целью
увеличения производительности.
24. Вопросы интеллектуальной собственности— понимание степени влияния
решающих вопросов.
25. Организация эффективных встреч— планирование и проведение
плодотворных совещаний.
26. Взаимодействие и общение — обсуждение вопросов с разработчиками,
менеджерами более высокого уровня и другими подразделениями.
27. Лидерство — подготовка групп, участвующих в проекте, для получения
оптимальных результатов.
28. Управление изменениями— наличие эффективных мероприятий по
проведению (кадровых) изменений.
29. Успешных ведение переговоров — успешное разрешение конфликтов и ведение
переговоров.
30. Планирование карьерного роста — обеспечение возможности карьерного роста.
31. Эффективное представление— использование ораторского и писательского
мастерства.
32. 11абор персонала — проведение собеседований с кандидатами и прием на работу.
33. Отбор команды — подбор классных специалистов.
34. Создание команды— формирование, руководство и поддержка эффективной
группы разработчиков
Эти последние 12 компетенций касаются деятельности менеджера проекта, группы
p.i.ifмботчнков продукта и управления главным ресурсом — персоналом. При разработке
! И > ничего невозможно сделать без участия людей на всех этапах: анализа, разработки
проекта и выполнения. Эта деятельность традиционно называется управлением
персоналом, по настоящая деятельность, которая приводит менеджера проекта к успеху— это
скорее не управление, а руководство людьми. Ниже приведены определенные методы и
инструменты, которые относятся к умению управлять персоналом.
Отбор команды разработчиков
Плодотворная и успешная работа команды разработчиков невозможна без
взаимопонимания, хорошего психологического климата, что, в свою очередь,
невозможно без учета индивидуальных особенностей членов команды. В таблице 88.18
приведены типы личностей по Майерсу-Бриггсу (Myers-Briggs). Она применима для всех
видок проектов. Также она позволяет членам команды разработчиков представить
каждого из них как уникальную личность, понять мотивы его поведения и тем самым
облегчить будущее сотрудничество. Эта таблица стоит того, чтобы ее использовать!
Оценивание длительности и стоимости проекта
Оценивание длительности и стоимости проекта, на первый взгляд, лучше
проследить через компетенции, осуществленные для реализации проекта. Однако
длительность и стоимость в целом зависят от людей, то есть на 100% они зависят от таланта

Резюме 1053
разработчиков. У автора этой книги на практике был случай, когда отличные
разработчики программ имели производительность, в 25 раз превышающую
производительность разработчиков среднего уровня. Это именно те ресурсы, которые могут
быть использованы менеджерами проектов для разработки продукта, причем это не
мифические нормированные цифры. На рис. 33.13 показаны этапы оценивания
длительности и стоимости проекта.
Таблица 33.13. Типы личности по Майерсу-Бригсу
(Myers-Briggs Type Indicator, MBTI)
Типы личности MBTI Характеристики
Источник и направление энергии
Интроверт (И) Интроверт: сосредоточен на своем внутреннем мире (при контакте
с внешним миром происходит утечка внутренней энергии)
Экстраверт (Э) Экстраверт: направленность на внешний мир и деятельность в нем
(при контакте с внешним миром черпает из него энергию)
Предпочитаемый метод получения информации
Чувства (Ч) Ч: предпочитает эмпирические сенсорные данные
Интуиция (И) И: предпочитает выразительные образы и абстракции
Способ обработки информации
Мышление (М) М: принимает решения в соответствии со своей беспристрастной
(обезличенной) логикой
Эмоции (Ч) Ч: принимает решение в соответствии со своими персональными
ценностями (воззрениями)
Способ существования, исходя из обработанной информации
Оценивание (С) С: организует все свои действия и жизненные события строго в
соответствии со своими планами
Ощущение (В) В: склонен к импровизации и поиску различных альтернатив
Распределение обязанностей
Одним из наиболее полезных инструментальных средств для определения объема
финансирования проекта является матрица распределения обязанностей (responsibility
assignment matrix— RAM, MPO). Ее также иногда называют матрицей
ответственности, матрицей персонала, а также диаграммой линейной ответственности (linear
responsibility chart, LRC). Матрица МРО четко определяет личную ответственность
отдельных сотрудников и их роль в разработке продукта. Матрицу можно положить
в основу рабочего листа, предназначенного для контроля работ, связанных с
проектом. На рис. 33.14 показан пример подобной матрицы.
Как и в случае с другими инструментальными средствами, эта матрица является
достаточно простой и позволяет получить информацию, которая является
инверсионной по отношению к затраченным усилиям, поэтому ее с успехом используют
менеджеры проектов.

1054 Глава 33
Рис. 33.13. Этапы оценивания проекта
Выработка технических требований
к программному продукту
Выработка технических требований к программному продукту является еще одной
компетенцией, которая на 100% зависит от людей. После сбора требований на основе
шпервью, сессий совместной разработки приложений (JAD sessions) и проверки
существующих систем, их необходимо записать. Важность четкости изложения
требований на згой стадии вы оцените позже. В настоящее время отсутствуют строгие
нормы, определяющие процесс выработки технических требований, например,
такие, как спецификации требований, но приведенные ниже указания помогут вам в
преобразовании одних требований в другие.
■ Определите понятие технических требований в контексте вашего проекта,
поскольку часто они по-разному понимаются разными людьми. Технические требования —
это заявление о функциональности и качестве, которыми должна обладать
система, по это еще не "спецификация". Технические требования могут быть включены

Резюме 1055
в высокоуровневые функциональные, поведенческие и информационные модели
(графики потоков данных, модели взаимосвязей элементов, объектные модели,
контрольные модели), но в них не детализированы модели пользовательского
интерфейса, которые будут использованы разработчиками.
Матрица
распределения
обязанностей
Содержание
1 1 1
Исполнитель
Роль
Рис. 33.14. Матрица распределения ответственности
■ Помните, что существуют разные виды технических требований:
функциональные, нефункциональные, требования качества, исполнения, экономические
требования, пользовательские, требования ограничений и т. п.
■ Учтите международные вопросы.
■ Определите функции, критичные по времени.
■ Рассмотрите вопросы безопасности и защиты.
■ Напишите технические требования, на основании которых можно было бы
составить спецификацию.
■ Проследите появление технических требований из системных требований,
случаев использования или документации, полученной в ходе сессий-семинаров.
■ Создайте схему идентификации технических требований (для контроля на всем
протяжении жизненного цикла).
■ Если на данный момент получены сообщения об ошибках, то зафиксируйте их.
■ Общайтесь, общайтесь и еще раз общайтесь. Часто складывается ситуация, когда
ответ даже и не предвидится, а груз выполнения календарного плана давит
неимоверно, разработчик пытается заполнить пробел, принимая решение при
отсутствии адекватной информации. Важно учитывать все категории пользователей.
Сотрудники, выступающие в защиту отдельных проектов, могут сами представить
необходимые категории пользователей, собрав у них исходные данные.
■ Как можно раньше сформулируйте максимально четко и неоднозначно
технические требования.

1056 Глава 33
■ Определите необходимость в производных и условных технических требованиях.
Требование может быть производным (т.е. быть необходимым или
предшествующим условием для другого требования) или условным (т.е. иметь другие
производные технические требования в качестве необходимых или предшествующих
условии). Функция, которую нельзя выполнить до тех пор, пока не будет установлена
определенная версия операционной системы, является примером условного
требования. Обратная совместимость с другими компонентами системы также
является условным требованием.
и При написании технических требований избегайте использования
субъективных и допускающих двоякое толкование слов. Такие слова, как: всегда, иногда,
чисто, минимизировать, максимизировать, оптимизировать, быстрый, дружественный
по отношению к пользователю, легкий, простой, нормальный, обычный, большой,
интуитивный, надежный, современный, улучшенный, эффективный, поддерживать и
гибкий являются "особенно опасными". Большинство подобных формулировок не
iii >ддаются проверке.
■ Напишите контрольные примеры напротив функциональных технических
требований.
* Рассмотрите разрабатываемые прототипы.
■ Cot тавьте словарь данных.
и Постарайтесь, чтобы предложения и параграфы технических требований были
лаконичными, но одновременно достаточно подробными (один контрольный
пример стоит функциональности).
* 11 листайте в технических требованиях многословности.
»тп рекомендации, наряду с анализами заинтересованных сторон, обеспечат над-
н ж.пцую о< цову для выработки требований к программным проектам.
Метрические показатели, относящиеся к ПО
Это еще одна компетенция, зависящая от персонала. Люди определяют, собирают
п анализируют метрические показатели. Широко используемым и наиболее
надежным метолом определения показателей, который можно рекомендовать для контроля
проекта и принятия решений, является парадигма из трех слов, которую придумал
доктор Виктор Бейзили (Victor Basili): цель, вопрос, метрика (goal, question, metric —
(iOM пли I (BM). Метод ЦВМ требует, чтобы до начала сбора данных была
установлена цель выполнения этой операции. Упрощенные сеансы "мозговые атаки" (метод
поиска творчески идей) служат для достижения консенсуса среди членов группы
разработчиков по конкретным целям проекта. Конечно же, цели могут быть
установлены высшим руководством или заинтересованными лицами в пределах всей
организации. Доктор Бейзили способствовал созданию лаборатории программного
инжиниринга (Software Engineering Laboratory, SEL) и консорциума, в состав которого входит
отдел вычислительной техники (Computer Science Department) университета штата
Мэриленд, филиал по выполнению программного инжиниринга НАСА (отдел
динамики полета Годдарда) (Software Engineering Branch of NASA Goddard's Flight
Dynamics)) и отдел по управлению программным инжинирингом корпорации Computer
Siu'vci's (Division Software Engineering Operation of Computer Sciences Corporation).
В результате работы лаборатории программного инжиниринга (SEL) был разработан

Резюме 1057
процесс, состоящий из семи этапов для систематических прикладных измерений ПО.
На рис. 33.15 показаны эти этапы: разработка набора целей; формирование набора
вопросов, которые характеризуют цели; определение показателей, необходимых для
получения ответа на эти вопросы; разработка механизмов сбора и анализа данных;
сбор, проверка достоверности и анализ данных; принятие корректирующих
действий; анализ в манере постпрограммы (программы контроля вычислений); прямая
связь и обратная связь с заинтересованными сторонами. На рис. 33.15 приводится
графическое представление метода ЦВМ (GQM).
Рис. 33.15. Метод ЦВМ (GQM) Бейзили, состоящий из семи этапов
Правовые вопросы
Авторы практического руководства не являются юристами, они даже не имеют
правовой подготовки. Юридические вопросы, описанные в главе и
проанализированные авторами этой книги, встречаются в большинстве проектов с начала 70-х
годов прошлого века. Единственный способ управления правовым риском проекта,
заключается в том, чтобы пригласить в группу разработчиков опытного юриста,
который будет заниматься оформлением контрактов, вопросами интеллектуальной
собственности и судебными спорами. Это именно та область, в которой менеджеру
проекта требуется помощь экспертов. Таблица 33.14 является расширенным
вариантом матрицы по определению рисков для проектов, где существует большой риск,
связанный с правовыми вопросами.

Таблица 33.14. Расширенная правовая классификация факторов риска
Факторы риска Н — Признак небольшого С — Признак среднего риска В — Признак большого Рейтинг Коммен-
и категории риска риска (ВСН) тарии
Факторы, связанные
с миссией и целями
Факторы, связанные
с менеджментом
организации
Факторы, связанные
с потребителями
Факторы, связанные
с затратами и
финансированием
Факторы, связанные
с графиком
Содержание проекта
Факторы, связанные
с выполнением
Факторы, связанные
с менеджментом
проекта
Факторы, связанные
с процессом
разработки
Факторы,
связанные со средой
разработки

Продолжение табл. 33.14
Факторы риска
в категории
Н — Признак небольшого С — Признак среднего риска В — Признак большого
риска риска
Рейтинг Коммен-
(ВСН) тарии
Факторы, связанные
с персоналом
Факторы, связанные
с эксплуатацией
Правовые факторы
Реклама и
потребитель
Альтернативное
решение спора
Коммуникации
Контракты
Недееспособность
Не является
потребительским продуктом
Стандартные условия
арбитража, внесенные в
контракт
Электронные коммуникации
не используются при
разработке проекта
Единый коммерческий
кодекс (UCC или ЕКК) для
любых влияний на продукт
и проект. Никакие другие
контракты не нужны
Все (производственные
и др.) объекты доступны
для сотрудников-инвалидов
Простой профаммный
продукт, который не требует
гарантии
Нестандартные условия,
внесенные в контракт
Электронные коммуникации
используются только при
разработке продукта
Необходим ЕКК и контракты
личного найма
Сложный профаммный
продукт, на который необходима
гарантия
Условия арбитража не
включены в контракт
Электронные коммуникации
являются интегральной
частью разрабатываемого
продукта
Проект базируется в основном
на разработке контракта и ин-
тефации коммерческих
компонентов
Объекты доступны для со- В наличии нет объектов, дос-
трудников-инвалидов отдельно тупных для инвалидов, кото-
от фуппы разработчиков рые выполняли бы
минимальные требования законов об
инвалидах

Окончание табл. 33.14
Факторы риска
н категории
Н — Признак небольшого С — Признак среднего риска
риска
В — Признак большого
риска
Рейтинг Коммен-
(ВСН) тарии
Занятость
Интеллектуальная
собственность
Регулирование
применения Internet

Конфиденциальность
Гражданское
правонарушение (деликт)
Наличие трудовых
соглашений (контрактов по найму),
защищающих
интеллектуальную собственность
Стандартный процесс для
проверки интеллектуальной
собственности определения
соответствующих точек
в пределах жизненного
цикла проекта
При разработке проекта
доступ в Internet запрещен
При разработке продукта не
обрабатывается никакая
личная информация
Разрабатываемое ПО не
контролирует физические
приборы (устройства)
Все разработчики являются
персоналом, работающим по
контракту
Интеллектуальная
собственность рассматривается только
на начальной и конечной
стадиях проектов
Доступ в Internet
осуществляется только для разработки
продукта
Персональная информация
используется только для
минимальной идентификации
пользователя
Разрабатываемое ПО
контролирует физические приборы,
которые не могут нанести
человеку вред
Контракты личного найма не
используются
Нет механизма определения
(защиты) интеллектуальной
собственности
Доступ в Internet является
интегральной частью
разрабатываемого продукта
Имеется система по
управлению персональными данными
или компоненты, которые
собирают и хранят
персональные данные
ПО контролирует функции
аппаратного обеспечения,
которые в случае сбоя могут
представлять опасность для
человеческой жизни

Резюме 1061
Практическое занятие
В прошлом месяце ситуация в полупроводниковой промышленности изменилась
к лучшему, и ваше назначение в Европейский центр по разработке ПО было утвер
ждено. Проект ARRS подходил к своему завершению, уже намечался выпуск первой
полной версии программы, а вслед за ним и окончание работы BSD по
программированию. Мистера Лу повысили в должности, а доктор Чжоу стал директором по
вопросам приобретения нового ПО для министерства CRM. Мисс Пайтель, новый
исполнительный директор корпорации AsiaPac по маркетингу, протестовала против
вашего нового назначения, но ваша организация убедила ее, что это назначение крайне
важно для развертывания следующего поколения ПО мобильной телефонной
инфраструктуры в Европе. Поскольку создание инфраструктуры должно была приносить
около 1,2 млрд. долларов в год, просьба мисс Пайтель не была удовлетворена. До
перевода на новую должность вас попросили представить план передачи бывших
обязанностей вашему преемнику. Преемник еще не подобран, и вы должны включить в
этот план свое предложение по его кандидатуре. Чем быстрее будет готов план, тем
скорее вы сможете переехать на новое место работы в Тулузу. Компания не
располагает шаблоном плана и рассчитывает, что вы разработаете шаблон, который будет
включен в состав интеллектуальной собственности корпорации. Рассматривайте эту
ситуацию как минипроект и подготовьте план передачи должностных обязанностей.

Организации,
поддерлсивающие
разработку ПО
Приложение в формате PDF находится на прилагаемом компакт-диске.

Реальные проекты
Приложение в формате PDF находится на прилагаемом компакт-диске.

Создание бизнес-плана
Приложение в формате PDF находится на прилагаемом компакт-диске.

Основы системного
инлсиниринга
Приложение в формате PDF находится на прилагаемом компакт-диске.

Дистанционное
управление проектами
Приложение в формате PDF находится на прилагаемом компакт-диске.

Шаблоны
компонентов проекта
Приложение в формате PDF находится на прилагаемом компакт-диске.

Организация
совместной разработки
приложений
Приложение в формате PDF находится на прилагаемом компакт-диске.

Словарь терминов
В словаре приводится описание набора понятий, имеющих отношение к
управлению персоналом, программному инжинирингу и управлению качеством. Если вы
нуждаетесь в получении более подробных сведений, обратитесь к дополнительным
словарям, указанным в перечне литературы.
Словари терминов по управлению качеством
www. lstnclass. com/quality_glossary.htm. Более чем 250 общих акронимов
и терминов, связанных с вопросами управления качеством вместе с "интуитивными
объяснениями".
www.asg.org/info/glossary/. Словарь терминов Американского общества
качества.
Словари терминов по программному
инжинирингу
Freedman Alan. 9th Computer Glossary: The Complete Illustrated Dictionary (в комплект
входит CD-ROM). NY: American Management Association, 2000.
IEEE Standard 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
Здесь идентифицируются термины, используемые в области программного
инжиниринга. Приводятся стандартные определения терминов.
Nader Jonar С. Prentice Hall's Illustrated Dictionary of Computing (в комплект входит CD-
ROM). Upper Saddle River, NJ: Prentice Hall, 1998.
www.geocities.com/ikind_babel/babel/babel.htm. "Babel: A Glossary of
Computer-Oriented Abbreviations and Acronyms".
Словари терминов по управлению проектами
www.pmforum.org/library/glossary/index.htm. "Wideman Comparative Glossary
of Project Management Terms v2.0".
www.pmi.org/publictn/download/2000welcome.htm. The Project Management
Institute. Inc., "A Guide to the Project Management Body of Knowledge".

1070 Словарь терминов
Словарь терминов, используемых в книге
Abstraction (Абстракция). A) Уровень технической детализации некоторого
представления ПО. B). Связанная модель данных или алгоритмическая процедура.
Activity (Действие). Элемент работы, выполняемой в рамках осуществления
проекта. Обычно действию соответствуют ожидаемая длительность выполнения,
ожидаемые затраты и прогнозируемые потребности в ресурсах. Действия могут
подразделяться на задачи.
Adaptive maintenance (Адаптивное сопровождение). Действие, связанное с
изменением приложения таким образом, чтобы адаптировать его в соответствии с
изменившимися условиями окружающей среды.
Analysis (Анализ). Набор действий, предпринимаемых с целью понимания и
моделирования потребностей и ограничений, связанных с пользователем.
Analysis methods (Методы анализа). Записи и эвристика, применяемые при
создании моделей, призванных соответствовать потребностям пользователя и
имеющимся ограничениям.
Architectural design (Архитектурный дизайн). Действие, в рамках которого
предпринимаются попытки внедрения "поэтажного плана" при разработке ПО.
Baseline (Базовая линия). Элемент конфигурации (здесь конфигурация выступает
в качестве предмета или набора предметов), который подвергается формальному
обзору и согласованию. Затем он служит в качестве базиса для дальнейшей
разработки и может изменяться только в результате выполнения процедур контроля
формальных изменений (перед этим изменения могут выполняться быстро и в
неформальном режиме).
behavioral modeling (Моделирование поведения). Представление режима
поведи ь . (состояния) приложения и событий, которые вызывают переходы между
различными состояниями.
Beta testing (Бета-тестирование). Тестирование, производимое конечным
пользователем.
Black-box testing (Тестирование методом "черного ящика"). Тестирование, в ходе
осуществления которого не выделяются внутренние детали программы, а делается
акцепт на применении внешних требований.
Business risks (Бизнес-риски). Набор потенциальных проблем бизнеса или
происшествий, которые могут привести к срыву проекта.
CASE. Система быстрой разработки программ.
Cause-effect graphing (Создание графиков анализа причин н следствий).
Тестирование методом "черного ящика".
Change Control (Контроль изменений). Объединяет процедуры, выполняемые
человеком и автоматизированными инструментами. Процедура контроля изменений
может включать следующие сущности и действия: запрос изменений, оценка, отчет об
изменениях, авторизация контроля изменений, заказ на изменение процесса
инжиниринга, проверка, изменения, обзор, входная проверка (контроль доступа и
синхронизации), базовая линия, тестирование, поддержка изменений с целью их
включения в следующую версию, перестроение версии, обзор изменений, включение всех
изменений, распространение новой версии.
Change Control Board (CCB, руководство контролем изменений). Лицо(а),
ответственное за принятие решений по поводу выполняемых изменений.

Словарь терминов 1071
Change report (Отчет об изменениях). Указываются подробности работы,
выполняемой в рамках выполнения изменений.
Change request (Запрос изменений). Указываются подробности типа
запрашиваемых изменений.
Classes (Классы). Базовая конструкция объектно-ориентированных методов,
которая разделяет на категории элементы сформулированной проблемы.
Classic life cycle (Классический жизненный цикл). Линейный последовательный
подход к моделированию процессов.
Coding (Кодирование). Разработка исходного кода программы.
Coefficient (Коэффициент). Символ или число, определяющий умножение
переменной или неопределенного числа с применением алгебраической записи,
например, в выражении 4х коэффициентом будет число 4, а в выражении х(а + Ь) в роли
коэффициента выступает х, любой из множителей в произведении, рассматриваемый
в связи с указанным множителем, особенно это относится к постоянному множителю,
который отличается от переменной.
Complexity (Сложность). Количественное измерение сложности программы.
Component reuse (Повторное использование компонента). Способность к
повторному применению части модели, исходного кода, тестового случая или другого
подобного элемента.
Configuration (Конфигурация). Набор программ, документов и данных, которые
должны контролироваться при выполнении изменений.
Configuration audit (Аудит конфигурации). Верификация всех требуемых
производимых элементов конфигурации, причем действующая версия отвечает указанным
требованиям, техническая документация полностью и точно описывает элементы
конфигурации, а все запросы изменений выполняются. Могут потребоваться ответы
на такие вопросы, как: "Производились ли обзоры происшедших изменений?
Выполняется ли программный процесс? Соблюдаются ли соглашения по наименованию?"
Configuration control (Контроль конфигурации). Оценивание, координация,
утверждение (или отрицание), а также внедрение одобренных изменений в
конфигурацию элемента.
Configuration item (Элемент конфигурации). Выделение
программного/аппаратного обеспечения либо любой их отдельных частей, которые соответствуют функции
конечного применения и предназначены для менеджмента конфигурации. Элементы
конфигурации широко применяются при оценке сложности, размера и типа ПО.
Configuration status accounting (Учет состояния конфигурации). Фиксация и
отчетность относительно внедрения изменений в конфигурацию. При этом получают
ответы на классические вопросы "Что?", "Кто?" и "Когда?".
Configuration status reporting (CSR, отчет о состоянии конфигурации). Действие,
призванное помочь разработчикам ПО понять суть и причины выполненных изменений.
Corrective maintenance (Корректирующее сопровождение). Поиск и устранение
дефектов, о наличии которых было сообщено пользователями.
Correctness (Корректность). Термин, обозначающий соответствие программы
имеющимся спецификациям и требованиям пользователя.
Curve fitting (Аппроксимация кривой). Задача аппроксимации кривой
формулируется следующим образом: дается общее уравнение кривой и набор точек, через
которые проходит данная кривая и определяется точное уравнение кривой в этом
случае. Обратите внимание на следующий пример:

1072 Словарь терминов
общее уравнение: у = Ах + В
набор точек: A,9), B,12), E,21)
Кривая, проходящая через эти точки, имеет вид:
у = Зх + 6
В общем случае невозможно привести точное решение для задач из реального
мира, поскольку при определении координат точек практически всегда бывают
ошибки. Поэтому при аппроксимации кривой предпринимаются попытки достичь
компромисса между ошибками в определении координат точек и
аппроксимированной кривой.
Учитывая ранее приведенное точное определение проблемы оптимизации, задача
оптимизации аппроксимации кривой приобретает следующий вид:
аппроксимация кривой;
целевая функция — минимизация ошибок в координатах точек и кривой с
помощью вычисляемых констант;
неизвестные параметры — неизвестная константа в общем уравнении;
ограничения — отсутствуют (хотя иногда константы ограничиваются с помощью
указанного диапазона).
Для вычисления ошибки между заданными точками и нарисованной кривой может
применяться множество методов, но наиболее распространенным (и единственным
применяемым здесь) методом является метод наименьших квадратов. При
использовании этого метода ошибка определяется в виде суммы квадратов разницы между
у-координатой и значением кривой в заданной х-координате. Рассмотрим ранее
обсуждаемый пример:
общее уравнение: у = Ах + В
набор точек: A,9), B,12), E,21)
текущие значения неизвестных параметров: А = 1, В = 10
В каждой точке значение разницы в у-координатах будет иметь следующий вид:
A,9) разница = 9-11 =-2
B,12) разница = 12-14 = -2
E,21) разница = 21-15 = 6
Если возвести в квадрат каждый их этих результатов и сложить их между собой,
получим значение 44. Это значение соответствует величине общей ошибки,
соответствующей 44 попыткам аппроксимировать набор данных (х и у являются числовыми
векторами) с помощью прямой линии, полиномиальной или другой функции
аргумента х. В данном случае рассматривается аппроксимация с помощью прямой линии
и игнорируется тот факт, что существуют лучшие аппроксимации.
При выполнении стандартной линейной аппроксимации по методу наименьших
квадратов в нашем распоряжении имеется набор точек данных (х,у), которые мы
хотим аппроксимировать моделью у = тх + Ь путем настройки параметров т и Ь и
вычисления значений у по формуле таким образом, чтобы они в максимальной степени
приближались к фактическим значениям у из набора данных. При полиномиальной
аппроксимации в модели применяются уравнения у = ахЗ + Ьх2 + сх + d. При
многомерной линейной аппроксимации точки данных записываются в виде (xl,x2,x3,y), а
модель в виде у = ах, + bx2 + cx} + d.

Словарь терминов 1073
В модельной формуле переменные х, и х2 называются независимыми, а у — зависимой
переменной. Такие переменные, как то, а и Ь, называются параметрами модели.
Customer (Заказчик). Лицо или группа лиц, которые заказали разработку
программного продукта и рассчитываются по завершению работ.
Data design (Проектирование данных). Действия, в результате выполнения
которых модель данных, разработанная в ходе осуществления анализа, преобразуется
во внедряемые структуры данных.
Data dictionary (Словарь данных). База данных, содержащая определения всех
элементов данных, присвоенных на этапе выполнения анализа; также см. requirements
dictionary.
Data flow diagram (DFD, диаграмма потока данных). Запись при осуществлении
моделирования, которая представляет декомпозицию функций в системе.
Data modeling (Моделирование данных). Метод анализа, применяемый для
моделирования данных и взаимосвязей между ними.
Data objects (Объекты данных). Вход или выход, видимый для пользователя.
Debugging (Отладка). Действия, выполняемые в процессе поиска и коррекции
ошибок/дефектов; недостаточное соответствие требованиям, выявленное после
передачи ПО заказчику.
Defect (Дефект). Проблема, обнаруженная на стадии или в процессе, которые
следуют после ее появления.
Design (Разработка проекта). Действие, в ходе выполнения которого модель
требований транслируется в более детализованную модель, которая определяет
внедрение ПО.
Design specification (Спецификация разработки проекта). Документ,
описывающий процесс разработки проекта.
Design walkthrough (Обход разработки проекта). Формальный технический
обзор разработки проекта.
Detail design (Разработка деталей). Действие в рамках разработки проекта, в ходе
осуществления которого происходит концентрация на создании алгоритма.
Documents (Документы). Поставляемые продукты, представляющие собой часть
процесса программного инжиниринга.
Efficiency (Эффективность). Объем вычислительных ресурсов и кода,
необходимых для выполнения функции.
Effort (Трудозатраты). Произведение "работа-время" (человеко-дни), связанное
с проектом.
Enhancement (Расширение). Расширение функциональных требований либо
требований к выполнению.
Equivalence partitioning (Разбиение эквивалентности). Тестирование методом
"черного ящика".
Errors (Ошибки). Несоответствие условиям, обнаруженное после поставки ПО
заказчику.
Estimation (Оценка). Действие в рамках планирования проекта, касающееся
трудозатрат проекта, а также затрат при производстве ПО, либо проблемы,
обнаруженной на текущей фазе или в процессе.
Exponent (Экспонента). Число или символ, например, 3 в выражении (х + у) ,
находящееся справа и выше другого числа, символа или выражения, означая тем самым
операцию возведения в степень. В этом смысле экспоненту часто называют степенью.

1074 Словарь терминов
Fail-Safe (Безопасность при сбоях). Свойство, позволяющее избежать каких-либо
повреждений в результате сбоя.
Fault-Tolerant (Устойчивость к сбоям). Свойство, позволяющее восстанавливать
систему при возникновении некоторого рода ошибок и продолжать
функционирование в прежнем виде.
Flexibility (Гибкость). Показатель трудозатрат, необходимых для изменения
функционирующей программы.
Formal technical reviews (Формальные технические обзоры).
Структурированные совещания, проводимые отделом программного инжиниринга с целью поиска
ошибок в некоторых поставляемых продуктах или рабочих продуктах.
Function points (Функциональные точки). Средства измерения, применяемые
при оценке приложения.
Functional decomposition (Функциональная декомпозиция). Методика,
применяемая при планировании, анализе и разработке проекта; создается функциональная
иерархия для ПО.
Hawthorne effect (Эффект Хауторна). Пользователи метрических программ
должны быть осведомлены о возможности появления некорректных заключений в
силу того, что сами измерения выполняются различным образом. В ходе изучения
этой проблемы выяснилось, что рабочие, находящиеся под контролем, уделяют
больше внимания работе, формируют связи с командой и в целом работают лучше.
Однако при выполнении измерений наблюдается простое смещение данных.
Исследования Хауфторна (или просто эксперименты) производились между 1927
и 1932 годами на заводе Western Electric Hawthorne Works в городе Чикаго. Здесь
профессор Эльтон Майо (Elton Mayo) из Гарвардской школы бизнеса исследовал
условия, необходимые для выполнения работы и достижения приемлемого уровня
производительности.
Этим исследованиям предшествовали предварительные эксперименты на
предприятии с 1924 по 1927 годы, когда исследовалось влияние освещенности на
производительность. В ходе этих экспериментов не было установлено однозначной
зависимости между производительностью и степенью освещенности, однако, исследователи
удивлялись, каким образом имеющиеся изменения способны повлиять на результат.
В задачи Майо входило обнаружение связи эффекта усталости и монотонности
с продуктивностью труда, а также методы контроля подобных эффектов путем
применения таких факторов, как перерывы на отдых, регулирование рабочих часов,
температуры и влажности в помещении. Он просто отделил шесть женщин,
выбранных наугад с конвейера завода, и поместил их под надзор руководителя. Наблюдение
в этом случае носило исключительно дружеский характер. В результате, в их рабочем
состоянии быстро появились перемены, причем Майо рассказывал и давал
необходимые пояснения по поводу этих перемен заранее. Он изменил количество часов в
рабочей неделе, в рабочем дне, количество перерывов на отдых и обед.
Во время проведения серии экспериментов наблюдатель находился вместе с
наблюдаемой командой на семинаре, записывая все происходящее. При этом команда
информировалась о проводимом эксперименте, спрашивала советы или необходимую
информацию, а также выслушивала излагаемые сведения.
Эксперимент начался с внедрения различных изменений, каждое из которых
действовало в течение тестового периода от 4 до 12 недель.

Словарь терминов 1075
В результате уровень производительности работников возрастал при условии
улучшения рабочих условий, но он также продолжал возрастать при отмене этих
улучшений. Секрет этого феномена заключается в том, что отдельные личности при
формировании команды хорошо работают вместе и это проявляется в ходе
эксперимента. В то же время члены команды ощущают себя автономными. При отсутствии
давления со стороны менеджмента они чувствуют ответственность за доставку
продукта и разрабатывают свою собственную методику производства.
Согласно исследованиям Майо, тенденция прироста в производстве не зависит от
изменения рабочих условий. Он полагал, что рабочие места представляют
социальную среду, а люди испытывают мотивацию, которая является более сильной, чем
экономическая выгода. В его исследованиях наблюдатель, отслеживавший
продуктивность, также участвовал в создании социальной атмосферы группы.
Работники, которые подвергаются "измерениям", ощущают смысл самооценки.
Поскольку их руководитель включает их в свои планы, они ощущают себя подлинной
частью команды. Подобная вновь найденная кооперация и верность объясняют
причину роста производительности даже при отсутствии улучшений условий труда.
Позитивный эффект, обнаруженный в ходе проведения экспериментов Хауфтор-
на, заключается в том, что мягкое руководство, слабо затрагивающее работников, и
их объединение в виде команды ведут к росту производительности. При этом
изменения в рабочих условиях не оказывают особого влияния на этот показатель.
Урок эксперимента, относящийся к менеджерам программных проектов, которые
используют метрическую программу, заключается в том, что участники тестов,
испытаний или исследований имеют хороший опыт. Это связано с тем, что им уделяется
повышенное внимание, стимулирующее работоспособность. При этом достигаются
хорошие результаты независимо от предпринятых изменений.
Independent test group (ITG, независимая группа по проведению
тестирования). Группа специалистов, в первоочередные обязанности которых входит
выполнение тестирования.
Integration (Интеграция). Специфичный подход к тестированию интеграции.
Integration testing (Тестирование интеграции). Этап тестирования, на котором
выполняется одновременное тестирование и разработка ПО.
Integrity/Security (Интеграция/Безопасность). Доступ к программному
обеспечению или данным со стороны неавторизованных персон может контролироваться.
Interface control (Контроль интерфейса). Оценка, координация и утверждение (или
неутверждение) всех предложенных изменений с целью формирования функционального
и физического интерфейсов, как определено в спецификациях. Осуществляется поиск с
целью идентификации и контроля изменений, гарантирования корректного внедрения
изменений, а также выполняется отчет об изменениях для заинтересованных лиц.
Interoperability (Взаимодействие между операциями). Степень взаимодействия
между приложениями или интерфейсами.
Joint Application Design (JAD, объединенная разработка приложений).
Специфическая методика выявления требований.
Levels of abstraction (Уровни абстракции). Степень детализации, с применением
которой осуществляется представление ПО.
Line-of-code-metrics (Метрические показатели, основанные на строках кода).
Методы измерения качества или продуктивности, которые нормализуются с
применением строк продуцируемого кода.
LOC. Строки кода (Lines of code).

1076 Словарь терминов
Maintainability (Способность к сопровождению). Действия, связанные с
изменениями в ПО после его поставки конечному пользователю.
Measurement (Измерение). Сбор количественных данных о программном
обеспечении или процессе программного инжиниринга.
Metrics (Метрические показатели). Специфические измерения.
Milestones (Стадии). Отметка времени, используемая для указания прогресса в
ходе выполнения проекта.
Modular design (Модульная разработка проекта). Подход к разработке проекта с
применением принципа модульности.
Modularity (Модульность). Атрибут разработки проекта, ведущий к созданию
высококачественных программных компонентов.
Multiple regression (Множественная регрессия). Регрессия, в ходе выполнения
которой одна переменная оценивается с применением более чем одной другой переменной.
Object-oriented way (Объектно-ориентированный подход). Подход к разработке
программ, входе осуществления которого применяется классификация и
распределение данных в пакеты, а затем выполняется совместная разработка.
Object-oriented analysis (OOA, объектно-ориентированный анализ). Методика,
применяемая для определенных классов объектов в отношении их взаимосвязей и
базовой структуры.
Object-oriented design (OOD, объектно-ориентированное проектирование).
Методика, предназначенная для трансляции ООА-модели в модель внедрения.
Objects (Объекты). Элемент из области определения проблемы, содержащий
данные и единицы обработки.
Perfective maintenance (Совершенное сопровождение). Расширение.
Portability (Переносимость). Способность перемещения программного
обеспечения с одной целевой среды в другую.
Preliminary design (Предварительная разработка проекта). Создание
представления данных и архитектуры.
Problem (Проблема). Отклонение от спецификаций или ожидаемых результатов.
Procedural design (Процедурная разработка проекта). Создание представлений
алгоритмических деталей в составе модуля.
Process error (Ошибка процесса). Некорректный вывод процесса, ведущий к
некорректному состоянию или условию.
Process failure (Сбой процесса). Событие, проявляющееся в том, что дефектный
ресурс, используемый процессом, приводит к генерированию в потоке вывода
обычно наблюдаемой ошибки.
Process fault (Дефект процесса). Дефект, коренящийся в сбойных ресурсах,
используемых в процессе, просматриваемый в виде входа процесса; представляет
некорректное состояние или условие системы, к которой относится данный процесс.
Processing narrative (Описание обработки). Описание модели (программного
компонента) на естественном языке.
Productivity (Производительность). Рабочий выход за единицу времени.
Project control (Контроль проекта). Контроль качества и изменений проекта.
Project database (База данных проекта). Место для хранения элементов
конфигурации.
Project planning (Планирование проекта). Действие, в результате выполнения
которого создается план проекта.

Словарь терминов 1077
Project risks (Проектные риски). Набор потенциальных проблем или
происшествий, проявившихся в ходе выполнения проекта, которые могут привести к сбою.
Project scope (Область действия проекта). Формулирование базисных
требований, в соответствии с которыми разрабатывается программное обеспечение.
Project size (Размер проекта). Отображение общих трудозатрат или количества
людей, работающих над проектом.
Project tracking (Отслеживание проекта). Действие, позволяющее менеджеру
понимать состояние проекта.
Prototyping (Прототипирование). Создание эскиза приложения.
Quality (Качество). Степень, в которой продукт удовлетворяет явным и неявным
требованиям.
Quality metrics (Метрические показатели качества). Измерение качества.
Re-engineering (Реинжиниринг). Набор действий, трансформирующих
наследственные системы (обладающие недостаточной способностью к сопровождению) в
высококачественное ПО.
Regression analysis (Регрессионный анализ). Предположим, что существует
взаимосвязь (корреляция) между двумя или большим количеством объектов. Подобный факт
вытекает их теории, согласно которой одна вещь зависит от другой. Например, если
предположить, что грамм потребленного сахара связан с образованием определенного
количества очагов кариеса, можно прийти к причинной гипотезе, согласно которой грамм
потребленного сахара приводит к образованию очага кариеса.
Специалисты по статистике проверяют, что теория не является ложной, а не
пытаются доказать ее истинность. Конструируется "нулевая гипотеза", в которой
утверждается, что исследуемая взаимосвязь не является статистически значимой. Здесь имеет
место попытка статистической демонстрации высокой степени вероятности и
важности взаимосвязи. Затем фальшивая нулевая гипотеза заключается в оказании доверия
идее относительно существования взаимосвязи, которая может использоваться для
объяснения наблюдаемого феномена. Если взаимосвязь установлена, для измерения
степени связности между переменными может применяться статистический анализ.
Рассмотрим пример, в котором используется нулевая гипотеза, утверждающая об
отсутствии взаимосвязи между граммами потребленного сахара и количеством очагов
кариеса у наблюдаемого лица. Если у этого лица взяли интервью и для упомянутых
ранее переменных были получены данные, можно отметить точки данных,
определенные за какой-либо период времени. Если сахар (в граммах) потреблялся на
протяжении года (ось х графика), а количество очагов кариеса, появившихся за год,
отображено на оси у, график становится похожим на диаграмму разброса. Если линия
проходит между точками, на линейном графике отображается четкая взаимосвязь,
показывающая, что количество очагов кариеса растет с потреблением сахара.
Вывод заключается в том, что рост потребления сахара приводит к увеличению
количества очагов. Алгоритм, применяемый в простом линейном регрессионном
анализе, пытается наилучшим образом аппроксимировать линию по отношению
к точкам данных. Уравнение линии может записываться в следующем виде:
С = К + S X I
где:
С = наблюдаемое количество очагов у отдельного лица;
К = числовое значение константы;

1078 Словарь терминов
S = количество граммов сахара, потребленного одним человеком;
I = увеличение числа очагов кариеса из расчета на грамм потребленного сахара.
В рассматриваемом примере очаги кариеса помещены на у-оси, константа
выполняет масштабирование по у-оси, количество граммов потребленного сахара
отображено на х-оси. Увеличение количества очагов кариеса из расчета на грамм
потребленного сахара, I, определяет угол наклона прямой. Под углом наклона прямой
подразумевается отношение прироста по оси у к приросту по оси х. Если угол наклона
регрессионной прямой не равен нулю, прослеживается линейная взаимосвязь. Если
известно значение переменной х, можно получить значимую оценку для у. В
статистической зависимости количество очагов кариеса представляется зависимой
переменной С, а количество потребленного сахара определяется независимой
переменной S. В данном случае имеет место непосредственная линейная зависимость,
поскольку при возрастании значения независимой переменной наблюдается рост
значения зависимой переменной. В ходе проверки на нулевую гипотезу выяснилось,
что в этом случае наклон регрессионной прямой будет равным нулю. Поэтому если
угол наклона прямой не равен нулю, нулевая гипотеза будет ложной и можно сделать
вывод о существовании зависимости.
В ходе выполнения множественной регрессии выполняется анализ нескольких
независимых переменных. Например, в ходе осуществления реального сопровождения
ПО будет использована следующая функция:
МС = К + ТВ, х СМ,
Regression testing (Регрессионное тестирование). Тесты, которые выполняются
в повторяющемся режиме до тех пор, пока изменения не перестанут приводить к
появлению побочных эффектов.
Reliability (Надежность). Измерение, в терминах которого программа
выполняется на необходимом уровне точности.
Requirements analysis (Анализ требований). Действие по моделированию, в ходе
выполнения которого осознаются реальные требования заказчиков.
Resources (Ресурсы). Какие-либо материальные и нематериальные активы,
требуемые для выполнения проекта (люди, оборудование, материалы и информация).
Reusability (Повторное применение). Свойство, обеспечивающее повторное
применение существующего компонента в другом приложении.
Reusable components (Повторно применяемые компоненты). Элементы
конфигурации, которые могут применяться повторно.
Reverse engineering (Обратный инжиниринг). Попытка разработки моделей
программного проекта либо получения представления относительно применения
проектного программного кода, используемого в качестве "точки отсчета".
Revision (Пересмотр). Новая версия ПО, призванная заменить старую версию.
Обычно закон появления новых версий носит линейный характер. Старые версии
программ сохраняются на случай проявления непредвиденных ошибок в новых версиях.
Risk (Риск). Потенциальная проблема или случайность, которая может привести
к срыву выполняемого проекта.
Risk Analysis (Анализ рисков). Методики, применяемые для идентификации
и оценки степени серьезности риска.
Robustness (Устойчивость). Свойство, определяющее устойчивое выполнение
программы при некорректных входных данных.

Словарь терминов 1079
Scheduling (Календарное планирование). Действие, в ходе осуществления
которого создается график выполняемых работ для данного проекта.
Scope (Область действия). Ограничивающие условия, в рамках которых
выполняется проект.
Selective testing (Выборочное тестирование). Тестирование выбранного набора
способов выполнения программы и входных данных.
Side effects (Побочные эффекты). Ошибки, являющиеся следствием
выполненных изменений.
Software (Программное обеспечение). Программы, документы и данные.
Software engineering (Программный инжиниринг). Дисциплина, предмет
изучения которой сосредоточен в области процессов, связанных с разработкой ПО;
методы, применяемые для анализа, проектирования и тестирования
компьютерного ПО; методики менеджмента, применяемые при осуществлении контроля и
мониторинга программных проектов; инструменты, применяемые для поддержки
процессов и методов.
Software failures (Программные сбои). Сбои, причина которых заключается
в дефектах/ошибках проектирования (система и ПО), в дефектах/ошибках
кодирования, в "канцелярских" ошибках, неадекватной отладке и ошибках, допущенных
в процессе тестирования.
Software metrics (Метрические показатели ПО). Количественные измерения,
имеющие отношение к процессу или продукту.
Software project management plan (SPMP, план управления программным
проектом). Описание подхода к выполняемому проекту с позиций менеджмента.
Software quality assurance (SQA, обеспечение качества ПО). Набор действий,
обеспечивающих разработку организацией качественного ПО.
Software Quality Engineer (SQE, инженер по качеству ПО). Сертификация ASQ,
обеспечивающая подход к программному инжинирингу относительно соблюдения
качества.
Software requirements specification (SRS, спецификация требований к ПО).
Документ, описывающий все данные, требования к функционированию и поведению ПО,
все ограничения, а также все требования к аттестации ПО.
Software testing (Тестирование ПО). Набор действий, предпринимаемых с целью
поиска ошибок в разработанном ПО.
Spiral model (Спиральная модель). Парадигма эволюционного программного
инжиниринга.
State transition diagram (STD, диаграмма переходов состояния). Запись
моделирования поведенческих представлений.
Statistical quality assurance (Статистическое обеспечение качества). Методики
улучшения процесса, основанные на измерениях продукта и процесса.
Status accounting (Учет состояния). Регистрация состояния, наступившего в
результате осуществления последних пересмотров и изменений. Сюда обычно
включается отчетность о действиях по составлению документации (количество одобренных
или выпущенных документов, количество выполненных изменений, количество
одобренных и внедренных изменений).
Stepwise refinement (Пошаговое улучшение). Методика, применяемая при
выполнении функциональной декомпозиции или процедурном проектировании (также
называется разбиением на разделы).

1080 Словарь терминов
Structured programming (Структурированное программирование). Метод
проектирования, при реализации которого производится ограничение конструктивных
модулей тремя базовыми формами. Также накладываются ограничения на поток
проектирования программы, что способствует достижению лучшего качества.
Task (Задача). Обобщенный термин для работы, которая не включена в структуру
пооперационного перечня работ, но может быть разбита на более мелкие задания,
выполняемые уполномоченными лицами. Также этот термин определяет
наименьший уровень трудозатрат для проекта.
Technical risks (Технические риски). Набор потенциальных технических
проблем или случайностей, которые могут привести к срыву проекта.
Test plan and procedure (План и процедура тестирования). Описание стратегии
и тактики тестирования.
Testability (Способность к тестированию). Трудозатраты, необходимые для
выполнения тестирования, в ходе осуществления которого можно убедиться в
корректности выполняемых программных действий.
Testing (Тестирование). Набор действий, направленных на обнаружение ошибок.
Tools (Инструменты). Прикладное ПО, применяемое для выполнения задач
программного инжиниринга (инструменты проектирования, инструменты тестирования
и т.д.); также см. CASE tools.
Total quality management (Общий менеджмент качества). Обязательства
компании по разработке процесса, который обеспечивает создание высококачественного
продукта и достижение удовлетворенности заказчика.
Unit testing (Модульное тестирование). Часть стратегии тестирования, которая
сосредоточена на тестах отдельных программных компонентов.
Usability (Применимость). Трудозатраты, необходимые для изучения, выполнения
операций, подготовки входных данных, а также интерпретации выходных данных.
User (Пользователь). Лицо, которое фактически использует ПО либо продукт со
встроенным ПО.
Validation (Аттестация). Тесты, позволяющие убедиться в соответствии ПО
имеющимся требованиям.
Version Control (Контроль версий). Процедуры и инструменты,
предназначенные для управления различными версиями объектов конфигурации. Версия включает
набор описывающих ее атрибутов, например, номер, дату и индикатор изменений.
White-box testing (Тестирование методом "белого" ящика). Методика
тестирования программного проекта, предусматривающая знания внутренней
программной логики.
Work breakdown structure (WBS, пооперационный перечень работ). Набор
рабочих заданий, необходимых для создания ПО. Определяется в виде части модели
процесса.

Литература
Список литературы включает ссылки на источники, связанные с обеспечением
качества, программным инжинирингом и менеджментом проектов. Эта ссылки
приводятся во всех главах книги. Если же вам потребуется более подробная информация,
относящаяся к области специфических знаний, обратитесь к соответствующим
книгам, указанным в данном разделе.
Книги
Abdel-Hamid Tarek, and Stuart E. Madnick. Software Project Dynamics: An Integrated
Approach. Upper Saddle River, NJ: Prentice Hall, 1991. Abran Alain, and James W. Moore,
eds., 2001. Trial Version 0.9 of the SWEBOK. Los Alamitos, CA: IEEE Press 2001.
Abreu F.B. «Metrics for Object-Oriented Environment». Proceedings of the Third
International Conference on Software Quality, Lake Tahoe, NV, pp. 67-75, 1993.
Ackerman Phillip L., et al., eds. Learning and Individual Differences: Process, Trait, and
Content Determinants. Washington, DC: American Psychological Association Books, 1990.
Adams John R. The Principles of Project Management. Sylva, NC: PMI Publication Division,
1997.
Akao Y., ed. Quality Function Deployment. Cambridge, MA: Productivity Press, 1990.
Albrecht A.J., and S.H. Gaffney. «Software Function, Source Lines of Code and
Development Effort Prediction: A Software Science Validation».IEEE Transactions on
Software. Engineering, 9F):639-648, 1983.
AJderfer Clavton P. Existence, Relatedness, and Growth: Human Needs in Organizational
Settings. NY: Free Press, 1972.
Alien Paul. Realizing e-Business witli Components. Reading, MA: Addison-Wesley, 2000.
Allport Gordon W. Personality and Social Encounter: Selected Essays. Boston, MA: Beacon
Press, 1960.
Allport Gordon W. Pattern and Growth in Personality. NY: Holt, Rinehart and Winston,
1961.
Archibald Russell D. Managing High-Teclinology Programs and Projects, 2nd ed. NY: John
Wiley & Sons, 1992.
Baber Robert Laurence. Error-Free Software: Know-How and Know-Whty Program Correctness.
NY. Wiley, 1991.

1082 Литература
Bache Richard, and Gualtiero Bazzana. Software Metrics for Product Assessment. NY:
McGraw-Hill, 1994.
Baker A.L., et al. «A Philosophy for Software Measurement». The Journal of Systems and
Software, 12C):277-281, 1990.
Barns Michael G. «Inheriting Software Metrics». Journal of Object-Oriented Programming,
November-December, pp. 27-34, 1993.
Baron Renee, and Elizabeth Wagele. The Enneagram Made Easy: Discover the Nine Types of
People. San Francisco, CA: Harper Collins Press, 1994.
Basili Victor R., and R.W. Selby. «Comparing the effectiveness of software testing
strategies». IEEE Transactions on Software Engineering SE-13A2):1278-1296, 1987.
Basili Victor. Tutorial on Models and Metrics for Software Management and Engineering. NY:
Institute of Electrical and Electronics Engineers, 1980.
Basili Victor, and Barry T. Perricone. «Software Errors and Complexity: An Empirical
Investigation». Commumicationsoj"theACM., 27(l):42-52, 1984.
Basili Victor, and D. Hutchens. «An Empirical Study of a Complexity Family». IEEE
Transactions on Software Engineering, 9F):664-672, 1983.
Basili Victor, and D. Weiss. «A Methodology for Collecting Valid Software Engineering
Data». IEEE Transactions on Software Engineering SE-10F):728-738, 1984.
Basili Victor R., et al. «Goal/Question/Metric Paradigm». Encyclopaedia of Software
Engineering, Volume 1. NY: John Wiley and Sons, pp. 528-532, 1994.
Basili Victor R. «Viewing Maintenance as Reuse-Oriented Software Development». IEEE
Software, January, pp. 19-25, 1990.
Basili Victor R. «A methodology for collecting valid software engineering data». IEEE
Transactions, on Software Engineering, SE-10F):728-738, 1984.
Bass Len, et al. Software Architecture in Practice. Reading, MA: Addison-Wesley, 1997.
Bass Len, Paul Clements, and Rick Kazman. Software Architecture in Practice: The SEI Series.
NY: Addison-Wesley, 1998.
Batini Carlo, et al. Conceptual Database Design: An Entity-Relationship Approach. Reading,
MA: Addison-Wesley, 1991.
Becker Shirley, and Mitchell Bostelman. «Aligning Strategic and Project Measurement
Systems». IEEE Software, 16C):46-51, 1999.
Beizer Boris. Software System Testing and Quality Assurance. NY: Van Nostrand Reinhold,
1984. Beizer Boris. Software Testing Techniques, 2nd ed. NY: Van Nostrand Reinhold, 1990.
Beizer Boris. Black Box Testing: Techniques for Finictional Testing of Software and Systems. NY:
Wiley, 1995.
Berard E.V. Essays on Object-oriented Software Engineering, Volume 1. Reading, MA:
Addison-Wesley, 1993.
Berg Cindy, and Kim Colenso. «Work Breakdown Structure Practice Standard Project —
WBS vs. Activities». PMNetwork, April, 2000.
Bias Randolph G., and Deborah J. Mayhew, eds. Cost-justifying Usability. Boston, MA:
Academic Press, 1994.
Binder Robert. «Scenario-Based Testing for Client/Server Systems». The Software Testing
Forum, 1B):12-17, 1993.
Binder Robert V. Testing Object-Oriented Systems: Models, Patterns find Tools. Reading, MA:
Addison-Wesley, 1999.
Black Rex. Managingthe Testing Process. Redmond, WA: Microsoft Press, 1999.

Литература 1083
Boar Bernard. Application Prototyping: A Requirements Definition Strategy for the '80s, 1st ed.
NY: John Wiley & Sons, 1984.
Boegh Jorgen, et al. «A Method for Software Quality Planning, Control, and
Evaluation».IEEE Software, 16B):69-77, 1999.
Boehm Barrv. «Software Engineering». IEEE Transactions on Computers. Los Alamitos,
CA: IEEE Computer Society, 1976.
Boehm Barry. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1981.
Boehm Barry. «A Spiral Model of Software Development and Enhancement». IEEE
Computer, 21E):61-72, 1988.
Boehm Barry W., and Rony Ross. «Theory W Software Project Management Principles
and Examples». IEEE Transactions on Software Engineering, 15G):902-916, 1989.
Boehm Barry W., et al. Software Cost Estimation with Cocomo II. Englewood Cliffs, NJ:
Prentice Hall, 2000.
Boehm Barry, and Alexander Egyed, et al. «Using Win Win Spiral Model: A Case Study».
IEEE Computer, 31 G):33-44, 1998.
Boehm Barry, et al. Characteristics of Software Quality. NY: American Elsevier, 1978.
Boehm Barry, et al. «Developing Multimedia Applications with the Win Win Spiral
Model». Proceedings, ESEC/FSE 97 and ACM Software Engineering Notes, November. NY:
Association for Computing Machinery, 1997.
Boloix Germinal, and Pierre Robillard. «Inter-Connectivity Metric for Software
Complexity». Information Systems and Operation Research, 26(l):17-39, 1988.
Booch Grady. Object-Oriented Design with Applications. Reading, MA: Addison-Wesley,
1994.
Booch Grady, et al. Unified Modeling Language User Guide. Reading, MA: Addison-Wesley,
1998.
Booch Grady, James Rumbaugh, and Ivar Jacobson. The UML Modeling Language User
Guide. Reading, MA: Addison-Wesley, 1999.
Bourque Pierre, et al. «The Guide to the Software Engineering Body of Knowledge».
IEEE Software, The IEEE Institute, No vember/ December, pp. 35-44, 1999.
Bowan Jonathan P., and Michael G. Hinchley. «Ten Commandments of Formal
Methods». Computer, 28D):56-63, 1995.
Bowditch James L., and Anthony F. Buono. A Primer on Organizational Behavior, 5th ed.
NY: John Wiley & Sons, 2001.
Briand Lionel C, Sandro Morasca, and Victor R. Basili. «Property-Based Software
Engineering Measurement». IEEE Transactions on Software Engineering, 22(l):68-86, 1996.
Brooks Fred. The Mythical Man-Month: Essays on Software Engineering 1st ed. Reading, MA:
Addison-Wesley, 1975.
Brooks Fredrick P. «No Silver Bullet: Essence and Accidents of Software Engineering»,
IEEE Computer. 20D):10-19, 1987.
Brooks Fredrick P. The Mythical Man-Month: Essays on Software Engineering anniversary ed.
Reading, MA: Addison-Wesley, 1995.
Brown Karen A., and Nancy Lea Hyer. «Mind Mapping as a WBS Development Tool».
PMI 2001 Seminar and Symposium, Nashville, TN, 2001.
Buck F.0. «Indicators of Quality Inspections». IBM Corporation Technical Report. IBM
TR21, 802, September, 1981.

1084 Литература
Bush Marilvn. «Improving Software Quality: The Use of Formal Inspections at the Jet
Propulsion Laboratory». Proceedings, 12th International Conference on Software Engineering.
Nice, France, March 26-30, pp. 196-199, 1990.
Buzan Tony. Use Both Sides of Your Brain, 3rd ed. NY: Penguin Putnam, 1991.
Buzan Tony, and Barry Buzan. The Mind Map Book: How to Use Radiant Thinking to
Maximize Your Brain's Untapped Potential NY: Penguin Putnam, 1996.
Buzan Tony, Tony Dottino, and Richard Israel. The Brainsmart Leader. Burlington, VT:
Gower Pub, 1999.
Calero Henry H. Winning the Negotiation. NY: Flawthorn Books, 1979.
Cantor Murray R. Object-Oriented Project Management with UML. NY: John Wiley& Sons,
1998.
Cantor N.. and J.F. Kihistrom. Personality and Social Intelligence. Englewood Cliffs, NJ:
Prentice-Hall, 1987.
Card David N., and Robert L. Glass. Measuring Software Design Quality. Englewood Cliffs,
NJ: Prentice Hall, 1990.
Carmel E. «Cycle Time in Packaged Software Firms». Journal of Product Innovation
Management, 12B): 110-123, 1995.
Cassel Paul, and Pamela Palmer. Sams Teach Yourself Access 2000 in 21 Days. Indianapolis,
IN:, 1999.
Sams, Chapin Ned. «A New Format for Flowcharts». Software - Practice and Experience,
4D):341-357, 1974.
Chapin Ned. «A Measure of Software Complexity». Proceedings of the AF1PS National
Computer Conference, Spring 1979, pp. 995-1002, 1979.
Chapin Ned. «Software Maintenance: A Different View». Proceedings of the 1985 National
Computer Conference. AFIPS Press, pp. 507-513, 1985.
Charette Robert N. Applications Strategies for Risk Analysis. NY: McGraw-Hill, 1990.
Chen J.Y, and J.F. Lu. «A New Metric for Object-oriented Design». Journal of Information
and Software Technology, 35D):232-240, 1993.
Chen Peter. The Entity-Relationship Approach to Logical Database Design. Wellesley, MA:
Q.E.D. Information Sciences, 1977.
Chevrier Sylvia, as reported by Larraine Segil in «Global Work Teams: A Cultural
Perspective». PMNetwork, March, 1999.
Chidamber Shyam R., David P. Darcy, and Chris F. Kemerer. «Managerial Use of
Metrics for Object-Oriented Software: An Exploratory Analysis». IEEE Transactions on
Software Engineering, 24(8):629-639, 1998.
Christensen K., G.P. Fitsos, and C.P. Smith. «A Perspective on Software Science». IBM
Systems Journal, 20D):372-387, 1981.
Cleland David I. Project Management: Strategic Design and Implementation, 2nd ed. NY:
McGraw-Hill, 1994.
Coad Peter, and Edward Yourdon. Object Oriented Analysis. NY: Prentice Hall Yourdon
Press Computing Series, 1991.
Coad Peter, and Edward Yourdon. Object Oriented Design. NY: Prentice Hall Yourdon
Press Computing Series, 1991.
Coad Peter, et al. Object Models: Strategies, Patterns and Applications, 2nd ed. NY: Prentice
Hall Yourdon Press Computing Series, 1996.
Codd E.F. «A Relational Model of Data for Large Shared Data Banks». Communications of
the ACM, 13F):377-387, 1970.

Литература 1085
Codd E.F. The Relationship Model for Database Management, Version 2. NY: Addison-
Wesley, 1990.
Cohen Herb. You Can Negotiate Any thing. Secaucus, NJ: L. Stuart, 1980.
Connell John, and Linda Shafer. «Reducing Software Maintenance Costs». Computer
Programming Management. Auerbach Publishers, 1986.
Connell John, and Linda Shafer. The Professional User's Guide to Acquiring Software. NY:
Van Nostrand Reinhold, 1987.
Connell John, and Linda Shafer. Structured Rapid Prototyping: An Evolutionary Approach to
Software Development, 1st ed. Englewood Cliffs, NJ: Prentice Hall, 1989.
Connell John, and Linda Shafer. Object-oriented Rapid Prototyping. NY: Prentice Hall
Yourdon Press Computing Series, 1995.
Conte S.D., H.E. Dunsmore, and V.Y. Shen. Software Engineering Metrics and Models.
Memo Park, CA: Benjamin/Cummings, 1986.
Cook Jonathan E., Lawrence Votta, and Alexander L. Wolf. «Cost-Effective Analysis of
In-Place Software Processes». IEEE Transactions on Software Engineering, 24(8): 640-649, 1998.
Curtis Bill. «In Search of Software Complexity». Proceedings of the Workshop on Quantitative
Software Models for Reliability, pp. 95-106, 1979.
Curtis Bill. «Measurement and Experimentation in Software Engineering». Proceedings of
the IEEE, 68(9): 1144-1157, 1980.
Curbs Bill, Herb Krasner, and Neil Iscoe. «A Field Study of the Software Design Process
for Large Systems». Communications of the ACM, 31A1), 1988.
Dart Susan A., et al. «Software Development Environments». IEEE Computer, 20A1):18-
28, 1987.
Daskalantonakis Michael K. «A Practical View of Software Measurement and
Implementation Experiences Within Motorola». IEEE Transactions on Software Engineering
18A1):998-1010, 1992.
Date CJ. An Introduction to Database Systems, 7th ed. Reading, MA: Addison-Wesley, 1999.
DeMarco Tom. Structured Analysis and Systems Specification. NY: Prentice Hall Yourdon
Press Computing Series, 1979.
DeMarco Tom. Controlling Software Projects. Englewood Cliffs, NJ: Prentice Hall, 1982.
DeMarco Tom. Why Does Software Cost So Much ? and Other Puzzles of the Information Age. NY:
Dorset House, 1995.
DeMarco Tom, and Barry W. Boehm. Controlling Software Projects: Management,
Measurement, and Estimates. Englewood Cliffs, NJ: Prentice Hall PTR/Sun Microsystems
Press, 1998.
DeMarco Tom, and P.J. Plauger. Structured Analysis and System Specification. NY: Prentice
Hall Yourdon Press Computing Series, 1985.
DeMarco Tom, and Timothy Lister. Peopleware: Productive Projects and Teams. NY: Dorset
House, 1987.
Deming W. Edwards. Out of the Crisis, 1st ed. Cambridge, MA: MIT Press, 2000. Deming
W. Edwards. The New Economics: For Industry. Government, Education, 2nd ed. Cambridge, MA:
MIT Press, 2000.
Department of the Air Force, Software Technology Support Center. Guidelines for
Successful Acquisition and Management of Software Intensive Systems. Version 2.0, June, 1996.
DeSantis Richard, John Biyskal, Assad Moini, and Mark Tappan. SPC-97057 CMC,
Version 01.00.04. Herndon, VA: Software Productivity Consortium, 1997.

1086 Литература
Deutsch Michael S., and Ronald R. Willis. Software Quality Engineering: A Total Teclinical
and Management Approach, 1st ed. Englewood Cliffs, NJ: Prentice Hall PTR/Sun
Microsystems Press, 1988.
Devor Richard E., et al. Statistical Quality Design and Control. NY: Prentice Hall, 1992.
Dijkstra Edsger Wybe. A Discipline of Programming. Englewood Cliffs, NJ: Prentice Hal],
1976.
Dorfman M., and R.H. Thayer, eds. Software Engineering. Los Alamitos, CA: IEEE
Computer Society Press, 1997.
Doyle Michael, and David Straus. How to Make Meetings Work: The New Interaction Method.
NY: Penguin Putman, 1982.
Dumas Joseph S., and Janice C. Redish. A Practical Guide to Usability Testing rev. ed.
Portland, OR: Intellect Books, 1999.
Dutoit Alien H., and Bernd Bruegge. «Communication Metrics for Software
Development».IEEE Transactions on Software Engineering, 24(8):615-628, 1998.
Dver Michael. The Cleanroom Approach to Quality Software Development. NY: Wiley, 1992.
Ebenau Robert G., and Susan H. Strauss. Software Inspection Process. NY: McGraw-Hill,
1994.
Eriksson Hans-Erik, and Magnus Penker. The UML Toolkit. NY: John Wiley & Sons, 1998.
Fagan Michael E. «Design and Code Inspections to Reduce Errors in Program
Development». IBM Systems Journal, 15C):185-211, 1976.
Fagan Michael E. «Advances in Software Inspections». IEEE Transactions on Software
Engineering, 12G): 744-751, 1986.
Fairley Richard E. Software Engineering Concepts. NY: McGraw-Hill, 1985.
Fairley Richard E. «Recent Advances in Software Estimation Techniques». IEEE 14th
International Conference on Software Engineering Los Alamitos CA: IEEE Computer Society
Press, pp. 382-391, 1992.
Fenton Norman. Software Metrics: A Rigorous Approach. NY: Chapman & Hall CRC Press,
1991.
Fenton Norman, and Martin Neil. «A Critique of Software Defect Prediction Models».
IEEE Transactions on Software Engineering 25E): 55-67, 1999.
Fenton Norman E., and Martin Neil. «Software Metrics: Successes, Failures and New
Dii-ections»./oumafq/",S)>stem5 andSoftware, 47B-3):149-157, 1999.
Fenton Norman E., and Shari Lawrence Pfleeger. Software Metrics - A Rigorous and
Practical Approach, 2nd ed. Boston, MA: PWS Publications, 1997.
Fisher Roger, and William Ury. Getting To Yes, 2nd ed. New York: NY: Penguin Books,
1991.
Flavin Matt. Fundamental Concepts of Information Modeling. NY: Prentice Hall Your-don
Press Computing Series, 1981.
Florae William A. Software Quality Measurement: A Framework for Counting Problems and
Defects, CMU/SEI-92-TR-22. Pittsburgh, PA: Software Engineering Institute, Carnegie
Mellon University, 1992.
Florae William A., and Anita D. Carleton. Measuring tlie Software Process. Reading, MA:
Addison-Wesley, 1999.
Florae William A., et al. Practical Software Measurement: Measuring for Process Management
and Improvement, CMU/SEI-97-НВ-ООЗ. Pittsburgh, PA: Software Engineering Institute,
Carnegie Mellon University, 1996.

Литература 1087
Frame J. Davidson. Managing Projects in Organizations. NY:Jossey-Bass, 1987.
Frame J. Davidson. The New Project Management. NY: Jossey-Bass, 1994.
Franker» Robert E. Human Motivation, 5th ed. Pacific Grove, CA: Brooks/Cole, 2002.
Freeman Daniel, and Gerald Weinberg. Handbook of Walkthroughs, Inspections, and
Technical Reviews, 3rd ed. NY: Dorset House, 1990.
Friedman Michael A., and Jeffrey M. Voas. Software Assessment: Reliability, Safety, Testability.
NY: Wiley, 1995.
Gacek Cristina, Ahmed Abd-Allah, Bradford Clark, and Barry W. Boehm. «On the
Definition of Software System Architecture». Proceedings of the First International Workshop on
Architectures for Software Systems, Seattle, WA, 1995.
Garmus David, and David Herron. Function Point Analysis: Measurement Practices for
Successful Software Projects. Boston, MA: Addison-Wesley, 2001.
Cause Donald C, and Gerald M. Weinberg. Exploring Requirements: Quality Before Design.
NY: Dorset House, 1989.
Gilb Tom. Software Metrics. Cambridge, MA: Winthrop Publishers. Gilb, Tom, and
Dorothy Graham A993). Software Inspection. Reading, MA: Addison-Wesley, 1977.
Goldratt Eliyahu M., and Jeff Cox. The Goal: A Process of Ongoing Improvement, 2nd ed.
Aldershot, Hampshire, England: Gower, 1993.
Goodman Paul. Practical Implementation of Software Metrics. NY: McGraw-Hill, 1992.
Gorden Raymond L. Basic Interviewing Skills. Prospect Heights, IL: Waveland Press, 1998.
Grable Ross, et al. «Metrics for Small Projects: Experiences at the SED». IEEE Software,
16B):21-29, 1999.
Grady Robert B. «Measuring and Managing Software Maintenance». IEEE Software,
4D):35л15, 1987.
Grady Robert B. Practical Software Metrics for Project Management and Process Improvement.
NY: Prentice Hall, 1992.
Grady Robert B. Successful Software Process Improvement. Englewood Cliffs, NJ: Prentice
Hall, 1997.
Grady Robert В., and Deborah L. Caswell. Software Metrics: Establishing a Company-Wide
Program, Englewood Cliffs, NJ: Prentice Hall, 1987.
Graham Ian. Migrating to Object Technology, 1st ed. Reading, MA: Addison-Wesley, 1995.
Grant Richard. Instructor, University of Texas Software Quality Institute Certificate
Program, Sequence XI, Session 3, 2000.
Guinta Lawrence R., and Nancy С Praizler. The QFDBook. NY: AMACOM Books, 1993.
Haag Stephen, M.K. Raja, and L.L. Schkade. «Quality Function Deployment Usage in
Software Development». Communications of the ACM, 39(l):41-49, 1996.
Haley Tom, et al. «Raytheon Electronic Systems Experience in Software Process
Improvement». Software Engineering Institute Technical Report, CMU/SEI-95-TR-017,
November, 1995.
Hall Anthony. «Seven Myths of Formal Methods». IEEE Software, September, 11-20,
1990.
Hall Tracy, and Norman Fenton. «Implementing Effective Software Metrics Programs».
IEEE Software. 14B):55-67, 1997.
Halstead Maurice H. Elements of Software Science. NY: Elsevier, 1977.
Hammer Theodore F., Leonore L. Huffman, and Linda H. Rosenberg. «Doing
Requirements Right the First Time». Cross Talk Journal of Defense Software Engineering,
December, 1998.

1088 Литература
Harmon Paul, and David A. Taylor. Objects in Action: Commercial Applications of Object-
Oriented Technologies. Reading, MA: Addison-Wesley, 1993.
Harrison Warren, and Kenneth Magel. «A Complexity Measure Based on Nesting
Level». ACMSICPEANNotices, 16C):63-74, 1981.
Hatley Derek J., and Imtiaz A. Pirbhai. Strategies for Real-Time System Specification. NY:
Dorset House, 1988.
Hauserjohn R., and Don Clausing. «The House of Quality». The Harvard Business Review,
May-June, pp. 63-73, 1988.
Hergenhahn B.R. An Introduction To Theories of Personality. Englewood Cliffs, NJ: Prentice
Hall, 1990.
Hersey Paul, and Kenneth H. Blanchard. Management of Organizational Behavior, 6th ed.
Englewood Cliffs, NJ: Prentice-Hall, 1993.
Hersey Paul, Kenneth Blanchard, and Dewey Johnson. Management of Organizational
Behavior: Utilizing Human Resources, 7th ed. Upper Saddle River, NJ: Prentice Hall, 1996.
Herzberg Frederick, Bernard Mausner, and Barbara Bloch Snyderman. The Motivation to
Work. New Brunswick, NJ: Transaction Publishers, 1993.
Hetzel William C. The Complete Guide to Software Testing 2nd ed. Wellesley, MA: QED
Information Sciences, 1988.
Hetzel William C. Making Software Measurement Work: Building an Effective Measurement
Program. Boston, MA: QED Pub. Group, 1993.
Hirsh Sandra, and Jean Kummerow. ElFETypes. NY: Warner Books, Inc., 1989
Howard Jr. Baetjer. Software As Capital: An Economic Perspective on Software Engineering. Los
Alamitos, CA: IEEE Computer Society, 1997.
Humphrey Watts. Managing the Software Process, 1st ed. Reading, MA: Addison-Wesley SEI
Series in Software Engineering (reprinted with corrections, August 1990), 1989.
Humphrey Watts. A Discipline for Software Engineering. Reading, MA: Addison-Wesley, SEI
Series in Software Engineering, 1995.
Humphrey Watts S., and W. L. Sweet. A Method for Assessing the Software Engineering
Capability of Contractors, Technical Report #CMU/SEI-87-TR-23. Software Engineering
Institute, Carnegie Mellon University, September, 1987.
Hunter Michael R., and Richard D. Van Landingham. «Listening to the Customer
Using QFD». Quality Progress, 27D): 55-59, 1994.
IEEE. «IEEE 1044 Standard Classification for Software Anomalies». IEEE Software
Engineering Standards Collection. NY: Institute of Electrical and Electronics Engineers, 1993.
IEEE. «IEEE 1058 Standard for Software Project Management Plans». IEEE Software
Engineering Standards Collection. NY: Institute of Electrical and Electronics Engineers, 1993.
IEEE. «IEEE 1044 Standard Classification for Software Anomalies». IEEE Software
Engineering Standards Collection. NY: Institute of Electrical and Electronics Engineers, 1995.
IEEE 1008-1987. «IEEE Standard for Software Unit Testing». NY: The Institute of
Electrical and Electronics Engineers, 1987.
IEEE 1016.1-1993. «Guide to Software Design Descriptions». NY: The Institute of
Electrical and Electronics Engineers, 1993.
IEEE 1016-1998. «Recommended Practice for Software Design Descriptions». NY: The
Institute of Electrical and Electronics Engineers, 1998.
IEEE 1045-1992. «IEEE Standard for Software Productivity Metrics». NY: The Institute
of Electrical and Electronics Engineers, 1992.

Литература 1089
IEEE 1061-1992. «IEEE Standard for a Software Quality Metrics Methodology». NY: The
Institute of Electrical and Electronics Engineers, 1992.
IEEE 1074-1997. «IEEE Standard for Developing Software Life Cycle Processes». NY:
The Institute of Electrical and Electronics Engineers, 1998.
IEEE 1233. «Guide for Developing System Requirements Specifications». Software
Engineering Standards Collection. NY: Institute of Electrical and Electronics Engineers, 1998.
IEEE 1320.1-1998. «Standard for Functional Modeling Language—Syntax and Semantics
for IDEFO». NY: The Institute of Electrical and Electronics Engineers, 1998.
IEEE 1320.2-1998. «Standard for Conceptual Modeling Language Syntax and Semantics
for IDEF1X97 (IDEFobject)». NY: The Institute of Electrical and Electronics Engineers,
1998.
IEEE 1471-2000. «Recommended Practice for Architectural Description of Software
Incentive Systems». NY: The Institute of Electrical and Electronics Engineers, 2000.
IEEE 610.12-1990. «IEEE Standard Glossary of Software Engineering Terminology».
Software Engineering Standards Collection. NY: The Institute of Electrical and Electronics
Engineers, 1990.
IEEE 729-1983. «IEEE Standard Glossary of Software Engineering Terminology». NY:
The Institute of Electrical and Electronics Engineers, 1983.
IEEE 829-1983. «IEEE Standard for Software Test Documentation». NY: The Institute of
Electrical and Electronics Engineers, 1983.
IEEE 830-1998. «IEEE Recommended Practice for Software Requirements
Specifications». Software Engineering Standards Collection. NY: The Institute of Electrical and
Electronics Engineers, 1998.
IEEE 982.1-1988. «IEEE Standard Dictionary of Measures to Produce Reliable
Software». NY: The Institute of Electrical and Electronics Engineers, 1988.
IEEE 982.2-1988. «IEEE Guide for the Use of IEEE Standard Dictionary of Measures to
Produce Reliable Software». NY: The Institute of Electrical and Electronics Engineers,
1988.
Ilichjohn, and Barbara Schindlerjones. Successful Negotiating Skills for Women. Reading,
MA: Addison-Wesley, 1981.
Ince Darrel. «Software Metrics». Measurement for Software Control and Assurance, NY:
Elsevier Applied Science, 1989.
International Function Point Users Group. Function Points as Asset Reporting to
Management, 1990. International Function Point Users Group. Function Point Counting
Practices Manual, Release 4.0. IFPUG Standards, 1994.
International Function Point Users Group. Guidelines to Software Measurement, Release
1.0, 1994. IFPUG Standards. Ishikawa K. Guide to Quality Control. Tokyo, Japan: Asian
Productivity Organization, 1976.
Ishikawa K., and D.J. Lu, trans. What is Total Quality Control? The Japanese Way, 1st ed.
Englewood Cliffs, NJ: Prentice Hall, 1988.
Jackson Michael. «Will There Ever Be Software Engineering?» IEEE Software, 15A):36-
39, 1998.
Jacobson Ivar. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-
Wesley Object Technology Series, 1994.
Jacobson Ivar, Grady Booch, and James Rumbaugh. The Unified Software Development
Process. Reading, MA: Addison-Wesley, 1999.

1090 Литература
Jacobson Ivar, et al. Object-oriented Software Engineering: A Use Case Driven Approach.
Reading, MA: Addison-Wesley, 1992.
Jazayeri A. Ran, and F. van der Linden. Software Architecture for Product Families. Reading,
MA: Addison-Wesley, 2000.
Jennerich Bill, foint Application Design: Business Requirements Analysis for Successful Re-
engineering. Berwyn, PA: Bluebird Enterprises, 1999.
Jensen Floward A., and K. Vairavan «An Experimental Study of Software Metrics for
Real-Time Software». IEEE Transactions on Software Engineering, SE-11B):231-234, 1985.
Jones Capers. «Measuring Programming Quality and Productivity». IBM SystemsJournal,
17A), 1978.
Jones Capers. Programming Productivity. NY: McGraw-Hill, 1986.
Jones Capers. Applied Software Measurement: Assuring Productivity and Quality, 2nd ed. NY:
McGraw-Hill, 1997.
Kafura Dennis. «A Survey of Software Metrics». Proceedings 1985 Annual Conference of the
ACM, Denver, CO, October 14-16, ACM Press, pp. 502-506,1985.
Kahler Taibi, and Hedges Capers. «The Miniscript». Transactional Analysis Journal,
4(l):27-42, 1974.
Kan Stephen H. Metrics and Models in Software Quality Engineering. Reading, MA: Addison-
Wesley, 1995.
Kaner Cem, et al. Testing Computer Software, 2nd ed. NY: Van Nostrand Reinhold, 1993.
Karolak Dale. Software Engineering Risk Management. Los Alamitos, CA: IEEE Computer
Society Press, 1996.
Karras Chester L. Give and Take: The Complete Guide to Negotiating Strategies and Tactics. NY:
HarperBusiness Publishers, 1993.
Katz Daniel, and Robert L. Kahn. The Social Psychology of Organizations, 2nd ed. NY:
Wiley. 1978.
Kearney Joseph K., et al. «Software Complexity Measurement». Communications of the
ACM, 29A1):1044-1050, 1986.
Keil Mark, and Erran Carmel. «Customer-Developer Links in Software Development».
Communications of ACM, 3S{5):33-44, 1995.
Keirsey David. Please Understand Me II: Temperament, Character, Intelligence. Del Mar, CA:
Prometheus Nemesis Book Company, 1998.
Keirsey David, and Marilyn Bates. Please Understand Me: Character and Temperament Types.
Del Mar, CA: Prometheus Nemesis Book Company, 1984.
Keirsey David, and Marilyn Bates. Please Understand Me, An Essay on Temperament Styles,
Amherst, NY: Prometheus Books, 1984. Kelvin W.T. Popular Lectures and Addresses, 1891-
1894.
Kemerer Chris F. «An Empirical Validation of Software Cost Estimation Models».
Communications of the ACM, 30E):416-429. New York: NY: Association for Computing
Machinery, 1987.
Kennedy Gavin. The New Negotiating Edge: The Behavioral Approach for Results and
Relationships. Sonoma, CA: Nicholas Brealey Publishing, 1998.
Kerzner Harold. Project Management: A Systems Approach to Planning Scheduling and
Controlling, 6th ed. NY: John Wiley & Sons, 1998.
King David. Project Management Made Simple: A Guide to Successful Management of Computer
Systems Pivjects. Englewood Cliffs, NJ: Yourdon Press, 1992.

Литература 1091
Kirchof Nicki S., and John R. Adams. «Conflict Management for Project Managers».
Principles of Project Management. Upper Darby, PA: Project Management Institute, 1982.
Kitchenham Barbara, and B. Littlewood, eds. Measurement for Software Control and
Assurance. NY: Elsevier Applied Science, 1989.
Kitchenham Barbara, and Shari Lawrence Pfleeger. «Software Quality: The Elusive
Target». IEEE Software, January, pp. 12-21, 1996.
Kitchenham Barbara, Shari Lawrence Pfleeger, and Norman Fenton. «Towards a
Framework for Software Measurement Validation». IEEE Transactions on Software
Engineering, 21A2):929-944, 1995.
Knight J.C, and E.A. Meyers. «An Improved Inspection Technique». Communications of
the ACM, 36A1):51-61,1993.
Koltzblatt Karen, and Hugh R. Beyer. «Requirements Gathering: The Human Factor».
Communications of the ACM, 38E):30-32, 1995.
Krasner Herb. «Teamwork Considerations for Superior Software Development».
Constructing Superior Software, 1st ed. Indianapolis, IN: Macmillan Technical Publishing, p.
180, 1999.
Krasner Herb. «Implementing Software Quality». Software Project Management Certificate
Program Sequence XI, Session 32. Software Quality Institute, The University of Texas at
Austin, 2001.
Kroeger Otto, and Janet Theusen. Talk Type at Work. NY: Delacorte Press, 1992.
Kruchten Philippe. «A Rational Process». CrossTalk, 9G):11-16, 1996.
Kruchten Philippe. The Rational Unified Process: An Introduction. Reading, MA: Addison-
Wesley, 2000.
Kummerowjean M., et al. Work Types. NY: Warner Books, 1997.
Lakshmanan K.B., S. Jayaprakash, and P.K. Sinha. «Properties of Control-Flow
Complexity Measures». IEEE Transactions cm Software Engineering, 17A2): 1289-1295, 1991.
Landsbaum Jerome В., and Robert L. Glass. Measuring and Motivating Maintenance
Programmers. Englewood Cliffs, NJ: Prentice-Hall, 1992.
Larman Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
Design. Reading, MA: Addison-Wesley, 1998.
Lavold Gary D. «Developing Using the Work Breakdown Structure». Project Management
Handbook, 2nd ed. NY: Van Nostrand Reinhold, 1998.
Leonard Nancy H., et al. «A Self Concept-Based Model of Work Motivation». Proceedings
ofthe Academy ofManagement Annual Meeting, Vancouver, B.C., Canada, 1995.
Leveson Nancy, and Clark S. Turner. «An Investigation of the Therac-25 Accidents».
IEEE Computer. 26G):18-11,1993.
Lewicki RovJ., et al. Think Before You Speak: The Complete Guide to Strategic Negotiation. NY:
John Wiley & Sons, 1996.
Lewicki Roy J., et al. Negotiation, 3rd ed. Boston, MA: Irwin/McGraw-Hill, 1999.
Lewin Kurt. Field Theory in Social Science: Selected Theoretical Papers. Westport, CT:
Greenwood Press, 1975.
Lewin Kurt. Resolving Social Conflicts; Field Theory in Social Science. Washington, DC:
American Psychological Association, 1997.
Lewis James P. Project Planning, Scfiediiling, and Control: A Hands-On Guide to Bringing
Projects in On Time and On Budget, rev ed. Chicago, IL: Irwin, 1995.
Lewis James P. Mastering Project Management: Applying Advanced Concepts of Systems
Thinking, Control and Evaluation, Resource Allocation. NY: McGraw-Hill, 1998.

1092 Литература
Lewis James P. Team-Based Project Management. NY: American Management Association,
1998.
Lewis James P. The Project Manager's Desk Reference: A Comprehensive Guide to Project
Planning, Scheduling, Evaluation, and Systems. NY: McGraw-Hill, 2000.
Lind Randy K., and K. Vairavan. «An Experimental Investigation of Software Metrics
and Their Relationship to Software Development Effort». IEEE Transactions on Sofiware
Engineering, 15E):649-653, 1989.
Lyu Michael R., ed. Handbook of Sofiware Reliability Engineering. NY: McGraw-Hill, 1996.
Maccoby Michael. Why Work: Leading the New Generation. NY: Simon and Schuster, 1988.
Maier David. The Theory of Relational Databases. Rockville, MD: Computer Science Press,
1983.
Manley John H. «CASE: Foundation for Software Factories». COMPCON Proceedings,
IEEE, September, pp. 84-91,1984.
Maples M.R, and C. Sieber. «Gestalt Theory». Counseling and Psychotlwrapy: Theories and
Interventions. Boston, MA: Merrill-Macmillan, 1998.
Marciniak John J., ed. Encyclopedia of Software Engineering. NY: John Wiley and Sons,
pp. 131-166, 1994.
Marick Brian. The Craft of Software Testing. Englewood Cliffs, NJ: Prentice Hall, 1995.
Marqulies Nancy. Mapping Inner Space: Learningand Teaching Mind Mapping. Tucson, AZ:
Zephyr Press, 1991.
Martin Charles C. Project Management: How to Make it Work Amacom, 1976.
Martin James. An End-User's Guide to Data Base. Englewood Cliffs, NJ: Prentice Hall,
1981.
Martin James. Computer Database Organization. Englewood Cliffs, NJ: Prentice Hall, 1982.
Martin James. Rapid Application Development, 1st ed. NY: Macmillan, 1991.
Martin James, and Carma McClure. Sofiware Maintenance: The Problem and Its Solution.
Englewood Cliffs, NJ: Prentice Hall, 1983.
Martin Roger J., and Wilma M. Osborne. «Guidance on Software Maintenance», NBS
Special Publication 500-106. National Institute of Standards and Technology, 1992.
Maslow Abraham H. The Farther Reaches of Human Nature. NY: Viking Press, 1971.
Maslow Abraham H. Toward a Psychology of Being, 3rd ed. NY: John Wiley & Sons, 1999.
Maslow Abraham Harold. Motivation and Personality, 1st ed. NY: Harper, 1954.
Maxwell John C. The 21 Indispensable Qualities of a Lender: Becoming tlie Person that People
Will Want to Follow. Nashville, TN: T. Nelson, 1999.
McCabe Т., and Charles W. Butler. «Design Complexity Measurement and Testing».
Communications of the ACM. 32A2):1415-1424, 1989.
McCabe Thomas J. «A Complexity Measure». IEEE Transactions on Software Engineering
SE-2D):308-320, 1976.
McCall James A., et al. «Metrics for Software Quality Evaluation and Prediction».
Proceedings of Second Summer Sofiware Engineering Workshop, Greenbelt, MD, September 19,
1977.
McCall John, et al. «Factors in Software Quality», NTIS AD-A049-014, 015, 055,
November, 1977.
McConnell Steve. Rapid Development: Taming Wild Software Schedules, 1st ed. Redmond,
WA: Microsoft Press, 1996.
McConnell Steve C. Code Complete: A Practical Handbook of Sofiware Construction. Redmond,
WA: Microsoft Press, 1993.

Литература 1093
McFarlan Warren F. «Portfolio Approach to Information Systems». Harvard Business
Review, January/February, pp. 142-150, 1974.
McFletcher Corporation. WorkStyle Patterns™ Inventory. Scottsdale, AZ, 1993.
McGregor Douglas. The Human Side of Enterprise. NY: McGraw-Hill. pp. 33-34, 1960.
McMenamin Stephen M., and John Palmer. Essential Systems Analysis. NY: Prentice Hall
Yourdon Press Computing Series, 1984.
Mellor Stephen J., and Paul T. Ward. Structured Development for Real-Time Systems:
Implementation Modeling Techniques. NY: Prentice Hall Yourdon Press Computing Series,
1989.
Mendonta Manoel G., and Victor R. Basili. «Validation of an Approach for Improving
Existing Measurement Frameworks». IEEE Transactions on Software Engineering, 26F):484-
499, 2000.
Meredith Jack R., and Samuel Mantel, Jr. Project Management: A Managerial Approach, 4th
ed. NY: Wiley, 2000.
Metzler Ken. Creative Interviewing: The Writer's Guide to Gathering Information by Asking
Questions. NY: Allyn & Bacon, Pearson Education, 1996.
Miller Ann. Engineering Quality Software: Defect Detection and Prevention. Reading, MA:
Addison-Wesley, Motorola University Press Six Sigma Research Institute Publications,
1992.
Miller George A. «The Magic Number Seven, Plus or Minus Two». Psychologicnl Review,
63:81-97, 1956.
Mills Harlan. «Software Development». IEEE Transactions on Software Engineering. SE-
2D):265-273, 1976.
Mills Harlan, et al. «Cleanroom Software Engineering». IEEE Software, 5E):19-24,1987.
Mintzberg Henry. Structures in Fives: Designing Effective Organizations. NY: Prentice-Hall,
p. 11, 1983.
Moder Joseph J., et al. Project Management with CPM, PERT, and Precedence Diagramming,
3rd ed. NY: Van Nostrand, 1983.
Moller K.H., and D.J. Paulish. Software Metrics: A Practitioner's Guide to improved Product
Development, 1st ed. NY: Chapman & Hall, 1993.
Mosley Daniel J. The Handbook of MIS Application Sofware Testing: Methods, Techniques, and
Tools for Assuring Quality through Testing. Englewood Cliffs, NJ: Prentice Hall, 1993.
Murray Mike. University of Texas Software Quality Institute Certificate Program,
Sequence XI, Session 22, 2000.
Musa John D. «Operational Profiles in Software Reliability Engineering». IEEE Software,
10B):14-32, 1993.
Musa John D. Software Reliability Engineering: More Reliable Software, Faster Development and
Testing. NY: McGraw-Hill, 1999.
Musa John D., et al. Software Reliability: Measurement, Prediction, Application. NY: McGraw-
Hill, 1987.
Myers Glenford J. The Art of Software Testing. NY: John Wiley & Sons, 1979.
Nassi I., and Ben Schneiderman. «Flowchart Techniques for Structured Programming».
SIG-PLAN Notices of the ACM, 8(8):12-26, 1973.
National Aeronautics and Space Administration. Software Formal Inspections Guidebook,
NASA-GB-A-302, Office of Safety and Mission Assurance, National Aeronautics and Space
Administration, 1993.

1094 Литература
Neumann Peter G. «On Hierarchical Design of Computer systems for Critical
Applications». IEEE Transactions on Software EngineeringSE-\2(9):905-920,1986.
Nielsen Jakob. Usability Engineering. Boston, MA: Academic Press, 1993.
Nielsen Jakob. «Usability Metrics: Tracking Interface Improvements». IEEE Software,
13F):12-13, 1996.
Nielsen Jakob, and Robert L. Mack, eds. Usability Inspection Methods. NY: John Wiley &
Sons. 1994.
Nierenberg Gerard I. The Art of Negotiating, 2nd ed. NY: Simon & Schuster, 1986.
Nierenberg Gerard I. Fundamentals of Negotiating. NY: Perennial Library, 1987.
Nierenberg Gerard I. The Complete Negotiator. NY: Berkley Books, 1991.
Norden Peter V. «Curve Fitting for a Model of Applied Research and Development
Scheduling». IBMfournal of Research and Development, 2C), 1958.
O'Brien James J. Scheduling Handbook. NY: McGraw-Hill, 1969.
OlTen Raymond J., and Ross Jeffery. «Establishing Software Measurement Programs».
IEEE Software, 14B):45-53, 1997.
Offutt A. Jefferson. «Investigations of the Software Testing Coupling Effect». ACM
Transactions on Software Engineering and Methodology, 1A), 1992.
Ogren Ingmar. «Requirements Management as a Matter of Communication». CrossTalk,
The journal of Defense Software Engineering, 13D), 2000.
O'Neill Don. «Setting Up a Software Inspection Program». CrossTalk, The Journal of
Defense Software Engineering, 10B), 1997.
Osborn Alex F. Applied Imagination. Buffalo, NY: Creative Education Foundation, 1983.
Ouichi William G., and Alfred M.Jaeger. «Type Z Organization: Stability in the Midst of
Mobility». Academy of ManagementRetnew, 3B):159-168, 1978.
Oviedo Enrique I. «Control Flow, Data Flow and Programmers Complexity». Proceedings
ofCOMPSAC80, Chicago IL. pp. 146-152,1980.
Page-Jones Meilir. The Practical Guide to Structured Systems Design, 2nd ed. Englewood
Cliffs. NJ: Prentice Hall, 1988.
Pall Gabriel A. Quality Process Management. Englewood Cliffs, NJ: Prentice-Hall, 1987.
Palmer Helen. The Enneagram, Understanding Yourself and the Others in Your Life. San
Francisco, CA: Harper, 1991.
Park Robert, E. «Software Size Measurement: A Framework for Counting Source
Statements». Software Engineering Institute Technical Report SEI-92-TR-020. Pittsburg, PA: SEI,
Carnegie Mellon University, 1992.
Parnas David L. «On the Criteria to be Used on Decomposing Systems into Modules».'
Communications of the ACM, 12A2):1053-1058, 1972.
Patel Sukesh, William Chu, and Rich Baxter. «A Measure for Composite Module
Cohesion». Proceedings of the 14th International Conference on Software Engineering, Melbourne,
Australia, pp. 38-48. NY: Association for Computing Machinery, 1992.
Paulk Mark C. «A Comparison of ISO 9001 and the Capability Maturity Model for
Software», Technical Report # CMU/SEI-94-TR-012. Software Engineering Institute, Carnegie
Mellon University, 1994.
Paulk Mark C, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis. The Capability
Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley SEI
Series in Software Engineering, 1994.

Литература 1095
Perlis Alan. Frederick Sayward, and Mary Shaw, eds. Software Metrics: An Analysis and
Evaluation. Cambridge, MA: MIT Press, 1981.
Perry William E. Howto Test Software Packages. NY: John Wiley & Sons, 1986.
Pfleeger Shari Lawrence. «Use Realistic, Effective Software Measurement». Constructing
Superior Software. Indianapolis, IN: Macmillan Technical Publishing, 2000.
Pfleeger Shari Lawrence, and J.C. Fitzgerald. «Software Metrics Tool Kit». Support for
Selection. Collection and Analysis. Information and Software Technology, 33G):477-482, 1991.
Pfleeger Shari Lawrence, Les Hatton, and Charles C. Howell. Solid Software. Upper
Saddle River, NJ: Prentice Hall, 2002.
Pfleeger Shari Lawrence, Ross Jeffery, Bill Curtis, and Barbara Kitchenham. «Status
Report on Software Measurement». IEEE Software, 14B):33-43,1997.
Pheatt Chuck. Computer Science CS 444. Emporia State University, Emporia, KS, 2000.
Plavie Greg, and Charles Schroeder. «Software Requirements Elicitation: Problems,
Tools, and Techniques». CrossTalk, Thefournal of Defense Software Engineering, 9A2), 1996.
Pisek Paul E. Creativity, Innovation, and Quality. NY: McGraw-Hill, 1997.
PMI Standards Committee, William R. Duncan, Director of Standards. A Guide to the
Project Management Body of Knowledge. Newtown Square, PA: Project Management Institute,
1996.
Porter A.A., et al. «An Experiment to Assess the Cost-Benefits of Code Inspection in
Large Scale Software Development». IEEE Transactions of Software Engineering, 23F):329-346,
1997.
Pratt Philip J., and Joe Adamski. Concepts of Database Management, 3rd ed. Boston, MA:
Course Technology, 2000.
Pressman Roger S. Software Engineering: A Practitioner's Approach, 5th ed. Boston, MA:
Course Technology, 2001.
McGraw-Hill. Pritchard Carl. Risk Management. Arlington, VA: ESI International, 1997.
Project Management Institute. A Guide to the Project Management Body of Knowledge. Sylva,
NC: PMI Publication Division, 1996.
Putnam Lawrence H. «A General Empirical Solution to the Macro Software Sizing and
Estimating Problem». IEEE Transactions of Sofiware Engineering, SE-4 D):345-361, 1978.
Putnam Lawrence H., and Ware Myers. Measures for Excellence: Reliable Software on Time,
within Budget. Englewood Cliffs, NJ: Yourdon Press, 1992.
Radice R.A., et al. «A Programming Process Study». IBM Systems Journal, 24B):91-101,
1985.
Rae A.K., et al., eds. Software Evaluation/or Certification: Principles, Practice and Legal
Liability. NY: McGraw-Hill, 1995.
Retting, Marc. «Five Rules of Data Normalization». Poster for Database Programming &
Design. San Francisco, CA: Miller Freeman Publications, 1992.
Richter Charles. Designing Flexible Object-Oriented Si/steins with UML. Indianapolis, IN:
Mac-millan Technical Publishing, 1999.
Rifkin Stan. «What Makes Measuring Software So Hard?» IEEE Software, 18C):4l-15,
2001.
Rising Linda, and Callis Frank W. «Problems with Determining Package Cohesion and
Coupling». Software Practice and Experience, 22G):553-571, 1992.
Rob Peter, and Carlos Coronel. Database Systems: Design, Implementation, and Management,
4th ed. Cambridge, MA: Course Technology, 1999.

1096 Литература
Rothwell J. Dan. In Mixed Company: Small Group Communication, 4th ed. Fort Worth, TX:
Harcourt College Publishers, 2001.
Royce W.W. «Managing the Development of Large Software Systems: Concepts and
Techniques». Proceedings WESCON, Los Alamitos, CA, August, 1970.
Rovce Walker Jr. Software Project Management, a Unified Framework. Reading, MA: Addison-
Wesley, 1998.
Rover Thomas C. Software Testing Management: Life on the Critical Path. Englewood Cliffs,
NJ: Prentice Hall, 1993.
Rumbaugh James. «Getting Started: Using Use Cases to Capture Requirements», fournal
of Object Oriented Programming, September, 1994.
Rumbaugh James, et al. Object-oriented Modeling and Design. Englewood Cliffs, NJ:
Prentice Hall, 1991.
Sawyer Pete, Ian Sommerville, and Stephen Viller. «Capturing the Benefits of
Requirements Engineering». IEEE Software, 16B):78-85, 1999.
Schach Stephen R. Classical and Object-oriented Software Engineering: With UML and Java, 4th
ed. NY: McGraw-Hill, 1999.
Schein Edgar H. Organizational Psychology, 3rd ed. Englewood Cliffs, NJ: Prentice-Hall,
1980. Schein Edgar H. Organizational Culture and Leadership, 2nd ed. San Francisco, CA:
Jossey-Bass, 1992.
Schneidewind Norman F. «Setting Maintenance Quality Objectives and Prioritizing
Maintenance Work by Using Quality Metrics». Proceedings of the Conference on Software
Maintenance (CSM91), October, 1991.
Schneidewind Norman F. «Software Metrics Model for Quality Control». Proceedings of
the 4th International Software Metrics Symposium (Metrics '97), Albuquerque, NM, 1997.
Schneidewind Norman F. «Measuring and Evaluating Maintenance Process Using
Reliability, Risk, and Test Metrics». IEEE Transactions on Software Engineering, 25F):769-781,
1999.
Schutz William. The Interpersonal Underworld. Palo Alto, CA: Science and Behavior Books,
1996.
Shafer L., and John Connell. «Deriving Metrics for Relating Complexity Measures to
Software Maintenance Costs». Proceedings of the 1982 Computer Measurement Group International
Conference, pp. 134-141, 1982.
Shepperd Martin, and Darrel Ince. Derivation and Validation of Software Metrics. NY:
Oxford University Press, 1993.
Shepperd Martin, ed. Software Engineering Metrics - Volume I: Measures and Validations. NY:
McGraw Hill, International Series in Software Engineering, 1993.
Shewhart Walter A., and W. Edwards Deming. Statistical Method from the Viewpoint of
Quality Control, 1st ed. NY: Dover Pubs, 1986.
Shiaer Sally, and Stephen Mellor. Object-Oriented Systems Analysis: Modeling the World in
Data. NY: Prentice Hall Yourdon Press Computing Series, 1988.
Shneiderman Ben. Designing the User Interface: Strategies for Effective Human-Computer
Interaction. Reading, MA: Addison-Wesley, 1997.
Shooman Martin L. Software Engineering Design, Reliability, and Management. NY: McGraw-
Hill, 1983.
Sommerville Ian. Software Engineering 6th ed. NY: Addison Wesley, 2000.
Sommerville Ian, and Gerald Kotonya. Requirements Engineering: Processes and Techniques.
NY: John Wiley & Sons, 1997.

Литература 1097
Stevens W.P, Glenford J. Myers, and Larry L. Constantine. «Structured Design». IBM
Systems journal, No. 2, pp. 115-139,1974.
Strehio Kevin. «Catching Up with the Joneses and 'Requirement' Creep». InfoWorld, July
29, 1996.
Stuckenbruck Linn C, and David Marshall «Team Building for Project Managers». The
Principles of Project Management: Collected Handbooks from the Project Management Institute. Sylva,
NC: PMI Publication Division, 1985.
Stuckenbruck Linn C, ed. The Implementation of Project Management: The Professional's
Handbook. Drexel Hill, PA: Project Management Institute, 1981.
Stutzke Richard D. Software Estimation: Projects, Products, Processes. Reading, MA: Addison-
Wesley, 2001.
Symons Charles R. «Function Point Analysis: Difficulties and Improvements». IEEE
Transactions on Software Engineering, 14A):2,1988.
Taylor David A. Object-oriented Technology: A Manager's Guide. Reading, MA: Addison-
Wesley, 1990.
Taylor David A. Object-oriented Information Systems: Planning and Implementation. NY: John
Wiley & Sons, 1992.
Tervonen likka. «Support for Quality-Based Design and Inspection». IEEE Software,
13(l):44-54, 1996.
Thayer Richard H., ed. Software Engineering Project Management. Los Alamitos, CA: IEEE
Computer Society Press, 1997.
Thayer Richard H., Merlin Dorfman, and Sidney C. Bailin, eds. Software Requirements
Engineering, 2nd ed. Los Alamitos, CA: IEEE Computer Society Press, 1997.
Tieger Paul D., and Barbara Barron-Tieger. Do What You Are: Discover the Perfect Career for
You Through the Secrets of Personality Type, 2nd ed. Boston, MA: Little, Brown, 1995.
Tomayko James E. Support Materials for Software Configuration Management. SEI-SM-4-1.0,
Carnegie Mellon University, Software Engineering Institute, 1986.
Tuckman Bruce W. «Developmental Sequence in Small Groups». Psychological Bulletin,
63:384-399,1965.
Tufte Edward. The Visual Display of Quantitative Information. Cheshire, CT: Graphics
Press, 1983.
Tufte Edward. Envisioning Information. Cheshire, CT: Graphics Press, 1990.
Tufte Edward. Visual Explanations: Images and Qualities, Evidence and Narrative. Cheshire,
CT: Graphics Press, 1997.
Ullman Jeffrey. Principles of Database Systems. Rockville, MD: Computer Science Press.
Ury, William A993). Getting Past No. NY: Bantam Books, 1982.
U.S. Department of Defense. Engineering Changes, Deviations and Waivers, MILSTD-480.
Washington, DC: U.S. Government Printing Office, 1986.
U.S. Department of Defense. Configuration Management Practices for Systems, Equipment,
Munitions, and Computer Programs, MIL-STD-483A. Washington, DC: U.S. Government
Printing Office, 1986.
U.S. Department of Defense. Military Standard for Configuration Management, MIL-STD-
973. Washington, DC: U.S. Government Printing Office, 1989.
van Solingen Rini, and Egon Berghout. The Coal/Question/Metric Method: A Practical
Guide for Quality Improvement of Software Development. NY: McGraw-Hill, 1999.
Verma Vijay K. Managing the Project Team: the Human Aspects of Project Management. Upper
Darbv, PA: Project Management Institute, 1996.

1098 Литература
Verma Vijay K. The Human Aspects of Project Management. Upper Darby, PA: Project
Management Institute, 1997.
Voas Jeffrey M., and Gary McGraw. Software Fault Injection: Innoculating Programs Against
Errors. NY: Wiley, 1998.
Von Mayrhaiiser, Anneliese. Software Engineering: Methods and Management. Boston, MA:
Academic Press, 1990.
Vroom Victor. Work and Motivation. NY: Wiley, Jossey-Bass Management Series, 1994.
Wnlston C.E., and C.P. Felix. «A Method of Programming Measurement and
Estimation». IBM Systemsfournal, 16(l):54-73, 1977.
Walters Stan B. Principles of Kinesic Interview and Interrogation. Boca Raton, EL: CRC Press,
1995.
Ward Paul Т., and Stephen J. Mellor. Structured Development for Real-Time Systems: Essential
Modeling Techniques. NY: Prentice Hall Yourdon Press Computing Series, 1986.
Warner Paul. «How to Use the Work-Breakdown Structure». Field Guide to Project
Management. NY: John Wiley & Sons, 1998.
Wasserman Anthony I. «Rapid Prototyping of Interactive Information Systems». Software
Engineering Notes, 7E):171-180, 1982. Wasserman Anthony I. «Toward a Discipline of
Software Engineering». IEEE Software, 13F), 1996.
Watson Arthur H., and Thomas J. McCabe. «Structured Testing: A Testing
Methodology Using the Cyclomatic Complexity Metric». National Institute of Standards and
Technology Special Publication 500-235. Gaithersburg, MD: NIST, 1996.
Webster's College Dictionary. NY: Random House, 1992.
Webster's Dictionary of the English Language. NY: Lexicon Publications, 1997.
Weinberg Gerald M. The Psychology of Computer Programming. NY: Van Nostrand
Reiuhold, 1971.
Weinberg Gerald M. Quality Software Management, Vol. t, Systems Thinking. NY: Dorset
House, 1992.
Weinberg Gerald M. Quality Software Management, Vol. 4, Anticipating Change. NY: Dorset
House, 1997.
Weller E.F. «Lessons Learned from Two Years of Inspection Data». IEEE Software,
]<>E):38-45, 1993.
Wheeler David A., Bill Brykczynski, and Reginald N. Meeson, Jr., eds. Software Inspection,
An Industry Best Practice. NY: IEEE Computer Society Press, 1996.
Wiegers Karl E. «Writing Good Requirements». Software Development, May, 1999.
Wiegers Karl E. Software Requirements. Redmond, WA: Microsoft Press, 1999.
Wiklund Michael E., ed. Usability in Practice: How Companies Develop User-Friendly Products.
Boston, MA: Academic Press, 1994.
Wing Janet M. «A Specifier's Introduction to Formal Methods». Computer, 23(9):8-24,
1990.
Wiorkowski Gabrielle, and David Kull. DB2: Design and Development Guide, 3rd ed.
Reading, MA: Addison-Wesley, 1992.
Wirfs-Brock4Rebecca, et al. Designing Object-Oriented Software. NY: Prentice Hall, 1990.
Wirth Nicholas. «Program Development by Stepwise Refinement». Communications of the
ACM, 14D):221-227, 1971.
Wohlin Claes, and Per Runeson. «Certification of Software Components». IEEE
Transactions on Software Engineering SE-20F):494-499, 1994.

Литература 1099
Wood Jane, and Denise Silver. Joint Application Design: How to Design Quality Systems in
40% Less Time. NY: John Wiley & Sons, 1989.
Woodcock Mike, and David Francis. Organization Development Through Team Building:
Planninga Cost Effective Strategy. NY: Wiley, p. 3, 1981.
Woolf Bob. Friendly Persuasion: My Life as a Negotiator. NY: Putnam, 1990.
Wycoff Joyce. Mindmapping: Your Personal Guide to Exploring Creativity and Problem-Solving.
NY: Berkley Books, 1991.
Wyllys R.E. «Overview of Normalization: Introduction». US 384K.11, Database-
Management Principles and Applications. The University of Texas at Austin Graduate School of
Library and Information Science, 2001.
Yamaura Tsuneo. «How to Design Practical Test Cases». IEEE Software, 15F):30-36,
1998.
Yoder Cornelia M., and Marilyn L. Schrag. «Nassi-Schneiderman Charts: An Alternative
to Flowcharts for Design». White Paper, IBM Corporation, System Products Division,
Endicott, NY, 1983.
Yourdon Edward. Classics in Software Engineering. NY: Yourdon Press, 1979.
Yourdon Edward. Managing the System Life Cycle, 2nd ed. Englewood Cliffs, NJ: Yourdon
Press, 1988.
Yourdon Edward. Modem Structured Analysis. NY: Prentice Hall Yourdon Press
Computing Series, 1989.
Yourdon Edward. Object-oriented Systems Design: An Integrated Approach. Englewood Cliffs,
NJ: Yourdon Press, 1994.
Yourdon Edward. «Metrics for Death-March Projects». Proceedings of Symposium: Eighth
International Conference on Applications of Software Measurement, Atlanta, GA, October, 1997.
Yourdon Edward. Death March: the Complete Software Developer's Guide to Surviving Mission
Impossible Projects. Upper Saddle River, NJ: Prentice Hall PTR, 1997.
Yourdon Edward, and Larry L. Constantine. Structured Design: Fundamentals of a Discipline
of Computer Program and Systems Design. Englewood Cliffs, NJ: Prentice Hall Yourdon Press
Computing Series, 1979.
Yuki Gary. Leadership in Organizations, 5th ed. Upper Saddle River, NJ: Prentice Hall,
2001.
Томас Конноли, Каролин Бегг. Базы данных — проектирование, реализация и
сопровождение. Теория и практика. 2-е изд. Вильяме, 2000.
Дополнительные сведения в Internet
Анализ и разработка проектов
fiat. gslis .utexas. edu/~1384kllw/rw38411 .html. R.E. Wyllys. «Overview of
Normalization». Database-Management Principles and Applications, LIS 384K. The University of
Texas at Austin, Graduate School of Library and Information Science, 2001.
ola.aacc. cc.md. us/csil22/norm/datanorm.html. KariSiner. Personal Computer
Database Management System with Microsoft Access 2000, CSI 122. Anne Arundel
Community College, Arnold, MD, 2001.
stein.cslil.org/genome_informatics/sqll/lecture_notes.html. Robert
Peitzsch. SQL and Relational Database Section, Genomic Informatics Class, CSHL.
Stein Laboratory, Cold Spring Harbor Laboratory, Cold Spring Harbor, NY, Genome
Informatics, 1999.

1100 Литература
www.baldwinw.edu/~gbouw/courses/csc280/puppy.html. Gerardus Bouw.
Department of Math and Computer Science, CSC 280. Baldwin-Wallace College, Berea,
OH, 2001.
www.omg.org. Object Management Group (OMG). Unified Modeling Language
(UML) Specification, Version 1.3, 2000.
www.open.org/~prslkg/sy_chap.htm. Paul R. Seesing and ARMA International.
«Basic Systems Analysis Tools for Computer Users», 1993.
www. oracle. com/. Компания Oracle Corporation.
www. ra t iona 1. com/index. jsp. Компания Rational Software.
www. sex.cmu.edu/architecture/definitions.html. Software Engineering
Institute. «How Do You Define Software Architecture?», 2001.
www. software.org/pub/darpa/darpa.html. Richard DeSantis, «Evolutionary
Rapid Development», Software Productivity Consortium.
tww.support.lotus.com/simso2d.nsf/. Lotus Customer Support Technote.
«The Five Rules of Database Normalization». Number 127782,1998.
www. Sybase. com/. База данных Sybase.
www. zoo. со. uk/"z0001039/PracCuides/pg_use_cases.htm. Edward Kenworthy,
«Use Cases».
www-4. ibm. com/software/data/db2/udb/. DB2 Universal Database.
Создание пооперационного перечня работ
stsc.hill. a f .mil/cross talk/1996/apr/project, asp. Lynn Satterthwaite.
«Project Management: Some Lessons Learned — April 1996». Software Technology Support
«enter, 1996.
vara tek. com/howtowbsO. html. «Work Breakdown Structure Development: How To
О eate A Project Work Breakdown Structure (WBS)». Varatek Software, Inc.
www. 4pm. com/art icles/wbs. html. «Work Breakdown Structure: Important Project
Design Issue or Clerical Task?»
www.acq.osd.mil/pm/newpolicy/wbs/wbs.html. «Work Breakdown Structures
(WBS) for Defense Material Items», MIL-HDBK-881.
www.pmi. org/publictn/pmboktoc. htm. PMl's A Guide to the Project Management
Body of Knowledge (PMBOK* Guide), Chapter 6.
www.pmi. org/standards/wbspractice.htm. Cindy Berg and Kim Colenso. «Work
Breakdown Structure Practice Standard Project — WBS vs. Activities». PM Network, 2000.
www.worldbank.org/worldlinks/english/training/world/webproj/define/
developZdevelop2.htm. «Building a Collaborative Web Project». World Links for
Development Program (WorLD) Training Materials.
Модель зрелости возможностей и непрерывное
совершенствование процесса разработки
www. sei. cmu.edu/. Институт программного инжиниринга (SEI).
www.sei.emu.edu/activities/str/indexes/glossary/. Словарь терминов
института SEI.
www.qualitydigest.com/mar01/html/ci.html. Craig Cochran. «Two Hidden
Gems of Continual Improvement» — Выполнив несколько основных действий, вы
сможете внедрить долговременные усовершенствования в вашей организации.

Литература 1101
www.gualitydigest.com/may99/html/ci.html. Lee С. Bravener. «The Road to
Continuous Improvement».
www.qualitydigest.com/jul/contimp.htmHfanchorll2080. J. Chris White.
«Reengineering and Continuous Improvement, in a complex system, relations dominate
and primarily determine the success of the system».
Менеджмент конфигурации
cm-solutions.com/cms/tools/application_developmcnt/joint_
application_design-jad.htm. Management Consulting & Information Technology
Solutions, JAD.
sourceforge.net/SourceForge. Бесплатная услуга для разработчиков Open
Source, обеспечивающая легкий доступ к наилучшим, что имеются в CVS, спискам
рассылки, методам отслеживания ошибок, управления задачами, доскам
объявлений/форумам, хостингу узлов, постоянной архивации файлов, полному
резервированию и общему web-администрированию.
www. cmtoday. com/yp/configuration_management.html. «Желтые страницы»
для вопросов менеджмента конфигурации.
www.mks.com/products/scm/si/2134.htm. Robert Bamford and William J.
Deibler II. «Configuration Management and ISO 9001. « Software Systems Quality
Consulting.
www. sei. cmu.edu/legacy/scm/. Назначение этого ресурса заключается в
обеспечении совместного использования результатов исследования менеджмента
конфигурации, выполненных Институтом SEI между 1988 и 1994 годами, и указание других
полезных источников информации по менеджменту конфигурации ПО.
www. sei. emu. ed4/legacy/scm/papers/CM_Plans/CMPIans.MasterToC.html.
Документ о значении плана менедмжента конфигурации (СМ) для формирования
результатов неформальной дискуссии, в ходе которой демонстрируется применение
СМ-планов, а также выполняется оценка трех СМ-стандартов.
www. sei. emu. edu/legacy/scm/scmDocSummary. html. Сводка по доступным
документам, имеющим отношение к менеджменту конфигурации.
Оценка затрат и трудозатрат
courses .cs.vt. edu/~cs3604/lib/Therac_25/Therac_l. html. Nancy Leveson
and Clark S. Turner. «An Investigation of the Therac-25 Accidents». IEEE Computer,
26G):18-41.
if pug. org. Международная группа пользователей метода функциональных точек
(IFPUG).
ourworld. compuserve. com/homepages/softcomp/fpfaq.htm. Часто
задаваемые вопросы (и ответы на них), имеющие отношение к анализу по методу
функциональных точек, by Software Composition Technologies, Inc., 1996-1997.
sern. ucalgary. ca/courses/seng/621/W98/johnsonk/cost.htm#SLIM.
University of Calgary.
www. cpsc. ucalgary. ca/~hongd/SENG/621/report2.html#2. 6.5. Danfeng Hong.
«Software Cost Estimation». Department of Computer Science, University of Canada,
Alberta, Canada.
www.dacs.dtic.mil/'databases/url/key.hts?keycode=4: 7&is lowerlevel=l.
The Data &: Analysis Center for Software (DACS) is a Department of Defense (DoD),

1102 Литература
Information Analysis Center (IAC). Оценка затрат: анализ по методу функциональных
точек.
www .jsc.nasa.go v/bu2/PCEHHTML/pceh .htm. Parametric Cost Estimating
Handbook.
www.pricesystems.com/prices.htm. Инструмент оценивания PRICE-S от
компании PRICE Systems.
www. gpmg. com/fp-intro.htm. Roger Heller. «An Introduction to Function Points».
Q/P Management Group, Inc.
www.qsm.com/products.html. Инструмент оценивания SLIM от компании
Quantitative Software Management.
iuww.rcinc.com/. Resource Calculations, Inc. Инструменты оценивания размеров
и моделирования затрат, включая ASSET-R, SSM, SOFTCOST-R.
www. sciam. com/1998/1298issue/1298jones.html#further. Capers Jones.
«Sizing Up Software: Unlike oil, steel or paper, software is an intangible commodity».
www. sepo. nose .mil/ revic. html. Инструмент оценивания REVIC.
www. SoftstarSystems. com/. Компания Softstar Systems предлагает инстурмент
Costar (автоматизированная реализация метода СОСОМО).
www. stsc.hill, af.mil/crosstalk/. Оценки ПО: проблемы и исследования.
www. sunset, use. edu/cocomol2. 0/cocomo.html. Инструмент оценивания
СОСОМО.
www.wwk.com/coolsoft.html. Количественный инструмент COOLSoft™,
применяемый при оценке затрат на разработку ПО.
Вопросы лидерства
www. typvworks. com/leadersh .htm. Дискуссия о модели лидерства MBTI.
Управление субподрядчиками, интеллектуальная
собственность и другие юридические вопросы
palinipsest.stanford.edu/bytopic/intprop/crews.html. Kenneth D.
Cnvvs. «Copyright Law, Libraries, and Universities: Overview, Recent Developments, and
Future Issues». Рабочие документы, представленные Ассоциации исследовательских
библиотек (Association of Research Libraries), 1992.
www4111egalinfo. com/. Этот узел призван оказывать правовую помощью в
любой ситуации.
www. abanet. org/. Американская ассоциация адвокатов.
www. adr.org/. Амерканская ассоцация арбитража может разрешать целый ряд
вопросов с помощью посредничества, арбитража, выборов и других подобных процедур.
www.ed.gov/databases/ERIC_Digests/ed381177.html. Janis H. Bruwelheide.
«Copyright Issues for the Electronic Age». ERIC Digest # ED381177. Syracuse, NY: ERIC
Clearinghouse on Information and Technology, 1995.
www.findlaw.com/. FindLaw. Web-портал, предназначенный для размещения
информации по правовым вопросам. Пользователи смогут получить доступ к
исчерпывающей и быстро растущей интерактивной библиотеке правовых ресурсов,
предназначенной для профессиональных юристов, заказчиков и бизнесменов.
www. ilrg. com/. Internet Legal Resource Guide™.

Литература 1103
www.ldrc.com/cyber6.html. Samuel Fifer and Chad J. Doellinger. Annotated
Bibliography of Materials Concerning First Amendment and Intellectual Property Internet
Law Issues».
www.mycounsel. com/. Узел MyCounsel.com предлагает руководство, участие в
составлении которого принимают ведущие юристы страны.
www. nolo, com/index. html. Web-узел Nolo Press: материалы, призванные оказать
правовую помощь людям при разрешении их посведневных вопросов.
www.richmond.edu/jolt/v2il/caden_lucas.html. Marc L. Caden and
Stephanie E. Lucas. «Comment, Accidents On the Information Superhighway: On-Line
Liability And Regulation». 2 RICH. J.L. & TECH. 3,1996.
www.usdoj.gov/crt/ada/cguide.htm. Американский департамент юстиции.
«A Cuide to Disability Rights Laws».
Формы и шаблоны
dijest.editthispage.com/stories/storyReader$91. Коллекция форм и
шаблонов Фила Вольфа (Phil Wolff).
web.mit.edu/entforum/www/Busmess_Plans/bplans.html. «MIT Enterprise
Forum's Business Plan Resource Guide». Это руководство представляет собой перечень
ресурсов, которые целиком или частично предназначены для помощи в составлении
бизнес-планов.
www.atlsysguild.com/GiuldSite/Robs/Template.html. Шаблон
спецификации требований, применяемый в качестве основы для выработки спецификаций.
Www. bplans. com/dp/. Описание разработки бизнес-плана.
www. eco finance. net/bptemplateOl .html. New Ventures Investor Forum.
«Writing your Business Plan».
www.newgrange.org/. New Grange Center for Project Management, tools and
templates sharing. Некоммерческая организация профессионалов, которые
пропагандируют практический подход к менеджменту проектов. Поддерживает рассылку
новостей по электронной почте и службу дискуссий.
www.planvare.org/bizplan.htm. Официальный документ: «Writing a Business
Plan».
www. sb. gov.be. ca/smallbus/workshop/sample, html. URL-ссылка на образец
бизнес-плана.
www.sba . gov/starting/indexbusplans.html. «The Business Plan, Road Map to
Success». Руководство и самонастраивающиеся действия.
Общие вопросы
bcentral. coni/resource/articles/bizplans/101 .asp. C.E. Yandle. «How to
write a business plan». Microsoft bCentral Business Plans.
dictionary.Cambridge.org/. ©Cambridge University Press, 2000.
dictionary, com/. Узел Dictionary.com, интерактивный английский словарь.
lifelong, engr. utexas.edu/sqi/index. cfm. Институт качества программ.
search.kachinatech.com/index.shtml. Набор архивов SAL (Scientific
Applications on Linux) представляет собой коллекцию данных и ссылок на ПО, которое
может представлять интерес для ученых и инженеров.
steaIthis.athensgroup.com/presentations/. Athens Group, Inc. «The
Business Case and Methodology for Performance Management», 2001.

1104 Литература
stsc.hill.af.mil/. Software Technology Support Center (STSC) of United States
Air Force (USAF). «Guidelines for Successful Acquisition and Management of Software-
Intensive Systems». CrossTalk, The Journal of Defense Software Engineering.
web.mit.edu/icrmot/. Школа Sloan School организовала международный центр
International Center for Research on the Management of Technology.
www. a cni. org. Association for Computing Machinery.
www.acg-ref.navy.mil/turbo2/index_ie.html. Хранилище информации
Turbo Streamliner включает описание основных терминов, принципов, наилучших
методик, учебных курсов, примеров оформления контрактов и ссылок на
соответствующие Web-узлы.
www. asg.org/standcert/certification/csge.htmicsgebok. Информация
CSQE BOK.
www.best, com/-wilson/fag/. Список частозаваемых вопросов
alt.folklore.computers A998).
www.bjmath.com/bjmath/least/curve.htm. Richard Reid. «Curve Fitting».
(Reference «Schaums Outline Series: Theory and problems of Probability and Statistics» by
Murray R. Spiegal, Ph.D.).
www. computer, org/. IEEE Computer Society.
www. esi.es/. European Software Institute.
www.geraldmweinberg.com. Страница Геральда М. Вайнберга (Gerald M.
Weinberg).
www. geraldmweinberg. com/shape, html. Форум SHAPE (ПО в качестве
эффективной человеческой деятельности).
www.m-w. com/cgi-bin/dictionary. NY: Random House.
www.m-w. com/netdict. htm. Merriam-Webster's WWWebster Dictionary.
www. seas. smu. edu/disted/ sys/ r .html. Southern Methodist University School of
Engineering Systems Engineering Resource Sites.
www. soft wa re. org. Software Productivity Consortium.
www. spc. ca/. Software Productivity Centre.
Взаимодействие и общение
type logic, com/. Инофрмация о типах MBTI.
www.cba.uri.edu/Scholl/Notes/Conflict.htm. Richard W. Scholl. «Conflict
Resolution». Учебные заметки для студентов по менеджменту, организационному
поведению, отношениям в рабочем коллективе и человеским ресурсам, школа
менеджмента. Университет острова Род (Rhode), 2001.
www.cba.uri.edu/Scholl/Notes/Equity.html. Richard W. Scholl. «Primer on
Equity». Учебные заметки для студентов по менеджменту, организационному
поведению, отношениям в рабочем коллективе и человеским ресурсам, школа менеджмента,
университет острова Род (Rhode), 2001.
www.cba.uri.edu/Scholl/Notes/Motivation_Expectancy.html. Richard W.
Scholl. «Expectancy Theory». Учебные заметки для студентов по менеджменту,
организационному поведению, отношениям в рабочем коллективе и человеским ресурсам,
школа менеджмента. Университет острова Род (Rhode), 2001.
www. cba. uri.edu/Scholl/Papers/Self_Concept_Motivation.HTM. Nancy H.
Leonard, etal. «ASelf Concept-Based Model of Work Motivation». Proceedings of the
Academy of Management Annual Meeting, Vancouver, B.C., 1995.

Литература 1105
www. humanmetrics. com/cgi-win/JungType.htm. Сокращенный тест MBTI.
www. keirsey. com/. Сокращенный тест темпераментов Кейси (Keirsey
Temperament Sorter).
www.ndu.edu/ ins s/books/strategic/ptlch5 .htm. «Chapter 5: Framing
Perspectives». Strategic Leadership and Decision Making. Washington, DC: National
Delense University.
www. persona 1 i typa ge. com/info .html. Информация о типах личностей.
www. personalitytype .com/. Барбара Бэррон-Тайгер (Barbara Barron-Tieger)
и Поль Тайгер (Paul Tieger), авторы четырех книг по типам личностей.
Основные выводы
/.-!:'"о. nrel. gov/esh/manual/esh-27. shtml. Программа NREL Lessons Learned
1'гоцгат.
st andisligroup. com/visitor/chaos. htm. Standish Group, Chaos Report.
www. 4pm.com/articks/pmtalk8-2-00.pdf. «Post-Project Reviews: Lessons Never
learned. Project Manager's Control Tower». PMTalk Newsletter.
www. ima .umn.edu/~arnold/455. f96/disasters.html. Две катастрофы,
происшедшие из-за вычислительных ошибок.
www. lanl .gov/orgs/ism/lessons .html. Los Alamos / DOE Lessons Learned.
Изложенные здесь интересные сведения представляют собой нечто большее, чем
анализ деятельности но совпровождению проекта. Авторы выражают благодарность
издатели) за курс Effective Lessons Learned Sharing.
www.nytimes.com/2001/05/20/business/20EXAM.html. Diana B. Henriques
and Jacques Steinberg. «Right Answer, Wrong Score: Test Flaws Take Toll». New York
Times Online, 2001.
www.salon.com/tech/feature/2000/12/06/bad_computers/index.html.
СЬеп'Н Aimee Barron. «High tech's missionaries of sloppiness. Computer companies
specialize in giving consumers lousy products—it's the American way of techno-capitalism».
SaIou.com, 2001.
www. sei . emu. edu/legacy/scm/abstracts/abscm_jpast_pres_future_TR08_
02. html. Автоматизированная поддержка менеджмента конфигурации (СМ)
представляет собой один из аспектов среды программного инжиниринга за последние 20
лет развития.
www. testing.com/writings/classic/mistakes.html. Брайан Мэрик (Brian
Marick), консультант по тестированию.
Жизненные циклы
:':<:. fqg .uni-lj . si/ICARIS/LIST/msg00007 .html. «The Application of Multi-
ageni Systems to Concurrent Engineering». Concurrent Engineering: Research and Applications
(ClJt'\j. West Bloomfield, MI: CERA Institute.
www. bra inyquote. com/quotes/quotes/. Распределение квот.
www. informatik.uni-bremen.de/uniform/gdpa/vmodel/vmi.htm. Стандарт
разработки ИТ-систем (V-модель) Федеративной Республики Германии.
www.software.org/pub/darpa/erd/erdpv010004.html. Эволюционная
быстрая разработка.
www. stsc.hill.af.mH/crosstalk/1996/aus/isoiec.asp. Lewis Gray A996).
i ISO/1EC 12207 Software Lifecycle Processes». Crosstalk, August.

1106 Литература
Метрические показатели
hissa .ncsl.nist.gov/. Center for High Integrity Software Systems Assurance —
международный симпозиум NIST по методам измерений, применяемым при
разработке ПО.
irb.cs. nni-magdeburg. de/sw-eng/us/. Лаборатория измерительных методов,
применяемых при разработке ПО, Магдебургского университета.
irb. cs. uni-magdeburg. de/siv-eng/us/index. shtml. Лаборатория
измерительных методов, используемых при разработке ПО (Software Measurement
Laboratory).
mijuno. larc.nasa.gov/dfc/societies/lspa.html. Международная
ассоциация параметрического анализа (International Society of Parametric Analysts).
sate. gsfc. nasa . gov/support/STC_APR96/quality//stc_qnal.html. 8th Annual
Software Technology Conference, Utah, April 1996.
sel.gsfc.nasa.gov/website/documents/'contents.html. Лаборатория
программного инжиниринга (Software Engineering Laboratory), раздел 6: измерения,
выполняемые в процессе разработке ПО.
stsc.hill.af.mil/. U.S. Air Force's Software Technology Support Center (поиск
осуществляется по ключевому слову «software metrics»).
www. cmg.org. Фирма Computer Measurement Group Inc.
www. iese. flig.de/lSERN/. Международная исследовательская сеть в области
программного инжиниринга (International Software Engineering Research Network,
ISERN).
www. ifpng.org. Международная группа пользователей метода функциональных
точек.
www.incose.org. Международный совет по инжинирингу систем (International
Council on Systems Engineering).
www. instmc.org.uk. Институт методов измерений и контроля (Institute of
Measurement and Control).
www.m2tech.net/rsm/default.htm. Ресурс, включающий описания
стандартных метрических показателей (Resource Standard Metrics).
www.nist.gov/. Национальный институт стандартов и технологий (National
Institute of Standards and Technology).
www.psmsc. com. Центр поддержки практических программных и системных
измерений (Practical Software and Systems Measurement Support Center).
www. gncis. gneensu.ca/Software-Engineering/Cmetrics.html. Исходный
код С-программ, кодирующих метрические показатели.
www. sigme tries. org/. Association for Computing Machinery SIG Metrics.
www. softwaremetrics. com/Articles/default .htm. Longstreet Consulting Inc.
www. spr. com/index. htm. Фирма Software Productivity Research выполняет
измерения, связанные с разработкой ПО, а также оценивание продуктов и служб.
Основателем и председателем являеетя Каперс Джонс (Capers Jones).
www. ssg. org. Ассоциация качества ПО (Society for Software Quality).

Литература 1107
Управление проектами: документирование планов
проектов, составление графика, мониторинг процесса
разработки и отслеживание хода выполнения проекта
www.allpm.com/. Здесь содержится подробное описание ресурсов по
менеджменту проектов.
www.ee.ed.ac. uk/~gerard/Management/art8.html. Gerard M. Blair. «Planning
a Project».
www. fek. umu. se/irnop/projweb.htmitop. Путеводитель по www-узлам,
содержащим результаты исследований в области менеджмента проектов.
www. hq. nasa . gov/office/hqlibrary/ppm/рртЫЬ. htm. Библиотека NASA PPM.
Перечень ресурсов Program/Project Management Resource Lists, изначально
предназначенный для сообщества управления проектами NASA.
www.infogoal.com/pmc/pmchome.htm. Центр менеджмента проектов (Project
Management Center).
www.michaelgreer.com/bibliog.htm. Библиография Грира (Greer) но
вопросам РМ, ID, а также ссылки на ID/PM.
www.michaelgreer.com/postmortem.htm. Web-узел Майкла Грира (Michael
Greer), консультанта по РМ-ресурсам.
www.pmforum. org/. WWW Project Management Forum. Форум Project Management
Forum является некоммерческим ресурсом и содержит информацию по менеджменту
международных проектов. В частности, тут рассматриваются вопросы разработки,
международной кооперации, продвижения и поддержки дисциплины менеджмента
проектов.
www.pmforum.org/library/glossary/PMC_P12.htm. Словарь терминов по
менеджменту проектов, связанных с РМ Forum.
www.pmi.org/. Институт менеджмента проектов (PMI, Project Management
Institute).
www.pmi. org / cert if icat ion/. Требования по сертификации РМР.
www.pmi.org/pmi2001/papers/quality.htm. Howland Blackiston. «Quality in
Project Management: Organizing for Continuous Improvement in Project Management».
PMI, Nashville, TN, 2001.
www.pmi. org/publictn/pmboktoc. htm. PMI's A Guide to the Project Management
Body of Knowledge (PMBOK® Guide).
www.pmibookstore. org/. Интерактивный источник PMI Bookstore включает
более 1000 лучших книг и продуктов из категории менеджмента проектов (включая
полный перечень книг института PMI).
www .project-manager .com/. Web-узел для менеджера проектов. Ресурсы и
информация.
www. spmn. com/. Миссия SPMN: поиск проверенных лучших методик разработки
ПО, предназначенных для органов государственного управления и промышленности,
с последующим их предоставлением менеджерам крупномасштабных программных
DoD-проектов.
www2.umassd.edu/SWPl/sei/tr25f/tr25_12c.html. Обзор и отслеживание
программных проектов.

1108 Литература
Команды разработчиков проектов
www. aftrstlook. com/docs/Schulz. Em Griffin. A First Look at Communication
Theory, McGraw-Hill, 1991.
www. enneagraminstitute. com/. Институт эннеаграмм (Enneagram Institute).
www. humanme tries. com/JungType. h tm. Метрические показатели,
применяемые при оценке человеческих личностных качеств, топология Юнга и MBTI.
www. humansource. com/trendspot ting/19 990201 .htm. Проведение опросов.
unvw.keirsey.com. Тесно связанным с MBTI является определитель темпераментов
Кирси (Keirsey Temperament Sorter), впервые упоминающийся в книге Дэвида Кирси
Please Understand Me.
www.purenlp.com/whatsnip.htm. Richard Bandler. «What Is NLP?» The First
Institute ofNcuro-Linguistic Programming™and Design Human Engineering™, 1996.
www. selbymillsmith.com. Selby MillSmith, Chartered Occupational Psychologists,
IIRO-I1 Instrument.
www. sol-ne.org/res/wp/toc. Edgar H. Schein. «Kurt Lewin's Change Theory in
the Field and in the Classroom: Notes Toward a Model of Managed Learning». Society for
Organizational Learning, 2000.
www.tajnet.org/articles/kahler-miniscript-addendum.html. Тэйби Ка-
лер (Taibi Kahler). Статья, в которой обсуждаются коррелирующие мотивации,
эгоцентрические состояния, психологические потребности, жизненные позиции,
занятия, указания, сценарии, роли, игры и вымышленные ситуации.
Журналы
computer, org/'software/'. IEEE Software Magazine.
kapis.www.wkap.nl/kapis/CCI-BIN/WORLD/journalhome.htm71382-3256.
Victor R. Basili. Empirical Software Engineering.
sel. gsfc.nasa . gov/website/documents/'contents.html. National
Aeronautics and Space Administration (NASA) A998). «Annotated Bibliography of
Software Engineering Laboratory (SEL) Literature». Goddard Space Flight Center (GSFC),
Greenbelt, MI).
sqp.asq. org/. ASQ Software Quality Professional.
www. 4pm. com/. Project Managers Watch Tower. Ресурсы и информация по менед-
мженту проектов.
www. a cm. org/jacm/. Association for Computing Journal of the ACM.
www. acm.org/sigsof t/. Association for Computing Machinery SIG Software
Engineering.
www.acm.org/tosem/. Association for Computing Transactions on Software
Engineering and Methodology.
www. adtmag. com/. Application Development Trends.
www. soft. com/News/TTN-Online. Testing Techniques Newsletter.
www sel. iit.nrc. ca/SPN/. Software Process Newsletter.
Вопросы обеспечения качества
acis.mit.edn/acis/sqap/sqap.rll.html. План SQAP, подготовленный
институтом MIT для NASA.
акао. larc.nasa.gov/dfc/qfd.html. Е.В. Dean. «Quality Function Deployment
from the Perspective of Competitive Advantage», 1997.

Литература 1109
hissa. ncsl.nist.gov/. Центр поддержки высокоинтегрированных систем
(Cent er for High Integrity Software Systems Assurance, NIST).
qaiusa . com. Институт качества ПО (Quality Assurance Institute).
satc.gsfc.nasa. gov/'homepage. html. Технологический центр по обеспечению
качества ПО (Software Assurance Technology Center).
www. acq-ref. navy.mil/wcp/gfd. html. Организация QFD.
www .asq. org. Американская ассоциация качества (American Society for Quality, ASQ).
www. asq. org/info/library/faq/. Путеводители по ресурсам, подготовленные
i нециалистами Центра информации о качестве (Quality Information Center) в ответ
ид часто задаваемые вопросы по этой тематике. Каждое руководство включает
рекомендованные статьи, книги и ссылки на web-узлы, на которых имеется
соответствующая информация по каждому вопросу.
www. asq-software, org. ASQ Software Division.
www. cs.uwf.edu/~wilde/gump/sqa .htm. В этом документе описывается план
обеспечения качества ПО (Software Quality Assurance, SQA), используемый в
обобщенном процессе поддержки ПО для учебной программы по программному
инжинирингу в университете Западной Флориды (UWF).
www. dhucton. com/samples/sampqfd. html. Организация QFD.
www. nauticom. net/www/qfdi/. Институт QFD.
www. qaiusa . com/. Институт обеспечения качества ПО.
www. qfdi . org/. Институт разработки функций по обеспечению качества (Quality
Function Deployment Institute).
-.■•■ww. qualitydigest.com/mar99/html/itech. html. Douglas L. Swanson, Ph.D.;
Richard A. Esposito: and Jean Jester, Ph.D. «Managing Quality for Information
Technology».
www. sqa tester, com. SQAtester.com.
www.sqazone.com/. Добро пожаловать на Web-узел SQAZone.com. Тут можно
найти нее, что необходимо знать о тестировании ПО и обеспечении его качества.
Информация должным образом классифицирована.
www. sqe. com. Инжиниринг качества ПО (Software Quality Engineering)
www. ssq. org/. Ассоциация качеевта ПО (Society for Software Quality).
www- sqi .cit.gu. edu .au/. Австралийский исследовательский институт качества ПО.
Надежность
inpiribers.aol.com/JohnDMusa/.J.D. Musa. «More Reliable Software Faster and
Cheaper (Обеспечение надежности ПО)», 1998.
''лс. iitri.org/. Миссия центра анализа надежности ПО (Reliability Analysis
Center, RAC).
www. asq-rd.org/. Американская ассоциация качества (American Society of
Quality), отдел обеспечения надежности (Reliability Division).
www.es. cmu.edu/~koopman/des_s99/siv_reliability/. Jiantao Pan A999).
«Software Reliability», Carnegie Mellon University, 18-849b Dependable Embedded
Systems. Spring.
www. ieee .org/orgamzat ions/society/rel. html. В задачи организации IEEE
Reliability Society иходит решение проблем, связанных с обеспечением необходимого
уровня надежности, который поддерживается на всем протяжении периода
эксплуатации системы или устройства, а также выполнение соответствующих измерений.

1110 Литература
www. ima. imm.edu/~arnold/455.f96Zdisasters.html. Две катастрофы,
происшедшие по причине вычислительных компьютерных ошибок.
www.nytimes.com/2001/05/20/business/20EXAM.html. Right Answer, Wrong
Score: Test Flaws Take Toll.
www. sre.org/. Ассоциация инженеров по качеству (Society of Reliability
Engineers).
Требования
brainstorming.org. uk/tutoriaIs/usenewpeople.html. Учебные пособия по
«мозговому шторму».
edweb. sdsu. edu/triton/guides/Brainstorming. html. Методы «мозгового
штурма».
members, ozemail. com.au/~caveman/Creative/Techniques/bramstorm.htm.
Разработка функции качества «мозгового штурма» в аспекте обеспечения
преимуществ при конкуренции.
sunset.usc.edu/research/WINWIN/wimwin_main.html. Barry Boehm,
Alexander Egyed, et al. «Using WINWIN Spiral Model: A Case Study». IEEE Computer,
31G):33M, 1998.
www. acq-ref. navi/.mil/wcp/qfd.html. Организация QFD.
www. advisorteam. com/user/ktsintro. asp. Keirsey Temperament Sorter.
www. brainstorming, со. uk. Infinite Innovations Ltd, «мозговой штурм».
www. brainstorming.org. uk/tutorials/usenewpeople.html.
www. cpsc .ucalgari/. ca/~danah/kaw96/FWAL. html. Daniela Elena Herla.
«Users' Involvement in the Requirements Engineering Process». Knowledge Science
Inst it ule, University of Calgary.
www. dhutton. com/samples/sampqfd.html. Организация QFD.
www. directedcrea tivity. com. «Мозговой штурм».
www. imappl.org/crest/requirement.html. Department of Systems and
Computer Science at Howard University.
www. inspire t ion. com/. Составление схем интеллекта.
www.mcli.dist.maricopa.edu/authoring/studio/'guidebook/bra in.html.
« M 03 го вой штурм ».
www.mindjet. com/. Составление схем интеллекта.
www.ozemail.com.au/~caveman/Creative/Mindmap/. Определяется выбор
узлов, содержащих информацию по разработке карт интеллекта.
www. process impact, com/a r tides/qua lreqs .html. Karl E. Wiegers, «Writing
Quality Requirements». Process Impact (первая публикация в журнале Software
Development, май 1999).
www. qfdi . org/. Институт по разработке функций управления качеством (Quality
Function Deployment Institute).
www.sdmagazine.com/documents/'s=758/sdm9905c/9905c.htm. Определение
образцовых документов требований.
www.sei.emu.edn/pub/documents/92. reports/pdf/trl2.92.pdf. Michael G.
Christel and Kyo C. Kang. «Issues in Requirements Elicitation», Technical Report
CMU/SEI-92-TR-12 ESC-TR-92-012, 1992.

Литература 1111
www.thebeenet.com/bluebird/jaddoc.htm. Bill Jennerich. «Joint Application
Design: Business Requirements Analysis for Successful Re-engineering». Berwyn, PA:
Bluebird Enterprises, 1999.
www. zoo. со. uk/~z0001039/PracGuides/pg_use_cases.htm. Edward Kenworthy.
«Use Cases».
Риски
www.cs~solutions.com/riskplus.htm. Risk+, дополнительный модуль для MS
Project.
www. ens.asu.edu/~riskmgmt/intro.html. James S. Collofello. «Software Risk
Management».
www.palisade.com/ptml/risk.html. ©Risk, дополнительный модуль для Excel
или MS Project.
www. sei. emu. edu/programs/'sepm/risk/.
www.sei.emu.edu/publications/documents/97.reports/97hb002/97hb002
abstract.html. Brian Gallagher, Christopher Alberts, and Richard Barbour. «Software
Acquisition Risk Management Key Process Area (KPA) — A Guidebook Version 1.0».
Программный инжиниринг — определение продукта
и понимание действий по разработке
liinwww. ira . ика . de/bibliography/index. html. Коллекция
библиографических ссылок на научную литературу в области информационных технологий.
mingo. info-science.uiowa.edu/soft-eng/. Виртуальная библиотека по
программному инжинирингу, находящаяся в World Wide Web.
sunset, nsc. edu/. Центр был основан в июне 1993 года усилиями д-ра Барри В.
Боэма (Barry W. Boehm) в целях поддержки среды для исследований и обучения в
области широкомасштабной разработки приложений и процессов, обобщенных и
специфичных для определенных предметных областей архитектур ПО, инструментов и
сред программного инжиниринга, совместной разработки систем и экономики
программного инжиниринга.
www.best.com/~wilson/fag/. alt.folklore.computers A998). Список часто
задаваемых вопросов.
www.computer.org/tab/swecc/. АСМ, комитет IEEE Software Engineering
Coordinating. В объединении IEEE-CS/ACM joint task force on Software Engineering
Ethics and Professional Practices (SEEPP) был разработан этический кодекс инженера-
программиста (Code of Ethics for Software Engineers). Этот документ содержит восемь
направляющих приницпов.
www. cs. queensu. ca/Software-Engineering/. Архивы World-Wide Web группы
новостей USENET comp.software-eng, включая статьи по часто задаваемым вопросам
(Frequently-Asked Questions, FAQ).
www. cs .umd.edu/projects/SoftEng/tame/. Экспериментальная группа
программного инжиниринга (Experimental Software Engineering Group, ESEG)
университета штата Мэриленд рассматривает специфические исследовательские проекты,
которые сосредоточены на формализации различных аспектов: (а) парадигма
улучшения качества (QIP, Quality Improvement Paradigm); (б) опытная фабрика (EF,
Experience Factory); (в) подход цель/вопрос/метрика (CQM, Goal/Question/Metric).

1112 Литература
www. faqs. org/fags/so ftware-eng/. Часто задаваемые вопросы в области
программного инжиниринга.
www.quels.queensu.ca/Software-EngineeringZreading.html.
Гипертекстовая версия перечня чтения в области программного инжиниринга, регулярно
отсылаемого в список рассылки comp.software-eng.
Стандарты
standards. ieee. org/index, html. Стандарты IEEE.
www. ansi. org/. Американский национальный институт стандартов (American
National Standards).
www. iso. ch/9000e/execabstract. htm. Информация ISO 9000.
www. iso. ch/9000e/plain. htm. Пояснения по стандартам ISO 9000 и 14000.
www. iso. ch/in foe/intro. htm. Информация по организации ISO.
www. iso. ch/iso/en/ISOOnline. openerpa . ge. Международная организация по
стандартизации (ISO).
www. nist .gov/. Национальный институт стандартов и технологий (National
Institute of Standards and Technology).
www. nssn. org. Национальная сеть по системным стандартам (National Standards
Systems Network).
Инструменты
a rgouml. tigris. org/. Цель проекта ArgoUML заключается в создании
инструмента объектно-ориентированного проектирования, который обладает следующими
свойствами: простота в применении, реальная польза в процессе проектирования для
дизайнеров, полностью открытый программный код Java, передовая технология
(поддержка последних UML-спецификаций), модульность и расширяемость,
интеграция с Web и с. другими инструментами Tigris.
ca . com/products/ superproject .htm. Computer Associates.
cvshome.org/. Система Concurrent Versions System представляет собой систему
контроля версий, «прозрачную» в сети открытых ресурсов.
ijtek. com/WebPM/'default. asp. ProjectLab.
si Ivor. sdsmt.edu/~fmatejci/kcqc~l.htm. Контроль статистических
процессов. Подробные примеры «древних» инструментов, средства вычислений,
стандартные отклонения, гистограммы, R-диаграммы и секторные S-диаграммы.
source forge. net/foundry/tel- foundry/. Foundry for Tel (командный
инструментальный язык), многоплатформенный (Unix /Windows /Macintosh /и др.) язык
написания сценариев.
www. aonix. com/content /index, html. Инструмент Aonix.
www.construx.com/. Инструменты программного инжиниринга и ресурсы по
разработке ПО, поддерживаемые Construx и другими организациями.
www.cs-solutions.com/riskplus.htm. Risk+, дополнительный модуль MS
Project.
www.eproject. сот. Инструмент eProject.
www. eroom. com. eRoom: инструменты по организации виртуального
сотрудничества между командами.

Литература 1113
www.gedanken.demon.co.uk/cxref/. Программа Cxref обеспечивает создание
документации (в форматах LaTeX, HTML, RTF или SGML), включая перекрестные
ссылки на исходный код языка С
www.gnu.org/'software/emacs/. Редактор GNU Emacs является современным,
документированным, настраиваемым, расширяемым экранным редактором для
Emacs, выполняющимся в режиме реального времени.
www. imagix. com/products /metrics .html. Программа Imagix Power.
www.mcose.org/tools/tootax/riskmgt_tools.html. Сводка по инструментам
управления рисками.
www. in ventx. corn. InventX: Менеджмент проектов на уровне организации,
основанный на Web.
www. it. swm. edu. au/projects/'jmetric/'products /jmetric/. Инструмент
J Met ric облегчает работу с объектно-ориентированными метрическими
показателями, а также исследования измерительных инструментов для специалистов-практиков.
iviviv.li.org/. Некоммерческая ассоциация Linux International объединяет
группы, корпорации и другие структуры, работающие на имидж операционной системы
Linux и сообщества ее пользователей.
www. lotusnotes. com. Пакет Lotus Notes Software.
iviviv. lysator. liu. se/~alla/dia/dia .html. Программа Dia функционирует на
основе gtk+ и предназначена для создания диаграмм (выпускается по лицензии GPL).
Ее возможности соответствуют характеристикам коммерческой Windows-программы
'Visio1. Программа Dia может применяться для создания диаграмм различных типов.
Действующая версия программы включает специальные объекты, облегчающие
построение диаграмм взаимосвязей между сущностями, UML-диаграмм, блок-схем,
сетевых диаграмм и простых монтажных схем.
www.man.deakin.edu.au/rodneyc/XLStats.htm. Программа XLStatistics
представляет собой набор рабочих книг Microsoft Excel (версия 5+), обеспечивающий
выполнение статистического анализа данных. Она предназначается для замены и
расширения возможностей инструментов, поддерживаемых дополнительным модулем
Excel, Data Analysis Toolbox.
www .mccabe. com/та in. htm. McCabe & Associates.
ivwiv. methods-tools. com/. Программные методы и инструменты.
www.microsoft. com/ms .htm. Инструменты Microsoft.
www.micmsoft. com/Off ice/Project/PRK/2000/Six/70ct .htm. MS Project
Central: сотрудничество.
www.netcomputing.de/html/main.html. Программа AnyJ представляет собой
межплатформенное решение, применяемое для разработки Java IDE и исходного кода.
ivwiv.open.org/~prslJfg/sy_chap.htin. Paul R. Seesing and ARMA International
A993). «Basic Systems Analysis Tools for Computer Users».
iviviv. oracle, com/. Фирма Oracle Corporation.
www.palisade.com/html/risk.html. Основные модули: ©Risk,
дополнительный модуль для Excel или MS Project.
www.perl, com/pub. Интерпретируемый язык Perl оптимизирован с целью
просмотра произвольных текстовых файлов, выборки информации из этих файлов, а
также создания отчетов на основе этой информации.
ivivw.plng.be/bertln/abs. shtml. Программа Abs представляет собой отдельное
измерение для электронных таблиц, предназначенных для выполнения на любой
платформе UNIX

1114 Литература
www.qsm.com/. Количественный менеджмент ПО (Quantitative Software
Management, QSM).
www.gualitydigest.com/apr99/html/excel.html. William A. Levinson, P.E.
Использование управляющих диаграмм Excel с изменяющимися размерами выборки.
Возможности электронных таблиц часто превышают способности многих
коммерческих SPC-пакетов.
www.gualitydigest.com/june97/html/cover.html. J. Michael Crouch.
«Essential Tools for Quality Managers, Or, What I Wish I Knew Before I Took This Job».
www. gualitydigest. com/pdf sZ2001src-software.pdf. «2001 Software Quality
and Calibration Guide». Отдельные разделы, посвященные калибрации ПО и услугам,
контролю документов, созданию блок-схем и имитации процессов, а также описанию
программных стандартов ISO 9000.
iviviv.guicJflist.org/. QuickList является свободно распространяемой (GPL)
программой gtk+ и может выполняться в любой unix-системе, в которой установлен
gtk+ 1.2 или его старшая версия.
www. rational, com/index. j sp. Компания Rational Software.
www. resourcedesigninc.com/RDImain.html. Ecomodeler — проект
автоматизированного внешнего интерфейса, обеспечивающего конструирование ПО для
проекта World Construction Set от фирмы ViewscapeSD Ltd.
iviviv. scitools. com/. Фирма Scientific Toolworks, Inc.
iviviv. sofl. com/AppNotes/TestWorksIndex/index, html. Индекс качества
Test Works Quality.
iviviv. softwaregatest. com/TOP. Программа Rick Hower. Центр обеспечения
качества ПО/ресурсов тестирования перечисляет десятки автоматизированных
инструментов, предназначенных для облегчения динамического тестирования
приложений нескольких типов. Этот исчерпывающий аннотированный список содержит
описания web-узлов для каждого инструмента.
www. spnm.com/rsktrkr.html. Программа Risk Radar построена на основе MS
Access и предназначена для отслеживания рисков.
iviviv. spr. com/. Свободно распространяемая web-служба оценивания
обеспечивает взгляд «изнутри» организации-разработчика ПО.
iviviv.sre.org/sresoft.htin. Программное обеспечение Reliability Test Planner
(RTF) упрощает конструирование планов тестирования статистической надежности
для экспоненциальных и биномиальных распределений.
www. stat. umn.edu/~luke/xls/xlsinfo/xlsinfo.html. Расширяемая
статистическая вычислительная среда Lisp-Stat предназначена для выполнения анализа
данных, статистических инструкций и исследований с выделением поддержки
каркаса, предназначенного для применения динамических графических методов.
wiviv. stgease. com/. Программа AxiomSys представляет собой метод
структурированного анализа, включая расширения режима реального времени Хатли-Пербая
(Hatley-Pirbhai). Сюда также включены возможности по моделированию архитектуры
Hat ley-Pirbhai.
iviviv . syba se. com/. База данных Sybase.
iviviv\ turbocase. com/. Программа TurboCASE/Sys for Windows автоматизирует
методы формирования системных требований и архитектуры. Эта программа
разработана Дереком Хатли (Derek Hatley), а позднее усовершенствована Имтиазом Пер-
басм (Imtiaz Pirbhai).

Литература 1115
www. verilog. com/. Язык описания аппаратного обеспечения Verilog HDL
применяется для проектирования и документирования электронных систем.
www-4. ibm. com/so ftwa re/da ta/db2/udb/. Универсальная база данных DB2.
zing, ncsl. nist. gov/WebTools/. Метрические показатели, применяемые в Web.
Аттестация и верификация
rexblackconsulting.com.
satc.gsfc.nasa.gov/fi/fipage.html. Процесс формального
инспектирования, принятый в NASA.
sel.gsfс. nasa.gov/website/index.htm. Лаборатория программного
инжиниринга (Software Engineering Laboratory).
stsc.hill.af.mil/CrossTalk/1998/dec/oneill.asp. Don O'Neill. «National
Software Quality Experiment, A Lesson In Measurement: 1992-1997», 1998. CrossTalk:
Journal of Defense Software Engineering, December.
world. std.com/~jr/Papers/QW96.html. Johanna Rothman. «Measurements to
Reduce Risk in Product Ship Decisions». Proceedings of the Ninth International Quality
Week, Software Research, San Francisco, CA, 1996.
www.chasnigroup.com/.
www.cse.dcn. ie/. Centre for Software Engineering, Ltd., Dublin City University
Campus, Dublin, Ireland.
www.geraldmweinberg.com. Страница Геральда М. Вайнберга (Gerald M.
Weinberg).
www. ics. hawaii . edu/-Johnson/FTR/. Архив формальных технических обзоров
(Formal Technical Review Archive).
www. ics.hawaii.edu/~siro/. Организация, обеспечивающая проведение
обзоров и формальных инспекций ПО (Software Inspections and Review Organization).
www.io.com/~wnzmo/qa/. Горячий список тестирования ПО (Software Testing
Hot list) под редакцией Бретта Петтичорда (Brett Pettichord).
www. iso. ch/iso/en/ISOOnlne.openerpage. International Organization for
Standardization (ISO).
www.j rothman.com.
www. kaner. com/. Д-р Кэнер (Kaner) основной автор Testing Computer Software.
www.kaner. com/coverage, htm. Cem Kaner. «Software Negligence and Testing
Coverage». STAR 96 Proceedings, 1996.
www. m tsu. edu/~storm/. Интерактивные ресурсы, описывающие тестирование ПО.
wuv.nist.gov/. Национальный институт стандартов и технологий (National
Institute of Standards and Technology, NIST).
www.nstl.com/. Национальные лаборатории по тестированию ПО (National
Software Testing Labs).
www. ondaweb. com/sti/. Институт тестирования ПО (Software Testing Institute).
www. ondaweb. coni/sti/newsltr.htm. Software Testing Newsletter.
www. ondaweb. com/sti/stivend. htm. Руководство по ресурсам
профессионального тестера ПО.
www.qaiusa.com/. Институт обеспечения качесвта ПО (Quality Assurance
Institute).
www. satisfice. com/articles/good_enough_quality.pdf.]zmes Bach. «Good
Enough Quality: Beyond the Buzzword». Software Realities column, IEEE Computer, 1997.

1116 Литература
www.satisfice.com/articles/software_reality.pdf. James Bach. «What
Software Reality is Really About». Software Realities column, IEEE Computer, 1999.
www.satisfice.com/nrticles/test_automation_snake_oil.pdf. James Bach.
«Test Automation Snake Oil». Windows Tech Journal, 1996.
www.softwarecjatest.com/TOP. Центр обеспечения качества ПО/ресурсов
тестирования (Software QA/Testing Resource).
www. softwaregatest. com/WEB_SECURITY. Тестирование узлов World Wide Web.
www. spmn.com. Сеть программных менеджеров (Software Program Managers
Network).
www. sqe. com/index. asp. Инжиниринг качества ПО.
www.stlabs.com/~marick/root.htm.
www. stcfemagazine. com/featured. asp?statnp=U29125440. James Bach.
«Risk-based Testing». Software Testing and Quality Engineering Magazine, 1999.
www. stqemagazine. com/webinfo_detail.asp?id=102. Brian Marick. «Web
Watch: Automating Testing». Software Testing and Quality Engineering Magazine, 1999.
wmv. stsc.hill.af.mil/CrossTalk/1998/dec/oneill.asp.
www. stsc. hill.af.mil/SMTesting/gilb.html. Документы Тома Джилба (Tom
Gilb).
www. testing, com/writings/automate.pdf. Brian Marick. «When Should a Test
be Automated?» Proceedings of International Quality Week, 1988.
www.testing.com/writings/classic/mistakes.html. Brian Marick. «Classic
Testing Mistakes». Proceedings of STAR 97, Software Quality Engineering, Jacksonville,
EL, 1997.
www. testing, com/writings/coverage.pdf. Brian Marick. «How to Misuse Code
Coverage». International Conference and Exposition on Testing Computer Software, 1999.
uww. testing, com/writings/effective.pdf. Brian Marick. «Working Effectively
With Developers». STAR West Conference, 1998.
www. festing. com/writings/exverience.pdf. Brian Marick. «Experience with
the Cost of Different Coverage Goals for Testing». Pacific Northwest Software Quality
Conference, 1991.
www.testing.com/writings/purpose-of-testing.htm. Brian Marick. «The
Testing Team's Motto».
www.testingcraft.com/exploratory~pettichord.html. Bret Pettichord «An
Exploratory Testing Workshop Report», 1999.
www. useit. com/.
www. zdnett. com/pemeig/pctech/content/11/11'/tulll 7. 001 . html. Neil
Randall. «Making Software Easier Through Usability Testing: Software companies take a
rigorous approach to determining how easy their products are to use». PC Magazine Online.
www2. ics. hawaii . edu/-Johnson/FTR/. Архив формальных технических WWW-
обзоров (WWW Formal Technical Review Archive).
www2. ics .hawaii. edu/~siro/. Организация обзоров и инспекций ПО (Software
Inspections And Reviews Organization).

Предметный указатель
о
О РА, 114
S
SA/SD, 755
V
V-образная модель жизненного цикла
разработки ПО
Действия, 289
А
Анализ, 704
граничных значений
статистический, 685
,894
Анализ методом силового поля,
Атрибут, 760
Аттестация, 843
Б
217
Базовый метрический показатель
запрос на изменение.
обзор, 730
трудозатраты, 727
Бюрократия, 440
В
Верификация, 843
Г
734
"героическое" сопровождение,
Группа
IFPUG. 332
OMG, 816
Д
Действие, 37; 45
185
классификация, 852
Диаграмма
ACD, 796»
AFD, 755; 790
AID, 791
CCD, 755; 784
CFD, 755; 785
DCD, 755; 774
DD, 788
DFD, 314; 528; 755; 774; 776
ERD, 314; 528; 755; 759, 760
сущность, 761
STD, 786; 831
вариантов использования, 824
взаимодействия, 827
Ганта, 260, 441; 475
действий, 826
Ишикава, 718
Несси-Шнайдермана, 808
Парето, 718
последовательная, 827
рассеянная, 718
сетевая, 462
сотрудничества, 827
структурная, 792
Чейпина, 899
Диаграмма ERD
сущность
атрибут, 762
отношение, 762
Диаграмма классов
интерфейс, 819
класс, 818
метод, 819
объект, 818
ответственность, 819
отношение, 819
сообщение, 819
стимул, 819
Дефект, 676; 852

1118 Предметный указатель
Диаграммы
Чейпина, 80S
Документ
IEEE 1058, 252
IEEE 1074, 281
PID, 251
РМВОК, 613
SCMP, 282
SDD, 306
Software Engineering Body of
Knowledge, 614
SOR, 248
SOW, 248
Драйвер затрат, 385
E
Единица измерения ПО
метод точек свойств, 345
Ж
Жизненный цикл разработки ПО, 31
V-образная модель, 141
быстрое отслеживание, 165
инкрементная модель, 155
исследование концепции, 34
каскадная модель, 32
критерии ввода и вывода, 34
повторение, 34
сопровождение, 34
спиральная модель, 159
спиральная модель "Win-Win", 166
фаза, 34
Жизненный цикл разработки ПО, 132
3
Зависимость, 462
"старт-старт", 467
"старт-финиш", 467
"финиш-старт", 466
"финиш-финиш", 467
внешняя, 463
внутренняя, 465
жесткая, 469
запаздывающая, 468
мягкая, 469
опережающая, 468
управляемая действиями, 465
управляемая ресурсами, 465
Задача, 37; 45
интегральная, 281
И
Иерархия потребностей, 218
Измерение, 704
Индекс
CPI, 989
SPI, 989
Индикатор
Майерса-Бриггса, 209, 1052
Инжиниринг
определение, 620
Инжиниринг ПО, 39
действия, 295
Инспекционная проверка
формальная, 844
Инструмент
Access, 936
AnyJ, 950
ArgoUML, 950
Risk Radar, 611
RSM, 951
SLIM-Control©, 404
SLIM-Esrimate©, 404
SLIM-Metrics©, 404
SPR KnowledgePLAN®, 376
Visio, 936
WSPI, 427
анализ производительности, 943
генератор тестов, 940
интерпретатор кода, 940
компилятор кода, 939
отладчик кода, 940
оценка тестов, 942
по конструированию ПО, 938
по разработке проекта ПО, 937
Редактор кода, 939
сопровождение ПО, 945
схема выполнения тестов, 942
управление процессом тестирования,
943
Инструменты
по определению требований к
программам, 936
Интеграция компонентов, 185

Предметный указатель 111Ч
Информационная система управления
проектом, 970
К
Каскадная модель жизненного цикла
разработки ПО
действия, 287
Качество ПО
критерий FURPS, 740
критерий IBM CUPRIMDSO, 740
критерий Аллеи 2000, 740
критерий Боэма 1978, 740
критерий Мак Колла, 740
Класс предметной области
деловой, 184
индустриальный, 184
научный, 184
потребительский;, 184
продукт с минимальной задержкой, 184
режим реального времени, 184
Когнитивный диссонанс, 881
Код
модифицируемый, 356
наследственный, 356
новый, 356
повторно используемый, 356
Комитет
ACM Software Engineering Coordinating
Committee, 614
Компетенция
вопросы интеллектуальной
собственности, 36
документирование планов, 35
взаимодействие и общение, 36
выбор метрических показателей, 36
выполнение начальной оценки, 35
знание стандартов процесса, 34
лидерство, 36
набор персонала, 36
определение продукта, 34
организация эффективных встреч, 36
отбор инструментов менеджмента
проектов, 36
отбор команды, 36
отбор методов и инструментов, 35
отслеживание качества продукта, 35
отслеживание процесса разработки, 35
оценка альтернативных процессов, 34
оценка производительности, 36
оценка стоимости, 35
оценка трудозатрат, 35
планирование карьерного роста, 36
подгонка процессов, 35
понимание действий по разработке
продукта, 35
процессы оценивания, 34
создание команды, 36
создание структуры пооперационного
перечня работ, 35
Составление графика, 35
управление изменениями, 36
управление субподрядчиками, 35
управление требованиями, 35
успешное ведение переговоров, 36
эффективное представление, 36
Контроль
сквозной, 844; 854
статистических процессов, 985
Коэффициент
ROI, 243
объединения по входу, 805
объединения по выходу, 805
Л
Лаборатория
SEL, 710
Линия
РМВ, 984
М
Матрица
распределения обязанностей, 1053
трассировки требований, 1018
функциональной ответственности, 226
Матрица гибкости, 973
Менеджмент, 38
QPM, 707
матричный, 451
прибавочной стоимости, 986
Менеджмент конфигурации, 127
Менеджмент прибавочной стоимости
компонент ACWP, 988
компонент BCWP, 988
компонент BCWS, 988

1120 Предметный указатель
Менеджмент процесса, 101
Метка
TBD, 571
Метод
GQM, 1056
ООП, 132
RA1), 132; 151
S.M.A.R.T., 248; 1030
Методика
"будет/ие будет", 249
гос, Зоя
ЮС. 306
JA1). 296
JRP, 296
Метрический показатель, 696'
Министерство путей сообщения Китая,
S3
Модель
ANSI/SPARC, 759
СММ, 316; 616
CMMI, 709
СОСОМО, 371
Пазовая, 380
базовый уровень, 579
внедренный режим, 379
детализированная. 396
органический режим, 378
промежуточная. 385
промежуточный уровень, 379
< блокированный режим, 379
СОСОМО И, 400
Delphi, 198
1)п Point, 199
FIRO-B, 210
Р-СММ, 228
SLCM, 105
SLIM, 402
анализ методом силового поля, 456
каскадная. 135
линейная, 377
межпроцессного взаимодействия
Келера, 212
развития команды, 221
регрессионная, 377
ситуативного руководства, 230
сортировки темпераментов Кирси, 2.
энпсаграмма, 213
Модель RAD жизненного цикла
разработки ПО
действия, 295
Модель жизненного цикла разработки
ПО
объектно-ориентированное быстрое
прототипирование, 168
Модель установки пути к цели, 217
Н
Надежность, 676
Нейро-лингвистическое
программирование, 213
Номинальная групповая техника, 470
Нормализация, 763
1NF, 766
2NF, 767
3NF, 769
4NF, 769
5NF, 771
BCNF, 769
О
Обеспечение надежности ПО
план, 686
Обзор, 844
автор, 865
демонстратор, 868
координатор, 866
неформальный, 853
регистратор, 866
рецензент, 866
формальный, 852
Область
КРА, 131
Ограничение, 760
Организация, 439
IEEE Computer Society, 614
зрелость, 442
матричная
сбалансированная, 451
сильная, 451
слабая, 451
матричный тип, 448
модель, 442
обобщенная модель, 443
персональный тип власти, 446

Предметный указатель 1121
плотность, 442
позиционный тип власти, 446
проективный тип, 448
размер, 442
рассеивание, 442
структура, 442
функциональная
диспетчер проекта, 449
координатор проекта, 450
функциональный тип, 448
Отказ при выполнении процесса, 676
Отказоустойчивость, 676
Отношение, 760
Оценивание
агрессивное, 482
Оценка размера ПО
блиц-модель. 351
количество строк кода, 325
метод Wideband Delphi, 353
метод объектных точек, 351
метод функциональных точек, 331
Оценка трудозатрат
человеко-дни, 371
человеко-месяцы, 371
человеко-часы, 371
Ошибка, 676; 730, 852
Ошибка при обработке, 676
Ошибки ПО, 676
П
Парадигма CQM
анализ данных с использованием
подпрограммы для оценки
соответствия целям и рекомендации
для дальнейшего
совершенствования, 721
определение метрических показателей,
необходимых для получения ответа
па вопросы, 715
определение набора вопросов,
характеризующих цели, 714
определение набора целей, 711
поддержка "обратной связи" для
организаторов проекта, 721
разработка механизмов сбора данных,
777
сбор, подтверждение и анализ данных в
реальном времени для поддержки
обратной связи между
корректирующими действиями и
проектами, 718
Парадигма GQM, 710
Параллельный инжиниринг, 165
План
SLCM, 282
SPMP, 248; 252
рисков, 580
ПО, 37; 38
SOUP, 680
надежность, 669
определение, 620
требование, 508
Показатель
АСАР, 701
СЕ, 875
EAF, 379
IRR, 243
MODP, 701
MTBF, 738
NRV, 243
РВР, 243
РСЕ, 874
SLA, 943
TDCE, 738
TDEV, 381
Полезность ПО
индекс обратной регистрации, 742
количество сбоев, 742
производительность ПО, 742
точность оценивания трудозатрат, 742
точность оценки графика, 742
удовлетворение запросов заказчика,
742
Портфель проектов, 197
Потоковый граф, 902
Предметная область, 183
процесс, 183
Презентация, 853
Приемочное испытание пользователем,
910
Принцип неопределенности, 469
Проблема, 676; 853
Проверка

1122 Предметный указатель
инспекционная, 853
Программа, 37; 41
Alignment Products and Processes, 221
WorkStyle Patterns Inventory, 219
Программный инжиниринг
определение, 619, 623
Продукт, 126, 699
COTS, 107
Поставляемый, 264
Проект, 37\ 38; 41
базовая линия стоимости, 977
буферный менеджмент, 997
Стадия, 267
управление затратами, 977
устранение, 974
Прототипирование, 145
эволюционное, 148
Процесс
Деминга-Шухарта-Ишикава, 1009
Процесс, 43; 92; 699
IEEE Standard 610, 620
I\'&V, 846
QA, 845
V&V, 844
Процесс SLCP, 104
P
Рабочий график, 475
PERT-диаграмма, 485
диаграмма Ганта, 484
диаграмма стадий, 484
критическая цепь, 497
критический путь, 497
логическая диаграмма, 485
метод ADM, 485
метод СРМ, 485
метод GERT, 485
метод PDM, 485
метод PERT, 485
бета-распределение, 488
перераспределение нагрузки, 492
сетевая диаграмма, 485
представление АОА, 485
представление AON, 485
таблица, 483
Рабочий пакет, 267
Разбиение эквивалентности, 893
Разработка проекта
на уровне архитектуры, 852
Распределение ресурсов проекта
идентификация и документирование
ролей и навыков, необходимых для
осуществления проекта, 422
матрица распределения обязанностей,
430
назначение обязанностей для
отдельных исполнителей, 424
организационное планирование, 421
отчеты о взаимосвязях, 430
Реинжиниринг, 185
Ресурс, 699
Риск
внешний,589
внутренний, 589
деловой, 583
известное в известном, 581
известное в неизвестном, 581
неизвестное в неизвестном, 581
операционный, 589
определение, 587
плана управления, 598
политический, 589
рыночный, 589
социальный, 589
технический, 589
управленческий, 589
чистый, 583
юридический, 589
С
Сбой при выполнении процесса, 676
Связность, 796
временная, 798
коммуникационная, 797
логическая, 798
последовательная, 797
процедурная, 798
синхронная, 799
функциональная, 796
Система, 37; 47
Система ARRS, 83
Система управления изменениями
проекта, 971
Словарь
DD, 755

Предметный указатель 1123
Совместное планирование требований,
152
Совместное проектирование
приложения, 152
Совокупность, 442
Соединение
подконтрольное, 795
содержательное, 796
стандартное, 794
типовое, 795
Спецификация
MSPEC, 794
PSPEC, 755
Спецификация SRS, 552
возможность верификации, 555
возможность трассировки, 555
завершенность, 554
корректность, 554
матрица трассировки, 567
оглавление, 557
однозначность, 554
предметный указатель, 570
приложение, 569
раздел 1. Введение, 557
раздел 2. Общее описание, 558
раздел 3. Специфические требования,
559
раздел 4. Информация о поддержке,
567
способность к изменению, 555
средства представления, 571
титульный лист, 557
упорядочение элементов согласно их
важности и/или устойчивости, 555
устойчивость, 572
язык, 571
Спиральная модель жизненного цикла
разработки ПО
действия, 301
Способность к трассировке, 853
Средневзвешенная стоимость капитала,
197
Стандарт
1074,114
MILSTD, 132
Структура OBS, 430
Структура WBS, 260
Структурированная модель
эволюционного быстрого
прототипирования жизненного цикла
разработки ПО
действия, 291
Студенческий синдром, 482
Т
Теория W, 166
Теория X, 218
Теория Y, 218
Теория Z, 218
Теория мотиватора/гигиены, 218
Теория ограничений, 495
Теория ожиданий, 217
Теория определения целей, 217
Тестирование
выполнение, 918
динамическое, 845; 879
"партизанское" тестирование, 886
альфа-тестирование, 885; 898
бета-тестирование, 885; 898
в достаточной степени оптимальное
тестирование, 886
инициализация ошибок, 885
инкрементное интеграционное
тестирование, 886
интеграционное тестирование, 887
интеграционный тест, 895
исследовательское тестирование, 886
код, 885
контрольный случай, 888
мутационное тестирование, 887
неисправность, 886
операционный профиль, 897
ошибка, 885
план тестирования, 888
поэлементное тестирование, 889
приемочное испытание, 884
приемочное испытание пользователем,
889
проект, 885
процедура тестирования, 889
регрессионное тестирование, 887; 898
сбой, 886
сертификация, 885
системное тестирование, 888
сквозное тестирование, 885
сравнительное тестирование, 885
тестирование безопасности, 887

1124 Предметный указатель
тестирование методом "белого ящика",
889
тестирование методом "черного ящика",
885; S91
тестирование на совместимость, 885
тестирование по принципу "заглушек",
885
тестирование по принципу
установки/удаления программы, 887
тестирование под нагрузкой, 887
тестирование под напряжением, 887
тестирование практичной пригодности,
889
тестирование рабочих характеристик, 8,
тестирование способности к
восстановлению, 887
тестирования методом "белого ящика",
890
функциональное тестирование, 886
динамичееское
тестирование работоспособности, 887
заключительное, 919
методом "черного" ящика, 683
объектно-ориентированное, 923
подготовка, 917
регрессионное, 846
Тетсирование
методом "белого" ящика, 683
Техническое задание.250
Требование, 508
к ПО, 853
к системе, 853
невообразимое, 509
неосознанное, 508
осознанное, 508
фактор CSF, 507
"треугольник ПМ", 39
У
Управление программным проектом
действие, 278
задача, 278
Управление проектами, 42
Управление процессом обеспечения
качества, 43
Устойчивость, 676
Ф
Фаза, 37; 46
Формулирование требований
анализ и обсуждение требований, 505
аттестация требований, 505
определение требований, 505
системное моделирование, 505
спецификация требований, 505
схема выбора, 532
Формулирование требований к ПО
диаграмма выбора, 533
интервью, 513
метод FAST, 526
методJAD, 527
метод QFD, 540
мозговой штурм, 518
схема мышления, 525
Функция
Нордена-Рейлайха, 403
X
XTRemeObjectMaker, 177
ц
Цикл
Шухарта-Деминга, 587
Цикл PDCA, 101
Ш
Шкала
абсолютная, 700
измерительная, 700
номинальная, 700
Э
Эволюционный ускоренный прототип, 145
Эксперт, 853
Экспертная оценка, 851
статическая, 844
Этап выполнение проекта
Как?, 244
Этап выполнения проекта
выполнение, 244
сделано, 244
что?, 243
почему?, 243
Этап оценивания трудозатрат
достижение целей, связанных с
оценкой затрат, 374

использование нескольких
независимых методик, 375
обзор точности оценивания, 376
определение требований по разработке
ПО, 375
разработка плана действий при
оценивании, 375
сравнение, понимание и
последовательный просмотр оценок,
375
учет максимально количества деталей,
375
Этический кодекс программиста
клиент и работодатель, 205
Пр ед метный указ атель 1125
коллегиальность, 205
критицизм, 205
менеджмент, 205
общественные интересы, 205
продукт, 205
профессионализм, 205
самосовершенствование, 205
Эффект
Хауторна, 709
Я
Язык
UML, 576; 937

Продолжение табл. 18.4
II
III
IV
VI
Участие в
выполнении
Заметная и основательная
поддержка
Опыт заказчика
Факторы, связанные с заказчиком
Вовлечение заказ- Конечные пользователи ши-
чика роко вовлекаются в работу
команды проектантов,
предлагая важную информацию
Конечные пользователи
имеют большой опыт работы над
подобными проектами, имеют
определенные идеи о том, как
выполнить их задачи
Конечные пользователи
владеют понятиями, им известно
о деталях системы, процесс
идет с учетом мнения
конечных пользователей
Задания по тренингу Задания по тренингу конеч-
заказчиков ных пользователей
согласованы, тренинг разрабатывается
или запускается
Доступность заказ'
чика
Подтверждение
действий со стороны
заказчика
Полное подтверждение со
стороны конечных
пользователей, точная реализация,
осведомленность
Непостоянная поддержка,
справки поддерживаются по
мере поступления запросов
Конечные пользователи
играют незначительную роль,
умеренное влияние в системе
Конечные пользователи
имеют опыт работы с подобными
проектами и имеют свои
представления о данном
проекте
Конечные пользователи
владеют большинством понятий,
имеют представление о
деталях системы, процесс идет с
учетом мнения конечных
пользователей
Задания по тренингу
конечных пользователей
согласованы, тренинг еще не создан
или разрабатывается план
тренинга
Поддерживается
подтверждение со стороны конечных
пользователей, имеются
некоторые вопросы по поводу
приложений
Отсутствует заметная поддержка,
нет помощи в затруднительных
случаях
Минимальная или же конечный
пользователь не привлекается,
небольшие объемы информации от
конечного пользователя
Конечные пользователи не имеют
опыта работы с аналогичными
проектами, неизвестно, как решать
стоящие перед ними задачи
Конечные пользователи не имеют
представления о понятиях или
деталях разработки системы
Требования не идентифицированы
или для них нет адресации
Отсутствует удовлетворительное
подтверждение для системы