Steve McConnel1


Soltwarl Еstillаtiоп:
IllIvstilviпа ·
thlllack Irt


Мiclosott .
Press




. EiИEiлиотr=КА проrРАММИСТА


с. Макконнелл


НОПЬНО СТОИТ
проrрIммны


,
ПРОЕНТ



.
 у с с к А Я


 А К
 И Я

ппТЕРФ


Москва · Санкт-Петербурr · Нижний HOBropoA · Воронеж
Ростов-на-Дону · Екатеринбурr · Самара · Новосибирск
Киев · Харьков · Минск
2007




ББК З2.97З
018
02
УДК 004.4
М15


Макконнелл с.
М15 Сколько СТОИТ проrраммный проект.
 М.: «Русская Редакция», СПб.: Питер,
2007.
 297 с.: ил.


ISBN 978
5
91180
090
1 (<<Питер»)
ISBN 978
5
 7502
0295
9 (<<Русская Редакция»)


.
в отличие от книr, опиршощихся исключительно на веточные методы (ВКЛIОЧая экономи

чески невыrодные в большинстве случаев непрерывные циклы обратной связи и жесткое Moдe

лироваНlIе), в этом уникальном издании предnаrается проверенный, удобный и реалистичный
подход к оценке затрат на разработку проrpаммных продуктов.
Автор этой Кllиrи является также автором всемирно известноrо бестселлера «Совершенный
код» .


ББК З2.97З
018
02
УДК 004.4


Подrотовлено к изданию по лицензионному доrовору с Мicrоsоft Соrpоrаtюп, Редмонд, Вашинrтон, США.
Microsoft, Excel, Microsoft Press, Vlsual Basic, Windows, and Windows NT являются товарными знаками или охраняемыми
товарными знаками корпорации Microsoft в США и/или друrих странах. Все друrие товарные знаки являются собственностью
соответствующих фирм.
Все адреса, названия компаний, орrанизаций и продуктов, а таЮl<е имена лиц, используемые в примерах, вымышлены и не имеют
никакоrо отношения к реальным компаниям, орrанизациям, продуктам и лицам.


ISBN 0735605351 (анrл.)
ISBN 978
5
91180
090
 1
ISBN 978
5
7502
0295
9


@ Перевод на русский язык Мiсrоsоft Corporation, 2007
@ Оформление и подrотовка к изданию 000 «Питер Пресс»,
000 «Издательство «Русская Редакция», 2007




Краткое содержание
Введение . . . . .
Блаrодарности . . . .
Об авторе. .. ....
От издател ьства
. . . .
13
17
. . . . 19
20
....... .
Часть 1. Основные принципы оценки
rлава 1. Что такое «оценка»? . . . .. ..... . . . 22
rлава 2. Какой из вас оценщик? . . . . . . . . . . . . . 34
rлава 3. О точности оценки ........ 39
rлава 4. Откуда берутся ошибки оценки? . . . . . . . . . .. . 50
rлава 5. Факторы, влияющие на оценку . . . . . . 71
Часть 11. Базовые методы оценки
rлава 6. Знакомство с методами оценки . . . . . . . 90
rлава 7. Подсчет, вычисление, экспертная оценка . . . . . . . . . . . . 95
rлава 8. Калибровка и исторические данные 102
rлава 9. Индивидуальные экспертные оценки . . . . . . 114
rлава 10. Декомпозиция и сводные оценки . ........ 122
rлава 11. Оценка по аналоrии . . . . . . 136
rлава 12. Опосредованные оценки . . . . . . . . . 143
rлава 13. Экспертные оценки в rруппах . . . . . 156
rлава 14. Оценочные проrраммы. . . . . . . .. 163
rлава 15. Использование альтернативных оценок 170

6 Краткое содержание
rлава 16. Формирование оценок в правильно оцениваемых проектах 175
rлава 17. Стандартизированные процедуры оценки . . . . . . . · .. 185
Часть 111. Конкретные проблемы оценки
rлава 18. Специфические проблемы при оценке размера. . . 200
rлава 19. Специфические проблемы при оценке объема работ . 211
rлава 20. Специфические проблемы при оценке сроков 224
rлава 21. Оценка параметров планирования . . . . . 235
rлава 22. Стили представления оценок ....... 252
rлава 23. Политика, переrоворы и решение проблем . 261
Приложение А. Проверка разумности оценки. . . . . 272
Приложение Б. Ответы на вопросы теста из rлавы 2 . 274
Приложение В. Рекомендации по оценке проrраммных проектов 275
Библиоrрафия . . . . . . . . . . .. ......... 286
Алфавитный указатель 295

Содержание
Введение . . . . . . . . . . . . . . . . . . . . . .
Оценка nporpaMMHbIX проектов: искусство или наука? .
Почему и для Koro написана эта книrа . . . .
Основные преимущества книrи. .
Чеrо нет в книrе
С чеrо начать . . . . . . . . .
. . . . . . . . . 13
. . . .. 13
14
15
16
. . . . . 16
Блаrодарности
Об а вторе. . . .
От издательства
. . . . . 17
. . . . . . . . . . . . 19
. . .. ..... 20
Часть 1. Основные принципы оценки
rлава 1. Что такое «оценка»? . ............... ... 22
1.1. Оценки, цели и обязательства ... . . . . . . . . 22
1.2. Связь между оценками и планами . . . . . . . . . . . . . . . . . . . . 23
1.3. Общение по вопросам оценок, целей и обязательств . . . . . . 24
1.4. Оценка как вероятностное утверждение . . . . . . . 25
1.5. Распространенные определения «хороших» оценок 28
1.6. Оценки и управление проектом ........... . . . . 30
1.7.Настоящеезначениеоценки. . . . . . . . . . . . . . . . . . . . . . 32
1.8. Рабочее определение «хорошей оценки». . . . . . . . 33
Дополнительные ресурсы . . . . . . . . . . . . .. 33
rлава 2. Какой из вас оценщик? . . . . . . . . . . .
2.1. Простой тест по оценке . . . . . . . . . . . . . . . . . . .
2.2. Обсуждение результатов теста. . . . . . . . . . . . . . . . . . . .
Насколько достоверна «90процентная достоверность»? . .
Как выбирать ширину диапазона? . . . . . . . . . . . . . . .
Откуда возникает стремление к сужению диапазонов? . . . .
Насколько показателен тест для реально.й оценки nporpaMMHbIX проектов?
. . . 34
34
35
35
37
37
38

8 Содержание
rлава 3. О точности оценки . . . . . . . . . · · · · · · · · · ·
3.1. Что лучше  переоценка или недооценка? . 39
ApryMeHTbI против переоценки . . . . . . 40
ApryMeHTbI против недооценки . . . . . . . . . . . . . . .. 40
Сравнивая apryMeHTbI . . . . . . . . . . . . . . . . . . 42
3.2. Достижения в области оценки проrраммных проектов . . .. .... 42
Насколько велики нарушения сроков? . . . .. .... 44
По данным одной компании . . . . . . . . . . . . . . . 44
Общесистемная проблема проrраммной отрасли . . 45
3.3. Преимущества точных оценок . . . . . . . . . . . . . . . . 45
3.4. Значение предсказуемости по сравнению с друrими желательными
атрибутами проекта . . . . . . . . . . . . . . .
3.5. Недостатки распространенных методов оценки .
Дополнительные ресурсы . . . . . . . . . . . .
. . . 39
. . 47
49
49
rлава 4. Откуда берутся ошибки оценки? . . . . . . .
4.1. Источники неопределенности в оценках . . . . . . . .
4.2. Конус неопределенности. . . . . . . . . . . . · · · · ·
Можно ли победить конус неопределенности?
Конус не сужается автоматически . . . . . .. ....
Учет конуса неопределенности в оценках nporpaMMHbIx проектов
Связь между конусом неопределенности и обязательствами
Конус неопределенности и итеративная разработка
4.3. Хаотические процессы разработки . . . . . . . . . .
4.4. Нестабильные требования . .
Оценка роста требований . . .
4.5. Пропущенные операции . . . .
4.6. Необоснованный оптимизм .....
4.7. Субъективность и пристрастие . . .
4.8. Импровизированные оценки . . . . . . .
4.9. Излишняя четкость . . . . . . . . . . . . . . . .
4.10. Друrие источники ошибки
Дополнительные ресурсы . . .
. . . . . . . . . . 50
. . . . . . 51
52
54
. . 55
. . 56
. . . . . . . . 57
. . 57
. . 58
. . 59
. . 60
61
. 63
.. .64
. . . . . . 66
. . 68
. . . . . . . . . 69
. 69
rлава 5. Факторы, влияющие на оцеt-iку . .... ....
5.1. Размер проекта . . . . . . . . . . . . . . . . . . . . . . . . . . .
Почему в книrе размер задается в количестве строк nporpaMMHoro кода?
Издержки масштаба . . . . . . . . . . . . . . . . . . . . . . .
Коrда можно смело иrнорировать издержки масштаба . . . . . .
Важность издержек масштаба при оценке проrpаммных проектов
5.2. Тип проrраммы . . . . . . . . . . . . . .
5.3. Факторы персонала . . . . . . . .
5.4. Язык проrраммирования .
5.5. Друrие факторы . . . . .
5.6. Снова об издержках масштаба .
Дополнительные источники . . . .
. . . 71
71
. . . 72
. 73
. . 76
. . 77
. . 78
79
. . 80 .
81
. 86
88
Часть 11. БаЗОВblе методы оценки
rлава б. Знакомство с методами оценки . .
6.1. Выбор методов оценки. . .
Что именно оценивается. .
Размер проекта .
Стил ь разработки . . . .
. . . 90
. . 90
. . 90
91
. 91

Содержание 9
Стадия разработки. . . . . . . . .
Возможная точность . . . . . . .
6.2. Таблицы применимости методов . .
. . 92
. . 93
. 93
rлава 7. Подсчет, вычисление, экспертная оценка. . . . . . . . . . . . . 95
7.1. Сначала подсчет. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 96
7.2. Что сч итать . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.3. Используйте вычисления для преобразования счетных показателей в оценки . . . 98
7.4. Используйте экспертное суждение только в крайнем случае . . . . . 100
Дополнительные ресурсы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
rлава 8. Калибровка и исторические данные . . . . . . . . . . . .
8.1. Улучшение точности и друrие преимущества исторических дaHHЫ
Учет орrанизационных Факторов . . . . . . . . . . . . . . . . . . . .
Предотвращение субъективизма и необоснованноrо оптимизма. . . . . . . .
Снижение влияния политических факторов при оценке . .
8.2. Сбор данных . . . . . . . . . . . . . . . . . . . . . .
Проблемы определения размера . . . . . . . . .
Проблемы измерения объема работ. . . . .
Проблемы измерения календарноrо времени  .
Проблемы измерения дефектов. . . .
Друrие проблемы сбора данных .......'.........
8.3. Способ калибровки . . . . . . . . . . . . .
8.4. Уточнение оценок по данным проекта. . . .
8.5. Калибровка средними отраслевыми данными
.. .
. . . 102
103
103
104
105
106
106
107
108
. . . . 108
109
109
110
. . . . 111
113
113
8.6. Итоrи ...................
. . .
Дополнительные ресурсы. . . . . . , . . . . .
rлава 9. Индивидуальные экспертные оценки
9.1. Структурированные экспертные суждения
Кто создает оценки? . . . . .. .
rранулярность . . . . . . . . .
Диапазоны . . . . .
Формулы . . . . . .
Контрольные списки.
9.2. Сравнение оценок с фактическими значениями
Дополнительные ресурсы. . . . . . . . . . . .
. . . . .
. . . . 114
115
115
. . . . . 115
116
. . . . . 117
119
119
121
. . . . . .
rлава 10. Декомпозиция и сводные оценки. . . . . . . . . . . .
10.1. Вычисление ожидаемоrо случая . . . . . . . . . . . . . . . . . . .
Закон больших чисел . . . . . . . . . . . . . . . . . . . . .
Насколько мелкими должны быть оцениваемые фраrменты?
10.2. Декомпозиция с использованием WBS . . . . . . . . . . .
10.3. Риск суммирования оценок для лучших и худших случаев. . . .
Осторожно: впереди математика! . . . . . . . . . . . . . . . .
rде произошел сбой? . . . . . . . . . . . . . . . . . . . .
10.4. Создание осмысленных общих оценок для лучшеrо и худшеrо случаев
Вычисление сводных оценок лучшеrо и худшеrо случаев при малом
количестве задач (упрощенная формула стандартноrо отклонения)
Вычисление сводных оценок лучшеrо и худшеrо случаев при большом
количестве задач (сложная формула crандартноrо отклонения) ....
Создание сводных оценок для лучшеro и худшеrо случаев . . . . . . . . .
Предупреждения по поводу достоверных оценок . . . . . .
Дополнительные ресурсы. . . . . . . . . . . . . . . . . . .
. . . . 122
122
124
124
. . . . . . . . 126
127
128
128
129
130
131
133
134
135

10 Содержание
rлава 11. Оценка по аналоrии . . . . . . . . . . . . . . . . . . . . · · 136
11.1. Основные принципы оценки по аналоrиям . . . . . . . . . . . . . . . . · · · 137
Шаr 1. Получение подробных данных об итоrовом размере, объеме работ
и затратах для предыдущеrо аналоrичноrо проекта. . . . . . . . . . . . . 137
Шаr 2. Сравнение размера HOBoro проекта с аналоrичным прошлым проектом . 138
Шаr З. Построение оценки размера HOBoro проекта в процентах от размера
cтaporo проекта . . . . . . . . . . . . . . . . . . . . . . . . · · .. 139
Шаr 4. Создание оценки объема работ на основе размера HOBoro проекта,
полученноrо сравнением с размером предыдущеrо проекта. . . . . .. 140
Шаr 5. Проверка соrласованности предположений между старым и новым
п рое кта м и . . . . . . . . . . . . . · · · · · · · · · ·
140
141
142
11.2. Замечания по поводу неопределенности в оценке Triad. ·
Неопределенность оценки, планы и обязательства . . .
rлава 12. Опосредованные оценки . . .. ....
12.1.Нечеткаялоrика................ ·
Как получить средние размеры . . . . . .
Классификация новой функциональности. . . . . .
Как не следует использовать нечеткую лоrику . · · · · · ·
Расширения нечеткой лоrики . . . . . . . . . . . · · ·
12.2. Стандартные компоненты . . . . . . . . · · · ·
Использование стандартных компонентов с процентилями
Оrраничения метода стандартных компонентов .
12.3. Абстрактные рейтинrи. . . . . .
О шкале абстрактных рейтинrов . . . . .
12.4. Метод футболки. . . . . . . . . . . . . . .
12.5. Друrие применения опосредованных методов
Дополнительные ресурсы. . . . . . . . . . . .
. . . . 143
144
144
145
145
146
146
148
149
149
151
152
155
155
rлава 13. Экспертные оценки в rpynnax . . . . . . . . . .
13.1.rрупповоеобсуждение . . . . . . . . . . . . . . . . · ·
13.2. Широкополосный Дельфийский метод . . . . . . . . . .
Эффективность широкополосноrо Дельфийскоrо метода
«Истина rдето рядом» . . . . . . . . . . . . . . . . .
Коrда применять широкополосныla Дельфийский метод . . . . . .
Дополнительные ресурсы. . . . . . . . . . . . . . . . . . . .
. . . . . 156
156
. . . . . 158
159
160
161
162
rлава 14. Оценочные nporpaMMbI. . . . . . . . . . .
14.1. Для чеrо необходимы оценочные проrраммы. . .
14.2. Данные, необходимые для калибровки проrрамм .
14.3. Оrраничения оценочных nporpaMM. . . . . .
14.4. Основные оценочные nporpaMMbI . . . . . . . . .
Дополнительные ресурсы. . . . . . . . . . . . . . .
rлава 15. Использование альтернативных оценок
Дополнительные ресурсы. . . . . . . . . . . . . . .
. . . . . . . . 163
. . . . . . . 163
. . . . 168
. . . . . . . .. 168
. . .. 168
169 .
. . . . . 170
. . . . . . 174
rлава 16. Формирование оценок в правильно оцениваемых проектах . . . 175
16.1. Формирование оценки в неправильно оцениваемом проекте . . . . . . . . . . 175
16.2. Формирование оценки в правильно оцениваемом проекте . . . . . . . . . . . 176
16.3. Хронолоrическая последовательность формирования оценки для вcero проекта . . 177
Формирование оценки в крупных проектах . . . . . 179
Формирование оценки в мелких проектах. . . . . . 179
16.4. Уточнение оценок. . . . . . . . . . . . . . . . . . . . . . 179

Содержание 11
16.5. Представление измененной оценки друrим ключевым сторонам проекта
Коrда представлять повторные оценки . . . . . . .. .....
Что делать, если начальство запрещает переоценку? . . . . . . .
16.6. Критерии правильной оценки проекта . . . . . . . . . .
180
181
182
183
rлава 17. Стандартизированные процедуры оценки .. ........ 185
17.1. Типичные элементы стандартизированной процедуры . . . . . . . . . . . . . 186
17.2. Адаптация оценки для процесса поэтапноrо контроля . . . . . . . . . . . . . 186
17.3. Пример стандартизированной процедуры оценки для последовательных проектов 189
17.4. Пример стандартизированной процедуры оценки для итеративных проектов . . 192
17.5. При мер стандартизированной процедуры оценки от проrрессивной орrанизации 194
17.6. Улучшение стандартизированной процедуры ................. 197
Допол н ител ьн ые ресурсы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
rлава 18. Специфические проблемы при оценке размера . . . . . .
18.1. Проблемы при оценке размера. . . . . . . . . . . . .. ....
Роль строк кода в оценке размеров . . . . . . . . . . . . . . .
18.2. Функциональные пункты ................
Преобразование функциональных пунктов в строки кода
18.3. Упрощенные методы вычисления функциональных пунктов
rолландский метод . . . . . . . . . . . . . . . . .
Элементы GUI ......... . . . . .
18.4. Сводка методов оценки размера .
Дополнительные ресурсы. . . . . .
Часть 111. Конкретные проблемы оценки
. . . 200
201
201
203
205
206
207
207
208
209
rлава 19. Специфические проблемы.при оценке объема работ . . . 211
19.1. Факторы, влияющие на объем работ . . . . . . . . . . . . . . 211
19.2. Вычисление объема работ по размеру . . . . . . . . . . . . . . . . . . . . . 213
Вычисление оценки объема работ посредством неформальноrо сравнения
с п рошл ы м и п роекта м и . . . . . . . . . . . . . . . . . . .. . 213
Какой объем работ включается в эту оценку? . . . . . . . .. ...... 214
19.3. Вычисление оценки объема работ научными методами . . . .. ...... 214
19.4. Среднеотраслевые rрафики объема работ . . . . . . . 215
19.5. Метод ISBSG ............... . 220
19.6. Сравнение оценок объема работ. . . . . . . . . . 222
Дополнительные ресурсы. . . . . . . . . . . . . . . . . 223
. . . 224
. 224
rлава 20. Специфические проблемы при оценке сроков. . . . . .
20.1. Базовая формула для вычисления срока . . . . . . . . .
20.2. Вычисление срока посредством неформальных сравнений
с прошлыми проектами . . . . . . . . . . . . . .. ........
20.3. Метод оценки первоrо порядка . . . . . . . . . . . . .
20.4. Вычисление оценки срока научными методами . . . . . . .
20.5. Сжатие rрафика и размер rруппы . . . . . . . . . . . . . . .
20.6. Соотношения между сроком и объемом работ . . .
Сокращение срока и размер rруппы. . . . . . . . . . . . . . .
20.7. Оценка срока и оrраничения численности rруппы '.
20.8. Сравнение результатов, полученных разными методами . . . .
Дополнительные ресурсы. . . . . . . . . . . . . . . . . .
226
. 227
. 228
. . . . . 228
. 231
. . 23 1
23З
. 234
. . . 235
rлава 21. Оценка параметров планирования . . . . . . .
21.1. Оценка операционной структуры проекта . . . . . . .
Оценка объема работ по разным .техническим операциям
. . . . 23б
. 236
. . . . . 237

12 Содержание
Оценка объема работ по требованиям ....
Оценка объема работ по управлению · ·
Оценка общеrо объема работ . · · · · · · · · ·
Поправки для типов проектов ..... · · · · · · · · ·
Пример распределения объема работы . · · · · · · · ·
Соотношения между численностью разработчиков и тестеров
21.2. Оценка срока для разных операций · · · · · · · · .. .....
21.3. Преобразование оценки в планируемый объем работы ·
21.4. Оценка стоимости . . .
Сверхурочные работы ..
Выбор типа затрат . . . . . · · ·
Друrие прямые затраты · · · · · · · · · · ·
21.5. Оценка дефектообразования и исправления · · · · · ·
Оценка работы по исправлению дефектов
Пример оценки эффективности исправления дефектов · · · ·
21.6. Оценка риска и резервные буферы . ....
21.7. Друrие эмпирические правила. .. ....
Дополнительные ресурсы. . . . . . . . . · · · ·
. 237
. 238
. 238
. 239
. 239
240
. 241
242
. 243
. 243
. 244
244
. 244
. 245
246
. 248
. 249
. 250
rлава 22. Стили представления оценок . . . . . . . . . . . . · . · 252
22.1. Представление предположений, заложенных в оценку . . . .. 252
22.2. Выражение неопределеннасти . . . . . . 254
Квалификаторы «плюс/минус» . . . . . . . . . 254
Квантификация рисков . . . . . . . . . . .' . . . . 254
Коэффициенты достоверности . . . . 255
Сценарные оценки . . . . . . 256
rрубая оценка дат и периодов времени . . . . . . . . . . 258
22.3. Диапазоны (любоrо типа) . . . . . . . . 258
Полезность диапазонноrо представления оценок . . . . 259
Диапазоны и обязательства ........... . . . . . . . . 260
Дополнительные ресурсы. . . . . . . . . . . . . . . . 260
rлава 23. Политика, переrоворы и решение проблем . ·
23.1. Особенности руководства . . . .'. . . .. ....
23.2. Влияние политических факторов на оценки
Внешние оrраничения ..........
Бюджет и даты . . . . . . . . . . . . . .
Переrоворы по поводу оценок и обязательств
Что делать, если ваша оценка не принята
Ответственность техническоrо персонала за обучение
23.3. Решение проблем и принципиальные neperoBopbI
Переrоворы как совместное решение проблем
Дополнительные ресурсы. . . . . . . . . . . . .
. . . . . . . . . . 261
. . .. . 261
. 262
. 263
263
. 263
. 264
264
265
. . . 266
. 271
Резу ль тат ..........................
. . . . 272
. . . . . 273
. 274
. 275
. 286
. . 294
Приложение А. Проверка разумности оценки. . . . .
Приложение Б. Ответы на вопросы теста из rлавы 2 .
Приложение В. Рекомендации по оценке проrpаммных проектов
Библиоrрафия . . . . . . . . . . . . . . . . . ·
Алфавитный указатель. . . . . . . . . . . . . . . . . . . .

Введение
Похоже, три самых тяжелых roда в обучении специалистов
по оценке приходятся на школьный курс арифметики.
Норман Р. OzacтUH
Оценка проrраммных проектов не так уж сложна. Эксперты ведут исследования
и пишут на эту тему уже около 40 лет; за это время был разработан целый ряд Me
тодов, обеспечивающих точную оценку проrpаммных проектов. Создание точной
оценки  дело простое и прямолинейное... коrда вы понимаете, как ее создать.
Но далеко не все методы оценки очевидны на интуитивном уровне, и даже очень
умный человек не сможет найти все полезные методы самостоятельно. Если
KTOTO является квалифицированным проrpаммистом, это еще не делает ero xopo
тим специалистом по оценке.
Мноrие аспекты оценки проrраммных проектов не видны с первоrо взrляда.
Нередко так называемые проблемы оценки обусловлены неверным пониманием
Toro, что же такое oцeHKa», или путаницеЙ с похожими, но не идентичными KOH
цепциями. Некоторые методы оценки кажутся полезными, но не дают точных pe
зультатов. Сложные формулы порой приносят больше вреда, чем пользы, тоrда
как обманчиво простые методы работают на удивление хорошо.
В этой книrе изложена суть четырех десятков лет исследований и еще более
долrой практической работы, направленной на то, чтобы разработчики, PYKO
водители проектов и специалисты по тестированию моrли эффективно работать
в области оценки проrраммных проектов. Знания в области оценки проrpаммных
проектов вообще полезны, потому что факторы, влияющие на оценку, также
влияют и на сам процесс разработки проrраммноrо обеспечения.
Оценка nporpaMMHbIX проектов:
искусство или наука?
в настоящее время исследования в области оценки проrpаммных проектов cocpe
доточены на совершенствовании методов оценки, чтобы передовые орrанизации
моrли проrнозировать результат с ТQЧНОСТЬЮ + 5 % вместо :1:10 %. В этих методах

14 Введение
задеЙствованы интенсивные вычисления, их понимание требует хорошей математи
ческой подrотовки и усердноrо, направленноrо изучения, а необходимая обработка
данных выходит далеко за рамки Toro, что l\10ЖНО проделать на ручном калькуляторе.
Такие rvlетоды лучше Bcero работают в виде специализированных коммерческих па
кетов оценки проrpаl\-IМНЫХ проектов. Я буду назьmать их 1lаучными мemодам-и оценки.
С друrоЙ стороны, типичная фирмаразработчик вовсе не стремится к по
вышению точности с + 10 % до + 5 %. Она пытается избежать оценок, ошибочных
на 100 % 11 более. (На то есть MHoro причин, которые подробно рассматриваются
в rлавах 3 и 4.)
Мы от природы склонны верить, что сложные формулы вида
Effort = 2 94 * ( KSLOC ) [0.91 + 0.01 * 2oJ=l slj] * П 7 ЕМ.
. 1=1 1
всеrда обеспечиваIОТ более точные результаты, чеrvI простые формулы
Затраты == КОЛllчествоФакторов х Сред1luеЗатраlпыНаФактор
Однако сложные формулы не всеrда лучше. Проrра1мные проекты находятся
под влиянием множества факторов, противоречащих мноrим допущениям, задей
cTBOBaHHbIl\1 в сложных фОРl\1улах научной оценки. Соответствующая динамика
будет рассмотрена далее в книrе. Более Toro, мноrие практические работники не
имеют ни свободноrо времени, ни желания изучать сложную математику, необхо
ДIlМУЮ для освоения научной оценки.
.
По этоЙ причине в книrе основное внимание уделяется эмпирике, процедурам
и простым формулам, высокоэффективным и одновременно понятным для прак
тикующих профессионалов в области проrраммноrо обеспечения. Такие методы
не обеспечивают оценок с точностью до :t5 %, но они сократят ошибку оценки
до + 25 % и менее; для большинства проектов этоrо вполне достаточно. Я буду Ha
зывать совокупность этих l\fетодов нефор.мальной оценкой.
Матерпал книrи основан как на научных, так и на нефОРlальных l\Iетодах, но
в целом книrа ориентируется на оценку проrpаммноrо обеспечения как искусство.
Почему и для Koro написана эта книrа
Литература, посвященная оценке проrpаммных проектов, весьма обширна. Ис
следователи опубликовали сотни статей, и мноrие из них достаточно полезны.
Однако у среднестатистическоrо практика нет времени следить за десятками CTa
тей в малопонятных технических журналах. Ранее было опубликовано несколько
книr, посвященных научной оценке. Такие книrи содержат по 800 1000 страниц,
требуют хорошеЙ матеl\lатическоЙ подrотовки и пишутся в основном для профес
сиональных оценщиков  консультантов или специалистов, которые часто зани
l\1аются оценкой крупных проектов.
Я написал эту книry для разработчиков, руководителей и специалистов по
тестированию, для которых построение оценок является лишь одной из MHO
rих составляющих повседневной работы. Полаrаю, мноrие практики хотели бы
улучшить точность своих оценок, но не располаrают своБОДНЫl\I временем для по
лучения докторскоЙ степени в области оценки проrраммных проектов. Им при

Основные преимущества книrи 15
ХОДИТСЯ решать практические вопросы: как обойти политические проблемы, свя
занные с оценкоЙ; как представить оценку, чтобы она была принята начальством;
и что нужно сделать, чтобы посторонние не моrли изменить оценку по своему
усмотреНИIО. Если вы относитесь к этой катеrории, значит, книrа написана для вас.
Методы, представленные в книrе, применимы к разработкам для Интернета
и интрасетеЙ, разработке BCTpoeHHoro проrра1мноrо обеспечения, ком:мерческим
системам, новым проектам, наследным системам, крупным проектам, Iелким про
ектам  словом, к оценке практически любых видов проrраммноrо обеспечения.
Основные преимущества книrи
Ориентируясь на неформальное искусство оценки, книrа освещает ряд важных
вопросов.
. Что такое oцeHKa? (Вероятно, вы думаете, что ответ на этот вопрос вам
уже известен, однако этот термин часто употребляется в неточном KOHTeK
сте, мешающем эффективной оценке.)
. Факторы, изза воздействия которых ваши прошлые оценки оказались Me
нее точными, чеl\-I моrли бы.
. Способы отличить хорошую оценку от плохой.
. Различные приемы, помоrающие лично вам создавать хорошие оценки.
. Некоторые приемы, которые помоrут друzим участникам вашей zpyппbl
создавать хорошие оценки.
. Пути создания хороших оценок в вашей орzа1-luзации. (Между методиками
личными, rpУППОВЫ1И И орrанизационными существуют важные различия.)
. Оценочные методы, работающие для проектов на базе rибких (agile) TeXHO
лоrий, и методы, ориентированные на традиционные, то есть последова
тельные (плановые) проекты.
. Оценочные методы, предназначенные для мелких проектов, и методы, pa
ботаIощие на крупных проектах.
. Искусство лавирования в бурных политических водах, часто окружающих
проблему оценки проrра1МНЫХ проектов.
Помимо лучшеrо понимания общих принципов оценки, материал книrи поможет
вам лучше оценивать конкретные атрибуты проrраМlНЫХ проектов, в том числе:
. Разработка новых проектов, включая планирование, объем и стоимость работ.
. Планирование, объем и стоимость работ по наследным системам.
. Количество функций, обеспечиваемых той или иной итерацией цикла раз
работки.
. Объем функциональности, обеспечиваемоЙ для Bcero проекта при фикси
рованном Bpe1eHHOM rрафике и раЗl\1ере rpуппы.
. Доля друrих необходимых операций, связанных с разработкой, включая
руководящую работу, постановку требований, конструирование, тестиро
вание и исправление недоста'Т,ков.

16 Введение
. Параметры планирования: соотношение между затратами и временем, оп
тимальный размер rpуппы, размер страховочноrо буфера, пропорции меж
ду численностью разработчиков и специалистов по тестированию и т. д.
. Параметры качества: вре1VIЯ, необходимое для исправления дефектов, pe
шение проблеl\-I с дефектами, оставшимися в проrраммном продукте во Bpe
мя выпуска, и друrие факторы.
. И вообще практически все, что вы захотите оценивать.
Во мноrих случаях описанные в книrе методы можно немедленно применять
на практике.
Мноrим: практичеСКИ1 специалистаI даже не потребуется выходить за рамки
концепций, представленных в книrе. Тем не менее понимание изложенных прин
ципов заложит основу для последующеrо перехода к друrим методам,' базирую
щимся на математических расчетах.
Чеrо нет в книrе
В книrе не рассматриваются вопросы оценки очень крупных проектов (более одноrо
миллиона строк проrpаммноrо кода, или более 100 человеколет). Очень крупные
проекты должны оцениваться профессионалами, прочитавшими десятки статей
в малопонятных технических журналах, изучившими книrи по 8001000 страниц,
знаком:ыми с коммерческими оценочными проrраммами, поднатореВШИIИ как
в научных, так и в нефОр1альных методах оценки.
с чеrо начать
Выбор отправноЙ точки зависит от Toro, что вы хотите получить от этой книrи.
. Если выкупили КllИlУ, потому Ч'!lО вам llУЖ1l0 составить оцеllКУ прямо сей
час... Начните с rлавы 1, а зате1Vl переходите к rлавам 7 и 8. После этоrо
кратко пройдитесь по рекомендациям в rлавах 1020 и найдите те методы,
которые принесут Ba1 l\-lаКСИlальную непосредственную пользу. Кстати,
приводимые в тексте рекомендации выделены и пронумерованы, и все они
(118) также собраны в приложении Б, Рекомендации по оценке проrрамм
ных проектов.
. Если вы хотите повысить ЛИЧllУЮ квалификацию в области оцеllКИ, улуч
шить свою репутацию в Орlанизации или стремитесь лучше разобраться
в области оценки прОlрЧНЬLX проектов в целом... Прочитайте всю книry.
Если вы хотите понять общие принципы перед тем, как поrружаться в дe
тали, читаЙте все подряд. Если же вы предпочитаете сначала ознаКО1ИТЬСЯ
с деталями, а затем выводить из них общие заключения, начните с rлавы 1,
прочитайте rлавы 723, а потом вернитесь к пропущенным rлаваl.
Бельвью, ВаШUlllтОll
Новый lOa 2006

Бла rода рности
Не перестаю поражаться тем возможностям, которые открывает Интернет для
повышения качества работы. Почти все рецензенты рукописи моей первой книrи
жили не далее чем в пятидесяти милях от меня. С рукописью этой книrи работа
ли рецензенты из Арrентины, Австралии, Канады, Дании, Великобритании, [ep
мании, Исландии, Нидерландов, Северной Ирландии, Японии, Шотландии, Ис
пании и Соединенных Штатов. Эти рецензии оказали orpoMHoe положительное
влияние на качество книrи.
Прежде Bcero я блаrодарен людям, предоставившим свои комментарии по зна
чительному объему материала: Фернандо Берзал (Fernando Berzal), Стивен Блэк
(Steven Black), Дэвид Э. Берджесс (David E.BUI.gess), Стелла М. Бернс (Stella М.
Burns), rевин Берроуз (Gavin Burrows), Дейл Кэмпбелл (Dale СаrnрЬеll), Роберт
А. Клинкенберд (Robert А. Clinkenbeard), Боб Коррик (ВоЬ Corrick), Брайан Дo
нальдсон (Brian Donaldson), Джейсон Хиллз (Jason Hills), Уильям Хорн (William
Horn), Карл Дж. Кристофчик (Carl J. Krzystofczyk), Джеффри Д. Мозер (Jeffrey
D. Moser), Томас Освальд (Thomas Oswald), Алан М. Пиндер (Alan М. Pinder),
Джон Прайс (Jon Price), Кэти Род (Kathy Rhode), Саймон Робби (Sirnon Robbie),
ЭДfУНД Швеппе (Edmund Schweppe), Джеральд Саймон (Gerald Simon), Крейr Р.
Смит (Creig R. Smith), Линда Тейлор (Linda Taylor) и Бернд Вифхьюз (Bernd
Viefhues).
Также спасибо тем, кто рецензировал отдельные части книrи: Лиза М. Адамс
(Lisa М. Adams), Хакон ArycTccoH (Hakon Agustsson), Брайон Бейкер (Bryon
Baker), Тина Колман (Tina Coleman), Крис Кроуфорд (Chris Crawford), Доминик
Кронин (Dorninic Cronin), Джерри Девилль (Jerry Deville), Конрадо Эстол (Conrado
Estol), Эрик Фриман (Eric Freeman), Хидэо Фукумори (Hideo Fukumori), С. Дейл
Хильдебрандт (С. Dale Hildebrandt), Барбара Хитчинrс (Barbara Hitchings), Джим:
Холмс (Jim Holmes), Рик Хауэр (Rick Hower), Кевин Хатчинсон (Kevin Huntch
inson), Фуннур Храфн Джонссон (Funnur HrafnJonsson), Аарон Киандер (Aaron

18 Блаrодарности
KiandeI), MeXl\tIeT Керем Кизилтунк (MehInet Kerem Kiziltunc), СеЛИl\IИР Кустудик
(Selin1iI Kustudic), Молли Дж. Maxai;'r (Моllу J. Mahai), Стив Маттинrли (Steve
Mattingly), Джо Николае (Joe Nicholas), Эл Ноэл (Al Noel), Дэвид o'дoHoxыo
(David О'Донохью), Шелдон Пореина (Sheldun Porcina), Дэвид Дж. Престон (David
J. Preston), Дэниел Рид (Daniel Read), Дэвид СпокеЙн (David Spokane), Д)канко
Танис (JaIlco Tanis), Бен Тилли (Вен Tilly) и Венди Бильrельм (\Vcl1dy Wilhelln).
Мне хотелось бы выразить особую ПРIIзнательность преподавателям семинаров
Construx по вопросам оценки проrраМ!vIНЫХ проектов. После fvlноrолетних дис
куссиЙ часто бывает неВОЗ10ЖНО сказать, какие идеи принадлежат мне, а какие 
им. Спасибо Эрлу Биду (EaI"1 Beed), [perry Боэру (Gregg Боеr), 1\IIэт1'У Пелокви
ну (Matt Peloquin), Памеле Перро (Pamela Perrott) и Стиву Токи (Steve Tockey).
Книrа посвящена неформальныl'll MeToдaI оценки, но введенные в неЙ упро
щенные методы стали ВОЗl\-IОЖНЫ блаrодаря исследоватеЛЯ?vI, в течение десятиле
тиЙ изучавших научные способы оценки. Я искренне блаrодарен TpeI rиrантаl\1
в области научной оценки: Барри Бему (BaITY Boehm), Кейперсу Джонсу (CapeI"s
Jones) II Лоуренсу ПаТНЭIУ (Lawrence Putnam).
Мне снова выпала привилеrия работать с ДеВОНОl\-1 МасrpеЙВОlVI (Devon Mus
grave), РУКОВОДlIтелем проекта этоЙ книrи. Спасибо, Девон! Бека МаккеЙ (Becka
lVIcKay), заlVIеститель редактора, также во мноrих отношениях способствовала улуч
шению IIСХОДНОI':'I РУКОПИСИ. Я также блаrодарен остальным работникам Мiсrоsоft
Press: это Патрисия Бредбери (Patricia Bradbury), Карл Дилц (Carl Diltz), Трейси
Фрил (TIacey Freel), Джесси [уд (Jessie Good), Патрисия Массерман (Patricia
Masserman), Д)I(ЭЛ Панчо (Joel Panchot) и Сэнди Резник (Sandy Resnick). Также
спасибо составителю алфавитноrо указателя Сету i\1еЙслину (Seth Maislin).
Остается лишь поблаrодарнть !\10Ю )кену Эшли  лучшеrо (по Iоей оценке)
спутника жизни, на KOToporo только я Mor надеяться.

Об авторе
Стив Макконнел работает ведушим проrра!\IМИСТО1 в КО!\-Iпании Construx Soft\vare.
Он является руководителе1 направления конструкторскоЙ информации в проекте
Soft\vare EngineeI'ing Body of Kno\\rledge (SWEBOK). Стив работал над проrра!vl!\-I
ными просктами в Microsoft, Boeing и друrих компаниях, расположенных в Сиэттле.
Он был веДУЩИ!vI разработчиком Constrllx Еstilпаtе и SPC Estimate Professional,
лауреатом преМlIИ )I(урнала «Soft\vare DеvеIОРП1епt».
Стив является aBTopO!v1 KHIIr «Rapid Development» (1996), «Software Project
Survival Guide» (1998), «PIofessional Soft\\rare DеvеlОРlпепt» (2004) и «Code Com
plete, 2nd Edition» (2004). Ero КН]lIИ дважды завоевывали ежеrодную преМИIО
журнала «Soft\vare DеvеlОРП1епt» за Ca!\'IbIe выдающиеся публикации в области
разработки проrраl\1мноrо обеспечеНIIЯ. СТIIВ также БыIл ведущим разработчиком
проrраl\-IМЫ SPC Estimate Рrоfеssiопаl, удостоенной преl\1ИИ за пrоизводитель
ность в разработке проrраrvl:Vlноrо обеспечения. В 1998 rоду читатели журнала
«Soft\\;rare DеуеlОРlпепt» назвали Стива одним нз трех самых влиятельных людей
в отрасли разработки проrраrvlмноrо обеспечения наряду сБиллом rейтсом и Ли
нусом Торвальдсом.
Стив получил степень бакалавра в колледже УИТl\1ена и степень маrистра в об
ласти проrраrvlмотехники в университете Снэттла. Он живет в Бельвью, штат
ВаШIIНrтон.

От издател ьства
Ваши замечания, предложения, вопросы отправляйте по адресу электронной
почты comp@piter.com (издательство Питер, компьютерная редакция).
Мы будем рады узнать ваше мнение!
На вебсайте издательства http://www.piter.com вы найдете подробную инфор
.
мацию о наших книrах.

Основные
принципы оценки
rлава 1. Что такое «оценка»?
rлава 2. Какой из вас оценщик?
rлава з. О точности оценки
rлава 4. Откуда берутся ошибки оценки?
rлава 5. Факторы, влияющие .на оценку

Что такое «оценка»?
Очень трудно составить энерrичное, правдоподобное обос
нование для оценки, которая не базируется на количест
венных методах, практически не поддерживается дaHHЫ
ми и продвиrается в основном усилиями начальства.
Фред Брукс
Вероятно, вы полаrаете, что вам не нужно объяснять, что такое 40цeHKa. К концу
этой rлавы я постараюсь убедить вас, что смысл термина oцeHKa отличается от
Toro, что в Hero вкладывает большинство людей. А хорошая оценка отличается от
общепринятоrо понимания еще сильнее.
Вот определение слова 40цeHKa из словаря: 1. приблизительный проrноз или
вычисление. 2. предварительный расчет стоимости проекта. 3. суждение, OCHO
ванное на впечатлениях; личное мнение.
Насколько это похоже на то, что вам нужно сделать при оценке проrpаммноrо про
екта? Можно ли назвать такой результат при6лuзuтельным или предварительным 
иначе rоворя, предполаrается ли, чтq вы сможете изменить свою оценку позднее?
Вероятно, нет. Коrда начальство требует у вас «оценки, оно часто подразуме
вает некое обязательство по соблюденю поставленной цели. Различия между
оценками, целями и обязательствами чрезвычайно важны для пони мания Toro,
чем является оценка, чем она не является и как повысить качество ваших оценок.
1.1. Оценки, цели и обязательства
CTporo rоворя, словарное определение термина «oцeHKa верно: оценкой называ
ется проrноз относительно Toro, сколько времени или денеr потребуется для pea
лизации проекта. Однако в контексте проrpаммных проектов оценка увязывается
с деловыми целями, обязательствами и контролем.
Целью называется формулировка деловой задачи'. Примеры целей.
. Версия 2.1 должна быть rOToBa к демонстрации на выставке в мае.
. Мы должны получить стабильную версию продукта до наступления пред
праздничных lродаж.

1.2. Связь между оценками и планами 23
. Затраты на следующую версию оrраничиваются двумя миллионами  это
максимальный бюджет, который нам удастся получить.
у фирм имеIОТСЯ веские причины для постановки целей, не зависящих от oцeH
ки проrраммных проектов. Но тот факт, что цель является желательной или даже
абсолютно необходимой, еще не означает, что она достижима.
Если цель может рассматриваться как описание деловой задачи, обязательство
является обещанием предоставить некоторую функциональность на соrласованном
уровне качества к конкретной дате. Обязательство может совпадать с оценкой,
может быть более аrрессивным или более консервативным. Друrими словами, не
ставьте знак равенства между обязательством и оценкой; это разные понятия.
СОВЕТ NQ 1
Не путайте оценки, цели и обязательства.
1.2. Связь между оценками и планами
Оценка и планирование  взаимосвязанные Tel\fbI, но оценка не является плани
рованием, а планирование  оценкоЙ. Оценка должна рассматриваться как объ
ективный, аналитически:Й процесс; планирование должно рассматриваться как
процесс изначально субъективный, целенаправленный. В контексте оценки было
бы рискованно изначально рассчитывать на получение HeKoToporo KOHKpeTHoro
ответа. Целью является точность проrноза, а не достижение KOHKpeTHoro резу ль
тата. С друrой стороны, под целью планирования понимается конкретный pe
зультат. Мы намеренно (и целесообразно) воздействуем на свои планы для дoc
тижения желаемоrо исхода. Мы планируем конкретные средства, необходимые
для достижения конкретной цели.
Оценки формируют основу для планов, но планы не всеrда совпадают с oцeH
ками. Если оценки радикально отличаются от целей, планы проектов должны
распознать этот разрыв и заложить более высокую степень риска. Если оценка
близка к цели, планы также становятся менее рискованными.
И оценка, и планирование важны, но фундаментальные различия между ними
означают, что попытки их объединения обычно приводят к плохим оценкам u пло
хим планам. Наличие сильной цели планирования может привести к тому, что
цель подменит оценку, полученную аналитическим путем; участники проекта дa
же MOryT называть цель «оценкой, придавая ей ореол объективности, KOToporo
она в действительности не заслуживает.
Примеры факторов планирования, частично зависящих от точности оценки:
. построение подробноrо rрафика;
. идентификация критическоrо пути проекта;
. создание полной декомпозиции работ!;
. выбор приоритетной функциональности для сдачи на промежуточных этапах;
. разбиение проекта на итерации.
1 W ork breakdown structure.  Прuмеч. 'nерев.

24 rлава 1 · Что такое «оценка»?
Точные оценки повышают качество выполнения работы по каждой из этих об
ластеЙ (в rлаве 21 приводятся более подробные сведения по всем перечисленным
вопросам).
1.3. Общение по вопросам оценок,
целей и обязательств
Одним из последствий тесных, а иноrда и сбивающих с толку связей между oцeH
ка!\IИ и планированием являются недоразумения, возникающие при общении Me
)кду критическими фиrураrvIИ проекта. Пример типичноrо недоразумения.
Директор: Как вы дУJиаете, сколько времени займет nроект? ПрОlра.м.ма дОЛJIC1-lа
быть zотова через 3 месяца, к выставке. Я не MOZY дать больше людей в zpynny,
поэтому вам придется обойтись теКУЩШt nерсоналом. Вот список тех функций,
которые НаА! llYJJC1-lbl.
Руководитель проекта: Ладно, я 1leMHOZO посчитаю, а потом снова зайду к вам.
Позднее...
Руководитель nроекта: По моей оценке, проект займет 5 месяцев.
Директор: Пять месяцев?! Вы что, меня не слушаеlпе? Я же сказал, что npo
zpaм..мa нужна нам через 3 месяца, к выставке?
Вероятно, после этоrо разrовора.руководитель проекта будет считать директора
ненормальным, ПОТОl\fУ что он требует втиснуть 5месячный объем работы в 3 Me
сяца. Директор же сочтет, что руководитель проекта не понимает деловых реалий
и не сознает, как важно, чтобы проrрамма была [отова к выставке через 3 месяца.
Обратите ВНИ!\'Iание: в ЭТО!\f примере директор в действительности не просит
оценки, а хочет получить от руководителя проекта плаll для достижения постав
ленной цели. Большинство начальников не обладает техническим образованием,
которое бы позволило им различать оценки, цели, обязательства и планы. Таким
образом, технический руководитель обязан сам преобразовать запрос начальства
в конкретные технические термины.
Вот более продуктивный сценарий TaKoro общения.
Директор: Как вы думаете, сколько времени займет nроект? Проzра.м.ма дОЛЖ1lа
быть zотова через 3 "месяца, к выставке. Я 1lе MOZY дать больше людей в lpynny,
поэтому вам придется обойтись текущим nерСОllалом. Вот список тех функций,
которые нам HY:J/C1-lbl.
р'уководитель nроекта: Давайте убедимся в том, что я вас правWlЬ1l0 nОllЯJl.
Что для 1lас ва,/снее  реализовать все возможности на 100 % Wlи u.м,eтb хоть
чтонибудь zотовое к выставке?
Директор: И,Л,tеть чтОllибудь zотовое к выставке. Ну u хотелось бы реализо
вать все вОЗМО'IC1l0сти на 100 %, если получится.
Руководитель проекта: А что делать, если окажется, что npozpaм..мa не zотова
1lа 100 % к выставке? Приzотовиться показать то, что есть, Wlи перенести
дату выхода на более поздний момент?

1.4. Оценка как вероятностное утверждение 25
Директор: Мы обязательно должны чтонибудь показать 1lа выставке. Если
время будет поджu.м,ать, oтпpaвu.м, то, что есть, даз/се если 11родукт ие будеl1Z
zomoB на 100 %.
Руководитель проекта: Хорошо. Я подzотовлю план, который позволит нам
реализовать как MOJlC1l0 большую долю ФуuкционаЛЬ1l0сти за следующие три
месяца.
СОВЕТ NQ 2
Коrда вас просят предоставить оценку, определите, что именно нужно спрашивающему  oцeH
ка или план достижения цели.
1.4. Оценка как вероятностное утверждение
Как известно, около трех четвертей проrpаммных проектов превышают свои oцeH
ки. Вероятность Toro, что любой отдельный проект завершится к поставлеННОl\1У
сроку и без нарушения бюджета, отлична от 100 %. Но стоит Ha1 признать, что
вероятность cBoeBpeMeHHoro завершения отлична от 100 %, возникает очевидный
вопрос: «Если не 100 %, то сколько?» Это один из центральных вопросов в облас
ти оценки проrраммных проектов.
Обычно оценки проrраммных проектов представляются в виде обычных чи
сел, например: «Этот проект займет 14 недель. Подобные упрощенные точеч
ные оценки бессмысленны, потому что они не включают никакой информации
о вероятности, связанной с точечной оценкой. Подразумевается ситуация, пред
ставленная на рис. 1.1,  возможен единствеН!iЫЙ исход, которым является за
данная точка.
1 00 0/0
Единственный возможный результат
(вероятность 100 %)
Вероятность
Сроки (или Затраты, или Рабочее время)
Рис. 1.1. Точечная оценка подразумевает стопроцентную вероятность совпадения
фактическоrо исхода с запланированной оценкой. В жизни так не бывает
Точечная оценка на поверку обычно оказывается целью, замаскированной под
оценку. Иноrда она возникает в результате удаления осмысленной вероятност
ной информации из более сложной и содер;жательной оценки.

26 rлава 1 · Что такое «оценка»?
СОВЕТ NQ 3
Сталкиваясь с точечной «оценкой», спросите себя, действительно ли это число является oцeH
кой или на самом деле перед вами цель.
Точные оценки учитывают, что проrраммные проекты подверrаIОТСЯ влиянию
l\fножества факторов неопределенности. В совокупности эти факторы неопреде
ленности означают, что результат проекта подчиняется вероятностному распре
делению  одни результаты более вероятны, друrие менее вероятны, а наиболее
вероятная rpуппа результатов сосредоточена rдето в середине распределения.
Можно было бы предположить', что распределение результатов проекта будет
иметь вид кривой нормальноrо распределения (рис. 1.2).
Номинальнь й результат
Вероятность
Сроки (или Затраты. или Рабочее время)
Рис. 1.2. Часто предполаrается, что результаты nporpaMMHoro проекта распределяются
по нормальному закону. Такое предположение неверно, потому что эффективность
выполнения любоrо заданноrо объема работы rруппой, работающей над проектом,
является оrраниченной величиной
Каждая точка кривой представляет вероятность Toro, что проект будет завер
шен точно к соответствующей дате (или на Hero уЙдет точно эта сумма). Площадь
под кривой представляет суммарную вероятность 100 %. Вероятностное распре
деление TaKoro рода учитывает возможный разброс результатов. Тем не менее
предположение о симметричном распределении результатов по отношению к cpeд
ней величине некорректно. Качество выполнения проекта является величиной
u u u
оrpаниченнои; это означает, что левы и краи распределения усекается вместо Toro,
чтобы бесконечно убывать, как в нормальном распределении. И хотя «удачные
результаты проекта оrраничены, возможности для «неудач безrраничны, поэто
му вероятностная кривая уходит очень далеко вправо.
На рис. 1.3 изображено уточненное представление вероятностноrо распреде
ления результатов проrраммноrо проекта.
Вертикальная пунктирная линия изображает «номинальный» результат, или
результат 50/50  существует 50%я вероятность Toro, что проект завершится
лучше, и 50%я вероятность Toro, что он завершится хуже. В статистике такой pe
зультат называется медианой.
На рис. 1.4 изображен друrой способ представления подобных вероятност
ных распределений. Если rpафик на рис. 1.3 показывает вероятность завершения

1.4. Оценка как вероятностное утверждение 27
проекта к конкретной дате, на рис. 1.5 показана вероятность завершения к KOH
кретной дате Wlи ранее.
1 00 0/0
Номинальный результат
(оценка 50/50)
Вероятность
Сроки (или Затраты, или Рабочее время)
Рис. 1.3. Уточненное представление возможных результатов nporpaMMHoro проекта.
Возможности удачноrо выполнения проекта оrраничены, но количество
потенциальных проблем бесконечно
1 00 0/0
Вероятность
завершения проекта
к определенной дате
или ранее (или 50 0/0
с определенными
затратами/объемом
работ и менее
Номинальный результат
(оценка 50/50)
Сроки (или Затраты, или Рабочее время)
Рис. 1.4. Вероятность завершения nporpaMMHoro проекта к определенной дате или ранее
(или без превышения определенных затрат или объема работ)
На рис. 1.5 идея вероятностных оценок проектов представлена с друrой точки
зрения. Как видно из рисунка, из rолословной оценки «18 недель пропадает ин
тересная подробность  что срок в 18 недель будет достиrнут с вероятностью Bce
ro 10 %. Оценка «от 18 до 24 недель более информативна и несет полезную ин
формацию о вероятном диапазоне результатов проекта.
СОВЕТ NQ 4
Если вы сталкиваетесь с точечной оценкой, скорее Bcero, ее вероятность отлична от 100 О/о.
Спросите себя, какова вероятность получения этоrо Числа.
Существуют различные способы выражения вероятностей, ассоциируемых
с оценками. Можно использовать процентное выражение: «Мы на 90 % уверены
в соблюдении 24недельноrо cpOKa. Можно описывать оценку в виде диапазона
лучший/худший случай, подразумевающем ероятность: «В лучшем случае про
ект будет завершен за 18 недель, а в худшем  за 24 недели. Наконец, можно

28 rлава 1 · Что такое «оценка»?
просто сформулировать предполаrаемый результат в виде диапазона вместо TO
чечной оценки: По нашей оценке, на проект уйдет от 18 до 24 недель. Принци
пиально здесь то, что любая оценка включает вероятность (явно или KOCBeH
но). Явное указание вероятности является одним из признаком хорошей оценки
\
+ :.
. '"1 ... :
. .)o. . .
.:;{ ..:
J ::.:.
. .{ .
" 1 .:;
  . .
Предполаraемое
время завершения
24 недели
22 недели
20 недель
18 недель
16 недель
14 недель
12 недель
1 О недель
8 недель
6 недель
4 недели
2 недел.и
Вероятность
успеха
90 0/0
75%
50 0/0
10 0/0
00/0
., ..
.,:,+ .
. .,...
-: :: . - .
'. .
: 1:Y': .
: .v..
, : : .:
- '. ':'. .: - .
.:.' ;
:.'. .:.
. .:-.'
. 'у .
"-:",.. . .
}, -. :
.' . .
:.. .. -
. }: :.'
Рис. 1.5. Любая точечная оценка связывается с вероятностью (явно или косвенно)
Ваше обязательство может относиться к оптимистичной или пессимистичной
rpанице диапазона оценки  или к любой позиции в середине. Важно знать, к Ka
кой части диапазона относится ваше обязательство, чтобы соответственно плани
ровать свои действия.
1.5. Распространенные определения
«хороших» оценок
Даже разобравшись с тем, что такое oцeHKa, мы остаемся с друrим вопросом:
что такое хорошая оценка? Эксперты предлаrают разные определения хороших
оценок. Кейперс Джонс (Capers]ones) утверждал, что точность + 10 % достижима,
но только в проектах с высокой степенью контроля (]ones 1998). Хаотичные про
екты слишком непредсказуемы для достижения такой степени точности.
В 1986 rоду профессоры Конт, Дансмор и Шен предположили, что хорошая
оценка должна в 75 % случаев отличаться от фактическоrо результата не бо
лее чем на 25 % (Conte, Dunsmore, Shen 1986). Этот стандарт до настоящеrо
времени является самым распространенным для выражения точности оценок
(Stutzke 2005).

1.5. Распространенные определения «хороших» оценок 29
Различные компании сообщали о результатах, близких к критерию точно
сти, предложенному Контом, Дансмором и Шеном. На рис. 1.6 показаны оценки
и фактические результаты для ряда проектов ВВС США.
600%
500 О/о
'"


400 0/0
Фактические
результаты в процентах 300 01'0
от проrнозируемоrо

о
200 0/0
0%
1 00 0/0
1
2
з
Уровень СММ орrанизации, проводящей проект
Источник: «Корреляционный анализ СММ и эффективности разработки
nporpaMMHoro обеспечения» (Lawlis. Flowe and Thodahl, 1995)
Рис. 1.6. Улучшение качества оценок в проектах ВВС США. Предсказуемость проектов
существенно улучшилась с переходом орrанизаций на более высокие уровни смм 1
На рис. 1.7 изображены резуль-r-аты аналоrичной проrраммы повышения эф
фективности в компании Боинr.
+150 %
Ошибка
оценки
0%
Данные, использовавшиеся
для оценки всех проектов
I I
150 %
..
2 3 4
5
1
Уровень СММ
Рис. 1.7. Повышение качества оценок в компании «Боинr». Как и в случае с ВВС США,
предсказуемость проектов радикально улучшается на более высоких уровнях СММ
Последний аналоrичный пример на рис. 1.8 был получен при улучшении pe
зультатов оценки в Schlumberger.
1 СММ (Capability Maturity Model)  система, определенная Институтом по разработке
nporpaMMHoro обеспечения (Software Engineering Institute) для оценки эффективности
орrанизаций. работаlОll1ИХ в области разработки nporpaMMHoro обеспечения.

30 rлава 1 · Что такое «оценка»?
35
ЗА
25
20
Среднее
превышение 15
(в неделях)
10
5
О
5
1
(4)
2
(О)
з
3
4
3)
5
(4)
6
(2)
7
(3)
Начальный период полуrодия
(количество проектов)
Рис. 1.8. Schlumberger повысила точность своих оценок от CpeдHero
превышения в 35 недель до среднеrо отставания в одну неделю
Одна из моих компанийклиентов завершает 97 % своих проектов вовреIЯ
11 в paIKax бюджета. КОl\IIпания Telcordia сообщает, что ей удается завершать 98 %
проектов в срок и без нарушеНИ?I бюджета (Pitterrnan 2000). Аналоrичные pe
зультаты публикопались ?vfножеством друrих КО?vlпаний (Pitnarn and Myers 2003).
Орrанизации создаIОТ хорошие оценки как по определению Джонса, так и по оп
ределеНИIО Конта, ДаНС?vl0ра и Шена. Тем не менее в обоих определениях OTCYTCT
вует одна важная концепция  а именно то, что точность результатов оценки не
достиrается за счет одних лишь методик оценки. Она также должна поддержи
ваться эффективным управление?vI проектом.
1.6. Оценки и управление проектом
Иноrда при обсуждении оценки проrpаммных проектов оценка раССl\fатривается
исключительно как проrноз. Все выrлядит так. словно оценка производится бес
пристраСТНЫl\1 оракулом, наХОДЯЩИl\1СЯ [дeTO в OTKpbITOl\.I Koclvloce, никак не свя
заННЫl\'1 с планпрованиеl\1 проекта и назначеНИЯl\ПI приоритетов.
В действительности опенка проrpal\;llvlНЫХ проектов не является столь отвлечен
НЬПvl делом. Если KOMYTO захочется увидеть пример принципа неопределенности
rейзен6ерrа в области проrpаМIноrо обеспечения  достаточно взrлянуть на oцeH
ку проектов. (Принцип неопределенности rейзенберrа состоит в TOf, что ca1 факт
наблюдения за явлениеlvl приводит к ero изменению, и наблюдатель никоrда не
"Iожет быть полностью уверен в том, как повел бы себя объект при отсутствии Ha
блюдения.) Сначала мы фОРlируе1 оценку, а затем на базе этой оценки береf на
себя обязательство обеспечить определеННУIО функциональность и качество к KOH
кретной дате; после этоrо rvlbI управляеJИ проеКТО1 для достижения поставленной

1.6. Оценки и управление проектом 31
цели. Типичные операции по управлению проектом включают удаление некри
тичных требований, переопределение требований, замену менее опытноrо персо
нала более опытным и Т. д. Схема управления проектом представлена на рис. 1.9.
.' ripiijah':idt&B .
::riЦН-ИР9Q.
:ATe
.f1рсqнщ1. .' .
. оtвлеt<ается 
ца проееденив
. .
:., '. ВЩ:ВКИ:
/' '
. Исключение':
'нвстабильныХ
v фукцYJ.
ЧаСтИчНое
снятие
: . reH .
«Оценка» =
= 20 человеко
месяцев
n.Qt<r
Результат =
= 20 человеко
месяцев
.:.' ДоеJ)ИfJ
: треоqваний '.
. ..
.  . . ....
'. '. нед<;)r.точн ..
.: щ:i$J1фSцИЯ 
. .... .. .
 . . . . . .
:. .. n.epOH<;ti:1 . :
.' .".-:.
:Персонаri .
. ... .
qТe :.
на . поер)Ю(у
'a' p 'Qro ':
nf3: 
Добане'
новых
.....ТРебоваНи\1.....
. . rI' .
Рис. 1.9. от отправной точки до завершения проект претерпевает значительные изменения.
Обычно эти изменения оказываются настолько значительными, что rотовый проекr отличается
от Toro, который был заложен в основу оценки. Тем не менее, если результат сходен
с проrнозом, можно сказать, что проект соответствует своей оценке
Кроме управляющих операций, проекты часто находятся под воздействием
непредвиденных внешних событий. Иноrда rруппе разработчиков приходится
создавать промежуточную версию продукта для передачи важному клиенту; пер
соналу приходится отвлекаться на поддержку cTaporo проекта и т. д.
События, происходящие во время работы над проектом, почти всеrда берут
верх над предположениями, которые использовались при первоначальной оценке
проекта. Изменяется предполаrаемая функциональность, изменяются предполо
жения по поводу доступноrо персонала, изменяются приоритеты. В итоrе CTaHO
вится невозможно вынести четкое аналитическое суждение относительно точно
сти оценки проекта, потому что проrраммный проект, полученный в конечном
итоrе, не идентичен из начально запланированному проекту.
На практике, если проект реализует всю предполаrаемую функциональность,
более или менее оrраничивается запланироваННЬПvfИ ресурсами и завершается
более или менее к назначенному сроку, можно сказать, что oцeHKa проекта OKa
залась верной, несмотря на все аналитические неточности, кроющиеся в этой
формулировке.
Таким образом, критерий «хорошеЙ оценки должен базироваться не на каче
стве проrнозирования, а на способности оценки обеспечить успех проекта. Так
мы вплотную подошли к следующей. теме . настоящему значению оценки.

32 rлава 1 · Что такое «оценка»?
1.7. Настоящее значение оценки
Предположим, вы собираетесь отправиться в поездку и решаете, какой чемодан
с собой взять. Маленький чемодан леrко нести, и он хорошо помещается в Bepx
нюю баrажную ячейку в салоне самолета. Большой чемодан не так удобен; ero
придется сдавать, а потом забирать на выдаче баrажа, на что потребуется допол
нительное время. Бы раскладываете свои вещи рядом с маленьким чемоданом 
они почти помещаются. Что делать? Можно попытаться очень тщательно упако
u
вать их, не оставляя ни малеишеrо пустоrо места, и надеяться, что они поместятся.
Если не получится, можно попробовать запихнуть их в чемодан rрубой силой,
сесть сверху и защелкнуть замки. Если и этот вариант не сработает, вы оказывае
тесь перед выбором: оставить часть вещей дома или взять большой чемодан.
Аналоrичная дилемма возникает и в проrpаммных проектах. Планировщики
проектов часто обнаруживают некоторые расхождения между деловыми целями
проекта, оцениваемым по срокам и затратам. Если расхождения невелики, воз
можно, планировщику удастся довести проект до успешноrо завершения за счет
либо умелоrо управления, либо давления на сроки, бюджет или предпола
rаемую функциональность. При больших расхождениях придется пересмотреть
цели проекта.
Основным назначением оценки проrраммноrо проекта является вовсе не про
rнозирование результата. Оценка должна определить, достаточно ли реали
стичны цели проекта, чтобы их можно было достичь за счет управления проек
том. Поместятся ли вещи в маленький чемодан или же придется брать большой?
А может, удастся взять маленький чемодан, если внести небольшие изменения?
Начальство хочет услышать от вас подобные ответы. Обычно, ему не нужна точ
ная оценка, которая скажет, что вещи в чемодан не поместятся. Вместо этоrо Ha
чальству нужен план, который позволит взять с собой как можно больше вещей.
Проблемы начинаются тоrда, коrда разрыв между деловыми целями и cpo
ками/объемом работ, необходимым для достижением этих целей, становится
слишком большим. По своему опыту MOry сказать, что если исходная цель и ис
ходная оценка расходятся в пределах 20 % в ту или иную сторону, у руководителя
проекта остается достаточное пространство для маневра, чтобы за счет управле
ния функциональностью, сроком, численностью rpуппы и друrnми параметрами
добиться поставленных целей; друrие эксперты с этим соrласны (Boehrn 1981,
Stutzke 2005). Если разрыв между целью и реальными потребностями окажется
слишком большим, руководитель не сможет довести проект до успешноrо'завер
шения, внося незначительные изменения в ero параметры. Сколько бы вы ни
перекладывали свои вещи и не сидели на крышке чемодана, большая ropa вещей
все равно не поместится в маленький чемодан, и вам придется брать большой или
оставлять часть вещей. Прежде чем руководитель начнет управлять проектом
для достижения поставленных целей, эти цели необходимо привести в COOTBeTCT
вие с реальностью.
Оценки должны быть не столько идеально точными, сколько полеЗllЫ.м'U. KOM
бинация из точных оценок, rpамотно выбранных целей и качественноrо планиро
вания управления позволит привести проект к результату, близкому к oцeHKe

Дополнительные ресурсы ЗЗ
(как вы, вероятно, доrадались, слово oцeHKa взято в кавычки, потому что oцe
ниваемый проект не идентичен завершенному).
Динамика изменения предпосылок проекта является rлавной причиной, по
которой основное внимание в этой книrе уделяется неформальным, а не научным
методам. Точность в + 5 % окажется бесполезной, если базовые предпосылки про
екта изменятся на 100 %.
1.8. Рабочее определение «хорошей оценки»
После Bcero, что было сказано в предыдущих разделах, мы можем ответить на BO
u u
прос, что же следует считать хорошеи оценкои.
Хорошей считается оценка, которая обеспечивает достатОЧ1l0 ЯС1l0е пpeд
ставление реаЛЬНОlО состояния nроекта и позволяет руководителю проекта
при1lимать хорошие решения относительно mOlO, как управлять проектом для
достижения целей.
Это определение заложено в основу Bcero последующеrо обсуждения оценок
в книrе.
Дополнительные ресурсы
Conte, S.D., Н.Е. Dunsrnore, and У.У. Shen. Software Engineering Metrics and
Models. Menlo Park, СА: Benjarnin/Curnrnings, 1986. В книrе Конта, Дансмора
и Шена приводится авторитетное обсуждение моделей оценки. В частности, в ней
рассмотрен критерий 25 % отклонений в 75 % случаев, а также друrие крите
рии оценки.
DeMarco, Тот. Controlling Software Products. New York: NY: Yourdon Press,
1982. ДеМарко рассматривает вероятностную природу проrраммных проектов.
Stutzke, Richard D. «Estirnating SoftwareIntensive Systerns». Upper Saddle River,
NJ: AddisonWesley, 2005. В приложении С содержится перечень мер, повышаю
щих точность оценки.
2 Зах. 893

Какой из вас
оценщик?
Ваша задача  выдать оценку, а не точное значение 1 .
ФWluп Армор
Итак, теперь мы знаем, что такое хорошая оценка. А вот хороший ли из вас oцeH
щик? СледующиЙ раздел поможет ответить на этот вопрос.
2.1. Простой тест по оценке
Б табл. 2.1 содержится краткий вопросник, предназначенный для проверки Ba
ших навыков оценки. Пожалуйста, прочитайте ero и выполните следующие peKO
мендации.
Для каждоrо вопроса запишите верхнюю и нижнюю rраницу, которые, на
ваш взrляд, обеспечивают 90 % вероятность включения правильноrо значения.
Постарайтесь избеrать чрезмерноrо' расширения или сужения диапазонов. Cдe
лайте их достаточно широкими для Toro, чтобы по вашему здравому смыслу
диапазоны с 90%й достоверностью включали правильный ответ. Пожалуйста,
не ищите ответы в справочниках  тест должен проверить ваши навыки оценки,
а не умение работать с литературой. Бы должны ввести ответ на каждый BO
прос; пропущенный ответ считается неправильным. На выполнение теста OT
водится 10 минут.
(Также можно скопировать лист перед заполнением, чтобы следующий чита
тель книrи тоже Mor ответить на вопросы.)
Правильные ответы на упражнение (например, rеоrрафическая широта Шан
хая) приводятся в приложении Б в конце книrи. За каждый диапазон, включаю
щий правильный ответ, Bal\1 начисляется одно очко.
1 В анrлийском языке  иrpа слов: estimation (оценка)  exactimation (точное значение). 
Прu.меч. перев.

2.2. Обсуждение результатов теста ЗS
Таблица 2.1. Какой из вас оценщик?
Нижняя оценка --- Верхняя оценка Описание
r ] Температура поверхности Солнца
r ] Широта Шанхая
r ] Площадь континента Азия
r 1 rод рождения Александра Македонскоrо
r ] Общая стоимость американской валюты, находившейся
в обращении в 2004 r.
r ] Общий объем Великих Озер
[ 1 Мировые кассовые сборы фильма «Титаник»
r ] Общая длина линии побережья Тихоrо океана
r ] Количество названий книr, опубликованных в США с 1776 r.
r ] Максимальный зафиксированный вес rолубоrо кита
Источник: иавеяно аНQJlОlИЧНЫМ тестом из К1lИlИ «Progl.ammiпg Pea1.Zs», Secoпd Editioп
(BeпtZey, 2000).
Tec"l из К1lИlИ «Sofт J a1.e Estimatioп?> Стива Макконнела (Mic1.osoft P,"ess, 2006) <9 2006 Stel.Je
МсСоппеП. Авторские права защищены. Копирование разрешается только при условии вк.лю
ченuя настоящеlО уведОМJlенuя об авторских правах.
Что у вас получилось? (Не оrорчайтесь. Большинство людей показывает
не лучший результат!) Пожалуйста, запишите свой результат здесь:
2.2. Обсуждение результатов теста
Зачем здесь приводится этот тест? Вовсе не для Toro, чтобы проверить, знаете ли
вы дату рождения Александра Македонскоrо или широту Шанхая. Он проверяет,
насколько хорошо вы понимаете свои собственные способности к оценке.
Насколько достоверна «90..процентная достоверность»?
в описании теста четко сказано, что целью теста должна быть оценка с ДOCTO
верностью 90 %. Тест состоит из 10 вопросов; если вы действительно оцениваете
с достоверностью 90 %, вы должны были получить 9 прав ильных ответов..
Возможно, вы были осторожны, определили СЛИШКО1 широкие диапазоны
и получили 10 правильных ответов из 10. Если вы поторопились И определили
· Математический смысл «90процентной достоверности» чуть более сложен. Если бы
оценка действительно производилась с 90ПРОЦСНТIIОЙ достоверностыо, то с вероятно
стыо 34,9 % вы бы получили 10 правильных ответов, с вероятностыо 38,7 %  9 правиль
ных ответов, 19,4 %  8 правильных ответов. Друrими словами, вероятность получения
8 и более правильных ответов равна 93 %.

36 rлава 2 · Какой из вас оценщик?
диапазоны более узкие, чем следовало, возможно, вам удалось правильно полу
чить 7 или 8 ответов из 10. Я давал этот тест сотням оценщиков. На рис. 2.1 пока
заны результаты для последних 600 человек, проходивших этот тест.
25 О/о
20 0/0
15%
Испытуемые
10 О/о
5 % .
0%
о 1 2 3 4 5 6 7 8 9 10
Правильные ответы
Рис. 2.1. Результаты теста «Какой из вас оценщик?» Большинство
испытуемых получает lЗ правильных ответа
Для rруппы, результаты которой показаны на рисунке, среднее количество
правильных ответов было равно 2,8. Bcero два процента испытуемых дали 8 и более
правильных ответов. Никто и никоrда не дал 1 О правильных ответов. Я сделал
вывод, что интуитивные представления большинства людей о 90 % ДOCTOBepHO
сти в действительности ближе к ЗО % достоверности. Друrие исследования
также подтвердили l\10e базовое открытие (Zultner 1999, J"rgensen 2002).
Я видел множество рабочих rpупп, представлявших rрафики, ДOCTOBepHыe на
90 %. Потом эти rpафики HepeдКD нарушались  собственно, чаще нарушались,
чем соблюдались. Если бы rрафик действительно составлялся с 90%й ДOCTOBep
ностью, то по статистике превышение встречалось бы лишь в одном случае из 10.
Отсюда следует, что значения достоверности в процентах (например, 90 %)
имеют смысл только в том случае, если они поддерживаются неким статистиче
ским анализом. В противном случае это не более чем подмена действительноrо
желаемым. Как добиться настоящей 90 % достоверности, мы разберемся позднее
в этой книrе.
СОВЕТ NQ 5
Не предоставляйте процентные оценки достоверности (особенно «достоверные на 90 О/о»),
если только они не поддерживаются количественными методами.
Если вы не прошли тест, приведенный ранее в этой rлаве, сейчас самое вреIЯ
вернуться и пройти ero. Вас удивит, как мало будет прав ильных ответов даже по
сле Toro, как вы прочли мои объяснения.

Откуда возникает стремление к сужению диапазонов? 37
Как выбирать ширину диапазона?
Столкнувшись с человеком, получившим 7 или 8 правильных ответов, я спраши
ваю: «Как вам это удалось?» Типичный ответ: «Я выбрал слишком широкие диа
пазоны.
Мой ответ: «Ничеrо подобноrо! Ваши диапазоны были слишком узкими!
Даже если вы получили 7 или 8 правильных ответов, значит, диапазоны все равно
оказались недостаточно широкими для получения желаемой доли правильных
ответов.
Мы склонны полаrать, что оценки, выраженные в виде узких диапазонов, точ
нее оценок с широкими диапазонами. Нам кажется, будто широкие диапазоны
свидетельствуют о невежестве или некомпетентности оценщика. Обычно все
наоборот (конечно, узкие диапазоны предпочтительны в тех случаях, коrда они
поддерживаются фактическими данными).
СОВЕТ NQ б
Избеrайте искусственноrо сужения диапазонов. Следите за тем, чтобы диапазоны, используе
мые в оценках, не искажали вашеrо представления о достоверности оценки.
Откуда возникает стремление
к сужению диапазонов?
Коrда вы отвечали на вопросы теста, хотелось ли вам расширить диапазоны? Или
вы чувствовали, что их лучше сузить? Как правило, испытуемые rоворят, что И1
хотелось сделать диапазоны как можно уже. Но если вы вернетесь к инструкциям
и внимательно прочитаете их, то обнаружите, что я не просил сужать диапазоны.
Действительно, в них rоворится, что диапазоны не должны быть ни слишком ши
рокими, ни слишком узкими  достаточно широкими для Toro, чтобы вы были на
90 % уверены в том, что они включают правильный ответ.
После обсуждения этоrо вопроса с сотнями разработчиков и руководителей
я пришел к выводу, что стремление к сужению диапазонов возникает самопроиз
вольно внутри caMoro оценщика. Отчасти оно обусловлено чувством профессио
нальной rордости  люди полаrают, что узкий диапазон свидетельствует о более
качественной оценке, хотя это совсем не так. Также не стоит сбрасывать со счетов
опыт общения с начальством и клиентами, настаивавшими на использовании
чрезмерно зауженных диапазонов.
Аналоrичное самопроизвольное стремление обнаруживается и в общении Me
жду клиентами и оценщиками. Йорrенсен и Сьеберr сообщают, что информация
об ожиданиях клиентов оказывает сильное влияние на оценку, причем оценщики
обычно не сознают, в какой степени она отражается на их результатах (]eJrgensen
nd Sjoberg 2002).
СОВЕТ NQ 7
Если вы испытываете воздействие, направленное на сужение диапазона, убедитесь в том, что
оно идет извне, а не рождается внутри ac.

38 rлава 2 · Какой из вас оценщик?
в rлавах 22 и 23 обсуждаются различные способы решения проблеIЫ для тех
случаев, Korlla давление действительно идет из внешнеrо источника.
Насколько показателен тест для реальной
оценки nporpaMMHbIX проектов?
в облаСТll проrpа!\Ilноrо обеспечения HaI нечасто приходится оценивать объем
воды ВеЛИКIIХ Озер или теl\fпературу поверхности Солнца. 11l\IОЖНО ли ожидать,
что BI удастся оценить общую CYI?\IY НCLходящейся в обращеНllИ валюты США
ИЛII количество книr, опубликованных в США,  особенно если вы живете в дpy
rоЙ стране?
Разра60ТЧIlКtL\I проrра1\ll\Iноrо обеспечеНI-1Я часто приходится оценивать про
екты IIЗ незнаКОIЫХ областей  проекты, в реаJlизации которых задействованы
новые технолоrllll, новые средства проrраI1.ПlроваНIIЯ, незнаКО?\IЫЙ персонап
п т. д. Оценка в условиях неопределеННОСТII является вполне оБЫЧНЫ1 деЛОI.
В оставшеЙся части этоЙ КНllrи я постараюсь оБЪЯСНJIТЬ, как добиться успеха в по
добноi"i ситуации.

о точности оценки
[Одно из распространенных определениЙ оценки  ...]
...наиболее оптимистичный проrноз, вероятность испол
нения KOToporo отлична от нуля. ...Руководствуясь этим
определением, мы неизбежно приходим к методу оцснки,
который можно назвать «поиском самой ранней даты, KO
[да Bl>I еще не можете точно сказать, что проект не будет
закончен вовремя».
Том Демарко (Тот DeMal.co)
Неточность оценок проrраммных проектов, замутненных нереалистичными цe
лями и недостижимыми обязательствами, оставалась проблемой в течение MHO
rих лет. Еще в 1970x rодах Фред Брукс указывал, что «нехватка календарноrо
времени заryбила больше проектов, чем все остальные причины B1eCTe взятые
(Бrооks 1975). Десять лет спустя Скотт Костелло заметил, что давление пре
дельных сроков является величаЙшим Bparo1 разработки проrраммноrо обеспе
чения (Costello 1984). Б 1990x тодах КеЙперс Джонс указал, что слишком
подробные или иррациональные rрафики, вероятно, оказывают наиболее разру
шительное влияние на судьбу всех проrраммных проектов.
Том Демарко сформулировал свое общее определение в 1982 rоду. Несмотря
на успехи, о которых я упоминал в первой rлаве, за прошедшие rоды ИЗlенилось
не так уж MHoro. Вероятно, вы уже соrласны с тем, что точные оценки ценнее He
точных. Б этой rлаве описаны преимущества точных оценок и тех данных, на KO
торых они базируются.
3.1. Что лучше  переоценка или недооценка?
На интуитивном уровне ясно: что точная оценка закладывает идеальную основу
для планирования проекта. Наличие точных оценок позволяет эффективно коорди
нировать работу между неСКОЛЬКИIИ разработчиками. Результаты, выдаваемые
одно rруппой для друrо1'i rрупriы, планируются с точностью до дня, часа или

40 rлава 3 · О точности оценки
минуты. Но мы 3HaeI, что точные оценки встречаются редко, и раз уж нам все
равно суждено ошибиться  в какую сторону это лучше сделать? В сторону завы
шения или занижения?
ApryMeHTbI против переоценки
Начальство и друrие заинтересованные стороны иноrда опасаются, что при пере
оценке проекта вступит в силу закон Паркинсона  принцип, соrласно которому
любая работа заполняет все отведенное для нее время. Если дать разработчику
5 днеЙ на решение задачи, которую можно решить за 4 дня, разработчик придума
ет, чеI заняться в лишний день. Если дать rруппе 6 месяцев на завершение проек
та, которыЙ можно завершить за 4 месяца, rруппа найдет способ использовать
лишние два месяца. В результате некоторые начальники сознательно поджимают
оценки, пытаясь избежать действия закона Паркинсона.
Друrая потенциальная проблема  студенческий синдром rолдрэтта (Gold
ratt 1997). Если выделить разработчикам слишком MHoro времени, они работают
спустя рукава. Коrда проект близится к концу, начинается аврал, и скорее Bcero,
разработчики не успеют сдать проект к сроку.
Недооценка также часто применяется еще по одной похожей причине  изза
желания внушить rруппе разработчиков чувство срочности проекта. Обоснова
.
ние выrлядит примерно так.
Разработчики lоворят, что nроект займет 6 месяцев. НавеРllяка, в их oцeи
ках ecпZb какиеllибудь допуски и излишества, которые .АIОЖ1l0 om:J/camb. Кроме
mOlO, в nроект llУЖ1l0 заложить пла1l0вую СРОЧ1l0сть, чтобы обеспечить elo
nриоритетllое ИСnОЛ1lеиие. 31lачит, llУЖ1l0 uастаивать иа Змесячuом сроке.
КОllеЧ1l0, я lle верю, что nроект МОЖ1l0 завершить за 3 .Аlесяца, ll0 разработчи
кшt llазову u.,tell1lo этот срок. Если я прав, разработчики все сделают за 4 или
5 месяцев. В худшем случае потребуются те 6 месяцев, которые бьUlИ llазва
llbl в ИЗllачалЬ1l0Й оце1lке.
Насколько убедительны эти aprYMeHTbI? Чтобы выяснить это, необходимо
изучить apryMeHTbI в пользу смещения в друrую сторону, то есть переоценки.
ApryMeHTbI против недооценки
Недооценка создает множество проблем  как очевидных, так и скрытых.
· Снижение эффективности планирования. Заниженные оценки подрыва
ют эффективность планирования и закладывают неверные предположения
в планы выполнения некоторых операциЙ. Они MOryT привести к ошибкам
планирования в численности rруппы  скажем, заложенная в план числен
ность rруппы окажется меньше необходимой. Также forYT быть подорва
ны возможности координации между rруппами  если rруппа не успевает
запершить работу к положенному сроку, друrие rруппы не CMOryT исполь
зовать ее результаты.

3.1. Что лучше  переоценка или недооценка? 41
· Если ошибка оценки приводит к нарушению плана Bcero на 5 % или 10 %,
она не вызовет серьезных проблем. Однако мноrочисленные исследова
ния показали, что оценки проrpаммных проектов часто оказываIОТСЯ He
точными на 100 % и более (Lawlis, Flowe, and Thordahl 1995; Jones 1998;
Standish Group 2004; ISBSG 2005). Если предпосылки планирования He
верны до такой степени, планы среднеrо проекта настолько отрываются от
реальности, что становятся практически бесполезными.
· Статистическое снижение верояnIОСТИ cBoeBpeMeHHoro завершения. Разра
ботчики обычно склонны оценивать объем работы на 2030 % ниже реаль
Horo (van Genllchten 1991). Даже если просто воспользоваться их обычными
оценками, планы проекта будут слишком ОПТИМИСТИЧНЫIИ. Дальнейшее co
кращение оценок делает своевременное завершение еще менее вероятны[.
· ПЛохая техническая база ухудшает результат по сравнению с номина
лом. Заниженная оценка может привести к тому, что на предварительные
операции (такие, как постановка требований и проектирование) будет по
трачено слишком мало времени. Если же требованиям и проектироваНИIО
уделено недостаточно внимания, вам придется переделывать и то и дpy
roe на более поздних стадиях проекта, причем с большими затратами, чем
при своевременном выполнении этих операций (Boehm and Turner 2004,
МсСоппеll 2004а). В конечном итоrе работа над проектом заЙlет больше
времени, чем при точной оценке.
· Деструктивная динамика поздней стадии работы над проектом ухудшает
результат по сравнению с номиналом. При переходе проекта в состояние
«опоздания» раБОЧИI rруппам приходится тратить вреIЯ на действия, не
нужные для CBoeBpeMeHHЫX» проектов. Бот лишь несколько ПрИl\1еров:
· Дополнительные встречи с начальством с обсуждением хода работ и мер,
призванных вернуть проект на правильный путь.
· Частые переоценки для определения уточненной даты завершения
проекта.
· Общение к важными клиентами по поводу нарушения срока поставки
(в том числе и посещение собраний с участием этих клиентов).
· Подrотовка промежуточных версий продукта для выставок, дeMOHCTpa
ций и т. д. Если бы проект был rOTOB вовреIЯ, можно было бы использо
вать саму проrрамму вместо промежуточных версий.
· Дополнительные дискуссии по поводу Toro, какие требования абсолют
но неоБХОДИIО ВКЛIОЧИТЬ в задание изза задержки проекта.
· Решение проблем с наспех сделанными обходными решениями, KOTO
рые пришлось реализовать ранее изза поджимающих сроков.
у всех перечисленных действий есть одна важная особенность: они соверше1l
11.0 не нужны, если работа над проектом идет по rрафику. Дополнительные дейст
вия отвлекаIОТ от продуктивной работы и задерживают сдачу проекта по cpaBHe
нию с точной оценкой и. планированием.

-
42 rлава з · о точности оценки
Сравнивая apryMeHTbI
4Студенческий синдром rолдрэтта может оказывать влияние на проrраммные
проекты, но я обнаружил, что самым эффективным способом ero устранения яв
ляется активное отслеживание задач и буферное управление (то есть управление
проектом), по аналоrии с предложениями rолдрэтта, а не смещение оценок.
Как видно из рис. 3.1, лучшие результаты проекта достиrаются при самых точ
ных оценках (Саймонс 1991). Если оценка занижена, неэффективность планиро
вания ведет к повышению затрат и затяrиванию проекта. Если оценка завышена,
начинает действовать закон Паркинсона.
.едl;еН.Ы(j.:llqrерй;
. :9щi4б6к P9J.ilitt.f.
. . fjДОЧёТQВ :H.: np(ipTeri6q::
:9f..:..P'1..
'ИСt{оаtuiых мета J ИК.
........... Недооценка
Объем.
.раБоты


Затраты/;
. ..CpQK
i41iЙi1::.noiр
 заkона:
. П ............. .......
. . а. кинсона.';.
<1 . . %
100%
>100 О/о
Цель в процентах от НQМИНальной оценки
Рис. 3.1. Потери от недQ9ценки превышают потери от переоценки, поэтому если точная оценка
невозможна, старайтесь ошибаться в сторону завышения, нежели в сторону занижения
я считаю, что закон Паркинсона применим к ироrраммным проектам; объем
работы растет, заполняя все отведенное время. Однако намеренная недооценка
проекта изза закона Паркинсона оправдана лишь в том случае, если потери изза
переоценки превышают потери изза недооценки. В области проrраммноrо обеспе
чения потери от переоценки ЯВЛЯIОТСЯ ЛllllеЙllЬLМИ и оzраllичеllllы.Aии  работа запол
няет все отведенное время, но не более Toro. С друrой стороны, потери от Heдo
оценки llеЛИllеЙllbl и llеОlраllичеllbl  ошибки планирования, недостаточные пред
варительные операции и создание новых дефектов приносят больший ущерб, чем
переоценка, причем предсказать размер этоrо ущерба заранее почти невозможно.
СОВЕТ NQ 8
Избеrайте намеренной недооценки. Потери от недооценки превышают потери от переоцен
ки. Если вас беспокоит возможная переоценка, решайте проблемы посредством планирования
и управления, а не за счет смещения оценки.
3.2. Достижения в области оценки
nporpaMMHbIX проектов
История достижений в области оценки проrраммных проектов помоrает сделать
ряд интересных выводов относительно природы возникающих проблем. В по
следнее время rpуппа The Standish Group каждые два rода публикует отчет «ТЬе

3.2. Достижения в области оценки nporpaMMHbIX проектов 43
Chaos Report» с описанием результатов проrpаммных проектов. В 2004 rоду 54 %
проектов завершались с опозданием, 18 % полностью проваливались, а 28 % за
вершались в положенный срок и в рамках бюджета. На рис. 3.2 изображены pe
зультаты за 10 лет, с 1994 по 2004 rод.
Обратите внимание: в данных ТЬе Standish Group даже не существует KaTero
рии для досрочноrо завершения проектов! Лучшим из возможных результатов
было соответствие ожиданиям вовремя/в рамках бюджета»  а все остальные
результаты ему уступали.
1 00 0/0
90 0 k
80 О/о
70 0J'o
60 О/о
Процент 50 0J'o
40 0/0
30 О/о
20 0/0
10 0 k
О 0J'o
1994
... Af:.. ..-t.. ....
у ...
1996
1998
2000
2002
2004
О О .'." Опозданиеl
Провал
' Превышение бюджета
. =' Вовремяl
В рамках бюджета
Рис. 3.2. Результаты проектов по данным отчета The Standish Group «Chaos Report»
изменяются от rода к rоду. Около 3/4 всех проrраммных проектов сдаются
с опозданием или проваливаются
Кейперс Джонс дает друrое представление статистики о результатах проектов.
На основании мноrолетних наблюдений Джонс заметил, что успех проекта зави
сит от ero размера. Иначе rоворя, в крупных проектах возникает больше проблем,
чем в мелких. Таблица 3.1 доказывает это утверждение.
Как видно из данных Джонса, чем крупнее проект, тем ниже вероятность ero
cBoeBpeMeHHoro завершения и тем выше вероятность полноrо провала.
В ходе мноrих исследований были получены результаты, соответствующие
результатам ТЬе Standish Group и Джонса,  примерно четверть всех проектов
завершается своевременно; еще четверть отменяется; и около половины проектов
сдается с опозданием и/или превышением бюджета (Lederer and Prasad 1992;
Jones 1998; ISBSG 2001; Krasner 2003; Putnarn and Myers 2003; Heernstra, Siskens
and van der Stelt 2003; Standish Group 2004).
Существует множество причин, по которым проекты нарушают поставленные
цели. Плохая оценка  лишь одна из них, но отнюдь не единственная. Эта тема
подробнее рассматривается в rлаве 4.

44 rлава з · о точности оценки
Таблица 3.1. Зависимость результата проекта от ero размера
Размер в функциональных Преждевременное Своевременное Опоздание
пунктах (и примерное завершение завершение
количество строк
nporpaMMHoro кода)
10 FP (1000 строк)
100 FP (10 000 строк)
1000 FP (100 000 строк)
10 000 FP (1 000 000 строк)
100 000 FP (10 000 000 строк) О О/о
Провап
(отмена)
11 О/о
81 О/о
75 О/о
б 1 О/о
28 О/о
14 О/о
б О/о
2 О/о
7 О/о
20 О/о
48 О/о
б5 О/о
б О/о
1 О/о
12 О/о
18 О/о
24 О/о
21 О/о
< 1 О/о
Источник: Estimatiпg Software Costs» (]oпes 1998).
Насколько велики нарушения сроков?
Количество проектов, нарушающих сроки или выходящих за рамки бюдже
та,  один показатель. Степень расхождения проектов с поставленными целя
IИ  друrой фактор. Соrласно первому обзору ТЬе Standish Group, среднее
превышение сроков составляло около 120 %, а среднее превышение затрат 
около 100 % (Standish Group 1994). Тем не менее точность оценки, вероятно,
была еще хуже, чем показывают эти числа. rруппа Standish Group обнаружила,
что из проектов, завершавшихся с опозданием, обычно исключалась значитель
ная часть функций; это делалось для обеспечения хотя бы Toro бюджета и сроков,
с которыми проект в итоrе завершался. Разумеется, оценка таких проектов
строилась не для усеченной версии, которая в коечном счете получалась, а для
полноценной исходноЙ версии. Если бы в опаздывающих проектах реализовы
валась вся запланированная функциональность, нарушение планов было бы
еще БОЛЬШИI.
По данным одной компании
Данные о результатах проектов для одной конкретной компании, полученные от
одноrо из моих клиентов, показаны на рис. 3.3.
ТОЧКИ, сrруппированные на линии О в левой части rрафика, представляют
проекты, о которых разработчики сообщили как о завершенных; тем не менее
при иптеrрации результатов с друrими rруппами оказалось, что проекты требуют
доработки.
Диаrональная линия представляет идеальную точность план:ирования. В идеа
ле rрафик должен состоять из точек данных, сrpуппированных вБЛИЗl-1 от диаrо
нальной линии. Вместо этоrо почти все 80 показанных точек данных находятся
над линией и представляют нарушения сроков. Одна точка расположена под
линией, и еще несколько  на линии. Линия демонстрирует стандартное опре
деление «оценки» по Демарко  самая ранняя дата, к котороЙ проект fожет
быть завершен.

3.3. Преимущества точных оценок 45
280
260
240
220
200
180
160
Фактический срок 140
завершения (в днях)
120
100
80
60
40
20
I...J.. -1 rw
--1-
[/7
I/
+ /
 /.
х!
..ш.. li?
,..... +.V
....
...1.. I ++ . редниезначения
t T if-+ l/ Целевой срок: 22 дня
.. ... J... lJ... Фактический срок: 56 дней
t"!WJ 1t 7 '\ I 1 I I
 I..J. 'Идеальная точность
. :4  (срок завершения = Целевой срок)
....
:: 
:: .
...
I
о
о 20 40 60 80 100 120 140 160 180 200 220
Целевой срок завершения (в днях)
Рис. 3.3. Результаты оценок для одной орrанизации. Данные по отрасли показывают,
что почти 100 О/о занижение оценок компании является типичным явлением.
Данные используются с разрешения
Общесистемная проблема проrраммной отрасли
Мы часто rоnорим о проблеме оценки в отрасли разработки проrpаммноrо обес
печения нейтрально  вроде бы иноrда проекты переоцениваются, иноrда Heдo
оцениваются, Hal\f просто не удается получить правильную оценку.
Но в отрасли разработки npolpaм.м1l0l0 обеспечения не существует проблемы
нейтральной оценки. Статистика ясно показывает, что в отрасли разработки про
rpaM!\1HOrO обеспечения существует проблема недооценки. Прежде чем занимать
ся повышением точности оценок, необходимо начать с их увеличения. Это CTaHO
вится изрядной проблемой для мноrих орrанизаций.
3.3. Преимущества точных оценок
Ваши оценки стали достаточно точными, и вы перестаете беспокоиться о боль
ших ошибках оценки как в одну, так и в друryю сторону. Действительно точные
оценки дают немало дополнительных преимуществ.
. Возможность отслеживания состояния проекта. Один из лучших спо
собов отслеживания состояния основан на сравнении запланированноrо
проrpесса с факти.ческим. Если запланированный проrресс был достаточно

46 rлава 3 · О точности оценки
реалистичным (то есть основанным на точных оценках), становится воз
можным отслеживание проrресса на предмет соответствия планам. Если
же запланированный проrресс является фикцией, проект обычно начинает
существовать сам по себе, без какойлибо связи с планами, и вскоре оказы
вается, что сравнивать фактический проrресс с запланированным уже бес
С1ысленно. Таким образом, хорошие оценки закладывают базу для отсле
живания проекта.
· Повышение качества. Точные оценки помоrают избежать снижения каче
ства, обусловленноrо приближающимся CpOKO?\-I сдачи. Как показали ис
следования, около 40 % всех ошибок проrраммирования возникает изза
стресса; этих ошибок мо)кно было бы избежать за счет правильноrо плани
рования и снижения наrрузки на разработчиков (Glass 1994). Коrда cpo
ки «под)кимают» особенно сильно, rотовая проrраIма содержит примерно
в 4 раза больше ошибок, чем проrрамма, разработанная в менее стрессовых
условиях (Джонс 1994). Одна из причин состоит в том, что рабочая rруппа
на CKOPYIO руку лепит» версии функций, которые безусловно должны быть
завершены к моменту выхода проrраммы. Также оказалось, что излишнее
давление сроков является основной причиной для выпуска модулей, co
держащих ошибки, исправление которых обходится чрезвычаЙно дороrо
(Jones 1997).
· Проекты, с caMoro начала ориентирующиеся на минимизацию числа дe
фектов, обычно также имеют самое короткий срок сдачи (Jones 2000). Но
если в результате давления руководства создаются нереалистичные оценки
и страдает качество, ничем ХОрОШИl\1 это не кончится: бюджет и rpафик TaK
же пострадают.
· Улучшение координации с функциями, не связанными с проrpаммирова-
нием. Проrpаммные проекты обычно координируются с друrими видами
деятельности: тестированием, написанием документации, маркетинrовыми
кампаниями, обучением ToproBoro персонала, финансовыми проrнозами,
обучением службы поддержки и т. д. Ненадежный rpафик сдачи проекта
способен привести к сбоям взаимосвязанных функций, а это может Ha
рушить весь lрафuк nроекта. Хорошая оценка проrраммноrо проекта пре
дусматривает более тесную координацию Bcero проекта, включая как про
rpaMMHbIe, так и прочие виды деятельности.
· Повышение качества бюджета. Как бы очевидно это ни прозвучало, точная
оценка способствует выработке точноrо бюджета. Орrанизация, не обеспе
чивающая точных оценок, подрывает свои возможности по проrнозирова
нию стоимости проектов.
· Повышение доверия к rpуппе разработчиков. Ирония судьбы: после Toro
как rруппа, работающая над проектом, создает оценку, начальники, отделы
маркетинrа и продаж превращают эту оценку в оптимистичную цель  He
взирая на все возражения разработчиков. Затем разработчики нарушают
оптимистичную цель, и тоrда начальники, отделы маркетинrа и продаж
обвиняют их в том, что они не умеют оценивать! Исполнительная rруппа,

3.4. Значение предсказуемости по сравнению с друrими атрибутами проекта 47
которая твердо держится на своих позициях и настаивает на точной oцeH
ке, пользуется БОЛЬШИl\l доверием в своей орrанизации.
. Получение ранней ИНфОРl\lации о рисках. Одной из самых частых упу
щенных возможностей в области разработки проrраммноrо обеспечения
является неправильная интерпретация исходноrо несоответствия между
целями и оценками проекта. Финансовый директор rоворит: Проект нуж
но сделать за 4 месяца, потому что нас ждет крупная BЫCTaBKa, а исполни
тельная rруппа rоворит: «По наШИl лучшим оценкам, на проект уйдет не
менее 6 месяцев. Как вы думаете, что будет дальше? Как правило, финан
совый директор обсуждает оценку с руководством проекта, а на rруппу Ha
чинают давить с требованиями обеспечить 4месячный rpафик.
. Неверно! Обнаружение несоответствия между целью проекта и оценкой
проекта должно рассматриваться как чрезвычайно полезная, крайне редкая
информация о риске, появившаяся на ранней стадии проекта. Такое pacxo
ждение с довольно высокой вероятностью указывает на то, что цели проек
та не будут соблюдены. На ранней стадии возможны различные корректи
ровочные меры, мноrие из которых обладают высокой эффективностью.
Бы можете переопределить объем работы, набрать дополнительный пер
сонал, перевести лучших работников на проект или изменить некоторые
функции. Возможно, вы даже решите, что с проектом вообще не стоит
связываться.
. Но если оставить несоответствие без внимания, возможностей корректи
ровки на более позднеЙ стадии будет rораздо меньше, и они будут обладать
куда меньшей эффективностыо. Как правило, приходится выбирать между
двумя вариантами: нарушением сроков и бюджета и отказом от важных
функций.
СОВЕТ NQ 9
Несоответствие между деловыми целями и оценкой проекта следует рассматривать как ценную
информацию о возможной неудаче проекта. Принимайте меры на ранней стадии, коrда еще
можно чтото сделать.
3.4. Значение предсказуеМQСТИ по сравнению
с друrими желательными атрибутами проекта
Орrанизации, занимающиеся разработкой проrраммноrо обеспечения, и люди,
ведущие собственные проекты, пытаются достичь ряда целей. Вот лишь HeKOTO
рые из них.
. Срок. Кратчайший возможный срок для реализации заданной функцио
нальности с заданным уровнем качества.
. Бюджет. Минимальные затраты на реализацию заданной функционально
сти за заданное время.
. Функциональность. Максимальный набор возможностей при доступном
времени и затратх.

48 rлава з · о точности оценки
Относительные приоритеты этих общих целей (а также друrих, более специ
фических) зависят от проекта. Разработки на базе динамических методолоrий
обычно отдают предпочтение динамичности, повторяемости, надежности, устой
чивости и наrлядности (Cockburn 2001, МсСоппе1l2002). Модель СММ институ
та SEI обычно фокусируется на целях эффективности, улучшаемости, предска
зуемости, повторяемости и наrлядности.
Во время дискуссий с руководством я часто спрашиваю: Что для вас важ
нее: возможность изменять решения относительно функциональности или за
ранее известные затраты, сроки и функциональность? По крайней мере 8 раз
из 1 О мне отвечают: заранее известные затраты, сроки и Функциональность 
друrими словами, предсказуемость. Друrие эксперты в области разработки про
rpaMMHoro обеспечения также отмечали это явление (Moseman 2002, Putnam and
Myers 2003).
После этоrо я часто rоворю: Допустим, я MOry предложить вам результаты
проекта, аналоrичные варианту NQ 1 или вариан.ту NQ 2 на рис. 3.4. Также будем
считать, что вариант NQ 1 означает, что проект будет завершен за предполаrаемый
срок в 4 месяца, но он может быть сдан как на один месяц раньше, так и на 4 месяца
позже. С друrоti стороны, вариант NQ 2 означает, что проект будет завершен в срок
5 месяцев (вместо 4), но я MOry rарантировать, что отклонение составит не более
недели. Какой вариант вы предпочтете?
8
7
б <>
5
Возможные сроки
завершения проекта 4
(в месяцах)
3
2
1
О
Вариант Вариант
1 2
Рис. 3.4. При выборе между коротким средним сроком при большой неустойчивости
и более длинным средним сроком при малой неустойчивости большинство
коммерческих орrанизаций выбирает второй вариант
По собственному опыту MOry сказать, что почти все руководители выбирают
вариант NQ 2. Сокращенные сроки, предполаrаемые вариантом NQ 1, не принесут
никакой пользы, потому что орrанизация не может твердо рассчитывать на них
Так как превышение срока может достиrать 4 месяцев, приходится планировать
8месячный rрафик вместо 4месячноrо или вообще отказаться от какоrолибо
планирования вплоть до фактическоrо завершения проекта. rарантированный
5месячный срок варианта NQ 2 выrлядит rораздо лучше.

Дополнительные ресурсы 49
За прошедшие rоды в отрасли разработки проrpаммноrо обеспечения важней
шими показателями считались время до внедрения продукта на рынок, затраты
и rllбкость. Каждая из этих целей важна, но руководители высшеrо звена более
Bcero ценят предсказуемость. Орrанизации должны брать на себя обязательства
перед клиентаIИ, инвесторами, поставщиками, рынком и т. д. В основе всех этих
обязательств лежит предсказуемость.
Сказанное вовсе не означает, что предсказуемость должна обладать наивыс
шим приоритетом в ваших проектах. Скорее, речь идет о том, что вам не следует
делать априорные предположения о приоритетах вашей фирмы.
СОВЕТ NQ 10
Мноrие орrанизации ценят предсказуемQCТЬ выше, чем срок разработки, затраты или rибкость.
Обязательно выясните, какие показатели считаются приоритетными в вашем случае.
3.5. Недостатки распространенных
методов оценки
Поскольку неудачи при оценках проrpаммных проектов встречаются сплошь и ря
ДО1\{, IОЖНО сделать вывод, что методы, используемые для построения оценок,
Iалоэффективны. Их следует тщательно проанализировать... и выбросить!
Альберт Ледерер (Albert Lederer) и Джайеm Прасад (Jayesh Prasad) обнару
ЖILТIИ, что самым распротраненным Iетодом оценки является сравнение HOBoro
проекта с ПОХОЖИf проектом из прошлоrо, причем на основании исключительно
личных воспо{инаний. Как выянилось,, эта методика имеет 1tfало общеro с точ
ной оценкой. Стандартные l.fетоды, основанные на интуиции" и .преДIIоложе
ЮIЯХ., связываются с превышением затрат и сроков (Lederer and Prasad 1992).
Дрyniе исследовате.ТIИ также выяснили, что доraдки, интуиция, неструктурирован
ные экспертныIe оценки, неформа.пьные аналоrnи и Т. д. являются преобладающими
стратеПfЯМИ, JJспольз)темыми В 6085 % всех оценок (Hihn and Habi1rAgahi 1991,
Heemstra and Kusters 1991, Paynter 1996, ]ergensen 2002, Кitchenham et al. 2002).
В rлаве 5 приводится более подробный анализ источников ошибок оценки,
а в OCT3}IbHЫX rлавах книrи представлены альтернативы для этих общих метОДОВ.
Дополнительные ресурсы
Goldratt, Eliyahu М. 4Critical Chain,>. Great Barringon, МА: ТЬе North River
Press, 1997. rолдрэп описывает меры борьбы со 4студенческим синдромом, а тaK
же подход к буферному управлению с учетом действия закона Паркинсона.
Putnam, Lawrence Н. and Ware Myers. .Five Core Metrics. New York, NY: Dorset
House, 2003. В r..'1aвe 4 превосходно проаllализирована важность предсказуемости
по сравнению с друrиfИ uеЛЯfИ проекта.

Откуда берутся
ошибки оценки?
Бессмысленно требовать точных формулировок, если вы
даже не знаете, о чем идет речь.
ДЖО1l фО1l НеLL\lЙ1l
у одноrо из проектов факультета информационных технолоrий Вашинrтон
cKoro университета возникли серьезные трудности с оценкой. Проект запаздывал
на несколько месяцев, а превышение бюджета С9ставило 20,5 миллиона долларов.
Спектр причин был широким, от недостатков проектирования и недоразуме
ний до вносимых в последнюю минуту изменениЙ и мноrочисленных ошибок.
Университет ссылался на некачественное планирование проекта. TeI не Me
нее ero нельзя было отнести к обычным проrраММНЫI проектам. Более Toro,
он вообще не являлся проrраммным проектом; речь шла о строительстве повоrо
университетскоrо корпуса информационных технолоrий и проектирования
(SaI1cI1ez 1998).
Оценка проrра{мноrо обеспечения сопряжена с проблемами, потому что caf
процесс оценки сопряжен с проблемами. В 1995 [оду строительство HOBoro бейс
больноrо стадиона в Сиэттле было оценено в 250 миллионов долларов. Стадион
был построен в 1999 [оду за 517 миллионов долларов  ОШllбка оценки состави
ла более 100 % (Withers 1999). Самым выдающимся случаем превышения за
трат за последнее время, вероятно, был проект строительства CKOpocTHoro шоссе
в Бостоне. Затраты, изначально оцениваемые в 2,6 миллиарда долларов, в конеч
ном: счете превысили 15 миллиардов  ошибка оценки составила более 400 %
(Associated Press 2003).
Конечно, в мире проrраммноrо обеспечения найдутся свои выдающиеся при
меры. Ирландская система PPARC (Personnel, Payroll and Related Systems) была
отменена после Toro, как она превысила свой бюджет в 8,8 миллиона евро на 140
миллионов евро (The Irish Times 2005)! Проект ФБР VCF (Virtual Case File) был
свернут в марте 2005 [ода; при вложениях в 170 миллионов долларов была pea
лизована Bcero 1/10 запланированных возможностей (Arnone 2005). Подрядчик
жаловался, что ФБР сменило 5 руководителей информационной службы и 10 pyкo
водит.лей проектов, не rоворя уже о 36 изменениях контракта (Knorr 2005).

4.1. Источники неопределенности в оценках 51
Подобный хаос довольно часто встречается в проектах, испытываIОЩИХ пробле
мы с качеством оценки.
[лаву, посвященную ошибкам оценки, с таким же успехом можно было Ha
звать «Классические ошибки при оценке проrраммноrо обеспечения. Даже если
вы просто постараетесь избежать проблем, описанных в этоЙ rлаве, половина пу
ти к созданию точных оценок будет проЙдена.
Ошибки, закрадывающиеся в оценки, идут из четырех общих источников.
. Неточная информация об оцениваемом проекте.
. Неточная инфорr.rtация о возможнос.тях орrанизации, котороЙ будет пору
чено исполнение проекта.
. Чрезмерное усердие, направленное на получение точноЙ оценки (то ес.ть
попытки оценивать измеПЯЮlциеся цели).
. Неточности, обусловленные самим процессом оценки.
Б этой rлаве подробно рассматривается каждый источник ошибок оценки.
4.1. ИСТОЧНИКИ неопределенности в оценках
Сколько стоит построить новыЙ дом? Это зависит от ДОlа. Сколько будет стоить
вебсайт? Это зависит от сайта. Пока все специфические особенности не будут
понятны во всех подробностях, невозr.rl0)КНО точно оценить стоимость проrраrvlМ
Horo проекта. Нельзя оценить объем работы, необходимый для построения че
rOTo HOBoro, пока это «чтото еще не было определено.
Разработка проrраммноrо обеспечения представляет собой процесс постепен
Horo уточнения. Бы начинаете с общей концепции продукта (своих представле
ний о проrрамме, которую собираетесь построить) и уточняете ее, PYKOBOДCTBY
ясь целями продукта и проекта. Иноrда требуется определить бюджет и сроки,
необходимые для реализации заданноrо объема функциональности. Б друrих
случаях нужно понять, сколько функциональности удастся реализовать в заранее
определенный срок при фиксированном бюджете. Мноrие проекты существуют
в условиях «золотой середины, то есть некоторой rибкости в выборе бюдже
та, срока и функционал:ьности. Б таких ситуациях различные пути, по KOTOpbIl\f
может пойти проrрамма, порождают сильно различающиеся комбинации затрат,
сроков и функциональности.
ДОПУСТИI, вы разрабатываете систему ввода заказов, но еще не сr.rl0rли Bыpa
ботать требования для ввода телефонных номеров. Среди факторов неопределен
ности, способных повлиять на оценку проrраммы, r.rfОЖНО выделить слеДУlощие.
. Желает ли клиент, чтобы введенный телефонный номер проверялся на
действительность?
. Если клиент хочет иметь систему проверки телефонных номеров, какую
верСИIО он предпочтет  дешеВУIО или дороryIО? (Обычно каждая конкретная
функция существуют в нескольких версиях, рассчитанных на 2 часа, 2 дня
или 2 недели  например, только для внутренних телефонных HOt\fepoB
США или для международных номеров).

52 rлава 4 · Откуда берутся ошибки оценки?
· Если реализовать дешеВУIО версию про верки телефонных номеров, не захо
чет ли клиент позднее переключиться на дороrую?
· Нельзя ли воспользоваться rотовоЙ системой проверки телефонных HOMe
ров или вследствие какихто проектных оrраничений необходимо разрабо
тать свою собствеННУIО?
· Как будет спроектирована система про верки? (Обычно разные проект
ные версии одной функции различаются по сложности как минимум на
порядок. )
· Сколько времени потребуется на проrраммирование системы проверки
телефонных номеров? (Время, необходимое разным разработчикам на
проrраммирование одноЙ возможности, также r.ложет различаться на поря
док и более.)
· Должна ли система проверки телефонных номеров взаимодействовать с сис
темой проверки адресов? Сколько времени потребуется на интеrраЦИIО
двух систем?
· Каким должен быть уровень качества системы про верки телефонных HOMe
ров? (В зависимости от уровня принятых мер предосторожности количест
во дефектов в исходной реализации может различаться на порядок.)
· Сколько времени потребуется на отладу и исправление ошибок в реали
зации системы проверки телефонных номеров? (Эффективность отладки
и исправления одних и тех же ошибок проrраммистами одноrо уровня
может различаться на порядок.)
Как видно даже из этоrо KopoTKoro списка, потенциальные различия в опреде
лении, проектировании и реализации одних и тех же возможностей MOryT накап
ливаться и увеличить время их реализации в сотни и более раз. А если объеди
нить их в сотнях и тысячах функций большоrо проекта, вы получаете Becb?vla
значительную неопределенность в оценке caMoro проекта.
4.2. Конус неопределенности
Разработка проrраммноrо обеспечения состоит из буквально тысяч решений OT
носительно всех вопросов функциональности, описанных в предыдущем разделе.
Неопределенность в оценках проrраммноrо обеспечения обусловлена разреше
нием неопределенности при принятии решений. С принятием все большей доли
этих решений сокращается общая неопределенность оценки.
Исследователи обнаружили, что оценкам проектов на разных стадиях при
сущи проrнозируемые уровни неопределенности. Конус неопределенности на
рис. 4.1 показывает, что оценки становятся более точными по ?vlepe продвижения
работы над проектом. (В последующем объяснении для простоты рассматривает
ся последовательная методолоrия разработки. В конце раздела объясняется, как
применить эти концепции к итераТИВНЫ?v1 проектам.)

4.2. Конус неопределенности 53
По rоризонтальной оси отложены основные ключевые этапы проекта  ис
ходная концепция, соrласованное определение проекта, завершение постановки
требований и т. д. Может показаться, что терминолоrия ориентирована на KOH
кретные проrpаммные продукты, но это объясняется лишь ее происхождением.
Скажем, определение продукта» просто обозначает соrласованное представление
о проrрамме, или 'Концепцию npolpaм..мbl, и в равной степени относится к вебслуж
бам, внутренним системам орrанизаций и к большинству друrих разновидностей
проrраммных проектов.
4х
2х
1,5х
Неопредеnенность 1,25х
в оценке проекта 1,Ох
(объем работы, О 8
, х
затраты,
функциональность) О,67х
О,5х
0,25х
О:: О::
ro s
:I:::f

X::f
U:c
SO

ффro
ost:
:I::C
:СФ
roc::
саФо.
8afc:
roo.
Е с:
00
()
ф,s
s s
:С :I:
фro
3 са
0.0
ф\о
са Ф
roo.
M
erg
:С :С е ,s
ФroUФ
зса-е-
о.8. т о.
фs....ф
mt:ro
мфсаs
00
0.С")
c:
а
с:
0)00::
ss
:со:с
ф:Ссо
зm
о.С::о
O)roo.
catD s
roctt:
м о)
о
о.
с:
)) t:

mX r:::[
oo
....O.
roC:
о.
L..
о
О.
с:
Рис. 4.1. Конус неопределенности для основных ключевых этапов проекта
По вертикальной оси отсчитывается относительная величина ошибки в про
ектах, создаваемых ОПЫТНЬПvIИ оценщиками на разных стадиях работы над про
ектом. Оценка может относиться к затратам или объему работы на реализа
цию определенноrо набора функций, количеству функциЙ для заданноrо объема
работы или срока и т. д. В книrе общим термином объем обозначается размер
проекта в рабочем времени, затратах, функциональности или некоторой их KOl\-I
бинации.
Как видно из rpафика, оценки, созданные на очень ранней стадии проекта,
подвержены высокой степени ошибок. Оценки, созданные на стадии исходной
концепции, MOryT отличаться в большую или 1еньшую сторону до 4 раз (что TaK
же выражается в виде О,25х, то есть 1/4). Полный диапазон от верхней оценки до
нижней составляет 4х/О,45х, то есть 16х!

54 rлава 4 · Откуда берутся ошибки оценки?
Руководство и клиенты часто задают вопрос: Если дать вам еще неделю на
работу над оценкой, сможете ли вы уточнить ее так, чтобы снизить степень неоп
ределеНIIОСТИ? Вопрос вполне лоrичный, но, к сожалению, ответить на Hero по
ложительно невозможно. Исследования Луиса Ларанхейра показывают, что точ
ность оценки проrраммноrо проекта зависит от степени уточнения определения
проrраIМЫ (Laranjeira 1990). Чем точнее определение, тем точнее оценка. Оценка
изменчива, прежде Bcero, ПОТОfУ, что неопределенность заложена в самом проек
те. ЕДIIнствеННЫNl спосоБОl сокращения неопределенности в оценке является co
кращение ее в проекте.
Стандартное изображение конуса неопределенности создает ошибочное впе
чатление, будто конус сужается очень медленно (словно хорошая точность oцeH
ки становится возможной лишь тоrда, коrда работа над проектом почти заверше
на). К счастью, это Bcero лишь ИЛЛIО3ИЯ, возникающая изза Toro, что ключевые
точки на rоризонтальной оси разделены равными интервалами; мы подсозна
тельно предполаrаем, что rОРИ30НТальная ось представляет календарное время.
В действительности все ключевые точки rруппируются в начальной части rpa
фика проекта. После перерисовки в календарном представлении конус принима
ет вид, показанный на рис. 4.2.
Завершение
требований rотовый
Завершение п р оrраммный
Завершение  детальноrо
П р оекти р ования продукт
проектирования
пользовательскоrо
интерфейса
Соrласованное
определение
продукта
Исходная
концепция Время
Рис. 4.2. Конус неопределенности в календарном представлении
Неопределенность
в оценке проекта
(объем работы,
затраты,
функциональность)
1,5х
1 ,25х
1,Ох
О,8х
О,67х
0,5х
0,25х
4х
2х
Как видно из этоrо рисунка, точность оценки быстро возрастает в течение пер
вых 30 % проекта и улучшается с + 4х до + 1,2Sx.
Можно ли победить конус неопределенности?
rоворя о конусе неопределенности, необходимо учитывать одну важную (и слож
ную) концепцию: конус неопределенности представляет лучшую тОЧll0стъ, которая
может быть обеспечена в различных ключевых точках проекта. Конус представляет

4.2. Конус неопределенноcrи 55
ошибку оценки, разработанную опытными специалистами. Результат вполне MO
жет оказаться и хуже. Получить более ТОЧНУIО оценку невозможно; разве что вам
может больше повезти.
СОВЕТ NQ 11
Проанализируйте воздействие конуса неоnределенности на точность вашей оценки. Ваша oцeH
ка не может быть более точной, чем это возможно на текущей позиции проекта внутри конуса.
Конус не сужается автоматически
Мы rоворим о конусе неопределенности как о наилучшеЙ оценке еще и потому,
что при недостаточно хорошем управлении проектом (или недостаточноЙ компе
тентности оценщиков) ожидаемоrо уточнения оценки может и не быть. На рис. 4.3
показано, что происходит, коrда управление проектом не направлено на сниже
ние неопределенности  последняя принимает вид не конуса, а облака, которое
не рассеивается до caMoro конца проекта. Пробле?\fа даже не в том, что оценки не
сходятся  не сходится сам проект (то есть неопределенность не вытесняется
в степени, необходимой для помержки более точных оценок).
4х
2х
Неопределенность
в оценке проекта
(объем работы,
затраты,
функциональность)
1.5х
1,25х
1,Ох
О,ах
О,67х
+
О.5х
О,25х
Время
Рис. 4.3. При недостаточно качественной оценке или управлении проектом возникает
«облако неопределенности», представляющее еще большую ошибку оценки
по сравнению с той, что заложена в конусе
Конус сужается только при принятии решений, направленных на устранение
неопределенности. Как видно из рис. 4.4, определение представлениЙ о продукте
(включая представления о том, что он ие дОЛ:JlCе1l делать) способствует снижению
уровня неопределенности. Определение требований (также включая требования
к тому, что он не будет делать) продолжает снижать неопределенность. Проекти
рование пользовательскоrо интерфейса способствует снижеНИIО риска неопреде
ленности, возникающеrо- изза HenepHoro понимания требован:ий. Конечно, если

56 rлава 4 · Откуда берутся ошибки оценки?
продукт не был толком определен или определение продукта было позднее изме
нено, конус расширяется, а точность оценки ухудшается.
СОВЕТ NQ 12
Не надейтесь, что конус неопределенности будет сужаться сам собой. Вы должны заставить ero
сужаться, устраняя источники неопределенности из проекта.
4х
2х . .
.. ...
;
..
.. ..
1.5х :
Неопределенность ;
1,25х . . . . .
в оценке проекта 1.0х .. .
. .
(объем работы, "-
затраты. О,8х
функциональность) : .. ..
О.67х . .. . . . .
.. ..
О.5х
Определение продукта
I I I
Подробные требования
Специфик"ация пользовательскоrо
интерфейса
О.25х
Время
Рис. 4.4. Конус неопределеннасти не сужается сам по себе. Вы заставляете ero сужаться,
принимая решения, которые способствуют устранению источников неопределеннасти
из проекта. Одни решения определяют, что должно быть реализовано в проекте;
друrие  чеrо в нем быть не должно. Последующее изменение решений
приведет к расширению конуса
Учет конуса неопределенности в оценках
,
nporpaMMHbIX проектов
АнаЛIIЗ оценок проrраммных проектов показал, что специалисты, начинающие
с точечных оценок и определяющие диапазоны на их основании, обычно не KOp
ректируют минимальное и максимальное значение с учетом неопределенности
в оценке, особенно в ситуациях высокой неопределенности (Jergensen 2002). TeH
денция к использованию зауженных диапазонов преодолевается двумя способами.
Вопервых, можно начать с наиболее вероятной оценки, а затем вычислить диапа
зоны с использованием заранее определенных множителей, как показано в табл. 4.1.
При использовании оценок из этой таблицы необходимо понимать, что в MO
I\ICHT создания оценки вы еще не знаете, в какую сторону окажется смещенным
фактический результат проекта  к началу или к концу диапазона.
СОВЕТ NQ 13
Учитывайте наличие конуса неопределенности, закладывая в своих оценках заранее опреде
ленную амплитуду неопределенности.

4.2. Конус неопределенности 57
Таблица 4.1. Ошибка оценки в ключевых точках работы над проектом
Фаза Ошибка
Возможная ошибка Возможная ошибка Диапазон
в меньшую сторону в большую сторону
Исходная концепция 0,25х (75 О/о) 4,Ох (+300 О/о) 1бх
Соrласованное определение 0,50х (50 О/о) 2,Ох (+100 О/о) 4х
продукта
Завершение проектирования 0,б7х (33 О/о) 1,5х (+50 О/о) 2,25х
пользовательскоrо интерфейса
Завершение детальноrо 0,90 О/о (10 О/о) 1,10х (+10 О/о) 1,2х
проектирования
ИсmОЧllUК: По .материала.м «Software Estimatioп with Сосото II (Boehm et а/. 2000).
Второй способ основан на отделении оценки Toro, что мы знаем от «оценки
неопределенности». Один специалист дает оценки наилучшеrо и наихудшеrо
случая (то есть концов диапазона), а друrой оценивает вероятность 1'oro, что фак
тический результат войдет в этот диапазон (J0rgensen 2002).
СОВЕТ NQ 14
Учитывайте наличие конуса неопределенности, разделяя оценку на две составляющие: один
специалист дает количественную оценку, а друrой оценивает ее неопределенность.
Связь между конусом неопределенности
и обязательствами
ОрrаНlIзации, заНИfающиеся разработкой проrpаммноrо обеспечения, нередко ca
fИ способствуют срыву собственных проектов, ПРИНИlая обязательства в слиш
KOI раннеЙ точке конуса неопределенности. Если обязательства ПРИНИl\lаются во
вреl\'lЯ разработки исходной концепции или определения продукта, в них закла
дывается ошпбка от 2х до 4х. Как обсуждалось в rлаве 1, опытный руководитель
проекта способен довести проект до завершеНI1Я, если оценка отклоняется от деЙ
ствитеJIЬНОСТИ не более чем на 20 %. Однако ни ОДНОl\lУ руководителю не удастся
успешно завеРШIIТЬ проект, если оценка смещена на несколько сотен процентов.
В раннеЙ, широкой области конуса принять осмысленные обязательства 1Iе
ВОЗ!\IОЖНО. Эффективно работающие орrаНIIзации откладывают принятие обяза
TeJIbCTB до Toro I01\IeHTa, Korna выполненная работа приведет к сужению конуса.
В более зрелоЙ фазе проекта (ПРИfерно 30 %) осмысленные обязательства воз
:можны и Yl\leCTHbI.
Конус неопределенности и итеративная разработка
Учесть воздействие конуса неопределеННОСТII в итеративных проектах несколько
сложнее, чеf при традИЦИОННОl\l последовательном подходе.
Если вы работаете над проеКТОI, который на каждой итерации проходит полный
цикл разработки (то есть от постановки требований до выхода rотовой версии),
... . v v
то на каждои итерации возникает свои l\fиниатюрныи конус неопределенности.

58 rлава 4 · Откуда берутся ошибки оценки?
Перед постановкой требований для текущей итерации проект находится в точке
соrласованноrо определения продукта и подвержен 4кратной амплитуде неоп..
ределеННОСТII в оценках. При коротких итерациях (меньше месяца) переход от
соrласованноrо определения проекта к фазам определения требований и завер
шения проектирования пользовательскоrо интерфейса происходит за несколько
днеЙ, а неопределенность снижается с 4х до 1,6х. При фиксированном rрафике
неопределенность 1,6х будет относиться к функциональности, rотовой в OTBeдeH
ное вре1Я, а не 1( объему работ или CpOkal\-l. IIeKoTopbIe преИ1ущества в оценке,
возникаlощие при использовании коротких итераций, обсуждаются в разделе 8.4.
С друrоЙ стороны, при выборе подходов, при которых требования остаIОТСЯ
неопределенными до начала каждой итерации, утрачивается возможность ДОЛ"
rосрочноrо проrнозирования комбинаций затрат, сроков и функциональности
(то есть их проrнозирования на несколько итераций спустя). Как рассказано в rла
ве 3, в вашей орrанизации приоритетным показателем может считаться именно
rибкость, а возможно, руководство выберет предсказуемость проектов.
Альтернативой пОЛ1l0стью итеративноrо цикла разработки вовсе не являет
ся omcyтC"l8Ue итераций; этот подход уже доказал свою полную неэффектив
ность. Скорее, речь идет о сокращении количества итераций или выборе apyzux
итерациЙ.
Мноrие rруппы разработчиков выбирают промежуточные методики, коrда
большинство требований определяется в началЫIОЙ стадии работы над проектом,
а проектирование, конструирование, тестирование и выпуск производятся KOpOT
кими итерациями. Друrими словами, проект движется последовательно от точки
завершения проектирования пользовательскоrо интерфейса (около 30 % кален
дарноrо времени проекта), а затем переходит на более итеративный путь. Неопре
деленность, обусловленная воздействием конуса, снижается до + 25 %; это позво
ляет добиться поставленных целей при качественном управлении проектом, не
утрачивая основных преимуществ итеративной разработки. Рабочие rруппы
MorYT оставить часть запланированноrо времени на требования, которые еще
,
предстоит определить, в конце проекта. В функциональность проекта вводится
небольшая неопределенность, которая в даННОl\l случае иrрает скорее положи
тельную роль  ведь данная ВОЗ1\10ЖНОСТЬ используется только в том случае, если
в ходе работы над проектом будут выявлены новые желательные возможности.
ПромежуточныЙ подход обеспечивает долrосрочную проrнозируемость затрат
и сроков в сочетании с умеренной rибкостью в требованиях.
4.3. Хаотические процессы разработки
Конус представляет неопределенность, присущую даже в хорошо управляемых
проектах. Плохое управление проектом создает дополнительную неопределен
ность  «факторы хаоса», которых IОЖНО было бы избе)кать.
Типичные примеры хаотических факторов:
. поверхностный анализ исходных требований;
. отсутствие участия конечноrо пользователя в постановке требованиЙ;

4.4. Нестабильные требования 59
. плохое проектирование, порождающее мноrочисленные ошибки в про
rpaMMHoM коде;
. плохая методолоrия проrpаl\fмирования, требующая продолжительноrо ис
правления ошибок;
. недостаточная квалификация персонала;
. неполное или неумелое планирование проекта;
. присутствие звезд в rpуппах;
. отказ от планирования изза давления;
. отсутствие aBTOl\-lатизированной системы контроля исходных кодов.
Я привел лишь частичный список ВОЗl\-10ЖНЫХ хаотических факторов. За более
полной ИНфОРlvlацией обращайтесь к rлаве 3 Moeii книrи «Rapid Development»
(McConnell1996) и к статье по адресу www.stevemcconnell.com/rdenum.htm.
Источники хаоса обладают д BYl\-f Я общими признакаfИ. Вопервых, каждый из
них порождает неопределенность, затрудняющую оценку. BOBTOpЫX, возникаю
щие под их воздействием проблеIЫ лучше Bcero решать на уровне управления
проектом, а не на уровне оценки.
СОВЕТ NQ 15
Не рассчитывайте, что совершенствование методики оценки само по себе обеспечит более
точную оценку в хаотических проектах. Невозможно точно оценивать процесс, который вами
не контролируется. На первом шаrе важнее избавиться от хаоса, чем совершенствовать
оценку.
4.4. Нестабильные требования
Изменения в требованиях часто называют среди стандартных источников He
определенности при оценке (Lederer and Prasad 192, Jones 1994, Stutzke 2005).
Кроме всех типичных проблеl\1 общеrо плана, нестабlLl'Iьные требования создаIОТ
две специфические пробле!vIЫ.
Вопервых, нестабильные требования представляют одну из конкретных раз
новидностей хаотических факторов. Если требоваНIIЯ не удастся стабилизиро
вать, конус неопределенности не сузится и неопределенность оценки останется
высокой вплоть до завершающеЙ стадии работы над проеКТОl.
BOBTOpЫX, ИЗl\lенения в требованиях часто не отслеживаются, а проект не
подверrается переоценке, как это должно быть. В хорошо управляе10l\1 проекте
исходный набор требованиЙ ПРИНИl\-fается за точку отсчета, на основании котороЙ
оцениваются затраты и сроки. По мере добавления новых IIЛII переС10тра старых
требований оценки затрат и СТОИl\10СТИ также ДОЛЖНЫ переСlатриваться с учеТОf
этих изменений. На практике РУКОВОД1IтеЛII проеКТОБ часто пренебреrают 06HOB
лениеf оценок СТОИfОСТИ и затрат при ИЗlенеНIIИ требоваНИII. Возникает пара
доксальная сиryация: оценка исходной Функциона. 1 ]ЬНОСТIf :моrла быть правильноЙ,
но после Toro, как проект был расширен десяткаIИ новых требованиЙ (соrла

60 rлава 4 · Откуда берутся ошибки оценки?
сованных, но не учтенных), у Hero не остается ни малейшеrо шанса выдержать
исходную оценку. Все соrласны, что добавленные возможности были полезны
ми,  а проект становится опоздавшим.
Конечно, описанные в книrе методы помоryт улучшить оценку в условиях BЫ
сокой изменчивости требований, однако совершенствование оценки само по себе
не решит проблем, возникающих изза нестабильных требований. Эффективные
меры должны приниматься на уровне управления проектом, нежели на уровне
оценок. Если рабочая ситуация не позволяет стабилизировать требования, поду
l\-Iайте о применении альтернативных подходов, предназначенных для сред с BЫ
V u
сокои изменчивостью,  коротких итерации, экстремальноrо проrраммирования,
Scrum, DSDM (Dynamic System Development Method ) и т. д.
СОВЕТ NQ 16
В условиях нестабильных требований следует ориентироваться на стратеrии управления проек
том вместо стратеrий оценки (или совместно с ними).
Оценка роста требований
Если потребуется оценить влияние нестабильности требований, один из воз
fОЖНЫХ путей заключается в простом включении допуска на рост и/или изме
нения требований в оценки. На рис. 4.5 показан видоизмененный конус неопре
деленности, учитывающий приблизительно 50%.:й POGT требований в ходе работы
над проектом. (Рисунок приведен только для наrлядности. Конкретные точки
данных не поддерживаются данными тех исследований, что и точки исходноrо
конуса. )
4х
2х
1\ 
" '-..
 
 
 
....
/
/ ,
/ v
Неопрццеленность
в оценке проекта
(объем работы,
затраты,
функциональность)
1,5х
1,25х
1,Ох
О,8х
О,67х
О,5х
О,25х
Время
Рис. 4.5. Конус неопределенности с поддержкой изменения требований в ходе проекта
Данная методика используется мноrими ведущими орrанизациями, в том чис
ле лабораторией разработки проrраммноrо обеспечения NASA, закладывающей

4.5. Пропущенные операции 61
в свои оценки возможность 40 % роста требований (NASA SEL 1990). Аналоrnчная
концепция присутствует в модели оценки Сосоmо 11 (Boehm et al. 2000).
4.5. Пропущенные операции
в предыдущих разделах были описаны источники ошибок, обусловленные спе
цификой проекта. В остальных разделах настоящей rлавы мы займемся ошибка
ми, обусловленными методами оценки.
Одним из самых распространенных источников ошибок оценки  необходимые
задачи, которые не были включены в оценку проекта (Lederer and Prasad 1992,
Coombs 2003). Аналитики обнаружили, что это явление проявляется как на уровне
планирования проектов, так и на уровне отдельных разработчиков. В одном из ис
следований обнаружилось, что разработчики обычно довольно точно оценивают ту
работу, которую ясно представляют себе, но при этом забывают от 20 до 30 % необ
ходимых задач, что приводит к 2030%Й ошибке в оценке (van Genuchten 1991).
Работа, не учтенная в оценке, делится на три общие катеrории: отсутствующие
требования, отсутствующие действия по разработке проrраМl\.fноrо обеспечения,
и отсутствующие действия, не связанные с разработкой.
В табл. 4.2 перечислены требования, часто не учитываемые при оценке проекта.
Таблица 4.2. Функциональные и нефункциональные требования, часто не учитываемые
при оценке проекта
Функциональные требования
Проrрамма установки/настройки конфиryрации
Утилита преобразования данных
Связующий код, необходимый для использования
nporpaMMHoro обеспечения сторонних
производителей (или распространяемоrо
с открытыми кодами)
Справочная система
Режимы развертывания
Интерфейсы с внешними системами
Нефункционanьныетребования
Точность
Способность к взаимодействию
Модифицируемость
Производительность
Портируемость
Надежность
Способность к реаrированию
Возможность мноrократноrо использования
Масuпaбируемость
БезопасноС1Ъ
Живучесть
Практичность
СОВЕТ NQ 17
Включайте в оценку время для всех видов требований  заявленных, неявных и нефункциcr
нальных. Ничто не создается «из ничеrо», и ваша оценка не должна подразумевать, будто воз
можно обратное.
в табл. 4.3 перечислены факторы, относящиеся к разработке проrpам1\1ноrо
обеспечения, о которых часто забывают при составлении оценки.

62 rлава 4 · Откуда берутся ошибки оценки?
Таблица 4.3. Действия по разработке nporpaMMHoro обеспечения, часто не учитываемые
при оценке проекта
«Время раэrона» для новых участников
rpYnnbI
Обучение новых участников rpYnnbI
Координация управления/встречи руководства
Развертывание
Преобразование данных
Установка
Настройка
Прояснениетребований
Сопровождение системы управления пересмотром
проектных решений (Revision Control System)
Поддержка сборки
Сопровождение сценариев, необходимых
для выполнения ежедневной сборки
Сопровождение автоматизированных тестов,
используемых в сочетании с ежедневной
сборкой
Установка тестовых сборок на оборудовании
пользователя
Создание тестовых данных
Управление проrраммой бетатестирования
Участие в техническом рецензировании
Работа по интеrрации
Обработка запросов на внесение изменений
Присутствие на собраниях, посвященных
управлению изменениями/назначению
приоритетов
,
Координация с субподрядчиками
Техническая поддержка существующих
систем
Работа по сопровождению предшествующих
систем во время проекта
Работа по исправлению дефектов
Настройка производительности
Изучение HOBoro инструментария
Административная работа, связанная
с отслеживанием дефектов
Координация с тестовой rруппой
(для разработчиков)
Координация с разработчиками (для тестовой
rруппы)
Ответ на вопросы rpYnnbI контроля качества
Поставка материалов для написания
пользовательской документации
и ее рецензирование
Рецензирование технической документации
Демонстрация nporpaMMbI клиентам
или пользователям
Демонстрация nporpaMMbI на выставках
Демонстрация nporpaMMbI или прототипа
высшему руководству, клиентам
и пользователям
Общение с клиентами и конечными
пользователями; поддержка установки
бетаверсий на оборудовании клиента
Рецензирование планов, оценок, архитектуры,
детальных проектов, поэтапных планов, кода,
тестовых случаев и т. д.
СОВЕТ NQ 18
Учитывайте в оценке все необходимые операции, связанные с разработкой проrраммноrо обес
печения, не только проrраммирование и тестирование.
в табл. 4.4 перечислены факторы, не ОТНОСЯlциеся к разработке проrраммноrо
обеспечения, но также часто не учитываемые при составлении оценки.
Таблица 4.4. Факторы, не связанные с разработкой nporpaMMHoro обеспечения,
часто не учитываемые при оценке проекта
Отпуска
Праздники
Болезни
Обучение
Выходные
Собрания уровня компании
Собрания отделов
Настройка новых рабочих станций
Установка новых версий инструментария на рабочих станциях
Диаrностика аппаратных и nporpaMMHbIx проблем

4.6. Необоснованный оптимизм 63
Некоторые проекты намеренно планируются с исключениеl\1 l\1ноrих факто
ров, перечисленных в табл. 4.4. Такой подход может сработать в течение KOpOTKO
v
ro времени, но все эти операции все равно заимут свое место в проектах, продол
жительность которых превышает несколько недель.
СОВЕТ NQ 19
В проектах, продолжительность которых превышает несколько недель, следует предусматри
вать допуск для дополнительных факторов: праздников, отпусков по болезни, времени обуче
ния, собраний.
Кроме использования этих таблиц для идентификации частей проrpаммноrо
продукта или операций, которые должны быть включены в оценку, также стоит
рассмотреть ВОЗ10ЖНОСТЬ применения методики WBS (Work Breakdown Structure)
для всех стандартных факторов, учитываемых в оценке. В разделе 10.3 обсужда
ется оценка с ПРИl\Jlенением WBS и рассматривается обобщенный пример WBS.
4.6. Необоснованный оптимизм
Оптимизм атакует проrрам:мные проекты из всех источников. Что касается oцeH
ки проекта со стороны разработчиков, Вllцепрезидент Мiсrоsоft Крис Питерс
(Chris Peters) заl\1етил: «Никоrда не следует опасаться Toro, что оценка, создан
ная разработчиком, окажтся излишне пессимистичной, потому что разработчики
всеrда назначают слишком оптимистичные сроки (Cusumano and Selby 1995).
Изучив 300 проrраIМНЫХ проектов, Майкл ван [енахтен заlетил, что в оценках
разраБОТЧIIКОВ обычно зак,"Iадывается допуск на оптимизм, составляющий от 20
до 30 % (van Genuchten 1991). Хотя руководители иноrда жалуются на обратное,
разработчики не склонны к завышению при оценках проектов  наоборот, их
оценки обычно оказываются заниженными!
СОВЕТ NQ 20
Не уменьшайте оценки, полученные от разработчиков,  скорее Bcero, они и без Toro излишне
оптимистичны.
Оптимизм также проявляется и в высшем звене. При изучении 100 оценок
проектов Министерства обороны США обнаружился устойчивый «коэффициент
фантазии, равный ПРИlерно 1,33 (Boehm 1981). Возможно, руководители про
ектов и начальство и не предполаzают, что проекты MOryT быть сделаны на 30 %
быстрее или дешевле, чем в действительности, но они хотят, чтобы это произош
ло. Это само по себе является проявлением оптимизма.
Несколько стандартных вариаций на тему оптимизма.
. Над этим проеКТОf мы будем: работать более эффективно, чеl\.1 над преды
дущим проектом.
. В последнем проекте все шло наперекосяк. В этом проекте проблеl\1 будет
меньше.

64 rлава 4 · Откуда берутся ошибки оценки?
. Проект начинался медленно, и мы прошли трудный начальный период.
Тем не ?\feHee мы MHoroMY научились на своих ошибках, и ближе к концу
мы будем работать rораздо эффективнее, чем в начале.
Учитывая, что оптимизм является почти неотъемлемой частыо человеческой
натуры, оценки проrраммных проектов иноrда нарушаются изза явления, KOTO
рое я называю croBopoM оптимистов. Разработчики предостаЛЯIОТ оптими
стичные оценки. Высшему руководству нравятся оптимистичные оценки, потому
что они подразумевают достижимость желательных деловых целеЙ. Менеджерам
нравятся эти оценки, потому что они подразумевают возможность выполнения
указаний начальства. ПроrраммныЙ проект набирает силу, и никому даже в ro
лову не приходит критически проанализировать обоснованность самих оценок.
4.7. Субъективность и пристрастие
Субъективность проникает в оценки в форме ОПТИfизма, в форме сознательноrо
пристрастия и в форме бессознательноrо пристрастия. Я различаю пристрастие
в оценке, предполаrающее намерение сместить оценку в том или ином направ
лении, и субъективность, то есть простое признание Toro факта, что на человече
ские суждения оказывает влияние житейский опыт (как сознательно, так и бес
сознательно ).
Что касается пристрастия, коrда клиенты и руководство обнаруживают, что
оценка не соответствует деловой цели, иноrда они пытаются оказать больше дaB
ления на оценку, на проект и на rруппу. Избыточное давление, направленное на
сокращение сроков работ, встречается в 7S100 %.крупных проектов (Jones 1994).
Ч то касается субъективности, при рассмотрении различных методик оценки
l\IbI от природы склонны полаrать: чем больше у нас «реryляторов, то есть мест
для подrонки оценки под наш конкретный проект, тем точнее будет оценка.
В действительности все наоборот. Че?\1 больше реryляторов у оценки, тем
больше возможностей 'для проникновения субъективности. Проблема даже не
в том, что оценщики намеренно смещают свои оценки. Скорее, каждый субъек
тивный фактор слеrка размывает оценку в ту или иную сторону. Если методика
оценки основана на большом количестве субъективных входных факторов, их
cYIMapHoe воздействие может быть весьма значительным. .
Я встречал один из примеров TaKoro рода, коrда учил несколько сотен специа
листов использовать модель оценки Сосото 11. Модель включает 17 множителей
..
и 5 масштабных коэффициентов. Чтобы создать оценку Сосото 11, оценщик дол
жен решить, какая реryлировка необходима для каждоrо из этих 22 факторов.
Факторы определяют квалификацию rpуппы (выше или ниже среднеrо), относи
тельную сложность проrpаммы (выше или ниже средней) и т. д. Теоретически
эти 22 реrулятора должны обеспечивать тонкую подстройку практически
любой оценки. Похоже, на практике они лишь открывают 22 пути для проникно
вения ошибок в оценку.
На рис. 4.6 показаны диапазоны результатов примерно 100 rpупп оценщиков,
определявших 17 множителей Сосото 11 для одной и той же проблемы оценки.

4.7. Субъективность и пристрастие 65
НижниЙ край каждой полосы представляет самую низкую, а верхний краЙ 
верхнюю оценку rруппы в.сеансе. Общая высота полосы соответствует изменчи
васти оценок.
60
55
50
45
40
Оценка
(человеко 35
месяцы)
30
25
20
15
10
(3) (3) (4) (4) (4) (5) (5) (5) (6) (6) (6) (6) (6) (7) (8) (8) (9) (10)
Сеанс оценки (количество rpynn)
Рис. 4.6. Пример неодноначности оценок при наличии мноrочисленных реryлирующих
факторов. Чем больше реryлирующих факторов предоставляет метод оценки, тем больше
возможностей для проникновения в оценку субъективности
Если бы 1vlетодика оценки давала последовательный результат, lbI бы увидели
тесную rруппировку результатов вдоль rОРИЗОI-lТальной синей линии (средняя
оценка). Но как видите, разброс между оценками orpoMeH. Наибольшая оценка
превышала наименьшую в 4 раза! Среднее отклонение верхнеЙ rруппы от ниж
ней в рамках одноrо сеанса было равно 1,7.
Важная особенность данных этоrо KOHKpeTHoro ПРИfера заключается в том,
что они бъUlИ освобождены от внешних смещений. Все происходило на учебном ce
м:инаре, в котором первоочередное внимание уделялось точности. Единственным
смещением, влиявшим на оценки, было при страсти е, из начально присущее oцeH
щикам. Вероятно, в реальной ситуации разброс был бы еще больше изза возрас
тания внешних факторов, влияющих на оценки.
Напротив, на рис. 4.7 показан диапазон результатов оценки для методики,
включающей единственную возможность введения субъективноrо мнения в oцeH
ку, то есть обладающей одним реryлятором (в данном случае этот реryлятор
никак не связан с множителями модели Сосото 11).
Вывод больше реryлируюших факторов  не значит лучше выходит за раfКИ
оценки проrpаммных проектов. По выражению эксперта по проrнозированию Дж.
Скотта ApMcTpoHra (]. Scott Armstrong), один из самых неизменных и полезных
выводов из исследований в области проrнозирования состоит в том, что простые l\fe
тоды в общеl\.f случае не уступают в точности сложным MeToдaM (Arrnstrong 2001).
3 Зах. 893

66 rлава 4 · Откуда берутся ошибки оценки?
150
125
100
Оценка
(человеко-
месяцы)
75
 . . C::::::::::I
50
25
(4) (4) (5) (5) (5) (6) (6) (6) (6) (6) (7) (7) (8) (9) (9) (11)
Сеанс оценки (количество rpупп)
Рис. 4.7. При мер низкоrо разброса в оценках, обусловленноrо малым количеством
реryлирующих факторов. Масштабы двух rрафиков различны, однако rрафики
можно сравнивать напрямую с учетом различий в средних значениях
СОВЕТ NQ 21
Избеraйте включения «реryляторов» В свои оценки. Хотя может показёПЬСЯ, будто реryляторы улуч-
шают точность, на самом деле они вводят в оценку субъективность и снижают реальную точность.
4.8. Импровизированные оценки
Рабочие rpуппы иноrда попадают в ловушку импровизированных оценок. Допус
тим, ваш начальник СПР{lшивает: ((Сколько времени потребуется для реализации
предварительноrо просмотра на вебсайте Gigacorp? Вы отвечаете: He знаю.
Наверное, около недели. Надо подумать. Вы идете к своему столу, анализируете
u u
архитектуру и код тои проrраммы, о которои спраШIIВал начальник, замечаете He
сколько обстоятельств, о которых забыли раньше, подводите итоr и решаете, что
потребуется около пяти недель. Вы торопитесь зайти в кабинет начальника, чтобы
обновить свою первую оценку, но начальник на собрании. На следующий день вы
встречаетесь с ним, но не успеваете и рта открыть, как он rоворит: Кажется, проект
небольшой, так что я сходу предложил одобрить функцию предварительноrо про
смотра на бюджетном совещании. Комитет по бюджету заинтересовался и хочет уви
деть rотовый результат на следующей неделе. Вы можете приступить немедленно?
Я обнаружил, что самая безопасная политика  не давать импровизирован
ных оценок. Ледерер и Прасад выяснили, что интуиция и доrадки при оценке
проrpаммных проектов коррелируются с превышениями затрат и сроков (Lederer
and Prasad 1992). Я собрал данные импровизированных оценок по 24 rруппам. На
рис. 4.8 показаны средние ошибки импровизированной оценки в этих 24 rpуппах
в сравнении с оценками, прошедшими процесс обсуждения в rpуппах.

4.8. Импровизированные оценки 67
225%
220 0/0 Рассмотренные
оценки
175 %
150 О/о . Импровизированные
оценки
125%
100%
Ошибка 75% t
50%
25 О/о
О О/о
25%
=:: I I' ,+, ,r, ,
1 2 3 4 5 6 7 8 9 1 О 11 12 13 14 15 1 б 17 18 19 20 21 22 23 24
rpynna оценки
Рис. 4.8. Средняя ошибка импровизированных оценок в сравнении
с рассмотренными оценками
Средняя импровизированная оценка обладала средней величиной относитель
ной ошибки 67 %, тоrда как у средней рассмотренной оценки ошибка составляла
Bcero 30 %  менее половины. (Пример взят не из области оценок проrpаммноrо
обеспечения, поэтому ошибки в процентах не следует применять буквально к oцeH
кам проrраммных проектов.)
Одна из ошибок, часто допускаемых при составлении оценок только на базе
собственных воспоминаний, заключается в том, что новый проект сравнивается
с воспоминаниями о том, сколько времени ушло на работу над прошлым проектом.
К сожалению, люди часто запоминают свои оценки прошлых проектов, а не фак
тuческие результатыl. Если прошлая оценка берется за основу для новой оценки,
а в результате прошлоrо проекта эта оценка была превышена  чем это кончится?
Оценщик изначально закладывает нарушение сроков в оценку HOBoro проекта.
Хотя Ледерер и Прасад обнаружили, что доrадки и интуиция положительно
коррелируются с превышением оценок, также выяснилось, что использование
документированных фактов отрицательно коррелируется с превышением oцe
нок. Друrими словами, существует оrромная разница между импровизацией и OT
ветом: He MOry сказать сразу  я должен подойти к столу и проверить коекакие
заметки. Я подойду через 15 минут, если вы не против.
Это может показаться тривиальным, однако импровизированные оценки co
ставляют одну из самых частых причин ошибок, допускаемых при работе над
проектами (Lederer and Prasad 1992, ]иrgепsеп 1997, Kitchenham et al. 2002). OT
каз от импровизированньrx оценок  один из самых важных моментов в Книrе.


68 rлава 4 · Откуда берутся ошибки оценки?
СОВЕТ NQ 22
Не давайте импровизированных оценок. Даже если потратить на оценку Bcero 15 минут, она
будет более точной.
Что делать, если начальник звонит вам по сотовому телефону и требует oцeH
ку немедлеН1l0? Вспомните свой результат в тесте из rлаве 2. Вам удалось полу
чить 8 правильных ответов из 10? Если нет, то каковы шансы на то, что импрови
зированная оценка (даже если учесть в ней неопределенности) с вероятностью
90 % будет включать правильный ответ?
4.9. Излишняя четкость
В повседневных разrоворах люди нередко считают точность и четкость» сино
нимами. Тем не :м:енее в области оценки между этими двумя терминами сущест
вуют принципиальные различия.
Точность указывает, насколько близка оценка к реальному значению. Чет
кость относится только к представлению числа и в области оценки проrpаммных
проектов равносильна количеству значащих цифр в оценке. Значение может быть
четким, не будучи точным, и наоборот. Простая цифра 3 является точным пред
ставлением числа пи с точностью до одной цифры, но четким такое представ
ление не является. С друrой стороны, число 3,37882 обладает большей четкостью,
но точность у Hero меньше.
Расписания полетов обладают четкостью дО IИНУТ, но они не очень точны. Из
l\lерение роста людей в целых метрах может давать точный результат, но о четко
сти не l\10жет быть и речи. .
В табл. 4.5 приводятся примеры чисел, которые являются точными и/или чет
кими.
Таблица 4.5. Примеры точности и четкости
,
Пример
1t=З
1t = 3,37882
1t = 3,14159
Мой pocr = 2 метра
Расписания полетов
«На выполнение проекта потребуется
395,7 ДНЯ :f: 2 месяца»
«На выполнение проекта потребуется
один rод»
«На выполнение проекта потребуется
7 ,214 человекочасов»
«На выполнение проекта потребуется
4 человекоrода»
Комментарий
Точность до одной цифры, но без четкоcrи
Четкоcrь до б значащих цифр, но точноcrь только
ДО одной значащей цифры
И точноcrь, И четкоcrь до б значащих цифр
Точность до одной значащей цифры, но не очень четко
Четкоcrь до минуты, но не очень точно
Высокая четкоcrь, но оценка неточна для заявленной
четкоcrи
Не очень четко, но, может быть точно
Высокая четкоcrь, но, вероятно, оценка неточна
для заявленной четкоcrи
Не очень четко, но может быть точно
,


Дополнительные ресурсы 69
в контексте оценки проrpаммных проектов различия между точностью и чет
костью становятся принципиальными. Ключевые фиryры делают предположе
v
ния относительно точности проекта на основании четкости, с которои им пред
ставлена оценка. Если вы представляете оценку в 395,7 дня, руководство будет
полarать, что оценка обладает точностью до 4 значащих цифр! Возможно, точность
оценки будет лучше отражена в друrом формате оценки: 1 rод, 4 квартала, или
13 месяцев. Использование оценки 395,7 дня вместо одноrо rода напоминает пред
ставление числа пи в виде 3,37882  высокая четкость при снижении точности.
СОВЕТ NQ 23
Количество значащих цифр в оценке (ее четкость) должно соответствовать точности оценки.
4.10. Друrие источники ошибки
Источники ошибок, описанные в первых девяти разделах rлавы, являются наиболее
распространенными и значительными, однако список нельзя назвать исчерпываю
щим. Вот еще несколько путей, по которым ошибка может проникать в оценку:
· незнакомая область деятельности;
· незнакомая технолоrическая область;
· неверное преобразование оцениваемоrо времени в проектное (например,
предположение о том, что rруппа будет работать над проектом по 8 часов
в день, 5 дней в неделю);
· неверно е понимание статистических концепций (особенно суммирование
набора оценок для лучших и худших случаев);
· БIоджетные процессы, подрывающие эффективную оценку (особеннq Tpe
бующие соrласования итоrовоrо бюджета в широкой части конуса неопре
деленности);
· наличие точной оценки масштаба проекта, с внесением ошибок при ее пре
образовании в оценку объема работы;
· наличие точных оценок масштаба и объема работы, с внесением ошибок
при их преобразовании в расписание проекта;
· завышенные ожидания от применения новых средств или методов разра
ботки;
· упрощение оценки при ее передаче на верхние уровни управления, при
формировании бюджета и т. д.
Эти темы подробно рассматриваются в следующих rлавах.
Дополнительные ресурсы
Armstrong, J. Scott, ed. Principles of forecasting: А handbook for researchers and
practitioners. Boston, МА: Kluwer Academic Publushers, 2001. ApMcTpoHr  один
из ведущих исследователей в области рыночноrо проrнозирования. Мноrие

....
70 rлава 4 · Откуда берутся ошибки оценки?
результаты наблюдений, приведенные в книrе, относятся к оценке nporpaMMHbIX
проектов. ApMcTpoHr также является ведущим критиком излишне сложных Moдe
лей оценки.
Боеhm, Barry, et al. Software Cost Estimation with Сосото II. Reading, МА:
AddisonWesley, 2000. Бем первым популяризировал идею конуса неопределен
ности (он называет ero «воронкой» ). В книrе приведено ero самое новое описание
этоrо явления.
Cockburn, Alistair. «Agile Software Development. Boston, МА: AddisonWesley,
2001. Б КlIиrе Кокберна представлены динамические методы разработки, особен
но полезные в условиях нестабильных требований.
Laranjeira, Luiz. Software Size Estimation of ObjectOriented Systems», IEEE
Transactions of Software Engineering, Мау 1990. В статье представлено теорети
ческое обоснование для конуса неопределенности, выявленноrо эмпирическим
путем.
Tockey, Steve. Return оп Software. Boston, МА: AddisonWesley, 2005. В rла
вах 21  23 обсуждаются основные принципы и общие методы, а также рассказано,
как учесть неточность в оценке. В книrе Токи приведено подробное описание по
строения собственноrо конуса неопределенности.
Wiegers, Karl. «More About Software Requirements: Thorny Issues and Practical
Advice. Redmond, W А: Мiсrоsоft Press, 2006.
Wiegers, Karl. «Software Requirements, Second Edition. Redmond, W А: Micro
soft Press, 2003. Методы, описанные Виrерсом в эт.их двух книrах, помоrают каче
ственно сформулировать исходные требования, что способствует существенному
снижению неустойчивости требований на последующих стадиях проекта.

Факторы, влияющие
на оценку
Сколько будет 68 + 73?
Инженер: 141. Коротко и мило.
Математик: 68 + 73 == 73 + 68 по свойству KOMMyтa
тивности сложения. Верно, но не слишком полезно.
Бухrалтер: «Обычно 141, но в каких целях вы соби
раетесь использовать результат?
Баррu В. Бем. u Ричард э. Фарли
,
Факторы, оказывающие влияние на проrраммный проект, следует подверrнуть
разностороннему анализу. Хорошее знание этих факторов повышает точность
оценки и улучшает понимание общей динамики проrpаммноrо проекта.
Разумеется, размер проекта является самым значительным фактором, опреде
ляющим объем работ, затраты и сроки. На втором месте стоит тип разрабатывае
мой проrpаммы, а на третьем  личные факторы. Язык проrpаммироваНl-1Я и pa
бочая среда не оказывают первостепенноrо влияния на исход проекта, но они
оказывают первостепенное влияние на оценку. Б этой rлаве представлены перво
степенные факторы в порядке снижения значимости, а в конце приводится CBOД
ка второстепенных факторов.
5.1. Размер проекта
Важнейшим фактором влияния в оценке проrраммноrо обеспечения является
размер разрабатываемой проrpаммы, потому что он подвержен наибольшему раз
нообразию по сравнению со всеми остальными факторами. На рис. 5.1 показана
зависимость роста объема работ в среднем проекте бизнессистемы при увеличе
нии размера проекта с 25 000 до 1 000 000 строк кода. Размер проекта на рисунке
выражается в строках проrраммноrо кода (LOC), но динамика останется одной
и той же независимо от Toro, в чем измеряется размер  в функциональных пунк
тах, длине списка требований, количестве вебстраниц или любых друrих показа
телях, выражающих те же диапазоны.


72 rлава 5 · Факторы, влияющие на оценку
Как видно из диаrpаммы, система, состоящая из 1 000 000 строк кода, потребу
ет rораздо большеrо объема работы, чем система, состоящая из 100 000 строк.
Утверждение о том, что размер проекта является основным фактором, опреде
ляющим затраты, покажется KOMYTO тривиальным, однако мноrие орrанизации
часто нарушают этот основополаrающий принцип в двух отношениях:
. затраты, объем работы и сроки оцениваются без информации о размере
проекта;
. затраты, объем работы и сроки не реryлируются при сознательном увели
чении размера проекта (то есть в ответ на запросы о внесении изменений).
2,250
2,000
1 ,750
1.500
Объем 1,250
работы
(человеко 1,000
месяцы)
750
500
250
о
&&&&&&&&&&&&&&&&&&
                   

Ю€О&&
'"
Размер проекта (LOC)
Источник: По данным модели оценки Сосото 11
при номинальных издержках масштаба (Boehm. et al 2000)
Рис. 5.1. Рост объема работ в типичном проекте бизнессистемы. Конкретные числовые
показатели имеют смысл только ДЛЯ средних бизнессистем, но общая динамика
применима к проrpаммным проектам всех типов
СОВЕТ NQ 24
Приложите соответствующие усилия ДЛЯ оценки размера nporpaMMbI, над которой вы работае
те. Размер вносит наиболее значительный вклад в определение объема работы и сроков.
Почему в книrе размер задается в количестве строк
проrраммноrо кода?
Люди, не имеющие опыта оценки, иноrда спрашивают, действительно ли количест
во строк проrpаммноrо кода является содержательным показателем для измерения
размера проrраМ1Ы. Вопервых, мноrие современные среды проrраммирования

5.1. Размер проекта 73
в меньшей мере ориентированы на строки кода, чем старые среды. BOBTOpЫX, He
малая часть процесса разработки проrpаммноrо обеспечения  постановка требова
ний, проектирование и тестирование  не производят проrpаммный код, измеряе
мый в строках. Если вас интересует, как эти факторы отражаются на полезности
измерения размера проrраммы в cpOKax кода, обратитесь к разделу 18.1.
Издержки масштаба
Мы часто полаrаем, что на построение системы, в 10 раз большей друrой, потребу
ется в 1.0 раз больше усилий. Однако объем работы для системы в 1 000 000 строк
превышает 10кратный объем работы для системы в 100 000 строк, а последний
более чем в 1 О раз превышает объем работы для системы в 1 О 000 строк.
Основная проблема заключается в том, что крупные п-роекты треБУIОТ коорди
нации между большим количеством rpупп, которым приходится больше общаться
между собой (Brooks 1995). С ростом размера проекта число КО?\-Iмуникационных
путей СВЯЗl1 между людьми растет в квадратиЧ1l0Й зависимости от количества
участников проекта 1 . Динамика роста показана на рис. 5.2.
G)
(з)
@
0-----0
д

Коммуникационный путь
с 2 участниками
Коммуникационный путь
с 3 участниками
Коммуникационный путь
с 4 участниками

@
Коммуникационный путь Коммуникационный путь
с 5 участниками с 1 О участниками
Рис. 5.2. Количество коммуникационных путей в проекте возрастает
пропорционально квадрату числа участников
Следствием экспоненциальноrо роста количества коммуникационных ка..
налов (наряду с друrими фаI(торами) является экспоненциальный рост Tpyдoel"
кости с увеличением размера проекта. Данное явление называется издеР'lCка..Аlи
.масштаба (diseconomy of scale).
t Количество каналов paBHO'n х (п.....1), то есть ФУНI\ЦИЯ 110рЯДI\3 112.

-
74 rлава 5 · Факторы, влияющие на оценку
Вне области проrраммноrо обеспечения мы обычно rоворим об экономии Mac
штаба, а не об издержках масштаба. Экономия масштаба означает примерно сле
дующее: Если построить больший обрабатывающий завод, мы сможем COKpa
тить стоимость единицы TOBapa. Друrими словами, чем больше объем, тем ниже
стоимость.
С издержками масштаба дело обстоит наоборот  с увеличением масштаба
системы стоимость каждой единицы повышается. Если бы в области проrpамм
Horo обеспечения проявлялся эффект экономии масштаба, то стоимость системы
в 100 000 строк была бы меньше 10кратной стоимости системы из 10 000 строк.
На практике почти всеrда наблюдается обратное явление.
На рис. 5.3 продемонстрированы типичные издержки масштаба в области про
rpaMMHoro обеспечения по сравнению с увеличением объема работы, ассоциируе
Moro с линейным ростом.
180
160
140
120
Объем 100
работы
(человеко 80
месяцы)
60
40  Линейный рост
20 ........... Типичный рост
о
         
\S \S r;::,\S \S \S \S \S \S \S 
'" ' ' ' ' '=> ' ro' '\' 'b' cъ' \S
Размер проекта (строк кода)
Источник: По данным модели оценки Сосото 11
при номинальных издержках масштаба (Boehm, et al 2000)
Рис. 5.3. Издержки масштаба в типичных проектах бизнессистем от 10 000
до 100 000 строк кода
Как видно из rрафика, в данном примере на систему в 10000 строк кода потре
буется 13,5 человекомесяцев. Если бы объем работ возрастал линейно, то систе
ма в 100 000 строк потребовала бы 135 человекомесяцев, но в действительности
она требует 170 человекомесяцев.
На рис. 5.3 эффект издержек масштаба не выrлядит особенно впечатляющим.
Действительно, в диапазоне от 10 000 до 100 000 строк он не так уж силен. Тем
не менее два фактора способны сделать эффект издержек масштаба более ради

5.1. Размер проекта 75
кальным. Один фактор  это большие различия в размерах проекта, а друrой 
условия проекта, снижающие производительность при росте размера проекта.
На рис. 5.4 изображен диапазон результатов для проектов в интервале от 10 000 до
1 000000 строк. Кроме номинальных издержек масштаба, на rрафике также пока
заны издержки в наихудшем случае.
6,000
5,000
 Линейный рост
............. Тип ич н ы й рост
мс ... Worst Case
.;
.;
,.
;
.;
4,000
.".
"
,.
.;
Объем
работы
(человеко 3,000
месяцы)
,
,.
,
1,000
,.
,
2,000
.;
"
.,;

о

                   
,,,'''''''''''' '
@Щ
t-..'
Размер проекта (строк кода)
Источник: По данным модели оценки Сосото 11 при номинальных
и худших издержках масштаба (Boehm, et al 2000)
Рис. 5.4. Издержки масштаба в проектах с большими различиями в размерах, а также
издержки в худшем случае
Из rpафика видно, что объем работы при худших издержках растет rораздо бы
стрее, чем при номинальных, а при больших размерах проекта эффект выражен
rораздо ярче. В соответствии с кривой номинальноrо роста, объем работы для
100 000 строк кода превышает объем работы для 10 000 строк не в 10, а в 13 раз.
При 1 000 000 строк кода объем работы превышает объем работы для 10 000 строк
уже не в 100, а в 160 раз.
е худшими издержками дело обстоит еще хуже. Объем работы для худшеrо
случая при 100 000 строк кода в 17 раз превышает объем для 1 О 000 строк, а при
1 000 000 строк он больше не в 100, а в целых 300 раз!
В табл. 5.1 продемонстрирована общая связь между размером проекта и про
изводит ель н остью.
Цифры, приведенные в таблице, действительны только для сравнения меж
ду диапазонами размеров. Тем не менее представленная ими общая тенденция
весьма важна. Производительность в lелких проектах в 23 раза превышает

76 rлава 5 · Факторы, влияющие на оценку
производительность в крупных проектах, а между тем самый мелкий проект может
превосходить самый крупный по производительности в 510 раз.
Таблица 5.1. Связь между размером проекта и производительноcrью
Размер проекта (в строках кода) Строк кода на человеко-rод (в скобках.....
номинальное значение Cocomo 11)
10К
100К
1М
10М
200(}-.-25 000 (3200)
100(}-.-20 000 (2600)
70(}-.-10 000 (2000)
ЗО(}-.-SООО (1600)
Источник: По даиllЫ.М «Measures for Ехсеllепсе (Pиtпaт aпd Meyers 1992), -«/пdust1ial Stl'eпgth
50ftlP)al-е» (Риtпат aпd Meyel's 1997), «50ftware Cost Estiтatioп with Сосото /I (Boehт et
al. 2000) и «50fwJare Developmeпt Worldwide: The 5tate о! the Practice» (Сиsumапо et al. 2003).
СОВЕТ NQ 2S
Не следует предполаrать, что объем работ линейно зависит от размера проекта. Рост происхо
дит по экспоненте.
В том, что касается издержек масштаба, имеются как положительные, так и OT
рицательные стороны. Начнем с отрицательных: при существенных различиях
в размере проектов новый проект нельзя оценивать применением простоrо Mac
штабноrо коэффициента к объему работ, известному по предыдущим проектам.
Скажем, если объем работ для предыдущеrо проекта в 100 000 строк кода COCTa
вил 170 человекомесяцев, можно предположить, что производительность COCTaB
ляет 100 000/170, то есть 588 строк кода на человекомесяц. Данное предполо
жение f\10жет быть разумным для друrоrо проекта примерно TaKoro же размера,
но если новый проект в 1 О раз больше, такая оценка производительности может
оказаться смещенноЙ на величину от 30 до 200 %.
Впрочем, это еще ие все: в области неформальной оценки не существует про
стоЙ методики, которая бы позволяла учесть значительные различия в размерах
двух проектов. Если вы оцениваете проект, по размеру значительно отличающий
ся от тех проектов, с КОТОРЫ?\fИ ранее имела дело ваша орrанизация, вам потре
буется оценочная проrраМl\lа, использующая научные методы для вычисления
оценки HOBoro проекта по результатам старых проектов. Моя компания предлаrает
бесплатную проrрамму Construx@ Estimate™, выполняющую подобные оценки.
Проrраl\If\'1У f\10ЖНО заrрузить по адресу www.construx.com/estimate.
СОВЕТ NQ 26
Используйте специализированные nporpaMMbI для вычисления влияния издержек масштаба.
Коrда можно смело иrнорировать издержки масштаба
После всех плохих новостей настал черед хороших. Как правило, проекты, KO
торыми занимается орrанизация, имеют сходные размеры. Если новый проект
по раЗf\fеру мало отличается от прошлых проектов, обычно при ero оценке можно

5.1. Размер проекта 77
использовать простой масштабный коэффициент  скажем, количество строк KO
да на человекомесяц. На рис. 5.5 показаны относительно малые различия при
линейном и экспоненциальном росте в конкретном диапазоне размеров.
300
Объем
работы
(человеко..
месяцы)
150
250
200
100
50
......... Линейный рост
 Типичный рост
о
          
c:s c:s c:s c:s c:s c:s c:s c:s c:s c:s c:s
<:;:)' ' ' ' ' ' ' ' " ' <::)"
"3 со '\: со oj      
Размер проекта (строк кода)
Источник: По данным модели оценки Сосото 11
при номинальных издержках масштаба (Boehm, et al 2000)
Рис. 5.5. Различия между оценками, полученными с применением простых коэффициентов,
и оценками с учетом издержек масштаба, в одном диапазоне размеров будут более
или менее минимальными
СОВЕТ NQ 27
Если ранее вы уже завершали предыдущие проекты, размер которых незначительно отличается
от размера оцениваемоrо проекта (в диапазоне, в котором самый большой проект превосходит
самый мелкий не более чем в 3 раза), для оценки HOBoro проекта можно смело использовать
масштабный коэффициент (скажем, количество строк кода на человекомесяц).
Важность издержек масштаба при оценке
nporpaMMHbIX проектов
в мире оценки проrраммных проектов на точное определение влияния издер
жек масштаба направляются значительные усилия. Несмотря на важность этоrо
фактора, следует помнить, что rлавным опредеЛЯЮЩИ1 фаКТОРО1 в оценке яв
ляется простой размер проекта. Эффект издержек масштаба является фактором
BToporo порядка, поэтому основные усилия следует направить на получение
хорошей оценки размера. О том, как создаются оценки размера, будет paCCKa
зано в rлаве 18.

78 rлаsа 5 · Факторы, влияющие на оценку
5.2. Тип nporpaMMbI
Послс размера проекта наибольшее влияние на оценку оказывает тип созда
JJаМ()Й npOrpaMMJJI. Если вы работаете над критически важным проектом, к KO
ТОРОМУ лреДЪЯВЛЯJОТСЯ особые требования, проект потребует rораздо большеrо
оGъ{ма работ, чем npOeJ<T бизнессистемы аналоrичноrо размера. В табл. 5.2
нринсдеНIJI лримерl)1 производительности (в строках кода на человекомесяц) для
t'pOeJ(TOJJ раэных ТИПОВ.
Таблица 5.2. Проиэводительность для стандартных типов проектов
Тип проrраммы Строк кода на чеповеко-месяц (номинал)
Проект на 10 000 Проект на 100 000 Проект на 250 000
строк кода строк кода строк кода
100--1000 (200) 2Q.-.300 (50) 2200 (40)
80Q.--18 000 (3000) 207000 (БОО) 10Q.-.SOOO (500)
2003000 (500) 5 (}-.б О О (100) 4Q.-.500 (80)
10(}-.-2000 (300) 3500 (70) 200 (БО)
БО0--10 000 (1500) 10(}-.-2000 (300) 101500 (200)
1500--18 000 (4000) 30Q.-.7000 (800) 20Q.-.5000 (БОО)
Авиационное оборудование
Бизнес-система
Системы управления
Встроенные системы
Интернет-сиcrемы (открытые)
Интрасетевые системы
(внутренние)
Микрокод
Управление процессами
С'1стемы реальноrо времени
Системы научных и инженерных
исследований
Коммерческие пакеты
Системные проrpaммы/драйверы
Телекоммуникации
10О--ВОО (200) 2Q.-.200 (40) 2Q.-.100 (30)
SOQ.-SOOO (1000) 10Q.-.1000 (300) 8(}-.900 (200)
10Q.-1500 (200) 2Q.-.300 (50) 2Q.-.ЗОО (40)
SOQ.-7500 (1000) 10 1500 (ЗОО) 8Q.-.1000 (200)
40Q.-5000 (1000) 10Q.-.1000 (200) 7(}-.800 (200)
20Q.-SOOO (БОО) SQ.-1000 (100) 4(}-.800 (90)
20Q.-3000 (БОО) 5Q.-.600 (100) 4Q.-.500 (90)
Ift"",tJtJпUN.' [10 cЭtlJUlbl" \IMsllrPSJo"Exce//e1lce (Put1Jam aпd Meyers 1992), .IndиstriaJ Stтeпgth
So.J'rtrl(II't! (/'111'(111' tllltJ \leyttrs 1997) 14 .Fir.'fJ Со,-в Metrics. (Pиtпaт alld Meyers 2003).
I(Нl( "IlДHO.1I тn(ilftllЦЫ, rруппа, разрабатывающая интрасетевую систему для
llttYTl1t'H"eto I1rпо"ьзоваНIlЯ 10жет rеиерllровать КОД в 1020 раз быстрее, чеl.i
rРУllпа, раuотаl0Щая над npoeктo.t управления aв}faцlIOHHblI оборудоваЮlем, сис
Tt'MfHl prt\Jtt}H01'O npett:'HlI IIЛIt BrTpoeHHOJ'\ снстеl\IОЙ. ТаБЛ11ца также в очередной
ра:1 :lt't01lt"TpllpyeT нздержн Inсштаба: в проектах на 100 000 строк КОД reHeplI
РУt'ТСЯ lрnадо te}lee Эtl)феКТllВНО, чем n проектCLХ на 10 000 CтpOK а в проектах
на 250 000 (TpOK эq>феJ\llIВНQСТЬ оказывается еще НИЖе..
OO,fH\C1"b, ЗЛЯ ()тopoii создает<,я nporpaмtHOe обеспеченlfе, можно учесть 
')1 t:НОl'об\Мlt,
· lltno..lb3yiiTe резу..,Ьrnты из табл.. 5..2 в качестве отправной ТОЧКII.. В этом
t\.1учае обратите ВНIlманllе на то_ что диапазоны в та1}lIце ШJfJIOКlI  оБыч
"О u{'рх1tяя l1.HlIU\\ ОТД1lчаетс-я ОТ НIlжнеJ" на порядок..

5.3. Факторы персонала 79
. Используйте модель оценки (такую, как Сосото 11) и отреryлируйте пара
метры оценки в соответствии со спецификой разрабатываемой проrpаммы.
Если вы пойдете по этому пути, вспомните предостережения из rлавы 4
о чрезмерном количестве реryляторов.
. Используйте данные, полученные ранее вашей орrанизацией; тем самым
в оценку автоматически ВКЛIочаются факторы разработки, действующие
в вашей отрасли. Данный способ однозначно является лучшим из трех. Ис
пользование исторических данных более подробно рассматривается в rлаве 8.
СОВЕТ NQ 28 .
в своей оценке учитывайте тип разрабатываемой nporpaMMbI  в отношении влияния на объем
работы и сроки этот фактор является вторым по значимости.
5.3. Факторы персонала
Факторы, связанные с подбором персонала, также оказывают значительное влия
ние на результат проекта. В соответствии с данными Сосото 11, в проекте на
100 000 строк кода суммарный эффект всех факторов персонала способен изме
нить оценку проекта в 22 уаза! Друrими словами, если проект получает наихуд
ший показатель в каждой катеrории, показанной на рис. 5.6 (светлые полосы), на
ero реализацию уйдет в 22 раза больше времени, чем на проект с лучшими показа
телями по каждой катеrории (темные полосы).
t
Квалификация аналитиков,
занимающихся постановкой требований
Квалификация проrраммистов (обща
Постоянство персонала (текуч
Опыт работы в прикладной об
Навыки владения языками и инструмен
Опыт разработки для данной пла
Слаженность
... .. . .. . ...
;Z$}*. 42 О/о'
..
я) :24 % 34 О/о
....
..
... . .
есть) ; ':71,9".%...- 29 00
. о.. .. .
ласти ;  1,g:,: о '. 22 %
. .. . ..
. . . . .. ...
тарием .....16 % 20 %
" .
тформы :'!' 1'5: '0,0'. 19 о/о
. ' . .
команды :::..;...1';:::% 11 ОА'
о'
:. -.?" J'(.:
Рис. 5.6. Зависимость объема работы над проектом от факторов персонала. В зависимости
от силы или слабости каждоrо фактора результаты проекта MOryт изменяться на указанную
величину, то есть если выработкой требований будут заниматься худшие аналитики,
объем работы возрастает на 42 О/о по сравнению с номиналом, а при лучших
аналитиках он снижается на 29 О/о
Воздействие этих факторов из модели Сосото 11 подтверждается мноrочислен
ными исследован:иями, начавши'МИСЯ еще в 1960x rодах и демонстрировавшими

80 rлава 5 · Факторы, влияющие на оценку
различия от 10:1 до 20:1 в производительности отдельных участников и целых
rpупп (Sackman, Erikson, and Grant 1968; Weinberg and Schulman 1974; Curtis
1981; Mills 1983; Boehm, Gray, and Seewaldt 1984; DeMarco and Lister 1985;
Curtis et аl 1986; Card 1987; Boehm 1987Ь; Boehm and Papaccio 1988; Valett and
McGarry 1989; Boehln et al. 2000).
Одно из следствиЙ подобных расхождений заключается в том, что точная
оценка проекта невозможна без HeKoToporo представления о том, кто будет за
ниматься ero выполнением, потому что производительность работников может
отличаться в 10 раз и более. Тем не менее в рамках одной конкретной орrаниза
ции TaKoro разброса, скорее Bcero, не будет, потому что разработчики как BepXHe
ro, так и нижнеrо уровня обычно склонны выбирать орrанизации, в которых pa
бота ют друrие люди аналоrичноrо уровня (Mills 1983, DeMarco and Lister 1999).
Есть и друrое следствие: выбор метода, обеспечивающеrо наиболее точную
оценку, зависит от Toro, знаете ли вы, кто именно будет выполнять оцениваемую
работу. Эта тема обсуждается в rлаве 16.
5.4. Язык проrраммирования
Язык проrраммирования, используемый в проекте, влияет на оценку по меньшей
мере в четырех отношениях.
Вопервых, как видно из рис. 5.6, опыт раБоl:ыI rруппы с конкретным языком
и инструментарием, используемыми в проекте, способен изменить общую произ
водительность в проекте до 40 %.
BOBTOpЫX, функциональность строки кода в разных языках проrpаммирования
также не является постоянной величиной. В табл. 5.3 приведены сведения о средней
функциональности ряда языков по отношению к языку проrраммирования С.
Таблица 5.3. Относительная функциональность команд языков BbIcoKoro уровня
по сравнению с эквивалентным кодом С
Язык
С
С#
С++
Cobol
Fortran 95
Java
Макроассемблер
Perl
Smalltalk
SQL
Visual Basic
По отношению к С
1:1
1:2,5
1:2,5
1:1,5
1:2
1:2,5
2:1
1:6
1:6
1:10
1:4,5
Источник: По дaHHbl.М ((Estiтatiпg Software Costs (]oпes 1998) и Software Cost Estiтatioп
with Сосото 11» (Boehт 2000).

5.5. Друrие факторы 81
Если используемый язык проrраммирования заранее известен, этот пункт
не относится к вашей оценке. Но если вы обладаете некоторой свободой выбо
ра языка проrраммирования, из таблицы видно, что такие языки, как J ava, С#
и Мiсrоsоft Visual Basic, обычно превосходят по продуктивности С, Cobol или
макроассемблер.
Третий фактор, также относящийся к языкам,  широта возможностей ин
струментария и рабочих сред. Соrласно данным Сосоmо 11, слабый инструмен
тарий и рабочая среда способны увеличить объем работы над проектом пример
но на 50 % по сравнению с сильными инструментариями и рабочими среда?\IИ
(Boehm et al. 2000). Также следует понимать, что выбор языка проrpаммирования
lvIожет определить выбор инструментария и рабочей среды.
Последний фактор, связанный с языком проrpаммирования, заключается в TO1,
что разработчики, использующие интерпретируемые языки, обычно работают
продуктивнее тех, кто применяет компилируемые языки  выиrрыш составляет
до 2 раз (Jones 1986а, Preschelt 2000).
Концепция объема функциональности на строку кода будет рассматриваться
дa.ТIee в разделе 18.2.
5.5. Друrие факторы
Модель оценки Сосоrnо 11 уже неоднократно упоминалась в этой rлаве. Как обсу
ждалось в rлаве 4, я испытываю определенные опасения по поводу проникнове
ния субъективности при использовании реryлирующих факторов Сосоmо 11. Тем
не менее мои опасения скорее относятся к неудачному применению, нежели к по
рокам методики. Проект Сосоmо II rораздо лучше справился со строrой изоля
цией влияния различных факторов на исход проекта, чем дрyrие проекты TaKoro
рода. В большинстве исследований происходит случайное или намеренное объ
единение нескольких факторов. Исследование может анализировать влияние Me
ТОДОВ совершенствования процесса проrpаммирования без изоляции эффекта от
перехода на друrой язык проrраммирования, объединения персонала с разных
площадок и т. д. В проекте Сосоmо 11 про водится наиболее строrий (в стати
стическом отношении) анализ отдельных факторов из всех проектов, которые
я видел. Итак, хотя я и предпочитаю друrие методы оценки, все же рекомендую
изучить реryлирующие факторы СосоПlО 11, чтобы понять важность различных
факторов, влияющих на оценку проrpаммноrо проекта.
В табл. 5.4 перечислены рейтинrи 17 множителей объема работы в модели
Сосоrnо 11. В столбце Очень низкие» представлена велич:ина, на которую следует
отреryлировать оценку объема работы для лучшеrо (или худшеrо) воздействия
данноrо фактора. Например, если rруппа обладает крайне низким опытом работы
в прикладной области, номинальная оценка объема работы Сосоmо 11 умножает
ся на 1,22. Если же rруппа очень хорошо разбирается в преДl\.lетной области, oцeH
ка вместо этоrо умножается на Ot81.

82 rлава 5 · Факторы, влияющие на оценку
Таблица 5.4. Реryлирующие факторы Сосото 11
Фактор Рейтинrи
Очень Низкие Номинальные Высокие Очень Чрезвычайно Влияние
низкие высокие высокие
Опыт работы 1,22 1,10 1,00 0,8 0,81 1,51
'"
в прикладнои
области
Размер базы 0,90 1,00 1,14 1,28 1,42
данных
Разработка 0,95 1,00 1,07 1,15 124 1,31
,
для повторноrо
использования
Объем 0,81 0,91 1,00 1,11 1,23 1,52
необходимой
документации
Навыки владения 1,20 1,09 1,00 0,91 0,84 1,43
языками
и инструментарием
Рассредоточенная 1,22 1,09 1,00 0,93 0,86 0,78 1,56
разработка
Постоянство 1,29 1,12 1,00 0,90 0,81 1,59
персонала
(текучесть)
Опыт разработки 1,19 1,09 1,00 0,91 0,85 1,40
для платформы
Неустойчивость 0,87 1,00 1,15 1,30 1,49
платформы
Сложность 0,73 0,87 1,00 1,17 1,34 1,74 2,38
продукта
Квалификация 1,34 1,15 1,00 0,88 0,76 1,76
проrраммистов
(общая)
Требуемая 0,82 0,92 1,00 1,10 1,26 1,54
надежность
проrраммноrо
обеспечения
Квалификация 1,42 1,19 1,00 0,85 0,71 2,00
аналитиков по
требованиям
Оrраничения по 1,00 1,05 1,17 1,46 1,46
объему хранимых
данных
Оrраничения по 1,00 1,11 1,29 1,63 1,63
быстродействию
Использование 1,17 1,09 1,00 0,90 0,78 1,50
проrраммных
инструментов

5.5. Друrие факторы 83
в крайнем правом столбце «Влияние» показана степень влияния каждоrо OT
дельно взятоrо фактора на общую оценку рабочеrо времени. Скажем, у фактора
квалификации в предметной области в этом столбце стоит значение 1,51; это
означает, что проект, выполняемый rpуппой с очень низкой квалификацией в этой
области, потребует в 1,51 раза больший объем работы, чем у rруппы с очень BЫCO
кой квалификацией (влияние вычисляется делением наибольшеrо значения на
наименьшее  например, 1,51 == 1,22/0,8).
На рис. 5.7 изображено друrое представление факторов Сосото 11; факторы
упорядочиваются по убыванию влияния.
Сложность продукта
Квалификация аналитиков по требованиям
Квалификация проrраммистов (общая)
Оrраничения по быстродействию
Постоянство персонала (текучесть)
Распределенная разработка
Требуемая надежность
проrраммноrо обеспечения
Объем необходимой документации
Опыт работы в прикладной области
Использование nporpaMMHbIX инструментов
Неустойчивость платформы
Оrраничения по объему хранимых данных
Изученностьпроцесса
Навыки владения языками
и инструментарием
Размер базы данных
Опыт разработки для платформы
Архитектура и разрешение рисков
Прецедентность
Разработка для nOBTopHoro использования
Слаженность команды
rибкость разработки
! '.'2t8"
I ::ry.oo:
.":;'i '.
..... . ..
I .. ... ........ . . ..... .. '
. . 1 .... . ...... '. . . .....
:. ..;?::' .... ... .... . .'
l ' .. .. ... ' !
16 '.] . . .. ..
:'.: ."... ... ...
..    . .  . . . . . .. .. .
[.59.' .. ..' :"::]
1:' 6',:...'.. .... ..... . .1
1> 1,54. ..' .... . ...... I
. . .. . .. ..
0.0. . .. .. . ..
l' . .. ' 1
....1"".:.. ....:.. ..:..: '.,
l ' .. ....... j
о... .... . .. . ..
.:: 1'.'5:1:'" . .
.... .t'.... ........ .
. .... . ..... ".' . .......
1:<1:Q' ':. '.:: ':..::: .........'. .... ......]
l:j.4........'... ...: . ......:..]
t: 1:46: ....:. ..... ....... :]
1.: i..:.,:.:. :.: .' ..'.:.:' ::... ..-: I
1 1:4З .. 1
".'. . .
i;":1 :42: .
I ",40 :'. J
[: :";8:' ,'.:.: :':':::":'::.= "0:::0 .: :]
l ' ..... )
. ..  
 . . . . . .
. 1:"'."'. ..... ..:.:. :.: :.
,. .1..:. .: .... : .... :. j
':.'1.$':.."..' ":.1
1:. {({ : .:' . "'1
J
Рис. 5.7. Факторы Сосото 11 по убыванию значимости. Относительная длина полос
представляет чувствительность оценки к различным факторам
На рис. 5.8 те же факторы представлены в зависимости от CBoero потенциа
ла к увеличению (светлые полосы) или снижению (темные полосы) общеrо
объема работы.

84 rлава 5 · Факторы, влияющие на оценку
. .... . . ..  ..
Сложность продукта :...... ...... '*T;%:':, 74 0/0
Квали ф ика ц ия аналитиков .,.. ....:. '.' :. .
'. . 29.. :%..: 42 0/0
по требованиям -.'..,.. ..... ...... .
Квалификация проrраммистов (общая) .,-::. '.. .:....:74'.' з4 0/0
Оrраничения по быстродействию О % 63 0/0
Постоянство персонала (текучесть) ," .'.>::1::'.'. 29 %
Распределенная разработка . _.. ...>:72:/. 22 %
Требуемая надежность - , " '.' ' :0' :" О
nporpaMMHoro обеспечения _. -:: . .. :.. 26 Уо
Объем необходимой документации . :-;.--:.49:;%:'; 23 %.
Опыт работы в прикладной области . ..... :+g:.::: 22 0/0
Использование nporpaMMHbIX инструментов _". ... .%.: 17 0/0
Неустойчивость платформы .:1::'% за %
Оrраничения по объему хранимых данных О % 46 0/0
Прецедентность '..,.. ':9;:.:. 15 %
Изученность процесса ...".. ;$: .: 15 0/0
Навыки владения языками : .. ....... 20 
и инструментарием' .... '.:. .. О
Размер базы данных 1.:.;: 28 00
Опыт разработки для платформы ...:.:?5::'%: 19 0/0' .
Архитектура и разрешение рисков ':" '::',:::: 14 %
rибкость разработки :' .....:.%.: .12 0/0.
Разработка для nOBTopHoro использования 5 :--. 24 %.
Слаженность команды >..j4:'%':: 11 %
Рис. 5.8. Факторы Сосото IJ по способности увеличивать (светлые полосы) или уменьшать
(темные полосы) общий объем работы
Некоторые замечания по поводу этих факторов приведены в табл. 5.5.
Таблица 5.5. Реryлирующие факторы Сосото 11
Фактор
Опыт работы
в прикладной
области
Архитектура
и разрешение
рисков
Влияние Комментарий
1,51 rруппам, незнакомым с прикладной областью проекта,
требуется значительно больше времени. Вероятно,
это никоrо не удивит
1,381 Чем активнее проект расправляется с ВОЗможными рисками,
тем ниже будут затраты и объем работ. Это один
из немноrочисленных факторов Сосото, находящихся
под контролем руководителя проекта
1 Точный эффект зависит от размера проекта. Приведенное значение соответствует разме
ру проеl:та около 100 000 строк. Эти факторы рассматриваются в следующем разделе.

5.5. Друrие факторы 85
Фактор Влияние Комментарий
Размер базы 1,42 Большие, сложные базы данных требуют больших усилий
данных на уровне проекта. Общее влияние  умеренное
Разработка 1,31 Затраты на nporpaMMHoe обеспечение, разрабатываемое
для повторноrо с расчетом на повторное использование в будущем, MOryт
использования увеличиваться до 31 О/о. Более Toro, успех инициативы
не rарантирован ....... опыт отрасли показывает,
что перспективные проекты nOBTopHoro использования
"
часто завершаются неудачеи
Объем 1,31 Слишком большое количество документации может
необходимой отрицательно повлиять на весь проект. Влияние.......
документации умеренно высокое
Навыки владения 1,43 rpYnnbI, обладающие опытом использования языков
языками проrраммирования и/или инструментария, работают более
и инструментарием продуктивно, чем rpYnnbI, проходящие период освоения
Распределенная 1,56 Проекты, выполняемые несколькими командами, находящимися
разработка на разных rеоrpафических мощадках, требуют на 56 О/о большеrо
объема работы, чем проекты, проводимые одной rруппой.
Эффект необходимо серЬеЗНО учитывать в распределенных
проектах, включая удаленную разработку (аутсорсинr)
и оффшорные проекты
Постоянство 1,59 Текучесть кадров обходится дороrо....... этот фактор входит
персонала в верхнюю треть
(текучесть)
Опыт разработки 1,40 Опыт разработки для технолоrической платформы умеренно
для платформы сказывается на общей производительности проекта
Неустойчивость 1,49 Если платформа нестабильна, разработка требует больше
платформы времени. Руководители проектов должны учитывать этот
фактор в своих решениях о переходе на новую технолоrию.
Это одна из причин, ПО которым системные проекты
выполняются дольше, чем прикладные проекты
Прецедентность 1,зз1 Показывает, насколько «прецедентно» приложение (хотя мы
чаще rоворим о «беспрецедентных» приложениях). Знакомую
систему всеrда проще создать, чем незнакомую
Изученность 1,431 Проекты, использующие развитые процессы разработки,
процесса требуют меньшеrо объема работы, чем проекты с плохо
проработанными процессами. Для применения этоrо
критерия к проектам в Сосото 11 используется
адаптированный вариант модели СММ
Сложность 2,38 Сложность продукта является самым значительным реryлирующим
продукта фактором в модели Сосото 11. В основном она определяется
v
типом создаваемои nporpaMMbI
Квалификация 1,76 Квалификация проrраммистов способна изменить общие
проrраммистов результаты проекта примерно в 2 раза
(общая)
продолжение &-
1 Точный эффект зависит от.размера"проекта. Приведенное значение соответствует разме
ру проекта около 100 000 строк. Эти факторы рассматриваются в следующем разделе.


86 rлава 5 · Факторы, влияющие на оценку
Таблица 5.5 (продолжение)
Фактор Влияние
Необходимая 1,54
надежность
Квалификация
аналитиков по
требованиям
2,00
rибкость
требований
1 261
,
Оrраничения по
объему хранимых
данных
Слаженность
команды
1,46
1 291
,
Оrраничения по
быстродействию
1,63
Использование
nporpaMMHbIx
инструментов
1,50
Комментарий
На построение более надежных систем уходит больше
времеIИ. Это одна из причин (хотя и не единственная),
по которым встроенные и критические системы требуют
большеrо объема работ, чем друrие проекты аналоrичноrо
размера. В большинстве случаев надежность проrраммноrо
продукта определяется рынком, и у вас нет скольконибудь
ощутимых возможностей для ее изменения
Важнейший из факторов персонала  хорошие навыки
в постановке требований  способен изменить объем работы
по всему проекту в 2 раза. Компетентность в этой области
способна снизить общий объем работы по проекту
от номинала более, чем какойлибо друrой фактор
Проекты, предоставляющие rpynne разработчиков определенную
rибкость в интерпретации требований, требуют меньшеrо
объема работы, чем проекты, настаивающие на жесткой,
буквальной интерпретации всех требований
Работа на платформе, на которой приходится постоянно
сталкиваться с оrраничениями объема, несколько
увеличивает объем работы по проекту
rpYnnbI с высоким уровнем сотрудничества разрабатывают
проrраммы более эффективно, чем rpYnnbI, в которых
взаимодействия часто сопровождаются разноrласиями
Снижение времени отклика приводит к увеличению объема
работ. Это одна из причин, по которым системные проекты
и проекты реальноrо времени требуют больших усилий,
чем друrие проекты аналоrичноrо размера
Выбор cOBpeMeHHoro инструментария способен заметно
снизить объем работ
Как я уже намекал ранее, изучение реryлирующих факторов Сосото 11 для
получения представления о сильных и слабых сторонах проекта является дея
тельностью относительно BbIcoKoro уровня. Для самой оценки rораздо проще
и точнее воспользоваться историческими данными из прошлых или текущих
проектов, чем возиться с 22 реryлирующими факторами Сосоrnо.
Процесс сбора и использования исторических данных подробно рассматрива
ется в rлаве 8.
5.6. Снова об издержках масштаба
Реryлирующие факторы Сосоrnо 11 позволяют взrлянyrь на издержки масштаба с HO
вой интересной точки зрения. Пять из факторов, изображенных на рис. 5.9, назы
ваются масштабными факторами  это те факторы, которые вносят свой вклад
1 Точный эффект зависит от размера проекта. Приведенное значение соответствует разме
ру проекта около 100 000 строк. Эти факторы рассматриваются в следующем разделе.

5.6. Снова об издержках масштаба 87
в издержки масштаба проrpаммноrо проекта. Они в разной степени влияют на про
екты разных размеров. На рис. 5.9 масштабные факторы выделены светлым.
Сложность продукта ': 8,., '"'":':'.. ,.."., ,: ,> ""> .
Квалификация аналитиков по требованиям ',".':'
Квалификация проrраммистов (общая) }:6;" ,:'
...............
Оrpаничения по быстродействию 'з:..." ...,;..:>:,.... * .':: ,» ','
Постоянство персонала (текучесть) "":"., .:.:. . ::,>.:
Распределенная разработка ;J.s&',. >"" ,.
Требуемая надежность проrраммноro обеспечения "f54: ,.
Объем необходимой документации "52' . ,-  
Опыт работы в прикладной области ,'.,.s=.f.): ., ,'. ,
Использование проrраммных инструментов JiO <:'." '::.. '
Неустойчивость платформы  4;1 , . ... . .......
Оrpаничения по объему хранимых данных 1  ..: ..
Изученность процесса [i.4, ,', ::::. :.:., ,>1
Навыки владения языками и инструментарием . 4з 
Размер базы данных 1;4.2,,' ..., >,..:f
Опыт разработки для платформы . M"" ,:. .
. . ...... '\0)-
Архитектура и разрешение рисков l'.;1З. . .. .'I
Прецедентность I:. ., '1
Разработка для повторноro использования 'i':?" :;.. '
Слаженность команды f:i,ig.. '. I
rибкость разработки 1: i.2o , .1
Рис. 5.9. Факторы Сосото 11; масштабные факторы выделены светлым.
Приведены данные для проекта на 100 000 строк кода
.<
Ни один из факторов, вносящих вклад в издержки масштаба проекта, не находит
ся в верхней половине факторов, упорядоченных по значимости. Более Toro, 4 из 5
наименее значимых факторов являются масштабными. Тем не менее, поскольку
масштабные факторы вносят разный вклад в зависимости от размера проекта,
диarpамма должна составляться для проекта конкретноro размера. Данные на рис. 5.9
приведены для проекта на 100000 строк кода. На рис. 5.10 показано, что происхо
дит при пересчете факторов для rораздо большеrо проекта на 5 000 000 строк кода.
е точки зрения оценки это означает, что в проектах разных размеров факторам
должны присваиваться разные весовые коэффициентыI. е точки зрения планирова
ния и управления проектами это означает, что успех мелких и средних проектов
сильно зависит от качества персонала. Б крупных проектах сильные личности
попрежнему необходимы, но не менее значительную роль иrpает и качество управ
ления проектом (особенно в отношении'управления рисками, -зрелость орrани
зации и то, насколько слаЖенно отдельные личности работают в составе rруппы).


88 rлава 5 · Факторы, влияющие на оценку
Сложность продукта ...' :$, ':" . __'. ". ;-"' .::.... ,;«' ..; ... :"'" . . .  ':'
Квалификация аналитиков по требованиям .: ..Q(f<"': ',.' '.: .. "';:. $(,,"a : ::':\:::]
Изученность процесса I:: 4/": ........ ......, ." :'.' : ... '. .." : :.. .'.'. .. .' .:'.' .... :....Н
Архитектура и разрешение рисков I:;::':":.:':"::::;::' .-:. '..  .  : ': .,:.. .: ':'':<tll
Квалификация проrpаммистов (общая) . 1$;:. .' >,п,:..., ..<: . :"'> .
Прецедентность 1:J;7.9>..  .. ..... I
Оrpаничения по быстродействию' 't$. .<.,  .... .,. ..:-
Слаженность команды 1.:i5:::; :'.::'.' ,::''::':'::'.'"'.::'::'::':': ,:'.: ::I
Постоянство персонала (текучесть) .' 5;t<., .:.. J . и'. ",>.,'
Распределенная разработка . '5 .. ...». ... -<<-'. ".
rибкость разработки 1:;)".?4:::" . .... ..'  ... . I
Требуемая надежность nporpaMMHoro обеспечения у ":.:;,,:: <'.:';;:
Объем необходимой документации S ..;"Y'" ;-:/ ,
Опыт работы в прикладной области ".' $. ..' ,..:  .: , . .
Использование проrраммных инструментов . :."':":.:'>::",,,:. :
Неустойчивость платформы 1'.,"'Y':'" ':';' ,.;
Оrраничения по объему хранимых данных .  \',' \....;.
Навыки владения языками и инструментарием ..4....o:,.;.::,.'O:.
Размер базы данных .' ': ,;. '.;.::
Опыт разработки для платформы  '4q" '.' , .
Разработка для повторноro использования :. 1:
Рис. 5.10. Факторы Сосото 11; масштабные факторы выделены светлым.
Приведены данные для проекта на 5 000 000 строк кода
Дополнительные источники
Боеhm, Barry, et al. Software Cost Estimation with Сосоmо II. Reading, МА:
Addison W esley, 2000. Книra содержит наиболее авторитетное описание Сосоmо 11.
Ее толщина внушает страх, однако базовая модель Сосоrnо описывается на пер
вых 80 страницах, вместе с подробными определениями множителей объема
работы и масштабных факторов и учетом издержек масштаба в Сосоmо 11. Б OCTaв
шейся части книrи рассматриваются расширения базовой модели.
Putnam, Lawrence Н. and Ware Myers. Measures for Ехсеllепсе: Reliable Software
Оп Time, Within Бudgеt. Englewood Cliffs, NJ: Yourdon Press, 1992. Б книrе описан
метод оценки Путнэма и способы учета издержек масштаба. Мне нравится модель
Путнэма, потому что она содержит малое количество реryляторов и лучше Bcero pa
ботает при калибровке с использованием исторических данных. Материал сильно
насыщен математическими формулами, поэтому чтение идет довольно медленно.

Базовые
методы- оценки
rлава б. Знакомство с методами оценки
rлава 7. Подсчет, вычисление, экспертная оценка
rлава 8. Калибровка и исторические данные
rлава 9. Индивидуальные экспертные оценки
rлава 10. Декомпозиция и сводные оценки
.
rлава 11. Оценка по аналоrии
rлава 12. Опосредованные оценки
rлава 13. Экспертные оценки в rруппах
rлава 14. Оценочные проrраммы
rлава 15. Использование альтернативных оценок
rлава 16. Формирование оценок в правильно оцениваемых проектах
rлава 17. Стандартизированные процедуры оценки
i
t


Знакомство
с методами оценки
в rлавах 1 5 были рассмотрены важнейшие концепции, заложенные в основу
всех ОЦСНОК nporpaMMHblX проектов. Настало время перейти к подробному описа
НJIЮ методов оценки, при меняемых к конкретным задачам.
При использовании этих методов следует учитывать одно важное обстоятельст
по: в разных ситуациях примеНЯIОТСЯ разные оценки. В этой rлаве представлены
некоторые обстоятельства, которые должны учитываться при выборе методики.
6.1. Выбор методов оценки
Выбор fvlетода, спосоБНОI'О принести наи:большую пользу в конкретной ситуацJ1И,
определяется как стре'Iление1 учесть факторы, описанные в rлаве 5, так и cтpef
ЛеIlIlС1 обоiiТII НСТОЧНIIКИ ошибок оценки, описанных в rлаве 4. Дапее ОПliсыва
IОТСЯ ОСНОВНЫе аспекты, ноторые следует принять во ВНИl\fание.
Что именно оценивается
Один IlpOeI(T[)I lIаЧннаIОТСЯ с опрсделения ФУНКЦlIона.п:ЬНОСТII, а затеf переходят
к оиенке сроков 11 объе'fа работы, неоБХОДIП\1ые для ее реализации. Друrllе проеК
ты опредеЛЯJОТ СПОН БК)Д)f(еТI)[ 11 Bpe'lellHble pal\fKlI разработки, nOC.Jle чеrо ВhIЯСНЯ
ется, СКОЛl1КО (1))'H](LtIl1'i 1()ЖIIО реаЛlIзовать за ЭТОТ срок.
l\IHorHc Iет()ды оцеlIl(1( раБОТtllОТ незаВIIСИIО ОТ TOro, что IIl\'leHHO оцени'вается;
HKOTopыe 't{,ТОДhl ЛУЧlllt' ПОДХОДЯТ для оценки объеl\'13 работ ПрОДОJIж,итеJIЬНОСТl1
lIЛll КОЛIIЧt.'стпа tt)Yllll1ltii.
В lTOii },HlIrt" Н0Д oItt.\IIKoii J)lli,,,eJJa ПОНlll\lается оценка всеЙ области теХНllЧе
(oii pa()oTl)l ДЛЯ рt'il.'lIt1аЦIIIl i,UlaHlIoii (I}УНКЦIl0наЛЬНОСТII  в таких еДIIНlIЦа..х, как
t'TPt}1,1f I1pOI'paM(H01'O t,ода. (I)YHJ\H1tOtla}Il}Hbl ПУНКТl\1 н Т. д. OlleHKoii Ф!lliА"Ц'Jона.tЬ
1I0(1111J It,1 оу :lt\M HaH\l B:lTl) о(\еII1\У I\ОЛJlЧt'стпа tf)YHUHii\ рt."аЛllзуеIЫХ в оrpанJlче
II'HIX СР()I,а It (}IО:\Жt'та. :-)Т1\ Tt'p1\tllllbl II ЯВ.1ЯI0Тс.н (Tall..1apTHЫIII: я опреде..1ЯIО их
ра;НI ()t\.tll'1I1t\,i }1СIН)С1'Н.

r
6.1. Выбор методов оценки 91
Размер проекта
Размер проекта  еще один фактор, который необходимо учитывать при выборе
методики.
Малые проекты. Я отношу к этой катеrории проекты с пятью и менее техниче
скими участниками, но это весьма вольная оценка. Статистические методы, подхо
дящие для больших проектов, в малых проектах обычно неприменимы, потому что
различия в производительности отдельных участников затмевают друrие факторы.
Как правило, в малых проектах используется плоская модель комплектования
кадрами (на протяжении Bcero проекта численность персонала остается неизмен
ной), изза чеrо некоторые алrоритмические методы оценки, рассчитанные на
большие проекты, становятся несостоятельными.
Лучшими методами оценки для малых проектов обычно оказываются BOCXO
дящие методы, основанные на оценках людей, которые будут непосредственно
заниматься выполнением работы.
Большие проекты. К большим проектам относятся проекты, выполняеl\lые
rpуппами около 25 участников, занимающие от 6 до 12 месяцев и более.
Оптимальный выбор методики оценки для большоrо проекта существенно
изменяется в зависимости от состояния проекта. На ранних стадиях лучший pe
зультат обычно дают нисходящие методы, основанные на алrоритмах и CTa
тистике. Они состоятельны на той стадии проекта, коrда конкретный состав
участников еще не известен  коrда планы основываются на rруппах, состоящих,
допустим, из 11 ведущих инженеров, 25 рядовых разработчиков и 8 TeCTepOB,
нежели на конкретных лиLчностях.
На средней стадии более точную оценку обеспечивает сочетание нисходящих
и восходящих методов, базирующихся на исторических данных caмoro проекта.
На поздних стадиях крупных проектов восходящие методы дают наиболее точ
ную оценку.
Средние проекты. К этой катеrории относятся проекты, выполняемые 525 уча
стниками, занимающие от 3 до 12 месяцев. К преимуществам средних проектов
можно отнести возможность применения практически всех методов оценки, при
менимых в крупных проектах, а также ряда методик fалых проектов.
Стиль разработки
в контексте оценки выделяются два основных стиля разработки: последО8аmель
llЫЙ и uтератU81lЫЙ. Отраслевая терминолоrия, окружающая итеративные, по
следовательные и динамические проекты, довольно сложна. Для наших целеЙ oc
новным различием между этими типами проектов является процент требований,
определяемых на ранней стадии проекта, по сравнеНIIЮ с процеНТОf требований,
определяемых в ходе работы.
Далее предстаВJ1ены некоторые подходы к разработке, выделенные по указан
ным I<ритериям.
Эволюционное макетирование используется D тех случях, коrда требоваНIIЯ
неизвестны, а одна из rлаnных причин для ПРIIlснеНIIЯ этоЙ tеТОДIIКII  С'О.1еЙС'т
вие в определении требований (McConnell 1996). В контексте оценки эвотrЮЦIl
онное макетирование относится I< итераТIIВНОIУ СТIIЛIО разработки.

l
92 rлава б · Знакомство с методами оценки
Экстремальное проrpаммирование намеренно оrраничивается определением
только тех требованиЙ, которые будут реализовываться при следующей итера
ции, обычно заНИfающей менее одноrо месяца (Beck 2004). В контексте оценки
экстремальное проrра1\.fмирование относится к высокоитеративному стилю.
Эволюционная выдача. В проектах с эволюционной выдачей доля изначально
определяемых требований изменяется от «почти отсутствует>.'> до «большинства»
(Gilb 1988, МсСоппе1l1996). В зависимости от Toro, к какому концу шкалы относит
ся конкретный проект, проекты с эволюционной выдачей MOryT быть как после
доватеЛЬНЬПfИ, так II итеративными. Как правило, проекты с эволюционной Bыдa
чей оставляют достаточно большое количество требований неопределенными на
MOfeHT начала разработки, чтобы разработку можно было отнести к итеративной.
Поэтапная выдача. В проектах с поэтапной выдачей основные требования опре
деляются до начала основной работы над проектом (МсСоппе1l1996). Поэтапная
вьщача использует итеративный подход к проектированию, конструированию и Tec
тированию и ПОЭТО!\IУ в некотором смысле является итеративной. Тем не менее
в контексте оценки ее следует отнести к последовательному стилю разработки.
Унифицированный процесс Rational. Стадии процесса RUP (Rational Unified
Process) называются «итерациями>.'>. Тем не менее в типичном проекте RUP OKO
ло 80 % требований должны определяться до начала разработки (] acobson, Booch,
and Rurnbaugh 1999). В контексте оценки RUP относится к последовательному
стилю разработки. .
Scrum  стиль разработки, при котором рабочая rpуппа проекта выбирает на 
бор ВОЗl\fожностей, которые она может реализовать в течение 30дневноrо «бро
ска» (Schwaber and Beedle 2002). После Toro как «бросок» начался, клиенту не
разрешается изменять требования. Если раССl\1атривать отдельные броски, в KOH
тексте оценки Scrurn относится к последовательному СТИЛIО. НО поскольку функ
циональность не распределяется более чем по одному броску, с учетом множест
венных итераций Scrurn относится к итеративному стилю.
Влияние стиля разработки на выбор методов оценки
Как итеративные, так и последовательные проекты обычно начинаются с нисхо
дящих (основанных на статистике) методов и постепенно миrрируют к восходя 
щим Iетодам. Итеративные проекты быстрее переходят к уточнению своих oцe
нок с использованием данных caMoro проекта.
Стадия разработки
По Iepe Toro как rруппа работает над проектом, накапливается информация,
позволяющая создать более точную оценку. Требования постепенно становятся
более понятными, архитектура  более подробной, планы  более стабильными,
а сам проект выдает данные производительности, которые MOryT использоваться
для оценки оставшейся части проекта.
В книrе стадии разработки определяются следующим образом.
Ранняя стадия. В последовательных проектах к ранней стадии относится пери
од от нача.па построения концепции проекта и до Toro момента, коrда требования

6.2. Таблицы применимости методов 93
в целом можно считать определенными. В итеративных проектах термином paH
няя стадия разработки обозначается период исходноrо планирования.
Средняя стадия. Средней стадией называется период времени между началь
ным планированием и ранним конструированием. В последовательных проектах
средняя стадия продолжается от этапа постановки требований и архитектуры до
момента, коrда проект будет в достаточной степени проработан для получения
данных производительности, на основе которых может быть составлена оценка.
В итеративных проектах под средней стадией понимаются первые двечетыре
итерации, происходящие до Toro, как в основу оценок проекта можно будет YBe
ренно заложить ero собственные данные производительности.
Поздняя стадия. Термином поздняя стадия обычно обозначается время от
середины разработки до выпуска.
Некоторые методы лучше Bcero работают в широкой части конуса неопреде
ленности. Друrие обеспечивают лучшие результаты после Toro, как в ходе проек
та будут сrенерированы данные, которые MOryT использоваться для оценки OCTaB
шейся части проекта.
Возможная точность
Точность методики отчасти зависит как от самой оценки, так и от Toro, насколько
правильно выбрана методика для конкретной проблемы, и от специфики проекта.
Некоторые методы оценки обеспечивают высокую точность ценой высоких
затрат. Друrие обеспечивают более низкую точность при меньших затратах. Как
правило, желательно использовать наиболее точные методы, однако в заВИСИIО
сти от текущеrо состояния проекта и точности, возможной в текущей точке KOHY
са неопределенности, метод с низкой точностью при низких затратах может OKa
заться более уместным.
6.2. Таблицы при мени мости методов
Большинство остальных rлав книrи начинается с таблиц, описывающих область
применения метода, представленноrо в данной rлаве. Пример:
Область применения методов этой rлавы  ПРИМЕР
rрупповой анализ
Размер, объем работ, сроки,
функциональность
СБ
Размер проекта
Стадия разработки
Итеративный
или последовательный
стиль
Ранняя--<:редняя
Оба
Калибровка данными проекта
Размер, объем работ, сроки,
функциональность
МСБ
СредНЯЯ......,03дняя
Оба
Что оценивается
Возможная точность
Средняявысокая
Высокая

94 rлава б · Знакомство с методами оценки
Приведенные в таблице данные основаны на сведениях, приведенных в пре
дыдущем разделе. Смысл содержимоrо таких таблиц объясняется в табл. 6.1.
Таблица 6.1. Содержимое таблиц «Область применения методов этой rлавы»
Строка таблицы Допустимые значения
Что оценивается Размер, объем работ, сроки, функциональность
Размер проекта М С Б (малый, средний, большой)
Стадия разработки Ранняя, средняя, поздняя
Итеративный или последовательный стиль Итеративный, последовательный, оба
Возможная точность Низкая, средняя, высокая
СОВЕТ NQ 29
При выборе метода оценки следует учитывать оцениваемый показатель, размер проекта, cтa
дию разработки, стиль разработки и требуемую точность.


Подсчет, вычисление,
экспертная оценка
Область применения методов этой rлавы
Счетные методы
Размер, функциональность
. Размер проекта
Стадия разработки
Итеративный или
последовательный стиль
Возможная точность
М,СБ
Ранняяпоздняя
Оба
Вычислительные методы
Размер, объем работ, сроки,
функциональность
МСБ
Ранняяредняя
Оба
Что оценивается
Высокая
Высокая
Представьте, что вы попали на конференцию лучших оценщиков. Зал заполнен
людьми; вы сидите за столом в середине комнаты с тремя друrими специалиста
ми. Куда ни rлянь, KpyroM одни оценщики. Внезапно распорядитель подходит
к микрофону и rоворит: 4Нам нужно точно знать, сколько людей находится в зале,
чтобы заказать десерт. Кто даст самую точную оценку количества собравшихся?>.'>
За столом немедленно завязывается оживленная дискуссия по поводу Toro,
как лучше Bcero получить оценку. Билл, ваш сосед справа, rоворит: 40ценка раз
мера толпы  мое хобби. На основании cBoero опыта MOry сказать, что в комнате
находится 335 людей>.'>.
Сосед напротив, Карл, rоворит: 4СТОЛЫ расставлены равномерно, 11 в длину
и 7 в ширину. Орrанизатор банкета  мой хороший знакомый  сказал, что они
собираются усадить по 5 людей за один стол. Кажется, за большинством столов
сейчас действительно сидит по 5 человек. Умножаем 11 на 7, затем умножаем на 5
и получаем 385 человек. Пожалуй, это значение можно использовать как оценку>.'>.
Сосед слева, Люси, rоворит: 4ПРИ входе я заметила табличку, на которой напи
сано, что зал рассчитан на 485 человек. Сейчас зал заполнен процентов на 7080.
Если умножить проценты на максимальную емкость, мы получаем от 340 до 388 че
ловек. Давайте используем среднее  364 человека... или 365 для надежности?»

"l'"
96 rлава 7 · Подсчет, вычисление, экспертная оценка
Билл: Итак, 1Ы имеем оценки 335, 365 и 385. Похоже, истина rдето посере
дине. Соrласен на 365.
«Я тоже»,  rоворит Карл.
Все смотрят на вас. Вы rоворите: «Мне нужно коечто проверить. Я ненадолrо
отлучусь, вы не возражаете? Соседи удивлены, но не возражают.
Вы возвращаетесь через пару минут. «Помните, при входе наши приrлашения
обрабатывались на сканере? Я заметил, что на сканере есть счетчик, поэтому по
дошел к контролеру у входа. Контролер rоворит, что было отсканировано 407 би
летов, и из зала еще никто не выходил. Полаrаю, в качестве оценки нужно ис
пользовать число 407. Что скажете?
7 .1. Сначала подсчет
Как вы думаете, каков правильный ответ? 335, как предложил Билл, эксперт по
оценке размера толпы? 385, как вычислил Карл по нескольким разумным пред
положениям? 365, как вычислила Люси по друrим разумным предположениям?
vlли правильным было число 407, отображающееся на сканере приrлашениЙ? Есть
ли какиенибудь сомнения относительно mOlO, что 407 является llаиболее точньLiU
ответом? Кстати, вся история кончилась тем, что ваш стол предложил число 407,
которое оказалось правильным, и первым получил десерт.
Один из секретов этоЙ книrи состоит в том, что BpI должны по возможности из
беrать Turo, что мы обычно назьmаем оценкой! Если ответ можно просто посчитать,
действуйте именно так. В нашей истории этот способ дал наиболее точный ответ.
Если прямой подсчет невозможен, нужно посчитать чтонибудь друrое и вы
числить ответ по вспомоrательным (калибровочным) данным. Скажем, Карлу было
известно, что на банкете за каждым СТОЛОf должно было сидеть 5 человек. Он
подсчитал количество столов и вычислил ответ по этому значению.
Люси действовала сходным образом: ее оценка основывалась на документиро
ванной вместительности зала. На основании cBoero экспертНОlО суждения она при
кинула, что зал заполнен -на 7080 % процентов.
Наименее точная оценка поступила от Билла, который руководствовался толь
ко своим экспертНbl.М суждениеА! для получения ответа.
СОВЕТ NQ 30
Считайте везде, rде это возможно. Если счет невозможен  вычисляйте. Используйте оценки,
полученные на основании одноrо лишь экспертноrо суждения, только в крайнем случае.
7.2. Что считать
Проrpаммные проекты порождаIОТ мноrочисленные показатели, которые MoryT
использоваться в подсчетах. На ранней стадии цикла разработки можно под
считывать маркетинrовые требования, функции, сценарии использования и т. д.
В середине работы над проеКТОf подсчет может вестись с большеЙ rлубиной
детализации. Вот лишь несколько примеров: инженерные требования, функцио
нальные пункты, запросы на внесения изменений, вебстравицы, отчеты, диало
rOBbIe окна, экраны, таблицы базы данных и т. д.

7.2. Что считать 97
На более поздней стадии проекта детализация становится еще большей: объем
уже написанноrо кода, количество выявленных дефектов, классы и задачи, а TaK
же уточнения всех показателей, которые подчитывались ранее в проекте.
Выбор показателя для подсчета определяется несколькими целями.
Ищите счетный показатель, высоко коррелированный с размером оцени..
Bael\lOrO проекта. Если вы оцениваете затраты и сроки при фиксированной функ
циональности, наибольшее влияние на оценку проекта оказывает ero размер.
Ищите показатели, убедительно обозначающие размер проrpаммноrо проекта. Ko
личество маркетинrовых требований, количество инженерных требований, функ
циональные пункты  все это примеры счетных показателей, тесно связанных
с итоrовым размером системы.
В разных средах наиболее точными показателями размера проекта оказыва
IОТСЯ разные величины. В одной среде лучшим показателем может быть количе
ство вебстраниц; в друrой  количество маркетинrовых требований, тестовых
сценариев или параметров конфиrypации. Трудность в том, чтобы подобрать xo
роший показатель размера именно для вашей среды.
СОВЕТ NQ 31
Найдите счетный показатель, который может использоваться для осмысленноrо измерения co
держания работы в вашей среде.
Ищите счетный показатель, доступный на ранней, а не на поздней стадии
цикла разработки. Чем скорее вы найдете осмысленный показатель для подсче
та, тем скорее сможете обеспечить долrосрочную проrнозируемость. Количество
строк проrраммноrо кода в проекте часто является отличным показателем объема
работы, однако этот показатель становится доступным лишь после завершения
проекта. Функциональные пункты тесно связаны с окончательным размером
проекта, но они остаются недоступными вплоть до появления подробных требо
ваний. Если вам удастся найти счетный показатель, доступный на более ранней
стадии, используйте ero для создания более ранней оценки. Например, можно
создать rруБУIО оценку на основании числа маркетинrовых требованиЙ, а затем
уточнить ее позднее по количеству функциональных пунктов.
Ищите счетный показатель, дающий статистически осмысленное среднее
значение. С точки зрения статистики для получения осмысленноrо среднеrо зна
чения выборка должна содержать не менее 20 элементов. Здесь 20  не волшеб
ное число, а Bcero лишь хорошая рекомендация для статической состоятельности.
Понимайте, что вы считаете. Чтобы подсчет Mor послужить точной основой
для оценки, необходимо проследить за тем, чтобы на них распространялись те же
предположения, что и для исторических данных, используемых в оценке. Если
вы считаете маркетинrовые требования, убедитесь в том, что понимание «маркетин
rOBbIx требований», действовавшее в отношении исторических данных, совпадает
с пониманием маркетинrовых требований в вашей оценки. Если исторические
данные показывают, что в предыдущем проекте rруппа обрабатывала 7 нефор
мальных требований заказчика (также называемых « историями пользователей»,
user story) в неделю, проследите за тем, что ваши предположения относительно
размера rруппы, опыта проrpаммистов, технолоrии разработки и друrих факто
ров аналоrичны предположениям в оцениваемом проекте.
4 Зах. 893

1
98 rлава 7 · Подсчет, вычисление, экспертная оценка
Найдите показатель, подсчитываемый с минимальными усилиями. При про
чих равных обстоятельствах предпочтение отдается показателям, подсчет KO
торых требует минимальных усилий. Б сценарии, описанном в начале rлавы,
количество людей в комнате уже было зафиксировано на сканере. Если бы вам
пришлось обходить все столы и считать присутствующих вручную, возможно, вы
решили бы, что иrpа не стоит свеч.
Один из выводов проекта Сосото 11 заключается в том, что метрика оценки
размера, называемая объектными пунктами, в такой же степени коррелируется с
объеМОfvI работ, что и функциональные пункты, но ее вычисление требует при
IepHo половинноrо объема работы. По этой причине объектные пункты paCCMaT
риваются как эффективная альтернатива для функциональных пунктов при про
ведении оценки в широкой части конуса неопределенности (Boehm et al. 2000).
7.3. Используйте вычисления для преобразования
u
счетных показателеи в оценки
Собранные исторические данные, относящиеся к счетным показателям, преобра
зуются в нечто более полезное  например, оценку объема работы. Б табл. 7.1
приведены примеры счетных показателеЙ и данных, необходимых для вычисле
ния по ним оценки.
Таблица 7.1. Примеры счетных показателей
Счетный покаэатепь
Маркетинrовые требования
Функциональность
Сценарии использования
Истории пользователя
Технические требования
Исторические данные, необходимые для
преобраэования результатов в оценку
· Среднее количество рабочих часов на требование при
разработке
· Среднее количество рабочих часов на требование при
независимом тестировании
· Среднее количество рабочих часов на требование при
документировании
· Среднее количество рабочих часов на требование при
формировании технических требований
по маркетинrовым требованиям
· Среднее количество рабочих часов на функцию при
разработке и/или тестировании
· Среднее общее количество рабочих часов на сценарий
· Среднее количество сценариев, реализуемых
за определенный календарный период
· Среднее количество рабочих часов на требование
· Среднее количество историй, реализуемых за определенный
календарный период
· Среднее количество технических требований, формально
анализируемых за час
· Среднее количество рабочих часов на требование при
разработке/тестировании/документировании

,-
7.3. Используйте вычисления для преобразования счетных показателей в оценки 99
Счетный показатепь
Функциональные пункты
Запросы на внесение изменений
Вебстраницы
Отчеты
Диалоrовые окна
Таблицы баз данных
Классы
Найденные дефекты
Параметры конфиryрации
Количество строк уже
написанноrо кода
Тестовые сценарии
(уже написанные)
Исторические данные, необходимые для
преобразования результатов в оценку
· Средний объем работы по разработке/тестированию/
документированию на функциональный пункт
· Среднее количество строк nporpaMMHoro кода используемоrо
языка проrраммирования на функциональный пункт
· Средний объем работы по разработке/тестированию/
документированию на запрос (в зависимости
от разнообразия изменений данные MOryт подверrаться
дополнительному разбиению на средний объем
работы для малых, средних и крупных запросов)
· Средний объем работы на вебстраницу для обеспечения
работоспособноrо интерфейса
· Средний объем работы на вебстраницу в масштабе Bcero
проекта (менее надежно, но может содержать интересную
информацию)
· Средний объем работы для получения работоспособноrо o'Neтa
· Средний объем работы на диалоrовое окно для обеспечения
работоспособноrо интерфейса
· Средний объем работы на таблицу для получения
работоспособной базы данных
· Среднее количество рабочих часов на класс при разработке
· Среднее количество рабочих часов для формальноrо
анализа класса
· Среднее количество рабочих часов для тестирования класса
· Среднее количество рабочих часов на дефект для исправления
· Среднее количество рабочих часов на дефект
для реrрессионноrо тестирования
· Среднее количecrвo дефектов, исправляемых за определенный
календарный период
· Средний объем работы на параметр
· Среднее количество дефектов на строку кода
· Среднее количество строк кода, которые MOryт быть
формально проанализированы за час
· Среднее количество новых строк кода при переходе
к следующей версии
· Средний объем работы на тестовый сценарий на стадии
выпуска
СОВЕТ NQ 32
Соберите исторические данные, которые позволят вам вычислить оценку по счетным показателям.
Пример подсчета дефектов на поздней стадии проекта. Данные, описанные
в таблице, закладывают более прочную основу для создания оценок, нежели экс
пертное суждение. Если вы знаете, что проект содержит 400 открытых дефектов,
а при исправлении 250 дефектов, обнаруженных ранее, потребовал ось по 2 часа

"""
100 rлава 7 · Подсчет, вычисление, экспертная оценка
на дефект, значит, на исправление всех открытых дефектов потребуется пример
но 400 х 2  800 часов.
Пример оценки подсчетом веб"страниц. Если данные указываIОТ на то, что до
настоящеrо ?\fOMeHTa на проектирование, кодирование и тестирование каждоЙ
вебстраницы с динамическим содеРЖИМЫ?\f ушло около 40 часов, а в проекте
осталось еще 12 вебстраниц, ?\fОЖНО сделать вывод, что работа над ними заЙмет
12 х 40  480 часов.
В этих примерах важно то, что оценки не строятся на эксnерmном СУЗlCдении.
Сначала мы считаем значение HeKoToporo показателя, а затем вычисляем по нему
оценку. Этот процесс помоrает избавить оценки от субъективноrо смещения, OT
рицательно сказывающеrося на их точности. Для уже известных счетных показа
телей (скажем, количества дефектов) построение таких оценок также требует ми
нимальных усилий.
СОВЕТ NQ ЗЗ
Не пренебреrайте возможностями простых, rрубых оценочных моделей, таких как средний объ
ем работы на дефект, средний объем работы на вебстраницу, средний объем работы на исто
рию пользователя и средний объем работы на сценарий использования.
7.4. Используйте экспертное суждение
v ·
тол ЬКО В кра и нем случае
Так называемое экспертное суждение является наименее точным методом oцeH
ки. Похоже, наибольшая точность достиrается тоrда, коrда оценка привязывается
к чемуто конкретному. В истории, изложенной в начале rлавы, наихудшей была
оценка, выданная экспертом исключительно на основе личноrо СУ)l(дения. При
вязка оценки к вместимости зала дала чуть лучшиЙ результат; тем не менее и эта
оценка содержала немалую ошибку, потому что эксперту потребовалось субъек
,
тивно оценить степень заполненности зала, а это открыло возможности для пор
чи оценки субъективными факторами.
Исторические данные в сочетании с вычислениями оказываются на удивле
ние свободными от С?\fещений, подрывающих оценки, основанные на экспертных
мнениях. Не поддавайтесь искушению подстраивать вычисленные оценки под
СБое экспертное суждение. Во время работы над вторым изданием книrи Code
Complete» (МсСоппеll 2004а) я руководил rруппой, проводившей формальный
анализ первоrо издания  всех 900 страниц. Во время нашей первой встречи
средняя скорость анализа составила 3 минуты на страницу. Выходило, что при
такой скорости на анализ всей книrи уйдет 45 часов. После первой встречи я за
метил, что мы еще только «срабатываемся» как единая команда, а в будущем, как
мне кажется, скорость должна возрасти. При планировании будущих встреч я по
рекомендовал использовать рабочую оценку в 22,5 минуты на страницу вместо
3 минут. Руководитель проекта ответил, что на данный момент мы располаrаем
данными только одной встречи, поэтому за основу нескольких будущих встреч
нужно взять имеющиеся показатели, то есть 3 минуты на страницу. Позднее при

Дополнительные ресурсы 101
необходимости планы можно будет подреryлировать на основании данных по
следующих собраний.
И как вы думаете, каким оказалось среднее время после завершения книrи,
всех 900 страниц? Бы не ошиблись, 3 минуты на страницу!
СОВЕТ NQ 34
Не используйте экспертные суждения для подrонки оценок, полученных на основании вычисле
ний. Подобная «экспертиза» обычно лишь ухудшает точность оценки.
Дополнительные ресурсы
ВоеЬrn, Barry, et al. Software Cost Estimation with Сосото 11». Reading, МА:
AddisonWesley, 2000. У Бема представлено краткое описание метрики объект
ных пунктов.
Lorenz, Mark and Jeff Kidd. ObjectOriented Software Metrics». Upper Saddle
River, NJ: PTR Prentice НаН, 1994. Лоренц и Кидд предлаrаlОТ ряд количествен
ных показателей, которые MorYT использоваться в объектноориентированных
проrраммах.

Калибровка
и исторические
данные
Область применения методов этой rлавы
Калибровка
средними данными
по отрасли
Что оценивается Размер, объем
работ, сроки,
функциональность
Калибровка
историческими
данными
Размер, объем
работ, сроки,
функциональность
МСБ
Ранняяредняя
Оба
Размер проекта
Стадия разработки
Итеративный или
последовательный стиль
Возможная точность
МСБ
Ранняяредняя
Оба
Низаяредняя
Среднявысокая
Высокая
1'1
Калибровка
проектными
данными
Размер, объем
работ, сроки,
функциональность
МСБ
СрeJ.\няя---поздняя
Оба
Калибровка используется для преобразования счетных показателей в оценки 
строк кода в объем работы, историй пользователей в календарное время, требований
в тестовые сценарии и т. д. Оценка всеrда подразумевает некую разновидность
калибровки, прямую или косвенную. Калибровка с использованием различных
типов данных образует вторую часть метода сначала подсчет, затем вычисле
ния, описанноrо в rлаве 7.
Баши оценки MOryT калиброваться по трем типам данных.
. Средllеотраслевые данные  данные друrих орrанизаций, занимающихся
разработкой аналоrичноrо проrpаммноrо обеспечения.
. Исторические данные  в книrе так называются данные орrанизации, KOTO
рая занимается оцениваемым проектом.
. Проектllые даниые  данные, полученные ранее в ходе оцениваемоrо
проекта.

8.1. Улучшение точности и друrие преимущества исторических данных 103
Исторические и проектные данные приносят оrромную пользу и позволяют
существенно повышать точность оценок. Отраслевые данные  не более чем
временная, резервная информация, которая может приrодиться при отсутствии
исторических или проектных данных.
8.1. Улучшение точности и друrие преимущества
исторических данных
Основная причина для использования исторических данных вашей орrанизации
заключается в том, что они заметно повышают точность оценки. Использование
исторических данных, или «документированных фактов», отрицательно Koppe
лируется с превышением сроков и затрат  иначе rоворя, для проектов, оцени
ваемых на основе исторических данных, превышения не характерны (Lederer and
Prasad 1992). .
Б следующих разделах представлены некоторые причины для повышения
точности оценок.
Учет орrанизационных факторов
Прежде Bcero, исторические данные учитывают великое множество орrанизаци
онных факторов, влияющих на результат проекта. Б очень малых проектах pe
зультат определяется личными качествами работников. С увеличением раЗl\fера
проекта талантливые личности попрежнему важны, однако их вклад либо под
держивается, либо подрывается влиянием орrанизационных факторов. Б средних
и крупных проектах орrанизационные характеристики начинают иrpать не ленее
важную роль, чем личные качества.
Далее перечислены некоторые орrанизационные факторы, влияющие на pe
зультат проекта.
. Насколько сложна проrpамма, какие оrpаничения накладываются на ее быст
родействие, KaKYIO надежность необходимо обеспечить, сколько ДOKYMeH
тации требуется, существуют ли предыдущие аналоrи  друrими словами,
какое место занимает проект в системе факторов Сосоmо 11, относящихся
к типу разрабатываемоrо проекта (см. rлаву 5)?
. Может ли орrанизация определиться с устойчивыми требованиями, или
рабочая rруппа должна учитывать возможные изменения на протяжении
Bcero проекта?
. Может ли руководитель проекта избавиться от проблемноrо участника,
или же кадровая политика орrанизации затрудняет (или делает невозмож
ной) ero увольнение?
. Может ли rpуппа полностью сосредоточиться на текущем проекте, или ее
участникам приходится часто отвлекаться на запросы, связанные с под
держкой предыдущих .проектов?


104 rлава 8 · Калибровка и исторические данные
· Может ли орrанизация включать новых участников в проект, как было за
планировано, или она откажется выдерrивать работников из друrих про
ектов вплоть до их завершения?
· Поддерживает ли орrанизация использование эффективных методов про
ектирования, конструирования, контроля качества и тестирования?
· Работает ли орrанизация в реrламентированной среде (например, под дей
ствием нормативных актов F АА или FDA), предписывающей обязательное
следование неКОТОРЫ1\! правилам?
· Может ли руководитель проекта рассчитывать на то, что участники rруппы
останутся на работе вплоть до завершения проекта, или для орrанизации
характерна высокая текучесть кадров?
Пытаться учитывать каждый из этих факторов по отдельности трудно, к тому
же при этом повышается вероятность ошибки. Исторические данные вносят по
правку на все эти факторы независимо от Toro, известны вам конкретные детали
или нет.
Предотвращение субъективизма
и необоснованноrо оптимизма
Один из путей, по которым субъективизм проникает в оценку: руководитель про
екта или оценщик смотрит на новый проект, сравнивает ero со старым, замечает
множество различий между ними, а затем делает вывод, что новый проект пойдет
лучше cTaporo. Он rоворит: B предыдущем проекте у нас была большая TeKY
честь кадров; на этот раз этоrо не будет, и наша работа станет более эффективной.
К TOIY же нас постоянно отвлекали на поддержку предыдущей версии; мы поза
ботимся о TOf, чтобы этоrо не произошло. Отдел маркетинrа вносил поздние из
менения в требования. Мы и с этим справимся лучше. Вдобавок на этот раз мы
будеI использовать более современную технолоrию и новые, более эффективные
1\fетоды разработки. При таких усовершенствованиях наша работа будет lораздо
более продуктивной.
В обоснованиях TaKoro рода леrко прослеживается оптимизм. Однако пере
численные факторы находятся под контролем орrанизации, а не KOHKpeTHoro py
ководителя проекта, поэтому большинство из них будет трудно контролировать
на уровне отдельноrо проекта. Друrие факторы подверrаются оптимистичной пе
реоценке, изза чеrо в оценку вносится смещение.
При наличии исторических данных используется упрощенное предположение
u u u
О том, что следующии проект поидет примерно так же, как прошлыи проект.
Вполне разумное предположение. По словам rypy в области оценки Лоренса Пут
нэма, производительность является атрибутом орrанизации и не может леrко из
fеняться между проектами (Putnam and Myers 1992, Putnam and Myers 2003).
Аналоrичная концепция представлена в экстремальном проrраммировании в ви
де «принципа вчерашней поrоды»: сеrодняшняя поrода не всеrда будет такой же,
как вчера, но она будет похожа на вчераШНЮIО поrоду с большей вероятностью,
чем на чтолибо друrое (Beck and Fowler 2001).

r
8.1. Улучшение точности и друrие преимущества исторических данных 105
СОВЕТ NQ 35
Стройте свои оценки производительности на исторических данных. Производительность вашей
орrанизации в прошлом дает наилучшее представление о ее производительности в будущем.
Снижение влияния политических факторов при оценке
Одна из потенциальных проблем моделей оценки с большим количеством pery
лируемых факторов заКЛlочается в том, что мноrие реryляторы BepxHero уровня
относятся 1( персоналу. Например, модель Сосоmо 11 требует оценки навыков
аналитиков и проrраммистов наряду с несколькими менее субъективными фак
торами, относящимися к опыту. Оценщик должен дать оценку проrраМIИСТОВ,
выбирая между 90й, 75й, 55й, 35й и 15й процентилью (эти значения процен
тилей являются общеотраслевыми).
Представьте, что руководитель проекта представляет высшему -Iачальству oцeH
ку Сосоmо 11, и теперь идет собрание, в ходе KOToporo выясняется, не заложены
ли в оценке какиелибо излишества. Леrко представить себе следующий разrовор.
Руководитель: Я знаю, что м,ы доЛЖ1lЫ выпустить продукт за 12 llедель, но
мои оценки nоказывают, что работа займет 16 недель. Давайте проанали
зируем оценку при помощи этой npolpaм.м,bl. Вот несколько nредполо,/сений, KO
торые я сделШl. СнаЧШlа НУ:НС1l0 отКШlибровать модель оценки. Для фактора
«квШlификацuя nРОlрам.м,истов» я указШl, что наши nРОlрам.м,исты относятся
к З5й процентили...
НаЧШlьство: Что?! В нашем штате нет ни OaHOlO человека ниже cpeaHelO ypoв
ня! Нужно быть более уверенны'м' в своих оценках! Что же вы за руководитель?
ВОЗJ\tОЖ1/.0, у нас есть несколько человек, которые чуть отстают от остШlЬ
ньа, но в целом' lpyпna не может быть настолько плохой. Давайте nред1l0ЛО
жим, что они по крайней мере иа среднем уровне, хорошо? Это можно ввести
в npOlpaм.м,y?
Руководитель: Ладно. Следующий фактор  квшzификацuя разработчиков тpe
бований. Мы НИКОlда не ставили себе задачу набрать хороших аllШlитиков ШlИ
развить эти llавыки в своих работниках, поэтому я использовал 15ю npo
центиль...
Начшzьство: Постойте! 15я nроцеllтШlЬ? Наши люди очень тШlаНmJlивы, хотя
они и 1lе прошли фОрАtШlЬНОlО обучения в разработке требоваllИЙ. Они дОЛJlC1lbl
быть по крайней мере не хуже cpeaHelo. МОЖ1l0 заменить этот фактор средним
значением?
Руководитель: Не представляю, как МОЖ1l0 назвать их средними. У нас нет ни
OaHOlO человека, KOmOpOlO М,0Ж1-l0 бьUlО бы иазвать спецИШlиcmоМ, по требованиям.
НаЧШlьство: Хорошо. Предлаlаю коМ,промисс: сойдемся на З5й процеllтuли.
Руководитель: Ладно (вздЬLXает).
В результате разrовора оценка объема работы, полученная руководителем с ис
пользованием реryлирующих факторов Сосоmо 11, сократилась на 23 %. А если бы
начальству удалось уrоворить руководителя на среДНIОЮ оценку специалистов по

i
106 rлава 8 · Калибровка и иcrорические данные
требоваНИЯ1 вместо 35Й процентили, то оценка бы сократилась на 39 %. Так или
иначе, один разrовор приводит к BeCЬ1a существеННЫ!\1 различиям.
Руководитель, калиБРУIОЩИЙ оценку историчеСКИ1И данными, обходит все pac
суждения о TOI, как работаIОТ проrраммисты  лучше или хуже среднеrо. Произ
водительность непосредственно следует из данных. Человеку, ответственному за
принятие решений, но не имеющему техническоrо образования, трудно спорить
с простыми выкладками типа: «По статистике один человек за месяц у нас выдает
от 300 до 450 строк кода; мы откалибровали модель с предположением 400 строк за
человекомесяц. Возможно, это HeMHoro оптиrvlИСТИЧНО, но в пределах разУ1\-lноrо.
Бесспорно, квалификация половины проrрамrvIИСТОВ в отрасли ниже средней.
Тем не менее я почти не встречал руководителей проектов или начальников, KO
торые бы соrласились признать, что их проrраIМИСТЫ И1\-lеют квалификацию ни
же среднеЙ.
СОВЕТ NQ Зб
Исторические данные помоrают избежать решений, имеющих политическую подоплеку и возни
кающих из предположений типа «Моя rpynna ниже среднеrо».
8.2. Сбор данных
Если вы еще не занимались сбором исторических данных, начните с очень Ma
ленькоrо набора.
· РазrvIер (строки проrра1мноrо кода или друrой показатель, который можно
получить после выпуска проrраммы).
· Объем работы (человекомесяцы).
· Время (календарные месяцы).
· Дефекты (с классификацией по степени тяжести).
Эта информация, даж собранная по завершении Bcero ДBYXTpex проектов,
даст достаточные основания для калибровки нескольких коммерческих пакетов
оценки. Кроме Toro, по ней можно будет вычислять простые производные показа
тели, такие как количество строк кода на человекомесяц.
Наряду с признанием Toro факта, что этих четырех видов данных достаточно
для калибровки моделей оценки, большинство экспертов рекомендует начинать
с rvlалоrо и хорошо разобраться в сути собираемых данных (Pietrasanta 1990,
NASA SEL 1995). Б противном случае может оказаться, что собранные данные не
соrласуются между проекта1И и потому становятся бессмысленными. Б зависи
мости от Toro, как именно определяются эти четыре показателя, полученные чис
ла MOryT отличаться в два раза и более.
Проблемы определения размера
Размер завершенных проектов может измеряться в функциональных пунктах,
историях пользователей, вебстраницах, таблицах баз данных и множеством
друrих способов, но большинство орrанизаций в конечном счете предпочитает

8.2. Сбор данных 107
измерять исторические данные, относящиеся к размеру проектов, в строках про
rpaMMHoro кода. (Достоинства и недостатки измерения в строках проrpаммноrо
кода обсуждаются в разделе 18.1.)
Чтобы вычислить размер проекта в строках кода, необходимо принять реше
ния по нескольким вопросам, в том числе:
. Учитывать ли весь код, или только код, входящий в выпущенную версию
проrраммы? (Например, нужно ли считать временный связующий код, код
фиктивных объектов, код модульных тестов и код тестирования системы?)
. Как учитывать код, позаИ1ствованный из предыдущих версий?
. Как учитывать свободно распространяемый код или код библиотек CTOpOH
них производителей?
. Включать ли в подсчет пустые строки и комментарии?
. Как учитывать интерфейсы классов?
. Как учитывать объявления данных?
. Как подсчитывать одну лоrическую строку кода, разбитую на несколько
физических строк для удобства чтения?
Никаких отраслевых стандартов на этот счет не существует. Более Toro, не так
уж важно, как именно вы на них ответите 1 . Важно друrое: чтобы вы не меняли
принятых решений между проектами, а предположения, заложенные в уже соб
ранные данные, сознательно распространялись на ваши будущие оценки.
Проблемы измерения объема работ
Аналоrичные проблемы возникают при сборе данных по объему работ.
. Как измеряется время  в часах, днях или друrих единицах?
. Сколько рабочих часов в день заложено в вычисления? Стандартные 8 ча
сов или фактическое время, действующее в конкретном проекте?
. Учитывать ли неоплаченные сверхурочные?
. Учитывать ли выходные, отпуска и время обучения?
. Учитывать ли время, проведенное на собраниях уровня компании?
. Какие работы включать в подсчет? Тестирование? Управление первоrо
уровня? Написание документации? Требования? Проектирование? Иссле
дования?
. Как учитывать время, разделенное между несколькими проектами?
. Как учитывать время, потраченное на поддержку предыдущих версий той
же проrраммы?
1 Самое близкое, что моrло бы сойти за стандарт в отрасли разработки проrpаммноro обеспе
чения,  непустые строки, не состоящие из одних комментариев, включая интерфейсы
и объявления данных. Впрочем, даже при таком определении некоторые вопросы остаются
без ответов (скажем, как учитывать код, позаимствованныЙ из предыдущих проектов).
l
l,

108 rлава 8 · Калибровка и иcrорические данные
· Как учитывать время, потраченное на общение со службой продаж, на про
ведение выставок и т. д.?
· Как учитывать время командировок?
· Как учитывать нечеткий первоначальный период  время, потраченное на
проработку концепции проrраммы до полноrо определения проекта?
Как и в предыдущем случае, rлавной целью должно стать достаточно четкое
определение собираемых данных. Представьте, что данные из прошлых проектов
содержали большой процент неоплаченных сверхурочных и эти исторические
данные используются для оценки будущеrо проекта. Как вы думаете, что при
этом произойдет? Бы сами закладываете в свой будущий проект высокий про
цент сверхурочных.
Проблемы измерения календарноrо времени
Как ни странно, во мноrих орrанизациях возникают затруднения с определением
сроков работы над тем или иным проектом.
· Что следует считать началом работы над проектом? Формальное соrласо
вание бюджета? Начало первых обсуждений проекта? Полное комплекто
вани е персоналом? Кейперс Джонс сообщает, что четко определенная Ha
чальная точка встречается менее чем в 1 % проектов (Jones 1997).
· Коrда проект может считаться завершенным? Коrда будет собрана оконча
тельная версия? Коrда предполаrаемая окончательная версия передается на
тестирование? А если большинство проrpаммистов прекратило работу над
проектом за месяц до выхода официальной версии? Джонс сообщает, что
в 15 % проектов встречаются неоднозначные сроки завершения (Jones 1997).
В этой области орrанизации сильно приrодятся четкие определениях ключе
вых точек начала и завершения проекта. Как и в предыдущих случаях, прежде
Bcero следует стремиться к простому пониманию собираемых данных.
Проблемы измерения дефектов
Наконец, результаты измерения дефектов также MorYT изменяться в 23 раза
в зависимости от Toro, что именно считается дефектом.
· Считаются ли дефектами все запросы на изменения или только те, которые
в конечном итоrе были отнесены к дефектам (то есть за исключением за
просов на внесение новых возможностей)?
· Как рассматривать разные сообщения об одном дефекте  как один или
как несколько дефектов?
· Учитывать ли дефекты, обнаруженные разработчиками, или только дефек
ты, обнаруженные при тестировании?
· Учитывать ли дефекты проrpаммирования, обнаруженные до начала аль
фа или бетатестирования?
· Учитывать ли дефекты, о которых сообщили пользователи после выпуска
проrраммы?

lIIf"""
8.3. Способ калибровки 109
СОВЕТ NQ 37
При сборе исторических данных для оценок убедитесь в том, что вы понимаете смысл показате
лей, и не изменяйте ero между проектами.
Друrие проблемы сбора данных
Исторические данные проще Bcero собирать во время работы над проектом. Tpyд
но будет вернуться через полrода после завершения проекта и попытаться при
помнить «нечеткий первоначальный период, чтобы определить дату начала про
екта, сколько приходилось работать сверхурочно в конце проекта и т. д.
СОВЕТ NQ 38
Собирайте исторические данные как можно раньше после начала проекта.
Данные, собранные в конце проекта, также полезны, но еще полезнее «MOMeH
тальные снимки, сделанные непосредственно в ходе работы. Статистика по раз
мерам, объему работ и дефектам, собираемая каждые 1  2 недели, способна дать
цеННУIО информацию о динамике проекта.
Например, сбор информации о выявленных дефектах помоrает проrнозиро
вать частоту обнаружения дефектов и их исправления в будущих проектах. ДaH
ные о распределении объема работы по времени помоryт понять, в какой степени
ваша орrанизация способна мобилизовать персонал на поддержку проекта. Если
комплектование персоналом одноrо проекта происходит медленнее, чем требует
ся, возможно, это случайное отклонение. Если же исторические данные указыва
ют на то, что три последних проекта комплектовались с одинаковой скоростыо,
вполне возможно, что вы столкнулись С орrанизационным фактором влияния,
который не удастся леrко изменить в следующем проекте.
СОВЕТ NQ 39
Орrанизуйте периодический сбор исторических данных во время работы над проектом. Это
позволит вам позднее построить профиль выполнения проекта, базирующийся на собранных
данных.
8.3. Способ калибровки
Конечной целью сбора данных является преобразование данных в модель, KO
торая может использоваться для оценки. Несколько примеров возможных MO
делей.
· Наши разработчики в среднем выдают Х строк кода за человеКО?\1есяц.
. rруппа из трех человек может реализовать Х историй пользователей за Ka
лендарный месяц.
. Нашей rруппе в среднем требуется Х человекочасов на создание сценария
использования и У часов на ero конструирование и реализацию.
. Наши специалисты по тестированию в среднем создают тестовый cцeHa
рий за Х часов.

,
110 rлава 8 · Калибровка и исторические данные
· В наше]I рабочей среде один функциональный пункт обычно реализуется
Х строками кода на языке С# и У строками на Python.
· До текущеrо момента работа по исправлению дефектов в проекте в среднеl\1
занимала Х часов на дефект.
Эти примеры лишь дают представление о моделях, строящихся по историче
скиrvl данным. Друrие ПРИ1еры приведены в табл. 7.1 из предыдущей rлавы.
Общей характеристикой всех моделей является их линейность. Математиче
ские формулы работают одинаково в системах как на 10 000, так и на 100 000
строк. Тем не менее изза эффекта издержек l\.lасштаба некоторые модели нужда
IОТСЯ в дополнительноЙ реrулировке для разных диапазонов размеров. Разбиение
по разrvIераl\1 10ЖНО попробовать выполнить на неформальном уровне. В табл. 8.1
показан ОДНН 1IЗ ПрИl\1еров.
Таблица 8.1. Пример неформальноrо учета издержек масштаба
(только для демонстрационных целей)
Размер rpYnnbI
1
23
4----5
&---7
8
Среднее количество историй пользователя на алендарный месяц
5
12
22
31
.
Для проектов этоrо размера данные отсутствуют
Такой подход состоятелен при малых расхождениях в размерах проекта. О том,
как учитываются большие расхождения в размерах, рассказано в разделах 5.1 и 5.6.
8.4. Уточнение оценок по данным проекта
Ранее в этоЙ rлаве я укаЗIВал, что исторические данные полезны тем, что они
учитывают влияние орrанизационных факторов  как признанных, так и CKpЫ
тыI.. Тот же принцип примеНИ1 к использоваНИIО исторических данных в KOH
кретных проектах (Gilb 1988, Cohn 2006). Отдельные проекты обладают динами
коЙ, несколько отличающейся от динамики орrанизаций. Использование данных
из caMoro проекта учитывает все факторы влияния, уникальные для данноrо про
екта. Че'f скорее в проекте вы начнете основывать оценки на данных caMoro про
екта. Te1 ваши оценки станут понастоящему точными.
СОВЕТ NQ 40
Используйте данные, полученные в ходе текущеrо проекта (проектные данные), для создания
высокоточных оценок для оставшейся части проекта.
Даже если вы не располаrаете историчеСКИl\.IИ данными из прошлых проектов,
соберите данные по текущеfУ проекту и используЙте их для оценки оставшейся
чаСТII проекта. Ваша задача  как rvl0ЖНО скорее переКЛIОЧИТЬСЯ с орrанизационных
или отраслевых данных на проектные. Чем более итеративными будут ваши про
екты, Tel\I скорее ПОЯВIIТСЯ такая возможность.

8.5. Калибровка средними отраслевыми данными 111
Сбор и использование данных из ваших проектов более подробно рассматри
ваются в разделе 16.4. В разделе 12.3 представлен конкретный пример использо
вания проектных данных для уточнения оценок.
8.5. Калибровка средними отраслевыми данными
Если вы не располаrаете собственными историческими данными, особоrо выбора
не остается  используйте средние отраслевые показатели; это приемлемый, хотя
и не лучший вариант. Как видно из табл. 5.2, производительность разных орrани
заций в одной отрасли может отличаться на порядок. Срелняя производитель
ность не учитывает то обстоятельство, что ваша орrанизация может находиться
на верхней или нижней части диапазона.
На рис. 8.1 показан пример оценки, созданной по отраслевым данным. Каждая
точка rрафика представляет ВОЗIОЖНЫЙ результат проекта, созданный с исполь
зованием статистическоrо моделирования по методу MOHTe Карло. Сплошные
черные линии представляют срединные значения объемов работ и сроков, най
денные в результате моделирования. Пунктирные черные линии предстаВЛЯIОТ
25й и 75й процентили объема работ и сроков.
250
225
200
175
Объем 150
работы 125
(человеко
месяцы)
100
75
50
25
Моделирование сроков и объемов работ
I
I
10
1
: а о
ID
Ь
D I
D аtl 011 а о D
 1 .
""tIq,1 аОа
о а о D 00
D 0001 . D О а D
а р rP
0.J:I срв", rP ОJl п
rI О УО d'a
 QJLPt.
: 'iP diP 010 f п а а пОП
: а п o:laa;: D
I 8 ;р- 00 LO' "
: аОО ':.. ;.., OEP aoCo  D rP D D D
1 а ',:.,';': ':' 1"  a 11 а rf
1 0 .... .4 ...... А a А
1 о о..  ",.;:-. . .  "".d'  19 1 а
I D а 0.!iJ .... " DJ;, D
а I Dy. 19 :.o о D I
а
а
а о
а па о па
о
п
о а
а
D
о
019 ь
о 0_ ,'.. .
а ...::.;:i.:'t....
о · '...'"
..  ........ t.... ..- ...,' !..,.:. -:.
D . .!\,..;,.. t;!..: '.: :oI.., а
 ..;:t.y;!...: '\ir.'CS)'
:.  , -,., DaU'I о а
о -tf., .::.. ,аоа по
D' Р, D
1
1
1
а D
01
19 О I
D 1
о'"

о 1
еР О а 1
о 00 :
о .
.
1
1
I
о
10
30
32
14
16
18 20 22 24
Срок (месяцы)
26
28
12
Источник: По результатам использования nporpaMMbI Construx Estimate (www.construx.com/estimate)
Рис. 8.1. Пример оценки результатов, откалиброванной по среднеотраслевым данным. Разброс
оценок объема работ составляет целый порядок (от 25 до 250 человекомесяцев)
На рис. 8.2 изображен пример сходной оценки, откалиброванной по историче
ским данным одноrо из моих клиентов.

112 rлава 8 · Калибровка и исторические данные
Моделирование сроков и объемов работ
90
Объем 80
работы
(человеко 70
месяцы)
60 а
а
50 а
40
ЗО
20
14 15
t а а. а rl' :6'
120 D D а а О.1Р 6' а аа : D
а а  '/ .....
ao:l rP а jf' d' tI' .
11 О а а EJ rI4  ,.(, D
О.
.-  .
rJ1P . D ао
RE.
I а
r а
а
100
D
D
D
а
Daa'
..о: / grIJ D
а i rP
g а .".. dI rP D
а d' ,. .a D rP
.. I a rP
:а  _ gr- D о.
1\ rP'
· dI
.
I
I
I
I
.
.
I
r
D
аа Е:!
00
g
а
аЕ:!
rPJ
а Е:! D
D
.
а Е:!
16
17
18
19
20
21
22
Срок (месяцы)
Рис. 8.2. При мер оценки результатов, откалиброванной по историческим данным. Оценка
объема работ расходится Bcero в 4 раза (от ЗО до 120 человекомесяцев)
Размеры и НО1vlинальные производительности в обоих проектах идеНТИЧНЫ 9 но
величины разброса в двух оценках кардинально различаются. Изза Toro, что
среднеотраслевая оценка должна учитывать различия производительности, дoc
тиrающие целых порядков, среднеквадратическое отклонение ДJIЯ оценок, постро
енных по таким даННЫl\f, составило почти 100 %1 Если вы хотите предоставить
начальству оценку с достоверностью от 25 до 75 % на основании среднеотраСwi'}е
вых данных, вам придется заложить в нее интервал от 50 до 160 человеКОl\lеся
цев TpoeKpaTHыe различия!
Если )ке за1енить средне отраслевые данные историчеСКИfИ, диапазон оценки
составит от 70 до 95 человеКО1есяцев  верхняя rpаница диапазона отличается
от нижней в 1,4 раза. Среднеквадратическое отклонение оценки, созданной по
историчеСКII'J дaHHЫ1, составляет лишь около 25 %.
Анализ исследований по точности оценок показал, что в тех С'ТJ)rчаяХ9 коrда
оценочная Iодель не калибровалась по рабочей среде, экспертные оценки дава.п:и
более точныii результаТ 9 чеl\'I модели. Но при IlспользоваНl-lИ l\Iоделей, отка.пIl6ро
ванных по IIсторичеСКИ-I данным, выяснялось, что l\lодеЛ11 дают такой же И.НН
лучшиi:i рсзультат, чеl\1 экспертные оценки (jиrgепsеп 2002).
СОВЕТ NQ 41
Там, rде это возможно, используйте для калибровки оценок проектные или исторические дaH
ные вместо среднеотраслевых. Помимо повышения точности оценок, историчес:кие данны,е ccr
кращают разброс оценок, обусловленный неопределеннОС1ЪЮ предположений по поводу про1З
ВОДительноcrи.


Дополнительные ресурсы 113
8.6. Итоrи
Теперь, коrда вы знаете, каКИ1vlИ возможностями обладают исторические данные,
пренебреrать ими в ваших оценках было бы непроститсльно. В следующем: rоду,
коrда вы будете снова перечитывать эту rлаву, вы уже не должны оrорченно по
DТОРЯТЬ: «Как жаль, что у меня нет исторических данных!»
СОВЕТ NQ 42
Если в настоящий момент у вас еще нет исторических данных, начните собирать их как можно
скорее.
Дополнительные ресурсы
Boehm, Barry, et al. Software Cost Estimation with Сосото II. Reading, МА:
AddisoIlWesley, 2000. Контрольный список из приложения Е книrи Бема помо
жет вам определиться с тем, что же считать строкой кода».
Gilb, Тот. Principles of Software Engineering Management. Wokingham, England:
AddisonWesley, 1988. В разделе 7.14 книrи rилба описано уточнение оценок на
базе проектных данных. Описание процесса эволюционной выдачи основано на
предположении об орrанизации в проектах обратной связи, используемоЙ при
оценке, планировании 11 управлении и в конечной счете обеспечиваlощей caMO
корреКЦИIО проекта.
Grady, Robert В. and Deborah 1.... Cas\vell. Software Metrics: Establishing а Coт
pany Wide Prog[am». EIlglewood Cliffs, NJ: Prentice НаН, 1987. В этой и следую
щеЙ книrах rрэйди рассказывает о том, как он орrанизовывал проrрамму сбора
данных в Hewlett Packard. Книrа содержит MHoro полезной, хотя и добытой He
леrким ТРУДОl\f информации о подrотовке метрических проrрамм, а также приме
ры полезных данных, получаемых в конечном счете.
Grady, Robert В. Practical Software Metrics for Project Management and Process
Improvenlent. Englewood Cliffs, NJ: PTR Prentice НаН, 1992.
Joncs, Capers. Applied Software Management: Assuring Productivity and Quality,
2d Ed.» New York, NY: McGra\vHill, 1997. В rлаве 3 приводится замечательное
обсуждение источников ошибок при оценках размеров, объемов работы и качества.
Putnam, Lawrence Н. al1d Ware Myyers. «Five Core Metrics. New York, NY:
Dorset House, 2003. В КIIиrе приведены убедительные apry1vleHTbI в пользу сбора
данных по пяти основным метрикам: раЗ1vlеру, производительности, времени,
объему работы и надежности.
Вебсайт Software El1gineering Measurement and Analysis (SEMA): www.sei.
cmu.edu/sema/. Сайт содержит разностороннюю ИНфОР1vtацию по формированию
в орrанизациях навыков сбора данных и их использования в оценке.

Индивидуальные
экспертные оценки
Область применения методов этой rлавы
Структуриро.. 'Контрольный Диапаэонная Сравнение
ванный процесс список оценки оценка задач оценок задач
с реальными
значениями
Что оценивается Объем работ, Объем работ, Размер, объем Объем работ,
сроки, функ сроки, функ работ, сроки, сроки, функ
ционаЛЬНОС1Ъ циональность фукциональ циональноcrь
ность
Размер проекта МСБ МСБ МСБ МСБ
Стадия разработки Ранняяпоздняя Ранняяпоздняя Ранняяпоздняя Сред н Я Я----N03ДНЯя
Итеративный или Оба Оба Оба Оба
v
последовательныи
стиль
Возможная Высокая Высокая Высокая
точность
vIндивидуальные экспертные суждения до сих пор остаются Ca?\fbIl распростра
неННЫ1\1 lеТОДОl\'1 оцеНКII) применяеfЫl\-I на практике (Jergensen 2002). XIIH и Xa
бибаrахи обнаружили, что 83 % оценщиков используют «нефОРlа..7Iьные aHa
лоrии в качестве OCHoBHoro ИНСТРУ1\lента опенки (Hihn and Habibagahi 1991).
Проnеденное в HOBOi:'1 Зеландии исследование показало, что 86 % фИР?\'iразработ
чиков ИСПО..:IЬЗУЮТ «экспертную oцeHKY (Paynter 1996). Барбара КIIтчеНХЭ'1 и ее
коллеrll также выяснили, что «l\lнение эксперта задействовано в 72 % оценок
проектов (КitсhепhаП1 et al. 2002).
Экспертные суждения относительно отдельных задач образуют основу ДJIЯ
ВОСХОДЯlцеЙ оценки, но все экспертные суждения равны. 1'1 действите.J1ЬНО, в rла
пе 7 ЭI(спертные с.уждения названы Cal\'lbIf рискоnаННЫ?\'1 l\.fеТОДОl\I оценки.

'1"""""""
9.1. Структурированные экспертные суждения 115
rоворя о «lVlнении эксперта», прежде Bcero необходимо спросить  «эксперта
В какой области?» БОЛЫlIОЙ опыт в технолоrии или разработке еще не делает pa
u
ботника экспертом в области оценок. Иорrенсен сообщает, что накопление опы
та в оцениваемой области не приподит к повыIениIоo точности оценок (Jel'gensen
2002). В друrих аналитических работах выяснилось, что «эксперты склонны при
менять простые стратеrии оценки даже при высокой компетентности в оценивае
мой Tefe (Josephs and Ha11n 1995, Todd and Benbasat 2000).
В этой rлаве описано, как повысить эффективность экспертных суждений.
Обсуждение тесно связано с материалоrv1 rлавы 10, посвященной точноrvIУ объеДll
неНИIО отдельных оценок.
9.1. Структурированные экспертные суждения
Индивидуальные экспертные оценки не обязаны быть неформальными или ин
туитивными. Исследователи обнаружили значительные расхождения в точности
между «интуитивными ЭI(спеРТНЫIИ суждеНИЯIИ», которые обычно оказывались
неточными (Lederer and Prasad 1992), и «структурированными экспеРТНЬПfИ суж
деНИЯlVIИ». Оценки, построенные на основании последних, не уступали по точно
сти OueHKaf\1, полученным при ПО1\fОЩИ математических f\10делей (JergeI1sen 2002).
Кто создает оценки?
Для конкретных задач  таких, как вреf\1Я, необходимое на проrра!\.lмирование
и откладку некоторой функции, или создание набора тестовых сценариев  наи
более точные оценки создают ЛIОДИ, непосредственно выполняющие эту работу.
Оценки людей, не связанных с работой, оказываются f\1eHee ТОЧНЫIИ (Lederer and
Prasad 1992). Кроме Toro, сторонние оценщики в большеЙ степени склонны к He
дооценкам, чем связанные с разработкой (Lederer and Prasad 1992).
СОВЕТ NQ 43
Оценки уровня задач следует поручать людям, непосредственно занимающимся выполнением
соответствующей работы.
Приведенный совет относится IПvIенно к оценкам уровня задач. Если ваш про
ект все еще находится в широкой части конуса неопределенности (то есть KOH
кретные задачи еще не были идентифицированы пли назначены исполнителям),
оценка должна создаваться опытным оценщиком или саМЫf\-IИ ОПЫТНЫf\1И разра
ботчикаrvIИ, специалистами по контролю качества и документированию из Иf\lею
щеrося персонала.
rранулярность
Одним из лучших способов повышения точности оценок уровня задач является
разбиение крупной задачи на HeCKOЬKO меньших. При создании оценок разработ
чики, руководители и спецйалисты по тестированию обычно сосредоточиваются

l
I
116 rлава 9 · Индивидуальные экспертные оценки
на хорошо понятных им задачах и пренебреrаIОТ задачами, которые им незнакомы.
Типичный результат  однострочная запись в rрафике (скажем, преобразо
вание данных»), на выполнение котороЙ должно было уiiти две недели, занима
ет два месяца, потому что никто не удосужился выяснить, что именно необходи
м:о сделать.
Оценки, составляемые на уровне задач, следует разбивать на задачи, на BЫ
полнение которых потребуется не более двух дней работы. Более крупные задачи
содержат слишком IHoro «подводных камней, требующих непредвиденной pa
боты. Желательно, чтобы rранулярность полученных оценок составляла 1/4, 1/2
или полный день.
Диапазоны
Если попросить разработчика оценить некий набор функциЙ, он обычно выдает
набор чисел  вроде Toro, который приведен в табл. 9.1.
Таблица 9.1. Пример точечных оценок, выданных разработчиком
Функция
Функция 1
Функция 2
Функция 3
Функция 4
Функция 5
Функция б
Функция 7
Функция 8
Функция 9
Функция 10
итоrо
Оценка времени реализации (в днях)
1,5
1,5
2,0
0,5
0,5
0,25
2,0
1,0
0,75
1,25 ,
11,25
Если затем попросить Toro же разработчика выдать те же оценки для лучшеrо
и худшеrо случая, разработчик обычно выдает друrой набор чисел, наподобие
приведенноrо в табл. 9.2.
Если сравнить исходные точечные оценки с оценкам:и для лучшеrо и худшеrо
случая, мы видим, что сумма 11,25 для точечных оценок rораздо ближе к оценке
лучшеrо случая (10,5), чем к оценке худшеrо случая (18,25).
Взrлянув на оценки функции 4, также можно заметить, что обе оценки выше
исходной точечной оценки. В ходе анализа худшеrо случая иноrда выявляется
дополнительная работа, которая должна быть выполнена даже в лучшем случае,
а это приводит к повышению номинальноЙ оценки. Обычно при анализе худших
случаев я спрашиваю разработчиков, сколько времени займет выполнение зада
чи, если все пойдет неправильно. Часто выясняется, что мне выдавали оценку для
оптимистичноrо худшеrо случая, а не для llасmоящеlО ХУДlпеrо случая.


I
9.1. Структурированные экспертные суждения 117
Таблица 9.2. Пример индивидуальных оценок для лучшеrо и худшеrо случаев
Оценка времени реализации (в днях)
Функция
Функция 1
Функция 2
Функция 3
Функция 4
Функция 5
Функция б
Функция 7
Функция 8
Функция 9
Функция 10
итоrо
Лучший случай
1,25
1,5
2,0
0,75
0,5
0,25
1,5
1,0
0,5
1,25
10,51
Худший случай
2,0
2,5
3,0
2,0
1,25
0,5
2,5
1,5
1,0
2,0
18,25
Если вы руководите проектом, поручите своим разработчикам создать набор
точечных оценок. Скройте от них результаты и предложите создать набор oцe
нок для лучших или худших случаев. Сравните полученные оценки с исходными
точечными  результат часто оказывается неожиданным.
Это упражнение полезно по двум причинам. Бопервых, оно помоrает понять,
что точечные оценки ближе к оценкам для лучшеrо случая. BOBTOpЫX, после
мноrократной формулировки оценок в вашем сознании начнет формироваться
привычка к анализу худшеrо из возможных случаев. Если вы привыкнете pac
сматривать как лучший, так и худший результат, вы постепенно начнете вклю
чать весь диапазон возможных результатов в точечные оценки задач независимо
от Toro, были реально сформулированы оценки для лучшеrо и худшеrо случаев
или нет.
СОВЕТ NQ 44
Создание оценок для лучшеrо и худшеrо случаев стимулирует мышление и nOMoraeT учесть весь
возможный диапазон возможных результатов.
Формулы
Создание оценок для лучшеrо и худшеrо случаев  Bcero лишь первый шаr. Вы
попрежнему стоите перед вопросом, какую из оценок использовать. А может,
вычислить среднее арифметическое? Б действительности оба варианта не rодят
ся. Во мноrих случаях худший случай HaMHoro хуже Toro, что можно называть
«ожидаемым случаем. Вычисление середин по диапазонам приведет к нежела
тельному смеlцеНИIО оценки.
1 При простом суммировании оценок для лучшеrо и худшеrо случаев возникают некоторые
статистические аномалии. Эта тема более подробно обсуждается в rлавс 10.
Ik


I
118 rлава 9 · Индивидуальные экспертные оценки
Методика PERT (Program Evaluation and Review Technique) предназначена
для вычисления ожидаемоrо случая, которыЙ может и не находиться в средней
точке диапазона между ЛУЧШИ1 и худшим случаями (Putnam and Myers 199,
Stutzke 2005). Для использования PERT в набор случаев включается дополни
тельныЙ «наиболее вероятныЙ» случай, который оценивается посредством экс
пертноrо суждения. Затем ожидаемый случаi"'! вычисляется по фОРl\fуле:
ФОРМУЛА NQ 1
Ожидаемый случай = [ЛучшийСлучай + (4 х НаиболееВероятныйСлучай) + ХудшийСлучайJ/6.
ФОРl\1ула учитывает как ПОЛНУIО длину диапазона, так и ПОЗИЦИIО наиболее Bepo
ятноrо случая внутри диапазона. В табл. 9.3 показаны оценки из табл. 9.2 с добав
лением наиболее вероятноrо и ожидаемоrо случаев. Как видно из таблицы, общая
оценка 13,62 ближе к нижнему концу диапазона, чем среднее значение 14,4.
Таблица 9.3. Пример индивидуальной оценки с лучшим, худшим и наиболее
вероятным случаями
Оценка времени реализации (в днях)
Функция Лучший Наиболее вероятный Худший Ожидаемый
\1 случай случай случай
случаи
Функция 1 1,25 1,5 2,р 1,54
Функция 2 1,5 1,75 2,5 1,83
Функция 3 2,0 2,25 3,0 2,33
Функция 4 0,75 1 2,0 1,13
Функция 5 0,5 0,75 1,25 0,79
Функция 6 0,25 0,5 0,5 0,46
Функция 7 1,5 2 2,5 2,00
Функция 8 1,0 1,25 1,5 1,25
Функция 9 0,5 0,75 1,0 0,75
Функция 10 1,25 1,5 2,0 1,54
итоrо 10,5 13,25 18,25 13,62
Как обсуждалось в rлаве 4, «наиболее вероятные оценки склонны к излишне
I\1Y оптимизму, что может привести к оптимистическому завышению общих oцe
нок при использовании этоrо подхода. Некоторые эксперты в области оценки pe
КОI\1ендуют И3fенить базовую формулу PERT, чтобы учесть смещение в оценке
(Stutzke 2005). Измененная формула выrлядит так:
ФОРМУЛА NQ 2
Ожидаемый случай = [ЛучшийСлучай + (3 х НаиболееВероятныйСлучай) + (2 х ХудшийСлучай)J/6.
Это разумное решение проблемы для краткосрочной перспективы. Долrосроч
ное решение проблеl\-IЫ  работа с люды\и,, направленная на повышение точности
их оценок наиболее вероятноrо случая.

r
9.2. Сравнение оценок с фактическими значениями 119
Контрольные списки
Даже эксперты иноrда забываIОТ учесть все необходимые факторы. При изучении
проrнозирования в различных дисциплинах выяснилось, что простые контрольные
списки способствуют повышеНИIО точности и напоминают о тех факторах, о KOTO
рых эксперт Mor бы забыть (Park 1996, Harvey 2001, Jrgensen 2002). В табл. 9.4
представлен контрольный список, который можно было бы использовать для по
вышения точности оценок.
Таблица 9.4. Контрольный список для индивидуальной оценки
1. Насколько четко определен оцениваемый показатель?
2. Включает ли оценка все виды работ, необходимые для завершения задачи?
З. Включает ли оценка все функциональные области, необходимые для завершения задачи?
4. Достаточно ли детализирована оценка для Вblявления скрытой работы?
5. Вы ознакомились с документированными фактами (письменными заметками) из прошлой
работы, не оrраничиваясь оценкой исключительно по собственным воспоминаниям?
б. Соrласована ли оценка с человеком, который будет заниматься непосредственным
выполнением работы?
7. Производительность, заложенная в оценку, сходна с той, которая достиrалась в аналоrичных
ситуациях?
8. Включены ли в оценку различные случаи  лучший, худший и наиболее вероятный?
9. Действительно ли худший случай является худшим? Нельзя ли сделать ero еще хуже?
10. Насколько правильно вычисляется ожидаемый случай?
11. Документированы ли предположения по поводу оценки?
12. Изменилась ли ситуация с момента подrотовки оценки?
Чтобы ничеrо не упустить, также сверьтесь с перечнем часто пропускаемых
действиЙ в разделе 4.5.
СОВЕТ NQ 4S
Используйте контрольные списки для улучшения индивидуальных оценок. Составляйте и веди
те собственные контрольные списки.
9.2. Сравнение оценок
с фактическими значениями
Отказ от точечных оценок и лучших случаев  Bcero лишь половина дела. ДруrоЙ
половиной должно стать сравнение фактических результатов с оцениваемыми,
чтобы вы моrли подреryлировать свои личные способности к оценке.
Ведите список оценок и дополняЙте ero фактическими результатами по за
вершении проекта. Затем вычислите величину относительной ошибки (MRE,
Magnitude of Relative Error) своих оценок (Conte, Dunsmore, and Shen 1986).
MRE вычисляется по следуiощей формуле:


120 rлава 9 · Индивидуальные экспертные оценки
ФОРМУЛА NQ 3
MRE = Абсолютное3начение х [(Фактический Результат  ОценкаРезультата)/Фактический
Результат].
в табл. 9.5 приведены результаты вычисления MRE дЛЯ оценок лучшеrо и xyд
шеrо случаев из предыдущеrо примера.
Таблица 9.5. Пример таблицы для отслеживания точности отдельных оценок
Функция Оценка времени реализации (8 днях)
Лучший Худший Ожидаемый Фактический MRE Входит в диапазон
случай v случай результат между лучшим
случаи
и худшим случаем?
Функция 1 1,25 2,0 1,54 2 23 О/о Да
Функция 2 1,5 2,5 1,83 2,5 27 О/о Да
Функция 3 2,0 3,0 2,33 1,25 87 О/о Нет
Функция 4 0,75 2,0 1,13 1,5 25 О/о Да
Функция 5 0,5 1,25 0,79 1 21 О/о Да
Функция 6 0,25 0,5 0,46 0,5 8 О/о Да
Функция 7 1,5 2,5 2,00 3 33 О/о Нет
Функция 8 1,0 1,5 1,25 1,5 17 О/о Да
Функция 9 0,5 1,0 0,75 1 25 О/о Да
Функция 10 1,25 2,0 1,54 2 23 О/о Да
итоrо 10,5 18,25 13,62 16,25 80 О/о Да
Среднее 29 О/о
в этой таблице для каждой оценки вычисляется относительная ошибка (MRE).
Ее среднее значение по набору оценок, показанное в нижней строке, составляет
29 %. Вы можете использовать среднюю относительную ошибку для измерения
точности своих оценок. По мере улучшения точности MRE начинает убывать.
ПравыЙ столбец показывает, сколько оценок попадает в диапазон между лучшим
II худшим случаеrv1. Также можно проследить за TeI, как со временем растет про
цент оценок, попадающих в диапазон.
СОВЕТ NQ 46
Сравнивайте оценки с фактическими результатами, чтобы повышать качество своих оценок
со временем.
Сравнивая оценки с результатами, попытайтесь понять, что было сделано верно,
что неверно, что вы упустили, и как избежать повторения этих ошибок в будущем.
Друrим средством: орrанизации обратноЙ связи и повышения точности оценок
является общественное обсуждение. Я работал с компаниями, в которых разработ
чики должны были на собраниях по понедельникам сообщать, в какоЙ степени их
оценки соответствовали результатам. Таким образом укреплялись представления
о точности оценок как об одном из стратеrических приоритетов компании.


Дополнительные ресурсы 121
Какой бы способ вы ни выбрали, ключевоЙ принцип остается одним и тем же:
орrанизация цикла обратной связи на основании фактических оценок, чтобы Ba
ши оценки улучшались со временем. Чтобы обратная связь была эффективноЙ,
она должна быть своевременной; задержка снижает эффективность цикла обрат
ной связи (]0rgensen 2002).
Дополнительные ресурсы
]0rgensen, М. A Review of Studies оп Expert Estimation of Software Development
Effort», 2002. В статье приводится разносторонний обзор исследованиЙ в области
экспертных оценок. Автор пользуется мноrими выводами, полученныlIии в ходе
стандартных исследований, и представляет 12 рекомендациЙ для достижения
точных экспертных оценок.
Humphrey, Watts S. A Discipline for Software Engineering». Reading, МА:
AddisonWesley, 15. Хамфри излаrает подробную методолоrию для сбора разра
ботчиками личных данных производительности, сравнения запланированных pe
зультатов с фактическими и постепенноrо совершенствования оценок.
Stutzke, Richard D. «Estimating Software Intensive Systems». Upper Saddle RiveI',
NJ: AddisonWesley, 2005. В rлаве 5 книrи Стуцке рассматриваются методы эксперт
ных оценок, а также приводятся математические обоснования некоторых формул,
упоминавшихся в этой rлаве.

1
I
!
Деком позиция
и сводные оценки
Область применения методов этой rлавы
Декомпозиция Декомпозиция WBS Вычиспение пучwеrо
по ФУНКЦИЯМ (Work Breakdown и худwеrо спучаев
или задачам Str.ucture) по стандартному
отклонению
Что оценивается Размер, объем работ, Объем работ Объем работ, сроки
функциональность
Размер проекта МСБ СБ МСБ
Стадия разработки РаННЯSН10ЗДНЯЯ (малые Ранняяпоздняя Ранняяпоздняя (малые
проекты); средняя проекты); средняя
поздняя (средние поздняя (средние
и крупные проекты) и крупные проекты)
Итеративный или Оба Оба Оба
v
последовательныи
стиль
Возможная точность Средняявысокая Средняя Средняя
Декомпозицией называется разбиение оценки на фраrменты, раздельная оценка
каждоrо фраrмента и последующее объединение отдельных оценок в составную
оценку. Данная методика также известна под названием восходящей оценки,
«l\lикрооценки, «модульноrо наращивания и ДРУПIМИ названиями (Tockey 2005).
Декомпозиция является краеуrольным камнем оценки, однако при ее исполь
зовании необходимо остереrаться некоторых ошибок. Б этой rлаве более под
робпо обсуждается базовая схема и объясняется, как обойти скрытые ловушки.
10.1. Вычисление ожидаемоrо случая
Сцена: Еженедельное собрание rруппы...
Вы: Мы дОЛ:НСllЫ создать оценку для 1l0BOlO проекmа. Чтобы подчеРК1lуmь, ltасколь
КО важны 1110чuые оцеики для этой zpynnbl, я lOmOB поспорить lta обед с пиццей,

,
10.1. Вычисление ожидаемоrо случая 123
что моя оце1lка проекта будет точнее вашей. Если вы вЫИlрываете, с меня пиц
ца; если вЫИlрываю я  пицца за ваш счет. Желающие есть?
Труппа: По рукам!
Вы: Ладно, llаЧUllаем.
После поиска информации о похожем прошлом проекте выясняется, что про
ект занял 18 человеконедель. Бы прикидываете, что нынешний проект примерно
на 20 % больше предыдущеrо, и создаете общую оценку в 22 человеконедели.
Тем временем ваши коллеrи создали более подробную оценку с разбиениеl\1 на
функции. У них получилась оценка, показанная в табл. 10.1.
Таблица 10.1. Пример оценки, полученной посредством декомпозиции
Функция
Функция 1
Функция 2
Функция 3
Функция 4
Функция 5
Функция б
Функция 7
Функция 8
Функция 9
Функция 10
итоrо
Оценка времени реализации (в человека-неделях)
1,5
4
4
1
4
б
2
1
3
1,5
27
Вы: 27 недель? OlO. Помоему, MHoloBamo, но это скоро выяснится...
Несколько недель спустя...
Вы: Теперь, KOlaa nроект завершен, мы знаем, что он за1lЯJl 29 человеконедель.
Похоже, ваша оценка в 27 человеконедель оказалась оптимистичной на 2 Heдe
ли, то есть ошибка составила 7 %. Моя оценка в 22 человеконедели смещена на
7 человеконедель, ошибка 24 %. Похоже, вы вЫИlрали, и я покупаю пиццу.
Кстати lоворя, я хочу знать, изза KOlO я «1Z0пал» на пиццу. Давайте пOCMoт
РИ.iИ, какие из частичных оценок бьUlИ самЬIИ точны.МИ.
Несколько минут уходит на то, чтобы проанализировать величины относи
тельной ошибки по всем оценкам и выписать данные на ДОСI(У. Результат показан
в табл. 10.2.
Труппа: OlO, как инmересно. Большинство наШllX индивuдуаЛЫlЬLX оценок не бbl
ли точнее ваULей  почти все они содержали ошибку oпz 30 до 50 %. Наша cpeд
llЯЯ ошибка составляла 46 %, что lораздо больше, чем у вас. И все же 1lаша об
щая ошибка составила BcelO 7 %, а ваша  24 %.
Однако aOlOBOP дороже aellel. Хотя llаши оценки бьUlИ :луже вашей, пицца все
равно с вас!

1
124 rлава 10 · Декомпозиция и сводные оценки
Таблица 10.2. Примеры результатов оценок, полученных посредством декомпозиции
Функция Оценка времени Фактический Непосредственная Величина
реализации объем ошибка относительной
(в человеко"неделях) работы ошибки
Функция 1 1,5 3,0 1,5 50 О/о
Функция 2 4,5 2,5 2,0 80 О/о
Функция 3 3 1,5 1,5 100 О/о
Функция 4 1 2,5 1,5 60 О/о
Функция 5 4 4,5 ......() I 5 11 о/о
Функция б 6 4,5 1,5 33 О/о
Функция 7 2 3,0 1 О 33 О/о
,
Функция 8 1 1,5 ......() , 5 ЗЗ о/о
Функция 9 3 2,5 0,5 20 О/О
Функция 10 1,5 3,5 2,0 57 О/о
итоrо 27 29 2
Среднее  7 О/о 46 о/о
KaKHfTO образО1 IIтоrовая оценка rpуппы оказа.чась точнее вашей, хотя oцeH
КII по отдеЛЬНЫ1 ФУНКЦIIЯ1 были хуже. Как такое ВЗIОЖНО?
Закон больших чисел
Оценка rpуппы выпrра.i'!а от статистическоrо своЙства. называеIОro закона\( БО1Ь
lJ1пX чисел. Суть закона заК.l1ючается в TOf. что при создании одной .бо.,ЬШОЙ
оценки ошибочные тенденции будут полностью сосредоточены на верхнеЙ И}IН
нижнеЙ стороне. Но еС.111 создать HeCKo.l1ЬKO lеНЬШIlХ оценок. часто ошибок окаж:ет
ся с ОДНОII стороны, а часть  с друrой. Ошибки ..10 опре...1е.lенной степени КО:\I
пеНСIlРУIОТ друr друrа. В О:lfIПХ случаях ваша rpуппа не:lооценнва.lа рtезу..lьтат НО
". "-"
13 друrllХ  переоцеНlIва.ла ero, поэто:му ОШJlока COBOIIHOH оценки составИ.13
Bcero 7 . В вашеЙ оценке все 24  ошибок БЫЛJI сосрезоточены с О.1НоЙ стороны.
ТакоН подход должен работать в теОРИll. 11 ИСС..iедованпя roворят о ТОМ.. что он
также работает на праКТlIке. ..Ледерер 11 Прасад обнаРУЖlI.iН.. что СI"п[рованне
ПРОДОЛ)КlIтсльноеТII подзадач oTplluaTe.;lbHO корре..1I}нруется с превышення..'ПI cpo
коп 11 объеl\IОВ работ (Lederer апd Prasad 1992).
СОВЕТ NQ 47
Разбейте общую оценку на фраrмеНТbl, чтобы воспользоватъся Дtств..1еМ закона бonыших. чtкел:
ошибки в сторону завышеН1Я t занижения до определенной creлен., КОJ-IПено,руют ДPJT АРУПd.
Насколько мелкими должны быть
оцениваемые фраrменты?
ЕСЛ1l ВЭl'л>tIlУТЬ 11:1 t'IITYf.1111l10 С ТОЧКII зrення рве, 10.1.. Т"1зра60тка ПI"О'1..'\r.\rn!ОIr\.)J
оt){'СП{'Чt'1tltя llрt\"Сl'&1вляет собоЙ ПОrТПННО COKp11IHH 13('шrn&'1 ПрiПnI),П;l1
MIIX Pl'lltt'tt"ii. Т3 нн"аЛt' ПРОt'1\та B1\l ПрНННН1те Рt.'tнення THn:t: KaK":He tx.'ll-iОВtN1е


10.1. Вычисление Qжидаемоrо случая 125
облаСlпи должна содержать эта проrрамма? Простое решение о ВКЛIочении или
ИСКЛlочении одноЙ области способно существенно сместить общий объем работ
или сроки проекта в одну или друrую сторону. При приближении к постановке
требованиЙ BJ>IcoKoro уровня вы принимаете большее количество решениЙ о TOlVl,
какие функции должны присутствовать или отсутствовать в проекте, но каждое
из этих реlпеllИЙ в среднем оказывает МИНИ1альное воздействие на общий pe
зультат проскта. Jlри переходе к детализироваННЫ1 требованиям обычно при
ХОДIlТСЯ ПРИНИl\'1ать сотнн реUlений; одни из них имеют большие последствия,
друrие  'Iеньшие, но в cpeДHe1 их влияние оказывается rораздо меНЬUIИ1\'f, че1
у решениЙ, IIрИНИfаемых на более ранней стадии проекта.
-
. ;.
Объем .
."-:
'.
Конструирование  тысячи решений
с низким воздействием
(и отдельные решения с высоким
воздействием)
Требования BbICOKoro уровня 
, дополнительные решения с высоким воздействием
Концепция nporpaMMHoro продукта 
Несколько решений с чрезвычайно высоким воздействием
Время
Рис. 10.1. Проrраммные проекты обычно проrрессируют от крупномасштабных решений
на начальной стадии к мелкомасштабным решениям в конце. Эта тенденция повышает
роль оценок, получаемых с использованием декомпозиции, по мере развития проекта
1< тому MorvleHTY, коrда вы сосредоточитесь на конструировании проrраrvl1Ы,
rvIасштаб ПРИНИ1\fаемых решений становится COBce1 1алЫ1: «Как спроектировать
интерфейс этоrо класса? Как азвать эту пере1еННУIО? Как орrанизовать этот
цикл? И т. д. Эти решения попрежнему иrрают важную роль, однако эффект
любоrо отдельноrо решения получается локализованным по сравнению с круп
ными решениями, ПРИНИ1аемыми на исходном, концептуальном уровне.
Таким обраЗОf, разработка проrраМl\lноrо обеспечения представляет собой
процесс постепенноrо уточнения требований, и чем дальше продвиrается проект
к завершению, тем более детализированными становятся оценки, полученные
в результате декомпозиции. На ранней стадии проекта восходящая оценка rvl0
жет базироваться на Функuиональных областях. Позднее за основу берется oиeH
ка маркетинrовых требований. Еще позднее используются подробные или Tex
нические требования. На завершаIощей стадии проекта l\IОЖНО использовать
оценки уровня задач, преl10ставле.нные разработчиками и специалиста1И по
тестироваНИIО.

126 rлава 10 · Декомпозиция и сводные оценки
Оrраничения количества оцениваемых показателеЙ имеют более практиче
ский, нежели теоретическиЙ смысл. На очень ранней стадии проекта бывает He
просто получить достаточное количество подробной информации для созда
ния детализированноЙ оценки. На более поздних стадиях информации может
оказаться слишком MHoro. Чтобы закон больших чисел дал скольконибудь за
метный выиrрыш, потребуется от 5 до 10 элементов, но даже 5 элементов луч
ше, чем один.
10.2. Декомпозиция с использованием WBS
Иноrда невидимая работа скрывается в форме забытых аспектов проекта, иноrда 
в виде забытых задач. Декомпозиция проекта с применением структуры трудозатрат
(WBS, Work BI'eakdown Structure) помоrает сделать так, чтобы забытых задач не
было. KpOle Toro, она помоrает подреrулировать ваши представления о том,
 u
оольше или 1еньше оцениваемыи проект друrих, похожих прошлых проектов.
Сравнение HOBoro проекта со старым в каждоЙ катеrории WBS поможет более
четко раЗЛIlчать относительную величину катеrорий.
В табл. 10.3 представлена обобщенная операционная структура WBS дЛЯ
проrраМ1НЫХ проектов от малоrо до среднсrо размера. В левом столбце пере
числены операции (планирование, постановка требований, проrраммирование
и т. д.), а в друrих столбцах  характер раБотыI по каждоЙ катеrории (создание,
планирование, обзор и т. д.).
Таблица 10.3. Обобщенная орrанизационная аруктура WBS
Катеrория Созда- Планиро- Управ- Обзор Дора- Сообщение
ние вание ление ботка о дефектах
Общее управление . . . .
Планирование . . . .
Корпоративная деятельность .
(собрания, отпуска,
выходные и т. д.)
Настройка конфиryрации . . . . . .
оборудования/проrраммноrо
обеспечения/Сопровождение
Подrотовка персонала . . . .
Технические/технолоrические . . . . . .
процессы
Работа по требованиям . . . . . .
Координация с друrими проектами . . . .
Управление изменениями . . . . . .
Макетирование пользовательскоrо . . . . . .
интерфейса
Проработка архитектуры . . . . . .
Подробное проектирование . . . . . .

r
10.3. Риск суммирования оценок для лучших и худших случаев 127
Катеrория Созда.. Ппаниро" Управ.. Обзор Дора.. Сообщение
ние вание пение ботка о дефектах
Проrраммирование . . . . . .
Приобретение компонентов . . . . . .
Автоматизирован ная сборка . . . . . .
Интеrрация . . . . . .
Ручное тестирование системы . . . . . .
Автоматизированное тестирование . . . . . .
системы
Выпуск nporpaMMbI (внутренние, . . . . . .
альфа и бетаверсии,
окончательн.ый выпуск)
Документация (пользовательская . . . . . .
и техническая)
Обобщенная структура WBS создается посредством объединения описаниЙ
столбцов с катеrориями. Самые распространенные комбинации отмечены в таб
лице точками.
WBS представляет в ваше распоряжение обширный список операций, KOTO
рые стоит учитывать при создании оценки. Вероятно, вы захотите расширить
список и включить в Hero несколько дополнительных элементов, относящихся
к специфике разработки прarраммноrо обеспечения в вашей орrанизации. А MO
жет быть, некоторые из катеrорий WBS будут ИСКЛlочены  это вполне нормаль
но, если решение принимается сознательно.
СОВЕТ NQ 48
Используйте обобщенную структуру трудозатрат nporpaMMHbIX проектов (WBS), чтобы не забыть
о типовых операциях.
10.3. Риск суммирования оценок для лучших
и худших случаев
Представьте, что вы составили подробный список задач. Вы тщательно оценивае
те каждую задачу в списке, думая: «Возможно, у нас это и получится, если как
следует постараться. После тщательноrо планирования вы усердно работаете
над первой задачей и выдаете ее в срок. Во второй задаче возникают непредви
денные проблемы, но вы сидите допоздна и сдаете ее по rрафику. В третьей зада
че появляется еще несколько проблем; в конце дня вы оставляете ее незавершен
ной, полаrая, что завершите ее следующим утром. Но к концу следующеrо дня
вам едва удается справиться с ней, а к той задаче, которую полаrалось выполнять
в этот день, вы даже не притронулись. К концу недели вы более чем на полную за
дачу отстаете от rрафика.
Что произошло? Вы ошиблись в оценках или просто недостаточно усердно
работали? .

128 rлава 10 . Декомпозиция и сводные оценки
Осторожно: впереди математика!
Ответ кроется в статистических тонкостях, возникающих при объединении OT
дельных оценок. Статистические тонкости? Да, нравится вам этот или нет,
но чтобы понять, как избежать распространенных пробле1 построения сводных
оценок по деКО?vlП03ИЦИОННЫМ оценкам задач или ВОЗIожностей, нам придется
иемноrо заняться fатематикой.
rде произошел сбой?
Чтобы понять, что случилось в предыдущем сценарии, давайте вернемся к cцeHa
рию, описанному в начале rлавы. [руппа выдала точную оценку, однако точность
ее точечных оценок была необычной. Более типичная попытка выдать оценку по
средством декомпозиции не приведет к 01lенкам, представленным в табл. 10.1;
скорее Bcero, полученные оценки будут выrлядеть ПрИ!vlерно так, как показано
в табл. 10.4.
1аблица 10.4. Примеры более типичной, подверженной ошибкам попытки создания
оценки посредавом декомпозиции
Функция 1
Функция 2
Функция 3
Функция 4
Функция 5
Функция 6
Функция 7
Функция 8
Функция 9
Функция 10
итоrо
Оценка времени реализации
(вчenовеко-недenях)
1,6
1,8
2,0
0,8
3,8
3,8
2,2
0,8
1,6
1,6
20,0
Фактический объем работы
Функция
3,G
2,5
1,5
2,5
4,5
4,5
3,0
1,5
2,5
3,5
29,0
в этом примере точность 20недельной оценки, полученной ПрОСТЫl СУ1\П\'IИ
рованием фраrментарных точечных оценок, оказывается хуже сводной оценки
в 22 человеконедели, предоставленной вами в этом сценарии. Как такое 1\fоrло
случиться?
Корнем проблеrvlЫ является сочетание проблемы «90 % уверенности, обсуж
давшейся в rлаве 1, и проблемы необоснованноrо ОПТИiИ3fа из rлавы 4. Коrда
разработчика просят предоставить точечную оценку, он часто бессознательно BЫ
дает оценку для лучшеrо случая. Допустим, что каждая из оценок лучшеrо случая
вероятна на 25 % (друrllIИ словаНI, вероятность Toro, что работа будет выпол
нена с указанным результаТО1 или лучше, составляет Bcero 25 %). Шансы Bыдa
чи любоЙ отдельной задачи в соответствии с оценкоЙ лучшеrо случая невелики:

i
10.4. Создание осмысленных общих оценок ДЛЯ лучшеrо и худшеrо случаев 129
1 из 4 (25 %). Однако шанс выдачи всех задач по rpафику стремится к нулю. Чтобы
выдать вовремя первую и вторую задачи, необходимо уложиться в вероятность
1/4 в первой задаче, а потом сделать то же самое во второй. Со статистической
точки зрения вероятности перемножаются, поэтому вероятность cBoeBpeMeHHoro
завершения обеих задач составит Bcero 1/16. Чтобы вычислить вероятность CBoe
BpeMeHHoro завершения всех 10 задач, необходимо перемножить 1/4 10 раз; pe
зультат составляет примерно 1/1 000 000, или 0,000095 %. На уровне отдельных
задач вероятность 1/4 выrлядит неплохо, но объединенная вероятность ryбит
проrраммные проекты. Статистика объединения оценок для худших случаев BЫ
rлядит аналоrично.
Эти статистические аномалии образуют друryю причину для определения He
скольких оценок для лучшеrо, худшеrо, наиболее вероятноrо и ожидаемоrо слу
чаев  см. rлаву 9. В табл. 10.5 показано, что может произойти, если попросить
эти оценки у разработчиков, выдавших оценки из табл. 10.4, и вычислить по ним
оценки для ожидаемоrо случая.
Таблица 10.5. Пример оценки, полученной посредством декомпозиции, с выделением
лучшеrо, ожидаемоrо и худшеrо случаев
Функция
Функция 1
Функция 2
Функция 3
Функция 4
Функция 5
Функция 6
Функция 7
Функция 8
Фун кция 9
Функция 10
итоrо
Недель на завершение
Лучший случай Наиболее Худший случай
(вероятность 25 О/о) вероятный случай (вероятность 75 О/о)
1,6 . 2,0 3,0
1,8 2,5 4,0
2,0 3,0 4,2
0,8 1,2 1,6
3,8 4,5 5,2
3,8 5,0 6,0
2,2 2,4 3,4
0,8 1,2 2,2
1,6 2,5 3,0
1,6 4,0 6,0
20,0 28,3 38,6
Ожидаемый случай
(вероятность 50 О/о)
2,10
2,63
3,03
1,20
4,50
4,97
2,53
1,30
2,43
3,93
28,62
Как обычно, выясняется, что точечные оценки разработчиков из табл. 10.4 в дей
ствительности были оценками лучшеrо случая.
10.4. Создание осмысленных общих оценок
для лучшеrо и худшеrо случаев
Если для получения общих оценок лучшеrо и худшеrо случаев нельзя использовать
суммирование, что же делать? Б статистике часто используется одно стандартное
приближение, в соответствии с' которым 1/6 диапазона от минимума до максимума
5 Зах. 893

130 rлава 10 . Декомпозиция и сводные оценки
считается равноЙ стандартному отклонению. Приближение основано на предпо
ложении, что минимум достиrается с вероятностью 0,135 %, а максимум с вероят
ностью 99,86 % включает все возможные значения.
Вычисление сводных оценок лучшеrо и худшеrо
случаев при малом количеcrве задач (упрощенная
формула crандартноrо отклонения)
При малом количестве задач (10 и менее) оценки лучшеrо и ХУДlпеrо случаев
Ivl0ryT базироваться на упрощенной формуле стандартноrо отклонения. Сначала
раздельно суммируются оценки лучших и худших случаев, после чеrо по ним BЫ
числяется стандартное отклонение по формуле:
ФОРМУЛА NQ 4
СтандартноеОтклонение = (СуммаОценокХудшеrоСлучая + СуммаОценокЛучшеrоСлучаЯ)/6.
Если взять 1/6 от диапазона между 20,0 и 38,6 из табл. 10.5, результат будет
равен одному стандартному отклонению в распределении результатов данноrо
проекта. Одна шестая разности составляет 3,1. Далее в зависимости от необходи
rvl0Й достоверности вычисляется статистически состоятельная оценка. В табл. 10.6
приведены форму ль! для ее вычисления.
Таблица 10.6. Вычисление доаоверных оценок с использованием crандартноrо отклонения
Достоверность
2 О/о
1 О О/о
16 О/о
20 О/о
25 О/о
30 О/о
40 О/о
50 О/о
60 О/о
70 О/о
75 О/о
80 О/о
84 О/о
90 О/о
98 О/о
Формула
ОжидаемыйСлучай  (2 х СтандартноеОтКлонение)
ОжидаемыйСлучай  (1,28 х СтандартноеОтклонение)
ОжидаемыйСлучай  (1 х СтандартноеОтклонение)
ОжидаемыйСлучай  (0,84 х СтандартноеОтклонение)
ожидаемы
случайй  (0,67 х СтандартноеОтклонение)
ОжидаемыйСлучай  (0,52 х СтандартноеОтклонение)
ОжидаемыйСлучай  (0,25 х СтандартноеОтклонение)
ОжидаемыйСлучай
ОжидаемыйСлучай + (2 х СтандартноеОтклонение)
ОжидаемыйСлучай + (0,52 х СтандартноеОтклонение)
ОжидаемыйСлучай + (0,67 х СтандартноеОтклонение)
ОжидаемыйСлучай + (0,84 х СтандартноеОтклонение)
ОжидаемыйСлучай + (1 х СтандартноеОтклонение)
ОжидаемыйСлучай + (1,28 х СтандартноеОтклонение)
ОжидаемыйСлучай + (2 х СтандартноеОтклонение)
Так, с применением этой методики статистически достоверная на 75 % оценка
вычисляется по формуле Ожидаемый Случай (29 недель) + 0,67 х CTaHдapTHoe
Отклонение, то есть 29 + (0,67 х 3,1), что составит 31 неделю.


10.4. Создание осмысленных общих оценок для лучшеrо и худшеrо случаев 131
Почему я назвал 31 неделю вместо 31,1? Потому что базовая оценка задачи
имеет точность не более двух значащих цифр, не rоворя уже о трех, так что OTHO
ситесь к результатам трезво. Вероятно, в нашеrvl примере оценка даже в 31 неделю
приведет к завышению точности результата, и 30 может оказаться более содержа
тельным числом.
СОВЕТ NQ 49
Используйте упрощенную формулу стандартноrо отклонения для вычисления содержательных
оценок лучшеrо и худшеrо случаев в проектах, состоящих из 10 и менее задач.
Вычисление сводных оценок лучшеrо и худшеrо
случаев при большом количестве задач (сложная
формула стандартноrо отклонения)
Если в проекте задействовано более 10 задач, формула стандартноrо отклонения
в предыдущем разделе становится несостоятельной, и вам придется искать более
сложное решение. Научный метод начинается с применения формулы CTaHдapT
Horo отклонения к каждой из отдельных оценок (Stutzke 2005):
ФОРМУЛА NQ 5
ОтдельноеСтандартноеОтклонение = (ОтдельнаяОценкаХудшеrоСлучая + ОтдельнаяОценка
ЛучшеrоСлучая)/б.
По этой формуле вычисляется значение в столбце CTaHдapTHoe отклонение
в табл. 10.7. Затем по довольно сложным математическим формулам определяет
ся стандартное отклонение сводной оценки.
1. Вычислите стандартное отклонение для каждой задачи или функции по
указанной формуле.
2. Вычислите квадрат стандартноrо отклонения каждой задачи (эта величи
на, называемая дисперсией, приведена в правом столбце табл. 10.7).
3. Просуммируйте дисперсии.
4. Вычислите квадратный корень из суммы.
В таблице сумма дисперсий равна 1,22, а квадратный корень из нее равен 1,1;
это значение и определяет стандартное отклонение сводной оценки.
СОВЕТ NQ 50
Используйте сложную формулу стандартноrо отклонения для вычисления содержательных CBOД
ных оценок лучшеrо и худшеrо случаев в проектах, состоящих из 10 и более задач.
l

I
l
Вспомним, что стандартное отклонение, полученное предыдущим способом,
составило 3,1. Новый подход дает ответ 1,10 при тех же данных  различия более
чем заметные! Как такое может быть?
Как выясняется, дело в различиях между четкостью и точностью. Проблема
формулы (ОценкаХудшеrоСлучаяОценкаЛучшеrоСлучая)/6 заключается в том,
что с точки зрения стаТИСТИКJ:I вы предполаrаете, что человек, создавший oцeH
ки лучшеrо и худшеrо случаев, включил шестикратный диапазон стандартноrо

132 rлава 10 · Декомпозиция и сводные оценки
отклонения от лучшеrо случая к худшему. Если бы это было правдой, диапазон
оценки должен был учитывать 99,7 % всех возможных результатов. Друrими сло
вами, из 1000 оценок только три фактических результата будут выпадать за пре
делы оценочных диапазонов!
Таблица 10.7. Пример вычисления стандартноrо отклонения по сложной формуле
Функция Недenьнаэавершение
Лучший случай Худший случай Стандартное Дисперсия (квадрат
отклонение стандартноrо отклонения)
Функция 1 1,6 3,0 0,233 0,054
Функция 2 1,8 4,0 0,367 0,134
Функция 3 2,0 4,2 0,367 0,134
Функция 4 0,8 1,6 0,133 0,018
Функция 5 3,8 5,2 0,233 0,054
Функция 6 3,8 6,0 0,367 0,134
Функция 7 2,2 3,4 0,200 0,040
Функция 8 0,8 2,2 0,233 0,054
Функция 9 1,6 3,0 0,233 0,054
Функция 10 1,6 6,0 0,733 0,538
итоrо 20,0 38,6 1,22
Стандартное 1,1
отклонение
Конечно, это совершенно смехотворное предположение. В нашем примере два
результата из 10 вышли за пределы оценочных диапазонов. Как было показано
в rлаве 1, 90%я достоверность в представлении большинства людей в действи
тельности ближе к 30%й -достоверности. После некоторой тренировки человек
может научиться задавать диапазоны, содержащие правильное значение в 70 %
случаев, но у оценщика нет даже малейшей возможности выдавать оценки с дoc
товерностью 99,7 %.
В более реалистичном способе вычисления стандартноrо отклонения по луч
шему и худшему случаю каждый отдельный диапазон делится на число, более
близкое к 2, нежели к 6. С точки зрения статистики деление на 2 подраЗУl\lевает,
что диапазоны оценщика будут включать фактический результат в 68 % случаев;
эта цель достиrается практикой.
В табл. 10.8 представлены значения делителей в зависимости от процента
фактических результатов, попадающих в ваши диапазоны оценки.
После этоrо число из таблицы включается в сложную формулу стандартноrо
отклонения:
ФОРМУЛА NQ б
ОтдельноеСтандартноеОтклонение = (ОтдельнаяОценкаХудшеrоСлучая + ОтдельнаяОценка
ЛучшеrоСлучая)/ ДелительИзТаблицы108.

..-
10.4. Создание осмысленных общих оценок для лучшеrо и худшеrо случаев 133
Таблица 10.8. Делители, используемые при сложном вычислении стандартноrо отклонения
Если этот процент фактических ...Используйте это число в качестве делителя
результатов попадает при вычислении стандартноrо отклонения
в оценочный диапазон... отдельных оценок
10 О/о 0,25
20 О/о 0,51
30 О/о 0,77
40 О/о 1,0
50 О/о 1,4
60 О/о 1,7
70 О/о 2,1
80 О/о 2,6
90 О/о 3,3
99,7 О/о 6,0
СОВЕТ NQ 51
Не используйте деление диапазона между лучшим и худшим случаем на 6 при вычислении отклоне.-
ний стандартных оценок. Выбирайте делитель в заВИQ1МОСТИ от точности диапазонов ваших оценок.
Создание сводных оценок ДЛЯ лучшеrо и худшеrо случаев
в рассматриваемом нами с.ценарии фактические результаты rруппы попадали
в диапазон от лучшеrо до худшеrо случая 8 раз из 10. Из табл. 10.9 следует, что
rруппы с 80%M попаданием должны использовать делитель 2,6. В табл. 10 пока
заны результаты пересчета стандартных отклонений, дисперсий и сводноrо CTaH
дартноrо отклонения после деления диапазонов на 2,6 вместо 6.
Таблица 10.9. Пример вычисления стандартноrо отклонения по сложной формуле
Функция Недель на завершение
Функция 1
Функция 2
Функция 3
Функция 4
Функция 5
Функция 6
Функция 7
Функция 8
Функция 9
Функция 10
итоrо
Стандартное
отклонение
Лучший случай Худший случай Стандартное
отклонение
1,6 3,0 0,538
1,8 4,0 0,846
2,0 4,2 0,846
0,8 1,6 0,308
3,8 5,2 0,538
3,8 6,0 0,846
2,2 3,4 0,462
0,8 2,2 0,538
1,6 3,0 0,538
1,6 6,0 1,692
20,0 38,6
Дисперсия (квадрат
стандартноrо отклонения)
0,290
0,716
0,716
0,095
0,290
0,716
0,213
0,290
0,290
2,864
6,48
2,55


134 rлава 10 · Декомпозиция и сводные оценки
Этот вариант дает для сводноЙ оценки стандартное отклонение в 2,55 недели.
Для вычисления достоверных оценок используется оценка ожидаемоrо случая
в 28,6 недели из табл. 10.5 и множители из табл. 10.6. Б результате будет получен
набор достоверных оценок, показанных в табл. 10.10.
Таблица 10.10. Пример достоверных оценок, вычисленных по стандартному отклонению
Достоверность Оценка объема работ
2 О/о 23,5
10 О/о 25,4
16 О/о 26,1
20 О/о 26,5
25 О/о 26,9
ЗО О/о 27,3
40 О/о 28,0
50 О/о 28,6
60 О/о 29,3
70 О/о ЗО,О
75 О/о ЗО,З
80 О/о 30,8
84 О/о 31,2
90 О/о 31,8
98 О/о З3,7
Б зависимости от аудитории содержимое этой таблицы может подверrаться
значительной правке. Тем не менее в некоторых ситуациях будет полезно YKa
зать, что хотя вычисление ддя лучшеrо случая дает оценку в 20 человеконедель,
вероятность преодоления пороrа в 23,5 недели составляет Bcero 2 %, а вероят
ность преодоления пороrа в 26,9 недели  25 %.
Как обычно, перед представлением оценок следует учитывать их четкость 
я обычно указываю 24 недели вместо 23,5 и 27 недель вместо 26,9.
Предупреждения по поводу достоверных оценок
Общая проблема только что описанной методики заключается в том, что оценки
общеrо случая должны быть точными  иначе rоворя, они должны быть дейст
вительно вероятными на 50 %. Занижение в этих оценках должно встречаться
с такой же частотой, как и завышение. Если обнаружится, что оценка завышается
чаще, чем занижается, значит, оценка не является вероятной на 50 % и не может
использоваться в ожидаемых случаях. Если ожидаемые случаи неточны, то и их
сумма не будет точной.
В rлаве 9 представлены рекомендации для повышения точности отдельных
оиенок.

,
Дополнительные ресурсы 135
СОВЕТ NQ 52
Направьте усилия на повышение точности оценок ожидаемоrо случая. Если отдельные оценки
точны, то и их объединение не создаст проблем. С друrой стороны, если отдельные оценки
неточны, объединение станет возможным лишь после Toro, как вы найдете способ повысить
их точность.
Дополнительные ресурсы
Hurnphrey, Watts S. A Discipline for Software Engineering. Reading, МА: Addison
Wesley, 1995. В приложении А книrи Хамфри приведена короткая сводка CTaH
дартных методов, применяемых при оценке проrраммных проектов.
Stutzke, Richard D. Estimating SoftwareIntensive Systems, Upper Saddle River,
NJ. AddisonWesley, 2005. fлава 5 содержит более подробные описания статисти
ческих показателей, представленных в этой rлаве. В rлаве 20 описан процесс co
здания WBS.
Gonick, Larry and Woollcott Smith. «The Cartoon Guide to Statistics. New York,
NY: Harper Collins, 1993. Несмотря на несерьезное название, это веСЫ\lа автори
тетное (и занятное) введение в методы статистическоrо анализа. По мнению MHO
rих читателей, иллюстрации помоrают лучше освоить статистические концепции.
Впрочем, некоторым читателям труднее сосредоточиться на rрафике, нежели на
тексте, и это усложняет ПОНИl\lание материала.
Larsen, RichardJ. and MorI:is L. Marx. An Introduction to Mathernatical Statistics
and Its Applications, Third Edition. Upper Saddle River, NJ: Prentice НаН, 2001.
Довольно доступное и традиционное введение в матеl\fатическую статистику...
насколько оно может быть доступным для данной темы. В конце концов, каж
дому, кто хочет использовать в своей работе статистические методы, рано или
поздно придется заняться математическими вычислениями.

",
Оценка
по аналоrии
Область применения методов этой rлавы
Что оценивается
Размер проекта
Стадия разработки
Итеративный или последовательный стиль
Возможная точность
Оценка по анапоrии
Размер, объем рбот, сроки, функциональность
МСБ
РанняяпозДНЯЯ
Оба
Средняя
Некая (вымышленная) корпорация Gigacorp собиралась начать работу над Triad 1.0 
обновленной версией успеlJlноrо пакета ToproBbIx презентаций AccSellerator 1.0.
Майк был назначен руководителеl\f проекта Triad 1.0, и ему требовалась хотя бы
приблизительная оценка для предстоящеrо собрания по планированию продаж.
Он созвал своих работников.
KaK вы знаете, мы приступаем к разработке Triad 1.0,  сказал Майк.  Tex
ническая сторона очень близка к AccSellerator 1.0. Мне представляется, что про
ект будет чуть крупнее AccSellerator 1.0, но не HaMHoro».
«База данных будет HaMHoro больше,  откликнулась Дженнифер.  Но поль
зовательский интерфейс останется примерно таким же.
«[рафиков И отчетов тоже будет rораздо больше, чем в AccSellerator 1.0, но oc
новные классы очень похожи; думаю, количество классов останется прежним, 
сказал Джо.
«Я думаю примерно так же,  сказал Майк.  Пожалуй, на основании этих
данных можно предварительно рассчитать объем работы. В моих записках указа
но, что общий объем работ по предыдущей системе составил 30 человекомеся
цев. Как вы полаrаете, какой должна быть разумная оценка объема работы по HO
вой системе?
А как вы ДУl\fаете, каким будет объем работы по новой системе?


11.1. Основные принципы оценки по аналоrиям 137
11.1. Основные принципы оценки по аналоrиям
в приведенном примере Майк использует методику, называемую оценкой по
аналоrии. В ее основе лежит простая мысль  ТОЧНУIО оценку HOBoro проекта
можно получить, сравнивая новый проект с похожим прошлым проектом.
Несколько сотен разработчиков представили свои оценки для проекта Triad.
Их оценки были разбросаны в диапазоне от 30 до 144 человекомесяцев, а среднее
значение составило 53 человекомесяца. Стандартное отклонение оценок COCTa
вило 24, или 46 % от среднеrо ответа. Нехорошо! Некоторое структурирование
процесса принесет существенную пользу.
Вот как выrлядит базовый процесс оценки по аналоrии, который даст более
точный результат.
1. Получите подробные данные об итоrовом размере, объеме работ и затратах
для предыдущеrо аналоrичноrо проекта. Если возможно, получите данные,
фраrментированные по функциональности, структуре трудозатрат (WBS)
или друrой схеме декомпозиции.
2. Шаr за шаrом сравните размер HOBoro проекта с размером cTaporo про
екта.
3. Постройте оценку размера HOBoro проекта в процентах от размера cTaporo
проекта.
,
4. Создайте оценку объема работ, руководствуясь размеРО1\1 HOBoro проекта
по сравнению с размером предыдущеrо проекта.
5. Следите за тем, чтобы показатели cTaporo и HOBoro проектов базировались
на единых предположениях.
СОВЕТ NQ 53
Оценивайте новые проекты, сравнивая их с похожими прошлыми проектами. Постарайтесь раз
бить оценку минимум на пять составляющих.
Давайте рассмотрим эту процедуру на при мере Triad.
Шаr 1. Получение подробных данных об итоrовом
размере, объеме работ и затратах для предыдущеrо
аналоrичноrо проекта
После первоrо собрания Майк попросил участников проекта Triad собрать более
конкретную информацию о размере старой системы и относительном объеме
функциональности старой и новой систем. Коrда сбор данных был завершен, Майк
поинтересовался результатами: Bы собрали те данные, о которых мы rоворили
на прошлоЙ неделе?»
«Конечно, Майк,  ответила Дженнифер.  Проект AccSellerator 1.0 состоял
из 5 подсистем. Структура пректа была примерно такой:

138 rлава 11 · Оценка по аналоrии
База данных
Пользовательский интерфейс
Диаrраммы и отчеты
Библиотека классов
Бизнес лоrи ка
Итоrо
5000 строк кода
14 000 строк кода
9000 строк кода
4500 строк кода
11 000 строк кода
43 500 строк кода
у нас также имеется общая информация об обще?vl количестве элементов в Ka
ждой подсистеме. Вот что мы нашли:
База данных
Пользовательский интерфейс
Диаrраммы и отчеты
Библиотека классов
Бизнес лоrи ка
10 таблиц
14 вебстраниц
10 диаrрамм + 8 отчетов
15 классов
???
Мы постарались определить аналоrичные показатели для новой системы.
Вот что у нас получилось:
База данных
Пользовательский интерфейс
Диаrраммы и отчеты
Библиотека классов
Бизнес лоrи ка
14 таблиц
19 вебстраниц
14 диаrрамм + 16 отчетов
15 классов
???
«Между большинством подсистем cTaporo и HOBoro проектов существует пря
мое соответствие, но с бизнеслоrикой возникли проблемы,  сказала Дженни
фер.  Мы полаrаем, что она будет сложнее, чем в старой системе, но не уверены
в цифровом выражении. Мы обсудили эту проблему, и по нашему ощущению,
бизнеслоrика по краЙней мере на 50 % сложнее, чем в старой системе».
«Отличная работа,  сказал Майк.  Теперь у l\1еня есть все необходимое для
вычисления оценки к собранию. Завтра я HeMHoro повожусь с цифрами и покажу
вам результат перед собранием.
Шаr 2. Сравнение размера HOBoro проекта
с аналоrичным прошлым проектом
Подробная информация о предыдущем проекте дает нам все необходимое для
создания содержательной оценки методом аналоrии. rруппа Triad уже выполни
ла шаr 1, «Получение подробных данных об итоrовом размере, объеме работ и за
тратах для предыдущеrо аналоrичноrо проекта. Далее собранные данные шаr за
шаrом сравниваIОТСЯ с соответствующими показателями HOBoro проекта. Резуль
таты сравнения показаны в табл. 11.1.

11.1. Основные принципы оценки по аналоrиям 139
Таблица 11.1. Сравнение размеров подсистем между AccSellerator 1.0 и Triad 1.0
Подсистема Фактический размер Оцениваемый размер Множитель
в AccSellerator 1.0 в Triad 1.0
База данных 10 таблиц 14 таблиц 1,4
Пользовательский 14 вебстраниц 19 вебстраниц 1,4
интерфейс
Диаrраммы и отчеты 10 диаrрамм + 8 отчетов 14 диаrрамм + 16 отчетов 1,7
Библиотека классов 15 классов 15 классов 1,0
Бизнеслоrика ??? ??? 1,5
Записать данные в столбцах 2 и 3 несложно  проблема'в том, что делать с MHO
жителем в столбце 4. Основной принцип вам уже знаком: сначала подсчет, затем
вычисления и в последнюю очередь субъективная оценка. Если наЙти какойни
будь счетный показатель, результат будет лучше, чем при использовании субъек
тивной оценки.
С множителями 1,4 для базы данных, 1,4 для пользовательскоrо интерфейса
и 1,0 для библиотеки классов вроде бы все понятно.
С множителем 1,7 для диаrрамм и отчетов дело обстоит сложнее. Должны ли
мы присвоить диаrраммам тот же весовой коэффициент, что и отчетам? Возмож
но, диаrраммы требуют больше работы, чем отчеты, и наоборот. Если бы кодовая
база AccSellerator 1.0 была доступна, мы моrли бы свериться с ней и определить,
присвоить ли диаrраммам и отчетам одинаковые или разные весовые коэффици
енты. В данном примере мы будем полаrать, что веса одинаковы. Это допущение
следует документировать, чтобы позднее при необходимости процедуру оценки
можно было бы воссоздать.
Бизнеслоrика также порождает проблемы. fруппа не нашла никакоrо показа
теля, поэтому наша оценка в этоЙ области покоится на более шатком основании,
чем в друrих областях. Для определенности мы соrласимся с оценкой, что биз
неСЛОI'ика Triad будет примерно на 50 % сложнее бизнеслоrики AccSellerator.
Шаr З. Построение оценки размера HOBoro проекта
в процентах от размера cтaporo проекта
На шаrе 3 метрики размеров из разных областей приводятся к общей единице из
мерения  в нашем случае это строки проrраммноrо кода. Преобразование позво
лит выполнить общесистемное сравнение размеров между AccSellerator и Triad.
Таблица 11.2 показывает, как это происходит.
Размеры подсистем AccSellerator в строках кода были получены по дaH
ным, собранным на шаrе 1. Множители определились в ходе шаrа 2. Оценивае
мый размер подсистемы Triad попросту равен произведению размера подсистемы
в AccSellerator и множителя. Общий размер системы в строках кода становится
основой для вычисления оценки объема работ, которая, в свою очередь, станет
основой для оценок сроков и' затрат.
l
I

I
140 rлава 11 · Оценка по аналоrии
Таблица 11.2. Вычисление предполаrаемоrо размера Triad 1.0 на основании
размера AccSellerator
Подсистема Размер кода Множитель Оценка размера
AccSellerator 1.0 Triad 1.0
База данных 5000 1,4 7000
Пользовательский интерфейс 14 000 1,4 19 600
Диаrраммы и отчеты 9000 1,7 15 300
Библиотека классов 4500 1,0 4500
Бизнеслоrика 11 000 1,5 16 500
итоrо 43 500 62 900
Шаr 4. Создание оценки объема работ на основе
размера HOBoro проекта, полученноrо сравнением
с размером предыдущеrо проекта
Теперь мы располаrаем достаточной информацией для вычисления оценки объема
работ. Это делается так, как показано в табл. 11.3.
Таблица 11.3. Итоrовое вычисление объема работ ДЛЯ Triad 1.0
Показатепь
Размер Triad 1.0
Размер AccSellerator 1.0
Соотношение размеров
Объем работ для AccSellerator 1.0
Оценка объема работ для Triad 1.0
3начение
62 000 строк кода
"'43 500 строк кода
= 1,45
х 30 человекомесяцев
= 44 человекомесяца
Разделив размер проекта Triad на размер AdccSellerator, мы получаем COOTHO
шение размеров двух систем. Умножение ero на объем работ AccSellerator дает
оценку для Triad  44 человекомесяца.
Оценка вычисленная и оценка субъективная  две совершенно разные вещи.
В вычислениях вы получаете точечную оценку, но можете представить ее в диа
пазонном виде (см. rлаву 22).
Я предложил оценщикам, создавшим исходные оценки для Triad, ВОСПОЛЬ30
ваться этой процедурой, и их результаты стали более точными и соrласованны
ми. Стандартное отклонение результатов составило Bcero 7 % вместо 46 %, даже
с учетом неопределенности, связанной с диаrpаммами, отчетами и бизнеслоrикой.
Шаr 5. Проверка соrласованности предположений
между старым и новым проектами
Проверяйте свои предположения на каждом rnare. Впрочем, полноценная про
верка некоторых предположений становится возможной только после заверше
ния оценки. Далее перечислены основные источники рассоrласования.

r
11.2. Замечания ПО ПОВОДУ неопределенности в оценке Triad 141
· Существенно различающиеся размеры cTaporo и HOBoro проектов, то есть
различия более чем в 3 раза (см. раздел 5.1). В нашем случае размеры отли
чаются Bcero в 1,45 раза; этоrо недостаточно, чтобы беспокоиться об из
держках масштаба.
· Разные технолоrии (например, один проект написан на С#, а друrой на
Java).
· Существенные различия в квалификации отдельных участников (в малых
проектах) или целых rрупп (в больших проектах). Небольшие различия
вполне допустимы, а часто неизбежны.
· Существенные различия в типе проrраммы. НаПРИl\lер, если старая систе
ма была внутренним интрасетевым проектом, а новая представляет co
бой критическую встроенную систему, сравнивать их было бы некорректно.
11.2. Замечания ПО ПОВОДУ неопределенности
в оценке Triad
Информация, доступная для оценки бизнеслоrики, была довольно туманной.
Стоит ли повысить количество бизнесправил, чтобы обеспечить консерватив
ность оценки? Нет, не стоит. Целью оценки должна быть точность, а не KOH
серватизм. !(ак только вы перестаете стремиться к точности, в оценку из разных
источников начинают проникать субъективные смещения, и полезность оценки
падает. Правильной реакцией на неопределенность должно быть не смещение
оценки, а rарантия Toro, что любая базовая неопределенность будет точно OT
ражена в оценке. Если вы абсолютно уверены в количестве бизнесправил, то
оценку можно было бы считать точной до + 10 %. Вероятно, с учетом неопреде
ленности в бизнеслоrике уровень неопределенности стоит повысить до (+25 %,
10 %).
Более качественное решение проблемы неопределенности, обусловленной co
ставляющей бизнеслоrики, заключается в использовании диапазонноrо фактора
бизнеслоrики вместо отдельноrо числа. Вместо точечноrо коэффициента 1,5 мож
но оценить фактор с 50%M отклонением (иначе rоворя, диапазон от 0,75 до 2,25).
В этом случае вместо точечной оценки в 44 человекомесяца вычисления дают
диапазон от 38 до 49 человекомесяцев.
В отличие от оценок, созданных описанным способом, в оценках монолит
HЫX (то есть не использующими декомпозицию) неопределенность в одной
области может распространяться в друrие области. Скажем, если в бизнесло
rике существует 50%я неопределенность, оценщик может применить ее ко всей
оценке, а не только к четверти, относящейся к бизнесправилам. Если применить
то же 50%e отклонение ко всей оценке, то мы получим диапазон от 22 до 66 l\lеся
цев, вместо диапазона от 38 до 49 месяцев. Умение идентифицировать факторы
неопределенности и их влияние на оценку способствует сужению общеrо диапа
зона оценки.

142 rлава 11 · Оценка по аналоrии
СОВЕТ NQ S4
Не решайте проблему неопределенноcrи смещением оценки. Поcrарайтесь отразить неопреде
ленноcrь в самой оценке.
Неопределенность оценки, планы и обязательства
Б конечном счете неопределенность в оценке перейдет в планы и обязательства
проекта. Поскольку планы и обязательства направлены на обеспечение макси
мальной производительности, а не на точность, отреrулируйте обязательства
в консервативном направлении, руководствуясь неопределенностью заложенной
в них оценки.

!
Опосредованные
оценки
Область применения методов этой rлавы
Нечеткая Стандартные Абстрактные Метод футболки
поrика компоненты рейтинrи
Что оценивается Размер, функ Размер, объем Размер, объем Размер, объем
циональноcrь работ работ, сроки, функ работ, сроки, Функ
циональность циональноcrь
Размер проекта СБ МСБ МСБ СБ
Стадия разработки Ранняя Ран няя---средняя Ран няя---средняя Ранняя
Итеративный или Последова Оба Оба Последовательный
последовательный '"
тельныи
crиль
Возможная точность Средняя Средняя Средняsrвысокая
Как правило, оценщик не может взrлянуть на описание функции и точно oцe
нить: Ee реализация будет состоять из 253 строк Koдa. Также трудно прямо
оценить, сколько тестовых случаев потребует ваш проект, сколько в нем отыщет
ся дефектов, сколько будет задействовано классов и т. д.
Семейство методов оценки, объединенных оБЩИ1 названием onocpeaOBallllbLX
методов, помоrают решать подобные проблемы. При опосредованной оценке снача
ла идентифицируется nOCpeallUK  показатель, коррелированный с оцениваемым,
который проще вычисляется или подсчитьmается (или становится доступным на бо
лее ранней стадии проекта, чем интересующая вас величина. Скажем, если вы хотите
оценить количество тестовых сценариев, может оказаться, что оно коррелируется
с количеством требований; если оценивается размер в строках кода, может оказаться,
что оно коррелируется с количеством функций (с поправкой на катеroрию размера).
После Toro как показательпосредник будет идентифицирован, вы оцениваете
или подсчитываете ero значение, а затем по формулам, основанным на историче
ских данных, преобразуете ero в нужную оценку.

144 rлава 12 · Опосредованные оценки
в этой rлаве обсуждаются некоторые из самых полезных опосредованных
методов. Суть каждоrо метода заключается в том, что целое содержит более
достоверНУIО ИНфОР1vlацию, чем отдельные части. Таким образом, эти методы по
лезны для создания оценок уровня проекта или итерации, но не для создания
подробных оценок с разбиением на задачи или отдельные функции.
12.1. Нечеткая лоrика
Метод, называемый 1lечеmкой ЛОlUКОЙ, применяется для оценки размера проекта
в строках кода (PutnaIn and Myers 1992, Hurnphrey 1995). Оценщики обычно l\10ryT
классифицировать функции по таким rpуппам: «очень малые», «малые», «cpeд
ние», большие» и очень большие». Затем по историческим данным 1\lbI опре
деляем, сколько строк кода в среднем требует очень малая функция, сколько 
l\lалая и т. д. В табл. 12.1 показан при мер создания подобных оценок.
Таблица 12.1. Пример использования нечеткой лоrики для оценки размера nporpaMMbI
Размер функции Среднее количество Количество Оценка количества
строк кода на функцию функций строк кода
127 22 2794
253 15 3795
500 10 5000
1014 30 30 420
1998 27 53 946
104 95 955
Очень малая
Малая
Средняя
Большая
Очень большая
итоrо
СодеРЖИ:Vlое столбца «Среднее количество строк кода на функцию» базиру
стся на JIсторических данных вашей орrанизации и фиксируется до начала oцeH
ки. Б столбце «Количество 'функций» содержится количество функциЙ в каждой
катеrории раЗfера. СодеРЖИl\10е столбца «Оценка количества строк кода» вычис
ляется по двум друrИI столбцам. Как видно из таблицы, оценка состоит из 5 зна
чащих цифр, что выходит за пределы точности базовых данных. Я бы представ
лял эту оценку как «96 000 строк кода» или даже  100 000 строк кода» (то есть
С 12 значаЩIll\lИ цифраПI), чтобы не создавать ложноrо впечатления высокоЙ
точности.
Как получить средние размеры
f\1етод нечеткой лоrики лучше Bcero работает при калибровке размеров по исто
РПЧССI(Иl\f данным вашеЙ орrанизации. Обычно размеры смежных катеrориЙ долж
ны отличаться как IИНИМУМ в два раза. Некоторые эксперты реКОl\fендуют ис
lIользовать 4KpaTHыe различия (Putnam and Myers 1992).
Начальные средние показатели раЗl\fеров создаются на основе данных, полу
чае1vIЫХ классификациеЙ одноЙ или нескольких законченных систеl\l. Проанали
знруНте старук) CJfCTeIY Jf отнесите каждую функцию к одноЙ из катеrориЙ 

r
I
12.1. Нечеткая лоrика 145
очень малая, малая, средняя, большая или очень большая. Затем подсчитайте
суммарное количество строк кода в функциях одной катеrории и разделите ero на
количество функций; вы получите средний размер в строках кода одной функции
данной катеrории. Пример приведен в табл. 12.2.
Таблица 12.2. При мер вычисления среднеrо размера функции в crpoKax кода
Размер Количество Общее количество Средний размер
функций строк кода функции
117 14 859 127
71 17 963 253
56 28 000 500
169 171 366 1014
119 237 762 1998
Очень малый
Малый
Средний
Большой
Очень большой
Данные в таблице приведены исключительно для при мера. Используйте соб
ственные показатели, баэирующиеся на исторических данных вашей орrанизации.
СОВЕТ NQ 55
Используйте нечеткую лоrику для оценки размера проrраммы в строках кода.
Классификация новой функциональности
При классификации новой функциональности по размерам очень важно, чтобы
ваши предположения относительно Toro, что считать очень малой, малой, cpeд
ней, большой или очень большой функцией, в оценке соответствовали предполо
жениям, которые использовались при исходном вычислении средних размеров.
Это можно сделать тремя способами:
. Поручите исходные вычисления тем же людям, которые будут заниматься
созданием оценок.
. Проведите обучение оценщиков, чтобы они правильно классифицировали
функции.
. Документируйте критерии классификации, чтобы оценщики последова
тельно при меняли их в своей работе.
Как не следует использовать нечеткую лоrику
у статистики имеется один интересный аспект: статистические сводные показа
тели часто оказываются более достоверными, чем отдельные элементы данных.
Как упоминалось в rлаве 10, закон больших чисел наделяет сводные оценки точ
ностью, превосходящей точность отдельных оценок. Целое действительно CTaHO
вится чемто большим, нежели простой совокупностью частей.
При использовании нечеткой лоrики важно помнить об этом явлении. Работа
нечеткой лоrики основана на наших предположениях о том, что если каждая из
71 мелких функций в прошлом состояла в среднем из 235 строк кода, то и в будущем
каждая из 15 мелких функций будет состоять примерно из 253 строк. Тем не менее

146 rлава 12 · Опосредованные оценки
из этоrо вовсе не следует, что любая отдельная функция будет действительно COCTO
ять ИЗ 253 строк. Размеры отдельных мелких функций MOryT лежать в диапазоне
от 50 до 1000 строк кода. Следовательно, хотя монолитная оценка, полученная
с применением нечеткой лоrики, может быть на удивление точной, не следует
расширять методику для оценки размеров отдельных функций.
По Tel\1 же причинам нечеткая лоrика хорошо работает при 20 и более co
стаВЛЯIОЩИХ. Если вы не располаrаете данными по крайней мере по 20 функци
ям, статистика этоrо метода будет работать некорректно, и вам лучше поискать
друrой м:етод.
Расширения нечеткой лоrики
Нечеткая лоrика также может использоваться для оценки объема работ  pa
зумеется, если вы располаrаете соответствующими данными. Пример показан
в табл. 12.3.
Таблица 12.3. Пример использования нечеткой лоrики для оценки объема работ
Размер Среднее количество человеко- Количество Оценка объема работ
дней на функцию функций (в человека-днях)
4,2 22 92,4
8,4 15 126
17 10 170
34 30 1020
67 27 1809
104 3217
Очень малый
Малый
Средний
Большой
Очень большой
итоrо
Данные в таблице приведены исключительно для при мера. Используйте соб
ственные значения количества человекодней на функцию, базирующиеся на ис
торических данных вашей с>рrанизации.
Окончательная оценка в 3217 человекодней снова получилась излишне чет
кой. Ее желательно упростить до 3200 человекодней, 3000 человекодней или
13 человеколет (для 250 рабочих дней в rоду). Также всеrда следует рассматри
вать возможность представления результата в виде диапазона  скажем, от 10
до 15 человеколет. Такая оценка создает совершенно иное ощущение точности,
чем: 3217 человеко дней.
12.2. Стандартные компоненты
Если вы разрабатываете несколько nporpaMM со сходной архитектурой, для oцeH
ки размера можно воспользоваться методом стандартных компонентов. Сначала
неоБХОДИIО найти подходящие элементы для подсчета в предыдущих системах.
Более конкретные рекомендации зависят от работы, которую вы хотите выпол
нять. Типичная система содержит динамические и статические вебстраницы,
таблицы баз данных, бизнеслоrику, диаrраммы, диалоrовые окна, отчеты и т. Д.

,
12.2. Стандартные компоненты 147
После идентификации стандартных компонентов вычисляется среднее I(оличест
во строк кода на компонент в прошлых системах. В табл. 12.4 показан при мер ис
торических данных для стандартных компонентов.
Таблица 12.4. Пример исторических данных по количеству строк кода
на стандартный компонент
Стандартный компонент
Динамические вебстраницы
Статические вебстраницы
Таблицы баз данных
Отчеты
Бизнесправила
Количество строк кода на компонент
487
58
2437
288
8327
Собрав исторические данные, оцените количество стандартных компонентов
в новой проrрамме и вычислите размер новоЙ проrраммы по CTapЫ1 размерам.
При мер показан в табл. 12.5.
Таблица 12.5. Пример использования стандартных компонентов для создания оценки размера
Стандартный Строк "ро- Минималь- Наиболее Максималь- Оцени- Оценка
компонент rpaMMHoro но воэмож- вероятное но воэмож- ваемое в строках
кода на ное число число ное число число кода
компонент
Динамические 487 11 25 50 26,8 13 052
вебстраницы
Статические 58 20 35 40 33,3 1931
вебстраницы
Таблицы баз 2437 12 15 20 15,3 37 286
данных
Отчеты 288 8 12 20 12,7 3658
Бизнесправила 8327 1 1 8327
итоrо 64 254
в столбцах 35 вводятся ваши оценки. Столбец 3 содержит МИНИIальное
количество компонентов, которые, по вашему представлению, может содержать
проект. Например, для динамических вебстраниц в данном примере этот показа
тель равен 11. В следутощем столбце вводится число, по BaIlleMY мнению наибо
лее вероятное (в нашем при мере 25). Затем в столбце 5 вводится максимально
возможное количество (50). Оценка в столбце 6 вычисляется по формуле PERT
(Program Evaluation and Review Technique), обсуждавшейся в rлаве 9. Вот как
выrлядит эта формула для оценки количества компонентов:
ФОРМУЛА NQ 7
ОжидаемоеКоличествоКомпонентов = [Минимум + (4 х НаиболееВероятноеКоличество ) + MaK
симум]/6.


148 rлава 12 · Опосредованные оценки
в нашем при мере оцениваемое количество динамических вебстраниц оказы
вается равным [11 + (4 х 25) + 50]/6 == 26,81.
Как и прежде, данные в таблице приведены ИСКЛIочительно для примера.
11спользуйте собственные значения, базирующиеся на исторических данных.
Использование стандартных компонентов
с процентилями
в одной из разновидностей представленноЙ методики вместо количества компо
нентов оценивается количество процентилеЙ. Для этоrо вам также потребуется
достаточное количество исторических проектов для вычисления OCl\-Iысленных
процентилей (иначе rоворя, по меньшей мере 10 исторических проектов, а в идеа
ле ближе к 20). Но если вы располаrаете таким объемом исторических данных,
вместо оценки количества можно оценить предполаrаемое отклонение от cpeДHe
ro значения по каждому из компонентов. В табл. 12.6 показано, как выrлядит co
ставляемая таблица.
Таблица 12.6. Пример таблицы с эталонными данными для стандартных компонентов
Количеаво арок кода на компонент (процентили)
Стандартные компоненты Очень малый Малый Средний Большой Очень большой
(10й) (25й) (50й) (75й) (90й)
5105 6037 12 123 24 030 35 702
1511 1751 2111 2723 3487
22 498 30 020 40 027 45 776 47 002
1518 2518 3530 5833 5533
7007 7534 8509 10 б63 12 111
Динамические вебстраницы
Статические вебстраницы
Таблицы баз данных
Отчеты
Бизнесправила
Данные в таблице определяют размер стандартных компонентов по отношению
к дрyrnм проектам, выполнявшимся вашей орrанизацией. Соrласно таблице, у 10 %
проектов орraнизации динамические вебстраницы содержали 5105 строк кода и Me
нее, у 50 % проектов статические вебстраницы содержали 2111 строк кода и Me
нее, у 75 % проектов бизнесправила содержали 10 663 строки кода и менее и т. д.
После заполнения эталонной таблицы классифицируйте размер, предполаrае
мый по каждому из стандартных компонентов, и наЙдите соответствующее коли
чество строк кода в табл. 12.6. Пример показан в табл. 12.7.
Как видно из таблицы, вы ожидаете, что оцениваемый проект будет содержать
средние динамические вебстраницы по сравнению с друrими проектами, выпол
нявшимися вашей орrанизацией; статические страницы будут больше среднеrо,
таблицы баз данных  меньше среднеrо и т. д.
1 Некоторые люди путаются с тем, нужно ли делить на 6 или на какоенибудь друrое чис
ло. Комментарии о друrих делителях из rлавы 10 относятся к вычислеНИIО стандартноrо
отклонения. В данном случае по формуле вычисляется ожидаемое значение, а не CTaH
дартное отклонение, поэтому предупреждение на Hero не распространяется.

12.3. Абстрактные рейтинrи 149
Таблица 12.7. Пример использования стандартных компонентов ДЛЯ оценки размера
Стандартный компонент Классификация размера Оценка в аРОК8Х кода
(из табл. 12.6)
12 123
2723
30 020
1518
8509
54 893
Динамические вебстраницы
Статические вебcrраницы
Таблицы баз данных
Отчеты
Средний
Большой
Малый
Очень малый
Бизнесправила
Средний
итоrо
Такой подход дает оценку в 54 893 строки кода. Как и прежде, при представле
нии оценки желательно упростить ее до 55 000 или 60 000 строк (то есть до одной
или двух значащих цифр).
Оrраничения метода стандартных компонентов
К преимуществам метода стандартных компонентов следует отнести то, что он
требует минимальных усилий с вашей стороны; собственно, все сводится к ин
туитивной оценке размера стандартных компонентов в новой системе и поиску
по таблице. HeMHoro времени потребуется на конструирование и сопровождение
справочной таблицы (вроде тех, что представлены в табл. 12.4 и 12.6).
.
Метод стандартных компонентов не базируется на подсчете, поэтому он Hapy
шает общий принцип сначала подсчет, затем вычисления и в последнюю оче
редь субъективная oцeHKa. Впрочем, он связывает оценки с какимито обосно
ванными показателями и поэтому в отдельных случаях может приrодиться.
В целом, хотя метод стандартных компонентов нельзя назвать лучшим MeTO
дом для поздней стадии проекта, он помоrает свести к минимуму усилия по co
зданию ранних оценок, которые все равно подвержены высокой неточности изза
конуса неопределенности.
СОВЕТ NQ 56
Рассматривайте метод стандартных компонентов как средство для получения оценки размера
с минимальными усилиями на ранних crадиях проекта.
12.3. Абстрактные рейтинrи
Друrой разновидностью метода нечеткой лоrики является метод а6страlСтllЫХ
рейтUlll0в, изначально ассоциировавшийся с экстремальным проrpаммировани
ем (СоЬп 2006). В целом он сходен снечеткой лоrикой, однако у Hero есть свои
интересные и полезные особенности, изза которых ero стоит обсудить отдельно.
При использовании метода абстрактных рейтинrов rpуппа просматривает спи
сок пользовательских историй (или требований, или функций), которые она Ha
u u
меревается реализовать, и присваивает каждои истории некоторыи размер, изме
ряемый в nУllктах. В этом отношении абстрактные рейтинrи сходны снечеткой


150 rлава 12 · Опосредованные оценки
лоrикоЙ, однако историям обычно назначаIОТСЯ числовые значения по одной ИЗ
числовых последовательностей, представленных в табл. 12.8.
Таблица 12.8. Наиболее распространенные шкалы абстрактных рейтинrов
Шкала
Степени 2
Числа Фибоначчи
1, 2, 4, 8, 16
1, 2, 3, 5, 8, 13
в результате оценки строится список наподобие представленноrо в табл. 12.9.
Таблица 12.9. Список историй с присвоенными пунктами
История
История 1
История 2
История 3
История 4
Пункты
2
1
4
8
История 60
итоrо
2
180
На этоЙ стадии пункты особой пользы не принесут, поскольку являются чисто
абстрактными единицами  они не преобразуются в количество строк проrpаммно
ro кода, человекодни или календарное время. Важнейшая концепция абстрактных
рейтинrов заключается в T01vI, что rруппа оценивает' все истории одновременно
и по одной шкале, а способ оценки в значительной степени свободен от смещения.
Затем rруппа планирует итерацию, включая в свои: планы выдачу HeKoToporo
числа абстрактных пунктов. В основу планов может быть заложено предположе
ние, что абстрактные реЙТ\iнrи преобразуются в некоторый объем работ, но на
столь ранней стадии проекта это Bcero лишь предположение.
После завершения первой итерации у команды появляется возможность для
составления реальноЙ оценки. rруппа смотрит, сколько абстрактных пунктов она
выдала, какой объем работ и календарное время для этоrо потребовался, и прово
дит предварительную калибровку преобразования абстрактных пунктов в объем
работ и календарное время. При мер представлен в табл. 12.10.
Таблица 12.10. Данные итерации 1 и начальная калибровка
Данные итерации 1
Выдано 27 абстрактных пунктов
Затрачено 12 человеконедель
Затрачено 3 календарных недели
Предварительная калибровка
Объем работ = 27 абстрактных пунктов/12 человеконедель = 2,25 пункта/человеконеделя
Сроки = 27 абстрактных пунктов/3 календарные недели = 9 пунктов/календарную неделю

r
12.3. Абстрактные рейтинrи 151
На основании исходной калибровки руководитель проекта составляет OЦHKY
оставшейся части проекта, базирующуюся на абстрактных данных. Пример пока
зан в табл. 12.11.
Таблица 12.11. Исходное планирование оставшейся части проекта
Данные итерации 1
Предположения (из предварительной калибровки)
Объем работ = 2,25 пункта/человеконеделю
Срок = 9 пунктов/календарную неделю
Размер проекта = 180 пунктов
Предварительная оценка для Bcero проекта
Объем работ = 180 пунктов/2,25 пункта/человеконеделю = 80 человеконедель
Сроки = 180 пунктов/9 пунктов/календарную неделю = 20 календарных недель
I

>
f
r
t
r
r
l'

Конечно, в вычислениях из табл. 12.11 подразумевается, что в будущих итера
циях rруппа останется неизменной, а планирование не учитывает влияние празд
ников, отпусков и т. д. Тем не менее в итеративных проектах она обеспечивает
очень раннее планирование результата проекта на основании абстрактных дaH
ных Toro же проекта.
Исходная оценка проекта ДОЛ)I(на уточняться по данным из последующих итера
ций. Чем короче итерации, тем скорее у вас появятся данные, которые MOryT исполь
зоваться для оценки оставшейся части проекта, и тем достовернее будут эти оценки.
СОВЕТ NQ 57
Метод абстрактных рейтинrов используется для получения ранней оценки объема работ и cpo
ков проекта, и в основу ero закладываются данные Toro же проекта.
о шкале абстрактных рейтинrов
в методе нечеткой лоrики используется описательная шкала размеров: очень Ma
лый, малый и т. д. В методе абстрактных рейтинrов используются степени 2 или
числа Фибоначчи. Что лучше?
На числовой шкале отношения между числами предполаrают, что измеряе
мые величины также находятся в соответствующем отношении. Например, если
абстрактные рейтинrи присваиваются по шкале Фибоначчи, шкала 1,2,3,5,8, 13
наводит на l\fЫСЛЬ, что объем работ для выполнения истории из 5 пунктов COCTa
вит 5/3 от объеl\1а работ для истории из 3 пунктов, а история из 13 пунктов будет
выполняться почти в 4 раза дольше, чем история из 3 пунктов.
Такие отношения оказываются «палкой о двух концах». Если вы приняли He
обходимые меры, чтобы 13пунктовая история действительно занимала пример
но в 4 раза больший объем работ, чем 3пунктовая  замечательно. Это означает,
что вы сможете вычислить средний объем работ на пункт абстрактноrо рейтинrа
(см. ранее), умножить ero на общее количество пунктов и получить осмысленный
результат.

152 rлава 12 · Опосредованные оценки
Однако достижение TaKoro уровня точности потребует большой осторожно
сти при назначении пунктов историй. Кроме Toro, фактические данные проекта
должны rарантпровать, что оцениваемые соотношения действительно встречаIОТ
ся на практике.
Если не принять мер к обеспечеНИIО точности числовых соотношений, обу
словленных шкалой Фибоначчи или степенью 2, то результаты, вычисленные на
базе абстрактных реЙтинrов, MorYT оказаться менее состоятельными, чем кажется
на первый взrляд. Применение числовой шкалы подразумевает ВОЗIОЖНОСТЬ BЫ
полнения числовых операций: умножения, сложения, вычитания и т. д. Но если
базовые отношения не состоятельны (то есть 13пунктовая история в деi1ствитель
ности не требует в 13/3 больших усилий, че!\I 3пунктовая), то выполнение MaTe
матических операций с числом 13 оказывается ничуть не более осмысленным,
чем выполнение IvIатематических операций с оценкой большой» или очень
1'" u
оольшои.
В табл. 12.2 представлен друrой способ описания этоЙ проблемы.
Таблица 12.12. Пример Toro, что может ПРОИЗ0ЙТИ при деформации числовой шкалы
Классификация Количество Условные Предполаrаемое Фактическое Реальные
в пунктах историй пункты соотношение соотношение пункты
(по данным)
«1» 4 «4» 1 2 4
«2 » 7 « 14» 2 2,5 18
«3 » 5 «15» 3 3 15
«5 » 5 «25» 5 7 35
«8» 12 «96» 8 11 132
« 1 3» 2 «26» 13 17 34
итоrо 43 «180» 238
в этом ПРИIере числовая шкала заставила нас поверить, что 180 пунктов об
разуют разУМНУIО оценку общеrо объема работ, но реальный объеI оказался при
IepHo на 30 % выше.
СОВЕТ NQ 58
Будьте внимательны при вычислении оценок, в которых используются числовые рейтинrовые
шкалы. Убедитесь в том, что числовые катеrории на шкале действительно ведут себя как числа,
а не как отвлеченные катеrории вроде «малый», «средний» или «большой».
12.4. Метод футболки
Участникам проекта, не обладающим технической квалификацией, часто прихо
ДIIТСЯ принимать решения относительно объема проекта в широкой части конуса
lIеопределенности. ХорошиЙ оценщик не станет предоставлять чеТКУIО оценку,
пока проект находится на этой стадии. Специалисты по продажам и маркетинrу
запротестуют: «Как Я l\Iory сказать, нужна мне эта функция или нет, если я не
знаlО, сколько она стоит? На что хороший оценщик скажет: A я не MOry ответить,

,
12.4. Метод футболки 153
сколько она стоит, пока мы не получим более подробные требования. Ситуация
заходит в тупик.
Чтобы выйти из тупика, необходимо понять, что целью оценки проrраммноrо
проекта является не идеальная точная оценка, а оценка, достаточно точная для
обеспечения эффективноrо управления проектом. В данном случае у вас не Tpe
буют оценку в человекочасах, а хотят узнать, с чем можно сравнить функцию по
размерам  с мышью, кроликом, собакой или слоном? Это замечание приводит
нас к чрезвычайно полезной методике оценки, называемой AtemOaOM футболки.
В этом методе разработчики клаССИфИЦИРУIОТ затраты на разработку каждой
функции по отношению к друrим функциям: малые, средние, большие или очень
большие. Параллельно отделы маркетинrа, продаж, обслуживания клиентов и дpy
rие стороны, не обладающие техническоЙ квалификацией, клаССИфИЦИРУIОТ
КОМIерческую ценность каждой функции по той же шкале. Затем два набора oцe
нок объединяются, как показано в табл. 12.13.
Таблица 12.13. Пример использования метода футболки для классификации функций
по коммерческой ценности и затратах на разработку
Функция Коммерческая ценность
Функция А Большая
Функция В Малая
Функция С Большая
Функция D Средняя
Функция Е Средняя
Функция F Большая
Функция G Малая
Функция Н Малая
Затраты на разработку
Малая
Большая
Большая
Средняя
Большая
Средняя
Малая
Средняя
Функция zz
Малая
Малая
Определение подобных отношений между коммерческоЙ ценностью и затратами
на разработку позволяет специалисту, не обладающему техническоЙ квалификаци
ей, высказывать мнения вроде слеДУlощеrо: «Если реализация функции В требует
больших затрат, она мне не нужна, потому что функция обладает малой коммерче
ской ценностью». ВОЗlvIОЖНОСТЬ принятия таких решений на ранней стадии работы
над функцией чрезвычайно полезна. Если бы вместо этоrо функция прошла через
определенную работу по постановке требований, проектированию, выработке
архитектуры и т. д., может оказаться, что вы напрасно расходуете усилия на функ
цию, не оправдаННУIО по затратам. В области разработки проrраммноrо обеспече
ния ранний ответ «HeT дороrоrо стоит. Метод футболки позволяет принимать
решения об исключении функций на ранней стадии работы над проектом и ис
ключить дальнейшее перемещение этих функций по конусу неопределенности.
Что стоит сохранить, а что выбросить? Обсуждать эту тему будет rораздо проще,
если список функций будет хотя бы приблизительно отсортирован по отношеНИIО
затратыjвыиrрыш. Как правило, для этоrо функциям присваивается показатель

l
154 rлава 12 · Опосредованные оценки
чuспzой CтO\tOCтu (еще одна абстрактная метрика), основанный на комбинации
затрат на разработку и КОl!\fерчеСКОI':'I ценности. Б табл. 12.14 представлена одна
lIЗ ВОЗ?\IОЖНЫХ CXef\1 присваивания чистоЙ СТОИl\iIОСТИ. Бы можете использовать
эту cxeIY или разработать друryю, которая бы более точно отражала специфику
вашей среды.
Таблица 12.14. Вычисление чистой стоимости по соотношению затрат к коммерческой ценности
Коммерческая Затраты на разработку
ценность Очень большие Большие Средние Малые
Очень большая О 4 б 7
Большая --4 О 2 3
Средняя б 2 О 1
Малая 7 з 1 О
Наличие подоБНОI':'I таблицы позволит включить третий столбец в исходную
таблицу затраТ/КОIlерчеСКОIi ценности (см. табл. 12.13) и отсортировать ее по
чистоЙ стои{ости. как показано в табл. 12.15.
Таблица 12.15. Пример сортировки оценок, полученных методом футболки,
по приблизительной чистой стоимости
Функция
Функция А
Функция F
Функция С
Функция D
Функция G
Функция zz
Функция Н
Функция Е
Коммерческая
ценность
Б
Б
Б
С
М
М
М
С
Затраты
на разработку
М
С
Б
С
М
М
С
Б
Функция В
м
Б
з
Приблизитепьная
чистая стоимость
3
2
О
О
О
О
1
2
ПОlните, что последний столбец содержит приближенные данные. Я не пред
лаrаю вычислить список и провести пороrОВУIО линию»  сортировка по при
ближенной коммерческой ценности полезна прежде Bcero Tel\.f, что она позволяет
быстро дать ответ определенно да» для функциЙ в верхней части списка и опре
деленно нет» для функций в НИ)I(неЙ части списка. Основное обсуждение переме
щается в середину списка, rде оно будет наиболее продуктивным.
СОВЕТ NQ 59
Используйте метод футболки, чтобы помочь нетехническим сторонам проекта принять реше
ния по Вl<лючению или исключению тех или иных функций В широкой части конуса неопреде
лен насти.

r
Дополнительные ресурсы 155
12.5. Друrие применения опосредованных методов
Приведенные в этой rлаве примеры показывают, как применять опосредованные
методы для оценки объема работ и затрат. Аналоrичные методы IOryT использо
ваться для оценки количества тестовых сценариев, дефектов, страниц ДOKYMeHTa
ции или ЛIобых друrих показателей, которые проще оценивать опосредованно,
нежели напрямую.
СОВЕТ NQ 60
Используйте опосредованные методы для оценки количества тестовых сценариев, дефек
тов, страниц документации и любых друrих показателей, которые трудно оценивать напрямую.
Как описано в rлаве 7, возможности выбора показателя почти не оrраничены.
В этой rлаве представлено лишь несколько конкретных примеров. Если вы счи
таете, что в вашей среде Иlеется друrой, более адекватный показатель размера
проекта, используйте ero вместо методов нечеткой лоrики, стандартных компо
нентов или абстрактных рейтинrов.
СОВЕТ NQ 61
Подсчитывайте тот показатель, который проще Bcero считается и обеспечивает максимальную
точность в вашей среде. Соберите калибровочные данные и используйте их для создания oцeH
ки, адаптированной к вашей среде.
Дополнительные ресурсы
СоЬп, Mike. «Agile Estimating and Planning. Upper Saddle River, NJ: Prentice НаН
Professional Technical Reference, 2006. В книrе Кона приводится более подробное
обсуждение абстрактных рейтинrов, включая факторы планирования и методы
оценки.
Humphrey, Watts S. «А Discipline for Soft\\rare Engineering. Reading, МА:
AddisonWesley, 1995. В rлаве 5 книrи Хамфри рассматривается опосредованный
метод, названный автором «методом PROBE, а также более подробно paCCMaT
риваются статистические методы. на которых он основывается. Кроме Toro, в rла
ве 5 обсуждается метод нечеткой лоrики.

Экспертные
оценки в rруппах
Область применения методов этой rлавы
rpynnoBoe обсуждение
Размер проекта
Стадия разработки
Итеративный или
последовательный стиль
Возможная точность
Размер, объем работ, сроки,
функциональность
СБ
Ранняяредняя
Оба
Широкополосный
. Дельфийский метод
Размер, объем работ, сроки,
функциональность
СБ
Что оценивается
Ранняя
Последовательный
Средняя
Средняя
Метод rрупповоrо обсуждения полезен при оценке проекта на ранней стадии или
при большом количестве факторов неопределенности. В этоЙ rлаве представлен
rvlетод неструктурированной rрупповой экспертной оценки (rрупповое обсужде
ние) и структурированный метод, называемый «широкополосным Дельфийским
l\1етодом» .
13.1. rpynnoBoe обсуждение
Простой способ повышения точности оценок, созданных отдельными эксперта
ми, заключается в проведении rpупповоrо анализа оценок. При обсуждении oцe
иок в rруппах я требую соблюдения трех простых правил.
. Каждый участник rруппы оценивает фраrменты проекта по отдельно-
сти, после чеrо rруппа встречается для сравнения оценок. Обсудите
различия в оценках и постарайтесь понять причины различий. Работай
те до тех пор, пока не достиrнете единоrо мнения по поводу верхней и ниж
ней rраниц оценок.


13.1. rРУППО80е обсуждение 157
· Не оrраничивайтесь принятием усредненной оценки. Вычислить среднее
значение fVIОЖНО, но непременно обсудите различия между отдеЛЬНЫ!\1И pe
зультатаl\IИ. f-Ie ПрИНИ!\1аЙтс вычисленное среднее значение автоматически.
· Соrласуйте оценку, которая будет принята всей rpуппой. Если обсужде
ние заЙдет в тупик, не прибеrайте к rолосованию. Обсудите различия и дo
беЙтесь консенсуса от всех членов rpуппы.
Несмотря на простоту, эта методика улучшает точность оценки. На рис. 13.1
показаны результаты по 24 lруппам оценщиков, с которыми я работал.
100 0/0
80%
60 О/о
40 О/О
20%
Ошибка
0%
20 0/0
O О/о
ook
----80 010
Обсужденные
оценки
Индивидуальные
оценки
.'>
"Т
1 :'"
, ,
... ...
1 2 3 4 5 6 7 8 9 1 О 11 12 13 14 15 16 17 18 19 20 21 22 23 24
rpynna оценщиков
Рис. 13.1. Простое обсуждение индивидуальных оценок существенно улучшает их точность
Средняя величина относительной ошибки для индивидуальных оценок на
рис. 13.1 составляет 55 %. У оценок, прошедших обсуждение в rpуппах, она Y!\leHЬ
шилась до 30 %. В данном примере 92 % rрупповых оценок превосходили 1"IНДII
видуальные оцеНКII по точности, причем обсуждение в среднем приводило к ДBY
кратному сокращению ошибки.
СОВЕТ NQ 62
Используйте rpynnoBoe обсуждение для повышения точности оценки.
I(aKoe количество экспертов считать достаТОЧНЫ!\1? Исследования в друrих
областях показали, что от 3 до 5 экспертов с разной квалификацией обычно OKa
зывается достаточно (Libby and Blashfield 1978, ]0rgensen 2002).
Также может быть полезно !1риrласить экспертов с подrотовкой в разных облас
тях или ПОЛЬЗУЮll{ИХСЯ разными методиками (Arrnstrong 2001, ]0rgensen 2002).

158 rлава 13 · Экспертные оценки в rpynnax
13.2. Широкополосный Дельфийский метод
ШирокополосныЙ ДельфиЙскиЙ Iетод относится к структурированным MeTO
дам rрупповой оценки. vIсходныЙ ДельфиЙскиЙ м:етод был разработан в Rand
COI'poration в конце 1940x rодов для проrнозирования технолоrических TeHдeH
циЙ (BoellI11 1981). Ero название происходит от древнеrреческоrо rорода Дельфы,
[де находился оракул. В базовом варианте ДельфиЙскоrо метода несколько экс
пертов создают независимые оценки, а зате'1 встречаются до тех пор, пока им не
удастся соrласовать одну оценку.
Первоначальные I1сследования применения ДельфиЙскоrо метода для oцeH
ки проrраl\1мноrо обеспечения показали, что базовыЙ ДельфиЙскиЙ метод не
обеспечивает большей ТОЧНОСТII, чеl\1 менее структурированные rрупповые обсу
ждення. Барри БеlvI и ero коллеrи сделали вывод, что общие собрания слишком
подвержены политическому давлеНИIО, и на них часто доминируют наиболее
настоЙчивые оценщики в rруппе. По ЭТОI':'r причине Бем с коллеrами доработали
базовый ДельфиЙский метод и превратили ero в то, что сеЙчас известно под Ha
званием ШUРОКО1Z0ЛОС1l0l0 ДеЛЬфИЙСКОlО .мепzода. Основная процедура представ
лена в табл. 13.1.
Таблица 13.1. Широкополосный Дельфийский метод
1. Координатор предоставляет каждому оценщику спецификацию и форму оценки.
2. Оценщики по отдельности rотовят исходные оценки (также этот шаr может выполняться
после шаrа 3).
3. Координатор созывает собрание rpYnnbI, на котором оценщики обсуждают проблемы,
связанные с оценкой текущеrо проекта. Если rpynne удается соrласовать единую оценку
без особых дискуссий, координатор назначает одноrо из участников на роль «адвоката
дьявола».
4. Оценщики анонимно передают индивидуальные оценки координатору.
,
5. Координатор rотовит сводку оценок в итеративной форме (рис. 13.2) и представляет форму
оценщикам, чтобы они видели, как выrлядят их оценки в сравнении с оценками друrих
участников rpYnnbI.
б. Координатор орrанизует встречу, на которой оценщики обсуждают расхождения в оценках.
7. Оценщики проводят анонимное rолосование по принятию средней оценки. Если хотя бы
один из оценщиков проrолосует отрицательно, процедура возвращается к шаry 3.
8. Окончательной считается точечная оценка, полученная по Дельфийской процедуре. Также
окончательная оценка может представлять собой диапазон, созданный в ходе обсуждения,
а точечная оценка представляет ожидаемый случай.
ИстОЧllИК: Ада1l1пирова1l0 по ,матерИШlам «5oftware Eпgiпeeliпg Ecoпomics» (Boehт 1981).
Шаrи 3 7 выполняются в личном общении, на rрупповых собраниях, по элек
тронной почте или в чате. Выполнение их на электронном уровне помоrает co
хранить aHOIIIll\IHOCTb экспертов. Итерации шаrов 37 ВЫПОЛНЯIОТСЯ немедленно
или в пакетном режиме, в заВИСИlvlОСТИ от критичности оценки по времени и дoc
тупности оценщиков.


13.2. Широкополосный Дельфийский метод 159

о
Средняя оценка
!
x€]
х
х
10
Человекомесяцы
Рис. 13.2. Форма оценки для широкополосноrо Дельфийскоrо метода
5
15

20
Оценочная форма, изображенная на рис. 13.2, l\10жет быть буrvIажной или же
может быть нарисована координатором на доске. На показаННОI';'! форме представ
лена шкала от О до 20 человекомесяцев. Исходный диапазон должен быть по
крайней мере втрое шире диапазона, которыЙ вы рассчитываете получить, чтобы
оценщики не чувствовали себя оrраниченными рамками заранее определенноrо
диапазона.
Координатор должен следить за тем, чтобы люди со склонностью к психолоrиче
скому доминированию не оказывали нежелательноrо влияния на оценку. Излишняя
напористость не присуща разработчикам, однако самыЙ сдержанныЙ участник
нередко предоставляет самый ценныЙ взrляд на оцениваемую работу.
Все итерации оценок полезно отображать на одноЙ шкале, чтобы разработчи
ки моrли проследить за их схождением (или в некоторых случаях  за расхожде
ниеI). Пример показан на рис. 13.3.
Итерация 1
о
5
10
15
20
Итерация 2
о
5
10

15 20
Итерация 3
о
5
10
15
20
Человекомесяцы
Рис. 13.3. Оценочная форма широкополосноrо Дельфийскоrо метода после трех итераций
После итерации 3 rруппа соrласилась на оценку в виде диапазона от 12 до
14 месяцев, при этом ожидае10е значение составляет 13 человекомесяцев.
Эффективность широкополосноrо Дельфийскоrо метода
я собрал данные по применению широкополосноrо Дельфийскоrо метода в очень
трудноЙ оценочной проблеме: На рис. 13.4 представлены данные об ошибках,

- l
160 rлава 13 · Экспертные оценки в rpynnax
полученных при простом усреднении исходных оценок, по сравнению с ошибка
ми при использовании широкополосноrо Дельфийскоrо метода.
Mo опыт пр:именения широкополосноrо Дельфийскоrо метода показывает,
что он снижает ошибку примерно на 40 % по сравнению со усредненной оценкой
rpуппыI. Из rpynn, участвовавших в моем исследовании, две трети предоставили
более точный ответ при использовании широкополосноrо Дельфийскоrо метода,
нежели при простом усреднении.
700 0,'0
600%
500%
Дельфийский
метод
. Усреднение
по rруппам
400%
Ошибка 300 %
200%
100 % t
O% 
100 %J I I I I I
/12345
I I I I I J I I I I I J I I J I I I J t
6 7 8 9 1 О 11 12 1 3 14 15 16 17 18 19 20 21 22 23 24 25
rpynna оценки
Рис. 13.4. Сравнение точности оценок при простом усреднении и широкополосном
Дельфийском методе. Широкополосный Дельфийский, метод сокращает ошибку
оценки в двух третях случаев
Из 10 rрупп, предоставивших наихудшие исходные оценки (рис. 13.5), ши
рокополосный Дельфийский метод улучшил точность оценки в 8 случаях из 10,
а среднее сокращение оширки составило 60 %.
По этим данным я сделал вывод, что широкополосный ДеЛЬфJIЙСКИЙ Iетод
в большинстве случаев улучшает точность и оказывается особенно полезным в pe
зу ль татах с большим разбросом ошибок.
«Истина rде"то рядом»
Методы, основанные на усреднении индивидуальных оценок, подразумевают, что
u u u u u
правильныи ответ лежит rдето в диапазоне между самои низкои и саман высокои
оценкой. Тем не менее в моих данных широкополосноrо Дельфийскоrо метода
исходные оценочные диапазоны 20 % rрупп не включали правильный ответ. Это
означает, что усреднени:е таких исходных оценок в принципе не может привести
к точному результату.
Вероятно, самое интересное свойство широкополосноrо Дельфийскоrо Iетода
заключалось в том, что одна треть rpупп, у которых исходный диапазон не включал
u u u
правильныи ответ, немедленно соrлашались с оценкои, лежаще:и за пределами
их исходноrо диапазона ближе к правильному ответу. ДрyrnfИ словами, в таЮ,IХ

I
13.2. Широкополосный Дельфийский метод 161
rруппах широкополосный Дельфийский метод работает лучше, чем лучшая из
индивидуальных оценок. Ситуация продемонстрирована на рис. 13.6. Обратите
внимание: ни одна из rpупп не соrласилась с окончательной оценкой, которая была
хуже наихудшей индивидуальной оценки.
1200 010
1100 010
1000 О/О
900 О О
800 О О
Дельфийский 4
метод
. Усреднение
по rpynnaM
700 0/0
Ошибка 600 о/о
500 о/о
400 О/о 1
300%
. .
200 о/о
..
. '.
1 00 0J'o  . .. '
0%
1 2 3 4 5 6 7 8 9 10
rpynna оценки
Рис. 13.5. Результаты применения широкополосноrо Дельфийскоrо метода к очень плохим
исходным оценкам. В этом наборе данных результаты улучшились в 8 случаях из 10
Правильный
ответ
t t t
Ни в одном из случаев Исходный диапазон В одной трети случаев
широкополосный индивидуальных оценок широкополосный
Дельфийский метод Дельфийский
не приводил к смещению метод смещал оценку
оценки в этом направлении за пределы исходноrо
(то есть за пределы исходноrо диапазона к правильному
диапазона, с удалением ответу
от правильноrо ответа)
Рис. 13.6. Примерно в трети случаев широкополосный Дельфийский метод помоrает
rруппам, у которых правильный ответ не входил в исходный оценочный диапазон,
выйти за пределы диапазона и приблизитЬсЯ к правильному ответу
Коrда при менять широкополосный Дельфийский метод
в сценарии с трудной оценкой, описанном в этой rлаве, широкополосный Дель
фийский метод сократил среднюю ошибку оценки с 290 до 170 %. Ошибки в 290 %
и 170 % чрезвычайно велики, но это характерно для оценок, создаваемых в широкой
6 Зах. 893


162 rлава 13 · Экспертные оценки в rруппах
части конуса неопределенности. Тем не менее сокращение ошибки на 40 % весьма
ценно, будь то уменьшение с 290 до 170 % или с 50 до 30 %.
Хотя мои данные, казалось бы, однозначно одобряют широкополосный Дель
фийский метод, в отрасли сейчас изучается вопрос о том, как объединять оценки,
созданные разными оценщиками. Некоторые исследования показали, что rруп
повой подход к объединению оценок работает лучше; в друrих лучше работало
простое усреднение (J0rgensen 2002).
Поскольку широкополосный Дельфийский ?vlетод требует проведения собра
ний, он связан с большими затратами рабочеrо времени и поэтому считается дo
роrостоящим методом оценки. Для получения подробных оценок для множества
задач он не подходит.
Широкополосный Дельфийский метод полезен при оценке работы, проводи
мой в малознакомой деловой области, базирующейся на новой технолоrии или
направленной на разработку HOBoro вида проrраммноrо обеспечения. Он помоrа
ет создавать приближенные оценки «с точностью до порядка на стадии опреде
ления продукта или выработки концепции, пока мноrие требования еще не были
сформулированы. Он также хорошо работает в проектах, связанных с нескольки
ми разнородными специализаЦИЯ1И,  сн:ажем, в комбинациях алrоритмической
сложности, исключительноrо быстродеЙствия, сложных бизнесправил и т. д. Кроме
Toro, метод способствует более четкому определению объема работы и помоrает
избавиться от лишних предположений. Короче rоворя, широкополосный Дель
фийский метод ПРИНОС11Т наибольшую пользу при оценке одиночных показате
лей, использующих входные данные из разных областей в очень широкой части
конуса неопределенности. В подобных неопределенных ситуациях широкополос
ный Дельфийский метод способен оказать неоценимую помощь.
СОВЕТ NQ 53
Используйте широкополосный Дельфийский метод для формирования оценок на ранней стадии
проекта, в незнакомых системах, а также тоrда, коrда в проекте задействовано несколько раз
нородных дисциплин.
Дополнительные ресурсы
Боеhrn, Бarry W. Software Engineering Econornics. Englewood Cliffs, NJ: Prentice
НаН, Inc., 1981. В разделе 22.2 книrи Бема описан исходный Дельфийский метод,
а также история создания широкополосноrо Дельфийскоrо метода.
NASA, «ISD Wideband Delphi Estirnation, Number 580PROGRAMMER
О 160 1, September 1, 2004, http://software.gsfc.nasa.gov/ AssetsApproved/PA1.2.1.2. pdf.
Документ описывает разновидность широкополосноrо Дельфийскоrо метода, ис
пользуемую Центром управления полетами NASA.
Wiegers, Karl. Stop Promising Miracles, Software Developrnent, February 2000.
Б статье Биrерса описана разновидность широкополосноrо Дельфийскоrо метода.

Оценочные
nporpaMMbI
Область применения методов этой rлавы
Что оценивается
Размер проекта
Стадия разработки
Итеративный или последовательный стиль
Возможная точность
Использование оценочных nporpaM
Размер, объем работ, сроки, функuиональность
СБ
Ранняя;:редняя
Оба
Высокая
в книrе основное внимание уделяется неформальным методам оценки, но ино
rда лучшей основой для неформальных методов оказывается научная оценка 
вычислительные методы, которые нельзя леrко проделать вручную даже на xopo
шем калькуляторе.
14.1. Для чеrо необходимы
оценочные nporpaMMbI
Оценочные проrраммы цозволяют выполнить некоторые операции, связанные
с оценкой, которые трудно проделать вручную.
Моделирование результатов проекта. Оценочные проrраммы способны BЫ
полнять сложное статистическое моделирование, которое помоrает ключевым CTO
ронам проекта представить объем работы. На рис. 14.1 показан пример имитации
результатов проrpаммноrо проекта.
Сплошные черные линии оозначают медианы (50/50) срока и объема работ.
Пунктирные черные линии представляют 25й и 75й процентили результатов.

.....
164 rлава 14 · Оценочные nporpaMMbI
Объем
работ
(человеко
месяцы)
60
55
50
45
40
35
30
25
20
15
10
5
О
5
I
.
I
,
I
I
I
I
l
1
. . а: 8". .
· t . .
I .
rt. "". .
... ."
. а. ... r. . ".. 11
rJ,
· "О '8"  О. " .
.. ..... 8.. Й" 11
11 .... . .1
. . а..." .. rt. I .
." ,. . -.., La 111
)i :.. .. " f(
. . ,,/'; 8 .." '.. 8
. ... ".. 8 11 .... , "
11.  ,/' 8 ".. 8 I
,.# ........... .08. ·
..  .М... '" I
« ..",rP "1
11
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Срок (месяцы)
Рис. 14.1. Компьютерное моделирование 1000 результатов проекта (выходные данные
Construx Estimate)
Оценочная проrраМlvlа учитывает несколько источников изменчивости:
. различия в производительности;
. различия в размере проrраммы, возможно с декомпозицией на несколько
модулей;
. различия в темпах комплектования персонала.
Для каждоrо моделируе10rо результата проrpамма использует метод стати
стическоrо моделирования, называемый методом MOHTe Карло, и моделирует один
ВОЗlvlОЖНЫЙ результат для конкретной комбинации производительности, размера
и состояния персонала. По трем факторам на диаrрамме строится одна точка.
Для создания всей диаrpаммы проrрамма повторяет цикл 1000 раз. Сами пони
?vlaeTe, делать это вручную никому не захочется!
В некоторых проrраммах (более дороrих, чем Construx Estimate) применяют
ся более сложные технолоrии.
Вероятностный анализ. В rлаве 1 объясняютс.я опасности оценок с формули
ровками типа c уверенностью на 90 %. Коrда оценка создается на базе субъ
ективноrо суждения, подобные выражения изначально подвержены ошибкам.
Но если оценка rенерируется специальной проrраммой, откали6рованной по
историческим данным, процентные показатели несут более .содержательную
информацию. Например, на рис. 14.1 объем работ в 45 человекомесяцев имеет
75%ю вероятность, потому что 75 % смоделированных проектов заняли менее
45 человекомесяцев.
В табл. 14.1 представлен пример вероятностноrо анализа объема работ, вычис
ленноrо оценочной проrраммой. «Номинал, упоминаемый в заrоловке TpeTbero
столбца, относится к оценке в 20 человекомесяцев, вероятной на SO %.
Самая интересная особенность таблицы заключается n том, что для повыше
ния достоверности с 70 до 80 % или с 80 до 90 % требуется очень большой рост
объема работ. При оценках, основанных на субъективном суждении, лишь HeMHO
rие оценщики умножают с.вои номинальные оценки на 6 для вычисления оценки

14.1. Для чеrо необходимы оценочные проrраммы 165
с 90%й достоверностью, но в данном случае нужно именно это (не используйте
эти данные в общем случае; они были вычислены по конкретным предположени
ям, введенным в оценочную проrрамму).
Таблица 14.1. Пример вероятностей различных объемов работ по проекту, вычисленных
при помощи оценочной nporpaMMbI
Вероятность Объем работ будет меньше
либо равен
Расхождение с номинальной
оценкой
1 О О/о 7 4 О/о
20 О/о 10 50 О/о
30 О/о 13  37 О/о
40 О/о 16 20 О/о
50 О/о 20 О О/о
60 О/о 26 30 О/о
70 О/о 37 84 о/о
80 О/о 58 189 О/о
90 О/о 142 611 О/о
На рис. 14.2 показано rpафическое представление данных в таблице.
1 00 0/0
90%
80%
70 О/о
60 0/0
Вероятность 50 0/0
40 О/о
30 0/0
20 0/0
10 %
О °k
О 20 40 60 80 100 120 140
Объем работ (чеЛО8екомесяцы)
Рис. 14.2. Пример вероятных результатов проекта по данным оценочной nporpaMMbI
Учет издержек масштаба. Оценочные проrраммы автоматически учитывают
различия в размерах проектов и их влияние на производительность.
Учет непредвиденноrо расширения требований. Проблема расширения Tpe
бований встречается настольк<? часто, что в большинстве коммерческих оценоч
ных проrрамм может учитываться в ходе проекта.

166 rлава 14 · Оценочные nporpaMMbI
Оценка вторичных аспектов разработки проrpаммноrо обеспечения. Oцe
ночные проrраммы обычно поддерживают возможность оценки размера ДOKY
l\lентации по требованиям, раЗlера архитектурноЙ документации, количества
тестовых сценариев, количества дефектов, среднеrо времени работы до отказа
и Iножества друrих веЛИЧIIН.
Вычисление плановых показателей и интеrрация с проrpаммами планирова-
ния. Некоторые оценочные проrpаIМЫ позволяют задавать объемы работ на по
становку требоваНlfЙ, проектирование, конструирование, тестирование и отладку,
а также делить проект на нужное количество итераций. Подобные вычисления
краЙне УТОl\Iительно производить вручную, но при наличии должноrо инстру
ментария они выполняются леrко. Некоторые проrраммы также интеrрируются
с Мiсrоsоft Project и друrими системами планирования проектов.
Анализ что--если.. Оценочные проrраммы дают возможность быстро CKOp
ректировать оценочные предположения и увидеть, к каким последствиям это
приведет. НеоБХОДИ?\.fые вычисления на компьютере ВЫПОЛНЯIОТСЯ MrHoBeHHo,
тоrда как их выполнение вручную занимает слишком MHoro времени и подвер
жено ошибкам.
Арбитраж нереалистичных ожиданий. Допустим, ваш начальник настаивает,
что проект должен быть завершен за 50 человекомесяцев и 11 календарных меся
цев; вы создали оценку, показанную на рис. 14.3. Светлый прямоуrольник в левом
нижнем уrлу показывает оrраничения, установленные начальником. Точечная
диаrрамма из 1000 смоделированных результатов показывает, что только 8 из
1000 результатов проекта попали в заданную область. Диаrрамма становится
весьма наrлядным apryMeHToM против попыток завршить проект в рамках этих
оrpаничений!
Объективное авторитетное суждение при пересмотре предположений. CTaH
дартная, хотя и нездоровая ситуация в области оценки проrpаммноrо проекта: одна
из ключевых фиryр проекта oTBepraeT исходную оценку, потому что она кажется
слишком большой. Из проекта предлаrается исключить несколько второстепен
ных функций, что якобы должно привести к непропорциональному сокращению
стоимости и сроков. Друrая вариация на ту же тему  небольшое увеличение
численности rpуппы и надежды на существенное сокращение срока.
Оценочная проrрамма может выступить в роли беспристрастноrо арбитра
в оценке эффекта таких изменений. Без оценочной проrраммы вам придется объ
яснять начальству, что урезание функциональности не обеспечит нужноrо из
менения в стоимости и сроках. С проrраммой вы просто встаете на одну сторону
с начальником и сваливаете все неприятное на проrрамму: это она указывает на
то, что предложенные изменения не дадут желаемоrо эффекта.
На рис. 14.4 показан пример вычисленноrо соотношения между объемом pa
бот и сроками проекта, то есть экономия в объеме работ при возможности про
дления сроков. Возможно, вам будет проще убедить начальника в своей правоте,
если npOlpa.ммa скажет, что сокращение срока на один месяц достиrается увели
чением объема работ с 20 до 26 человекомесяцев.
Лоrическая проверка оценок, полученных неформальными методами. Луч--
шие оценщики при меняют несколько методов оценки, а затем анализируют

14.1. Для чеrо необходимы оценочные nporpaMMbI 167
тенденции к схождению или расхождению между полученными результатами.
Оценка, созданная с помощью коммерческой проrраммы, может стать одним из
таких результатов.
250
225
200
175
Объем 150
работ 125
(человека..
месяцы)
100.
75
50
25
I
I
.
I
I ..
r "
...
I
I
I _ . а 
_(>"  " :10.. >с
I (> .,. iIO
.' .."
I '" :10
" J">c"'''
:10.", м".о'" If
,. J( с l.,r ..
"м ,t м" t 4<" '"
r"""""",, ....................................................
r " .. iIII l' ".. "''' t JC iIO "
I ,, .JC." С х. '"
r " ..1'  1.. х)А
I t<- " ,!. 1..  ..
I ".."" )<  ..<о.. .. I
I '" '" "," 1.
I А """" "'i' ..,,'" . I
I " '*'" ," "" I 11
I :10". 1( '" .o  I
1.0 "ь.)C". /'" "'. " I
I '" ... ".. ",,":10 1 у
с I 000. .е" ",С  "А. "'" :
 >/'.  "ОР 'f t Jl!" .о · I
..   .,. "  I
:10" 6 "" "".V' I С
  :t;.  ...... ,.,."'" -:::   .... ........  .. .. ....  ..  ..  ...... ..   .. .. ........ ..  ..
Xc,'t. . J< ...о... . .с' 1
.... 'L. <:...... 1
..;. . 't: III. .. ""," " 1
"'" "M..... "1: х ",. :
I .
I I
1 I
1, I ,
I
с -
:10 l'
.- V "
.
" ..
:J> ..
"
· JI
"
.
"
"
:10 101:
о
10
,
I
,
I
,
I
12
4
16
18
20
22
24
26
28
за
32
Срок (месяцы)
Рис. 14.3. В этой модели только 8 из 1000 результатов удовлетворяют желаемым
оrpаничениям на стоимость и сроки
за
8
25 8
8
Объем 8[]
работ 20
(человека.. 8
месяцы)
8
15 8
8
8
8
8
10
11 12 13 14
Срок (месяцы)
Рис. 14.4. Вычисленный эффект от сокращения или увеличения срока
Оценка крупных проектов Чем крупнее оuениваемый проект, тем в MeHЬ
шей степени он может оцениваться исключительно неформальными методами.

168 rлава 14 · Оценочные nporpaMMbI
в крупном проекте оценочная проrpамма должна предоставить по крайней мере
одну из задействованных оценок.
СОВЕТ NQ 64
Используйте оценочные nporpaMMbI для лоrической проверки оценок, созданных ручными MeTO
дами. Оценки крупных проектов должны в большей степени опираться на коммерческие oцe
ночные nporpaMMbI.
14.2. Данные, необходимые
для калибровки nporpaMM
Калибровка оценочных проrрамм для использования исторических данных не
требует больших объемов информации. Если у вас имеются данные по одному
или нескольким завершенным проектам (объем работ в человекомесяцах, сроки
в месяцах, размер в строках кода), вы можете откалибровать некоторые из Moдe
лей (в том числе Construx Estimate), чтобы проrрамма использовала ваши исто
рические данные вместо среднеотраслевых. Исторические данные даже одноrо
проекта  лучше, чем ничеrо, но в идеале желательно располаrать исторически
ми данными по трем и более проектам.
Высокая цена более дороrих проrpамм (см. раздел 14.4) обычно оправдывает
ся БОЛЬШИl"IИ базами данных результатов историчесн:их проектов. Но если у вас
имеются исторические данные по трем прошлым проектам, оценка, построенная
по собственным данным, обычно будет точнее оценки, созданной на основе обоб
щенных данных проrраммы. Некоторые из дороrих проrрамм стоят своих денеr,
но не за большие базы данных с исторической информацией.
14.3. Оrраничеl-;lИЯ оценочных nporpaMM
Тот факт, что оценка была получена при помощи проrраммы, еще не означает,
что она является точной. Причины MOryT быть разными: неверные предположе
ния, калибровка оценки по непододящим или дефектным данным, внесение CMe
щения при помощи реrуляторов. А может выясниться, что базовая методолоrия
оценки была выбрана неудачно.
СОВЕТ NQ 65
Не относитесь к результатам оценочной nporpaMMbI как к божественному откровению. Прове
ряйте их на соответствие здравому смыслу точно так же, как любую друryю оценку.
14.4. Основные оценочные nporpaMMbI
Существует множество оценочных проrpамм. Разброс цен очень широк, от бесплат
Horo распространения до $20 000 за rодовую лицензию на одно рабочее место.
Далее представлены некоторые из наиболее популярных проrpамм.

Дополнительные ресурсы 169
Angel, http://dec.bournemouth.ac.uk/ESERG/ANGEL/. Analogy Softfare Tool  инте
ресная проrpамма с возможностью оценки будущих проектоп по аналоrии с про
шлыми проектами.
Construx Estimate, www.construx.com/estimate. Бесплатная проrрамма, которая
использовалась для создания диаrрамм, представленных в этой rлаве. Основная
методолоrия оценки основана на модели Путнэма (Putnam and Myers 1992). Часть
функциональности базируется на модели Сосоmо 11. Я работал старшим проrра!\f
мистом при создании первых двух версий этоЙ проrраммы.
Сосото 11, http://sunset.usc.edu/research/COCOMOll/. Некоторые проrраММIIые pea
лизации Сосоrnо 11 можно наЙти вИнтернете, проведя поиск по строке Сосото [[.
Официальные версии находятся на сайте IОжнокалифорнийскоrо университета
и распространяются бесплатно.
Costar, www.softstarsystems.com. Costar  недороrая полноценная реализация
Cocolno 11, предлаrаемая компаниеЙ Softstar Systerns.
KnowledgePLAN, www.spr.com. Проrрамма разработана и продается в Software
Productivity Research (компания Кейпера Джонса). Отличается высокой степе
ныо интеrрации с Мiсrоsоft Project.
PriceS, www.pricesystems.com. Исходная версия PriceS была разработана в RCA.
Сейчас проrрамма представляет собоЙ пакет проrраммных продуктов, предназна
ченных для оценки проектов.
SEER, www.galorath.com. Как и PriceS, SEER состоит из нескольких взаимосвязан
ных продуктов. SEERSEM предназначается для оценки, планирования и управ
ления; SEERSSM  для уrлубленной оценки размеров проrраммных проектов,
а SEERAccuScope  для простой оценки размеров.
SLIMEstimate и Estimate Express, www.qsm.com. СеlVlейство проrраммных продук
тов от Quantative Software Managernent состоит из SLIMEstirnate, полноФунк
циональной и мощной оценочноЙ проrраммы, и Estirnate Express  обладаIощеЙ
меньшими возможностями, но все равно мощной. Обе nporpaMMbI баЗИРУIОТСЯ на
модели оценки Путнэма. Компания QSM была основана Лоренсом ПУТНЭfОМ.
Дополнительные ресурсы
За дополнительными и обновленными ссылками на оценочные проrраммы обра
щайтесь на моЙ сайт www.construx.com/estimate/.

Использование
альтернативных
оценок
Область применения методов этой rлавы
Что оценивается
Размер проекта
Стадия разработки
Итеративный или последовательный стиль
Возможная точность
Альтернативные оценки
Размер, объем ррбот, сроки, функциональность
МСБ
Ранняяпоздняя
Оба
Высокая
Идеальноrо 1eToдa опенки не сущестпует, поэтому применение нескольких альтер
нативных методоп приносит пользу во мноrих ситуациях. Производители самых
сложных коммерческих прЬrраммных продуктов обычно используют три разных
метода оценки, а затем анализируют тенденции между полученными оценками.
Схождение оценок указывает на то, что оценки, вероятно, достаточно хороши.
Расхождение означает, что какието факторы были упущены и в проблеме следует
разобраться получше. Методика альтернативных оценок в равной степени OTHO
сится к oцeHKa1 размера, объема работ, сроков и функциональности.
Я впервые столкнулся с этой концепцией при создании оценки для первоrо из
дания своей книrи Code Cornplete (McConneIl1993). Около двух лет было по
трачено на сбор материала для книrи, написание прототипов rлав и прочую подrо
топку. В эти дпа [ода мне казалось, что книrа будет занимать от 250 до 300 страниц.
Идея не была подкреплена никакими аналитическими выкладками  просто пред
ставления, засевшие у меня в rолове.
До этоrо я ни разу не публиковал книrи и поэтому решил, что предложение
издательству должно убедительно показать, что книrа действительно будет закон
чена. Коrда подrотовка предложения подходила к концу, я создал свою первую
оценку методом декомпозиции. Я перебрал все пункты примерной структуры

I
I
Использование альтернативных оценок 171
книrи в плане и оценил каЖДУIО секцию по отдельности. В табл. 15.1 показан при
мерный вид полученных данных.
Таблица 15.1. Оценки количества страниц в черновом варианте «Code Complete»,
полученные субъективным суждением и методом декомпозиции
rлава
Оценка N2 1. Исходная
оценка «по интуиции»
Оценка N2 2. Экспертная
оценка с декомпозицией
4
5
11
52
Предисловие
Введение
Модели
Предварительные условия
Послесловие
Обзор тем
итоrо
250ЗОО
20
20
802
Фактически до этоrо lloMeHTa я использовал два метода оценки: собственную
интуицию, подсказывавшую диапазон от 250 до 300 страниц, и экспертную oцeH
КУ с декомпозицией, которая вела к оценке в 802 страницы. Между двумя oцeHKa
ми существовало значительное расхождение, и я должен был понять, почему они
так сильно отличаются.
Я был привязан к своим 250страничным представлениям о длине книrи и по
думал: «Оценка в 802 страницы не может быть правильной. Наверняка я rдето
ошибся. Я решил оценить книry еще раз и получить правильныЙ ответ.
Для третьей оценки было взято количество страниц в каждой из прототипов
rлав. Я разделил количество страниц на количество пунктов в примерной CTPYK
туре книrи. Получилось, что один пункт примерноЙ структуры соответствует
1,64 страницы. Далее я перебрал все пункты примерноЙ структуры всей книrи,
просуммировал пункты и УlНОЖИЛ сумму на 1,64. В табл. 15.2 показана оценка,
полученная этим способом.
Таблица 15.2. Оценка количества страниц в черновом варианте «Code Complete»
с использованием при мерной структуры и исторических данных
rлава
Оценка N2 1.
Исходная оценка
«по интуиции»
Оценка N2 2.
Экспертная оценка
с декомпозицией
4
5
11
52
Оценка N2 з.
Примерная структура
и исторические данные
4
5
11
52
Предисловие
Введение
Модели
Предварительные
условия
Послесловие
Обзор тем
итоrо
250ЗОО
20
20
802
16
21
759

172 rлава 15 · Использование альтернативных оценок
Третья оценка в 759 страниц l\leHee чем на 5 % отличалась от второй оценки
(802 страницы). Изза близости оценок я четко уяснил, что моя книrа займет
не 250300 страниц, как думал в течение двух лет, а от 750 до 800 страниц.
Moi:i опыт был типичным проявлением более общеrо принципа: объединение
результатов, полученных разными оценщиками (или с применением разных
методов), повышает точность оценки (J0rgensen 2002, Tockey 2004).
СОВЕТ NQ бб
Используйте несколько альтернативных методов оценки и проанализируйте совпадения или
расхождения результатов.
Между моей оценкой книrи и проrраммными проектами можно провести пря
MYIO аналоrllЮ. НаШIl представления о возможнь'IХ затратах, сроках и функцио
нальности проектов не строятся ни на какой конкретной основе. ЛIОДИ склонны
придерживаться cBoero предвзятоrо мнения, пока ктонибудь не представит им
достаточно данных, чтобы поколебать это предубеждение. Без дополнительных
данIIыIx я бы не поверил, что l\loii проект окажется в три раза больше, чем я пред
ставлял. Но даже после получения некоторой информации мне все равно потре
бовались новые данные, которые убедили меня окончательно.
Есть и друrая параллель с проrраммным обеспечением: плохие новости лучше
узнавать раньше, че?\'1 позже. Я изменил свои ожидания относительно раЗl\lера
проекта на стадии составления предложения. Вообще rоворя, на этом можно бы
ло остановиться, однако я проанализировал объем проекта и решил, что за Hero
все равно стоит взяться,  оценка дала мне более реалистичное представление
о плаllируеrvlЫХ сроках и обязательствах, которые я J-ta себя ПрИНИl\lал.
Тот факт, что два совершенно разных метода дали сходные оценки, укрепил
lVI0IO уверенность в точности оценок. Обязательно применяйте в проrраммных
проектах различные виды оценочных методов для создания разных оценок. Ha
пример, воспользуЙтесь опосредоваННЫl\1 методом, экспертной оценкой, оценкой
по аналоrии и какойнибудь оценочной проrраммой.
I(aK только я принял схождение моих оценок, внезапно стало очевидно, что
этот раЗl\lер подтверждается и друrими данными. одна из моих rлавпрототи
поп занимала 72 страницы. В 250страничной книrе это составило бы 29 % об
щеrо объема. Тем не менее после завершения этой rлавы у меня и в мыслях не
было, что проект rOToB на 29 %. На интуитивном уровне я знал, что r.лава co
ставляет не более 10 % кнпrи. Коrда две сходящиеся оценки открыли мне rлаза,
я понял, что длина прототипа подтверждает общую длину книrи в диапазоне
750800 страниц.
Наиболее точная оценка обычно формируется по даННЫ?\1, специфическим для
KOHKpeTHoro проекта. В итоrе у меня получилась рукопись из 749 страниц; ее объ
ем Bcero на 10 страниц (1 %) отличался от оценки, полученной с использованием
исторических данных Toro же проекта.
Исходная интуитивная оценка была основана на чтении друrих книr из диапа
зона 250300 страниц. До этоrо я книr не писал и поэтому наивно предположил,
что если написать 250300 страниц текста, то получится книrа из 250300 CTpa
ниц. Однако количество страниц в издаваемой книrе увеличивается изза пустых

Использование альтернативных оценок 173
страниц lежду I'лавами, пустых страниц между частями книrи, содержания, спи
ска иллюстраций, алфавитноrо указателя и прочих служебных данных. Кроме
Toro, объем книrи зависит от выбора шрифта, размера полеЙ, межстрочных ин
тервалов и т. д. Все эти обстоятельства вполне очевидны, если вы о них знаете,
однако неОПЫТНО1\-IУ автору вроде меня леrко забыть о них в своеЙ оценке. Даже
в своей декомпозиционной оценке я допустил классическую ошибку: я тщатель
но оценил стороны проекта, хорошо мне известные, но забыл учесть некоторые
важные состаВЛЯIощие проекта.
Наконец, две оценки сошлись в диапазоне 5 %. Тоrда я еlце этоrо не знал, но
такое значение является хорошим показателем сходимости вообще (в широкоЙ
части конуса неопределенности обычно приходится довольствоваться большим
расхождением ).
СОВЕТ NQ 67
Если разные методы оценки приводят к разным результатам, попытайтесь выявить факторы,
изза которых возникают различия. Продолжайте оценивать проект заново до тех пор, пока
результаты, полученные разными методами, не будут расходиться в пределах 5 О/о.
Позднее lVlеня попросили провести оценку проrраl\fмноrо проекта для ОДНОI'О
из моих клиентов. На рис. 15.1 крестиками отмечены отдельные оценки, co
зданные lVIНОЙ для этоrо проекта. Размер крестика представляет r-.10Ю уверенность
в каждой оценке. Треуrольником обозначена «самая точная оценка» в 75 чело
векомесяцев 11 12 календарных lVlесяцев. Хотя в расположении крестиков суще
ствует некоторыЙ разброс, все оценки, в которых я был уверен, отличалпсь от
«самоЙ точной оценки» в пределах 5 %. Квадрат изображает деЛОВУIО цель MoeI'o
клиента  25 человекомесяцев при 5 календарных месяцах.
Объем
работ
(человеко
месяцы)
75

+ Отдельные оценки
. Самая точная оценка
  . Деловая цель -
+ :-
.:r! 
: :
Тl
+
::
-
..
150
125
100
50
25
о
о
2
4
6
8
10
12
14
16
Срок (месяцы)
Рис. 15.1. Пример альтернативных оценок в nporpaMMHoM проекте

174 rлава 15 · Использование альтернативных оценок
в этом конкретном случае клиент решил действовать, руководствуясь дело
вой целью в 5 календарных месяцев и 25 человекомесяцев. Решение оказалось
неудачным. В конечном счете проект был выдан через 14 календарных месяцев
при 80 человекомесяцах работы, причем rруппа реализовала rораздо меньше
функциональности, чем планировалось первоначально.
СОВЕТ NQ 68
Если деловая цель противоречит нескольким сходящимся оценкам, лучше доверьтесь оценкам.
Дополнительные ресурсы
Tockey, Steve. «Return оп Software. МА: AddisonWesley, 2005. Б rлаве 22 книrи
Токи обсуждаIОТСЯ оценки с применением альтернативных методов. [лава 23
посвящена учету неточности в оценках, а rлавы 2425  особенностям принятия
решений в условиях риска инеопределенности (J0rgensen 2002).

Формирование
оценок в правильно
оцениваемых
проектах
Область применения методов этой rлавы
Переход к более точной оценке
на более поздней стадии проекта
Размер,объем работ,сроки,
функцональность
СБ
Размер проекта
Стадия разработки
Итеративный или
последовательный стиль
Возможная точность
Ранняяпоздняя
Последовательный
Уточнение оценки
по данным проекта
Размер, объем работ,
сроки, функциональность
МСБ
Ранняяпоздняя
Оба
Что оценивается
Высокая
Высокая
В проектах снекачественной оцепкоi"'I процесс направлен на прямое проrнозиро
вание затрат, объеlа работ и сроков; при этом размер проrраммноrо обеспечения
практически иrнорируется. Проект подверrается l\fноrократной оценке, но обыч
но в ответ на нарушения rрафика на поздней стадии проекта.
Проекты с качественной оценкой отличаются направленностью оценки и точка
1\IИ переоценки. Настоящая rлава посвящена процедуре уточнения оценок в пра
вильно оцениваемом проекте. В частности, она входит в процесс выработки CTaH
дартизированной проuедуры оценки, описанный в rлаве 17.
16.1. Формирование оценки внеправильно
оцениваемом проекте
Процесс создания оценки в неправильно оцениваемых проектах показан на рис. 16.1.
Входные данные, процесс оцени и выходные данные не имеют четкоrо определе
ния, хотя и остаются открытыми для оспаривания и изучения. Изучение процесса

176 rлава 16 · Формирование оценок в правильно оцениваемых проектах
оценки сыrрало бы положительную роль, если бы оно было направлено на по
лучение более точных результатов. Но как правило, целью J1зучения является
уменьшение оценки. Иначе rоворя, изучение давит на оценку сверху, и это давле
ние не уравновешивается соответствующим давлением снизу.
Выходные данные.
определенные
для этой конкретной
оценки
Нестандартный
процесс
оценки
Выходные
данные
Рис. 16.1. Процесс создания оценки в неправильно оцениваемых проектах. Ни входные
данные, ни процесс не имеют четкоrо определения
СОВЕТ NQ 69
Не оспаривайте результаты оценки, а принимайте их как данность. Изменение результата может
производиться только одним способом: изменением входных данных и повторным вычислением.
16.2. Формирование оценки в правильно
оцениваемом проекте
Если входные данные и процесс четко определены, произвольное изменение BЫ
Бода не рационально. Возможно, лицам, ответственным за принятие решений, pe
зультат оценки не понравится, но правильным действием по ero корректировке
должна быть реrулировка входных данных (например, сокращение объема проек
та) II пересчет результатов, а не подмена результата.
На рис. 16.2 показан процесс создания оценки в правильно оuениваемом проекте.
Техническая
спецификация
Приоритеты
Стандартная
процедура
оценки
Оценка объема работы
Оценка срока
Оrраничения
Оценка затрат
Оценка
фуинси
Исторические данные
Рис. 16.2. Процесс создания оценки в правильно оцениваемых проектах. Входные данные
и процесс четко определены. Процесс и результаты не оспариваются; тем не менее
входные данные MOryт подверrаться итеративным изменениям вплоть
до получения приемлемоrо вывода
в правильно оцениваемом проекте входные данные включают техническую
спецификацию, приоритеты и оrраничения. Эти входные данные реryлируются

16.3. Хронолоrическая последовательноcrь формирования оценки 177
до тех пор, пока процесс оценки не даст приемлемый результат. Исторические
данные также относятся к входным данным оценки и используются для калибровки
предположений о производительности. Они расположены отдельно в нижней части
диаrраммы, потому что исторические данные не должны реrулироваться в KOH
тексте конкретной оценки (и особенно для ее подrонки под нужньп':'r результат).
Сама процедура оценки стандартизирована. Друrими словами, эта процедура
определяется заранее, еще до Toro, как возникнет надобность в создании KOHKpeT
ной оценки. Блаrодаря стандартизации она не реryлируется на уровне отдельных
оценок (как и в предыдущем случае, особенно для подrонки под нужный резуль
тат). Некоторые стандартизированные процедуры оценки описаны в rлаве 17.
Выходные данные, то есть оценки объема работ, сроков, СТОИ1\-10СТИ и (pYHK
циональности, создаются следованием четко определенному процессу, исполь
зующему четко определенные входные данные. В правильно оценивае1\10М проек
те результаты в принципе не MOryT оспариваться.
В этом контексте особенно полезны четкие различия ме)кду оценками, целями
и обязательствами. Даже если оценка отлична от желаемой, у руководства проекта
MoryT найтись достаточно убедительные причины для выбора цели, более arpec
СИЕНОЙ по сравнению с оценкой. Тем не менее сама оценка от этоrо не изменится.
Единственным фактором в процедуре оценки, который коrдалибо ПрlIХОДИТ
ся оценивать в традиционном смысле (то есть посреДСТЕО1\1 суждения), является
размер. Субъективное суждение применяется для оценки размера только на очень
ранней стадии проекта, до появления требований, пользовательских историЙ,
сценариев тестирования или друrих счетных показателей. ОбъеI работы выIIlс
ляется по оценке размера с использованием исторических данных ПРОllзводитель
насти. Сроки, затраты и функциональность вычисляются на основании оценки
объема. Общая схема показана на рис. 16.3.
..f:.J Сроки
",,##"" .
Ni/'.'
Размер 1OmOC Объем работ ;.,'x.тx,«-:.:.;.:> Стоимость
. '"
,
...
, Функциональность
Рис. 16.3. Лоrика создания единой оценки в правильно оцениваемом проекте. Объем
работ, срок, стоимость и функциональность определяются по оценке размера
СОВЕТ NQ 70
Сначала сконцентрируйтесь на оценке размера. Затем вычислите объем работ, сроки, стоимость
и функциональность по оценке размера.
16.3. Хронолоrическая последовательность
формирования оценки для Bcero проекта
Изза присутствия конуса неопределенности мноrие проекты полезно пере
оценивать по несколько раз: Оценка, созданная на поздней стадии проекта,
может оказаться более точной, чем ранние оценки. Повторная оценка проекта

178 rлава 16 · Формирование оценок в правильно оцениваемых проектах
с улучшением точности также помоrает уточнить планы и порядок управления
проектом.
СОВЕТ NQ 71
Проводите повторную оценку.
Повторная оценка не сводится к ПрОСТОJ\.IУ повторению процедуры оценки.
В ней должны быть задействованы более точные методы, которые становятся
доступными по мере продвижения проекта. На рис. 16.4 приведена сводка lIаибо
лее полезных методов оценки для разных стадий типичных проектов.
) /
 ,t
;if 
J  ,.:,:
$ J J
,! 1  Iq} 
$'д! l  1;
ф< t:: W'., i 
8 б,' '. 0 @
 1.8 . ...;J  
1 I/ . b l? :yff /
9: R-  " l   R-
 .,'   
rh' S   .:, бt  (j
(J ;f


o O gj
"!оо: .;с
 ttr "'
A""
  tJ;t" О ;t :)} ,. :' () qj
0;!:  @ о 'I' {.J..  9J
J.;;. rri  ," " .. о
9j P; р; р; 1.1  р;
 r8 i flj i rf ,0 .:' ' , . 0  i
3 "Ф 3-" 3- 3- .lJ. J} 03-1 3-
Тип метода Q: r:8  о ' .' о  r.8
Qi . .', '.',' <С."
Вычисление . . . . . .
.. . , , , :
Подсчет О . . q о .
... . ,
, .
Исторические данные орraнизации . . о
>
Исторические данные .. .. , .. .
ПО тому же проекту . .
, . " .
Декомпозиция О . . . .. .
... . .. .
, , ..
Аналоrия . . о .
..
Опосредованная оценка . . . о Q , . о
, ,
Сложные алrоритмы . . о :0'" . . о
, ..
Оценочные проrраммы .. . , , .'
. . о ,О : О
Экспертная оценка О О . О . . о
, . .. ,
Оценка опытным специалистом . . о : О
:
Оценка со стороны участников О . .
Восходящая оценка уровня задач . . о'
rРУППО8ые обсуждения . . о
о
.
. Основной
метод
О Вторичный
метод
Рис. 16.4. Сводка применимости различных методов оценки в зависимости
от типа и фазы проекта

16.4. Уточнение оценок 179
Формирование оценки в крупных проектах
На очень раннеЙ стадии КРУПIIоrо проекта счетные показатели MOryT оказаться
недоступными, и Bal\1 придется прибеrнуть к алrОРИТlам, оценочным проrpаммам
и друrим makpOl\-lетодам. Далее эти ранние оценки улучшаются на rрупповых
обсуждениях и с применением альтернативных l\1етодов.
При переходе к более поздним стадиям крупноrо проекта следует перехо
дить к более точным, основанным на исторических данных счетным методам,
и ориентироваться на микрометоды, обеспечивающие более BbICOKYIO точность
(SYInons 1991).
СОВЕТ NQ 72
Переходите от неточных оценок к более точным по мере продвижения работы над проектом.
Формирование оценки в мелких проектах
Мелкие проекты с caMoro начала оцениваются по тем же принципам, по которым
крупные проекты оцениваются в самом конце. Как только вы поближе познако
митесь с людьми, которым предстоит работать над проектом, и начнете раздавать
задания, переходите от крупномодульных алrоритмических методов к восходя
щим методам, баЗИРУЮЩИlvIСЯ на индивидуальных оценках заданий работниками.
В мелких проектах это может происходить в первый день, а в крупном проекте 
через несколько месяцев после начала работы над проектом.
СОВЕТ NQ 73
Коrда проект будет rOToB к назначению индивидуальных заданий, переходите на восходящую
оценку.
16.4. Уточнение оценок
При нарушении контрольных точек в проектах возникает вопрос о перекалиб
ровке rpафика. Допустим, для завершения проекта был установлен 6месячный
срок. Вы намеревались достичь первой контрольной точки за 4 недели, но в дей
ствительности для этоrо потребовалось 6 недель. Как вы будете действовать
дальше?
· Понадеетесь скомпенсировать две потерянные недели позднее?
· Прибавите две недели к общему сроку?
· Умножите весь срок на величину ошибки (в данном случае на 50 %)?
На праl(:тике чаще Bcero встречается вариант N2 1. Обычно это обосновывают
так: «Требования заняли чуть больше времени, чем предполаrалось, но теперь
они стабильны, и это позволит нам сэкономить время позднее. Наверстаем при
проrраммировании и тестировании. Тем не менее анализ более 300 проектов
в 1991 rоду показал, что проекты практически никоrда не наверстывают упу
щенное время  чаще отставание лишь увеличивается (van Genuchten 1991).
Вариант NQ 1 почти никоrда не бывает лучшим.

180 rлава 16 · Формирование оценок в правильно оцениваемых проектах
Вариант NQ 2 предполаrает, что первый этап проекта занял на две недели боль
ше, чем следовало, но все оставшиеся этапы уложатся в изначально отведенные
сроки. «Ахиллесова пята» варианта NQ 2 заключается в том, что ошибки оценки
оБЫЧIIО обусловлены системныI\пII причинами, распростраНЯIОIЦИf\'IИСЯ на весь
проект. Маловероятно, чтобы вся оценка оказалась точноЙ, а наРУlпение встрети
лось в тоЙ единственноЙ части, KOTOPYIO вы опробовали на практике. За редкими
IlСКЛlочеНИЯf\,fИ саf\-10Й праВIIЛЬНОЙ реакциеЙ на результаты, ОТКЛОНЯIОlциеся от
оцеНlIваеl\1ЫХ, является вариант NQ 3.
Конечно, I1Зf\,lенение оценки после нарушения контрольноЙ ТОЧКИ  не един
ственныЙ вариант. Также l\10ЖНО урезать часть функциональности, израсходовать
часть буфера риска cBoero проекта или BHecTII пеКОТОРУIО КОl\lбинацию реrули
ровок. Наконец, можно отложить решение и собрать дополнительные данные
по слеДУIОlllеЙ контрольноЙ точке. Но если II на слеДУIощеЙ контрольной точке
проект будет на 50 % отставать от срока, на корректировку останется меньше
вреf\,lени.
СОВЕТ NQ 74
Если оценка пересчитывается в результате нарушения промежуточных сроков, новая оценка
должна базироваться на фактическом ходе проекта, а не на запланированных показателях.
.
16.5. Представление измененной оценки
друrим ключевым сторонам проекта
В неправильно управляемых проектах оценщики часто поддаIОТСЯ давлеНИIО и BЫ
дают точечную оценку на ранней стадии проекта. Далее им приходится нести
ответственность за эту оценку на протяжении оставшеI';iся части проекта. Напри
l\lep, предположим, что в ходе проекта был получен набор оценок, перечисленных
в табл. 16.1.
Таблица 16.1. История изменения точечной оценки
Фаза проекта
Исходная концепция
Соrласованное определение продукта
Завершение требований
Завершение проектирования пользовательскоrо интерфейса
Первая промежуточная версия
итоrо
Оценка (человеко-месяцы)
10
10
13
14
16
17
При таком наборе оценок уже при первом возрастании оценки с 10 до 13 Me
сяцев клиент сочтет, что проект нарушил БIоджет и сроки. При каждой послеДУIО
щеЙ переоценке будет казаться, что дела идут все хуже. Но в действительности
проблема состояла в TOrvI, что первая оценка в 10 месяцев содержала выIокуюю
степень неточности и потребовала мноrократной переоценки. Вполне возможно,

16.5. Представление измененной оценки друrим ключевым сторонам проекта 181
окончательный показатель в 17 человекомесяцев стал результатом XOpOIlIO
реализованноrо проекта, но способ представления оценки создает иное впе
чатленис.
Сравните со сценарием, в котором диапазонные оценки сужаются по мере
продвижения проекта, как показано в табл. 16.2.
Таблица 16.2. История изменения диапазонной оце нки
Фаза проекта
Исходная концепция
Соrласованное определение продукта
Завершение требований
Завершение проектирования пользовательскоrо интерфейса
Первая промежуточная версия
итоrо
Оценка (человека-месяцы)
3---40
520
20
1218
1518
17
При пошаrовом уточнении оценки ваш клиент будет считать, что проект OCTa
ется в рамках предположений. BleCTO Toro чтобы терять доверие клиента при Ha
рушении одноrо срока за друrим, вы улучшаете свою репутацию, последователь
110 удовлетворяя ожиданиям клиента с сужением диапазонов.
Для применения диапазонов вместо точечных оценок СУlдествует еIде одна
причина: исследователи выяснили, что исходные оценки часто становятся оп()
рой» для будущих оценок, даже если они не были достаточно хорошо обоснованы
(Lim and Q'Connor 1996, ]ergensen 2002). Таким образом, одна неудачная точеч
ная оценка может испортить оценки для целоrо проекта. Использование диапа
зонных оценок вместо точечных помоrает избежать этоЙ проблемы.
СОВЕТ NQ 75
Предcrавляйте свои оценки в таком виде, чтобы они уточнялись по мере продвижения проекта.
Коrда представлять повторные оценки
Не существует единственно правильных моментов для составления повторнuii
оценки. Точность оценки непрерывно улучшается на протяжении жизненноrо
цикла проекта. Проекты обычно переоцениваются в основных контрольных точ
ках, после выпуска новых версий, а также при серьезном изменении основных
предположений проекта (например, при смене требований).
Сколько бы раз вы ни планировали повторную оценку, заранее сообщите свон
планы друrим сторонам, участвующим в проекте. Конус неопределенности OCBO
бождает вас от жестких обязательств на ранней стадии проекта, коrда вероят
ность их выполнения невелика. Тем не менее вы обязаны периодически ин
формировать друrие стороны по мере Toro, как ваши представления о проекте
становятся более четкими.
В табл. 16.3 приведен при.мер rрафика оценки, который можно опубликовать
для последовательноrо проекта.

182 rлава 16 · Формирование оценок в правильно оцениваемых проектах
После контрольной точки
Таблица 16.3. Примерный rрафик уточнения оценок для последовательноrо проекта
Исходная концепция
Точность оценки
(для оставшейся
части проекта)
75 О/о, +300 О/о
Соrласованное определение продукта
50 о/о, + 100 О/о
Завершение требований
и проектирования пользовательскоrо
интерфейса (UIDC)
20 О/о + 25 О/о
,
Первая промежyrочная версия
10 О/о + 10 О/о
,
Вторая промежyrочная версия
 10 о/о, + 10 О/о
Третья промежуточная версия t
10 о/о, +10 О/о
Промежуточные версии 4---Х
 10 о/о, + 10 О/о
Завершение кода
5 о/о, +5 О/о
Комментарии
Только для BHyтpeHHero
пользования; не публикуется
за пределами rpYnnbI разработки
Исследовательская оценка.
Используется только внутри
компании и не публикуется
за ее пределами
Оценка бюджета. Допускается
публикация верхней rраницы
диапазона. Нижняя rраница
и средняя точка не публикуются
Предварительная оценка,
отреryлированная по данным
проекта. Не подлежит внешней
публикации; это Bcero лишь
информация к размышлению.
Становится доступной
приблизительно в UIDC+45 дней
Предварительная оценка
для принятия обязательств.
Допускается внешняя публикация
верхней rраницы диапазона.
Нижняя rраница не публикуется
Окончательная оценка
для принятия обязательств.
Допускается внешняя
публикация средней точки
Оценки обновляются только
при одобрении новых требований
Комитетом по изменениям
Тоже
Б зависимости от потребностеЙ сторон, задействованных в проекте, оценки
иноrда приходится предоставлять чаще или реже, че?\1 ноказано в таблице. OTpe
rулируйте детали, чтобы они соответствовали специфике вашеЙ среды. [лава 17
U u
развивает этот пример и предлаrает дополнительныи метод, хорошо подходящии
для итеративных проектов.
СОВЕТ NQ 76
Сообщайте о своих планах nOBTopHoro проведения оценки заранее.
Что делать, если начальство запрещает переоценку?
Ваше начальстпо деЙствительно не разрешает проводить повторную оценку?
Сомневаюсь. Оно fожет запретить изменять обязательства, но это совсем не

16.6. Критерии правильной оценки проекта 183
то же самое. Всеrда планируйте периодический пересмотр оценок, хотя бы для
собстпенных целей BHYTpeHHero планирования и упрапления проектами, незави
симо от Toro, примет ли начальство или клиент ero результаты.
Во мноrих орrанизациях пересмотр оценок планируется заранее. Эта тема
более подробно обсуждается n разделе 17.2.
16.6. Критерии правильной оценки проекта
Во время работы над проектом трудно сказать, насколько хороши ваши oцeH
ки. Точность оценок становится очевидноЙ только в ретроспективе. Te1 не менее
в ретроспективе можно отличить правильно оцениваемый проект от непра
вильноrо.
После Toro как проект будет заnершеl:l, проанализируйте ИСТОРИIО оценок и оп
ределите, удалось ли спроrнозировать конечныЙ итоr. На рис. 16.5 показан
ПРИl\1ер правильно оцениваемоrо проекта.
Объем
1 . I I
."  '" ". " 1 . :':':"' »>:''''<,<<<''''':'>C'':':':<<""":"<,:,.:::.,<,,,,,,:,x,'\О»"'.:.,...,.........-»:<...х.»"':.х.:.:.:.:.:.:."'<.>ж.>:"'.><.'<i':<.х.
.:.:." ВЫХОД
..... . Завершение Завершение окончательной
"::,, Завершение Завершение второй третьей версии
основной первой внутренней внутренней
архитектуры внутренней версии версии
Завершение версии
требований
Начало
проекта
Время
Рис. 16.5. Правильно оцениваемый проект. Точечные оценки не попадают в цель,
но все диапазоны включают конечный итоr
ВеРТИI(альные полосы на рисунке предстаВЛЯIОТ диапазоны оценок. Светлые
точки представляют точечные оценки ожидае!\1ЫХ случаев, а однородная синяя
точка  фактический рез"ультат проекта. В этом проекте точечные оценки до
caMoro конца проекта отличались от фактическоrо результата. Tel\f не менее
каждый из диапазонов, представленных в проекте, включал итоrовый результат,
поэтоrvlУ я считаю, что этот проект оценивался правильно.
На рис. 16.6 изображен пример систематически недооцениваеl\10rо проекта.

184 rлава 16 · Формирование оценок в правильно оцениваемых проектах
J:-
Объем
I I окон::ьной
Завершение версии
Завершение третьей
Завершение ВТОРОЙ.. внутренней
первой внутреннеи версии
Завершение .. версии
основной внутреннеи
архитектуры версии
I ..
.....
Начало Завершение
проекта требований
Время
Рис. 16.6. Неправильно оцениваемый проект. Оценка хронически занижалась, а диапазоны
оценок были слишком узкими и часто не включали, фактический результат
в сущности, этот проект пал жертвоЙ проблемы, обсуждавшеЙся в rлаве 2,
коrда fvlbI rоворили о нереалистично узких диапазонах и 90 % достоверности».
В IIpoeKTe использовались диапазоны (и это хорошо), однако диапазоны были
СЛИШl(О'1 узкими И не включали фактический результат проекта, а это уже плохо.

Стандартизированны
процедуры оценки
Область применения методов этой rлавы
.
Размер проекта
Стадия разработки
Итеративный или
последовательный стиль
Возможная точность
СТандартизированная
процедура оценки
Размер, объем работ, сроки,
функциональность
МСБ
Проверка эффективности
процедуры оценки
Размер,объем работ,сроки,
функциональность
МСБ
Что оценивается
Ранняяпоздняя
Оба
Ранняяпоздняя
Оба
Высокая
Высокая
Стандартизированная процедура оценки представляет собой четко определен
ный процесс создания оценок, принятый на уровне орrанизации и устанаВЛII
ваIОЩИЙ правила на уровне отдельных проектов. Стандартизация защищает от
типичных ошибок  таких, как «оценка наобум» и доrадки. Она защищает от
произвольноrо изменения оценок только изза Toro, что влиятельному участнику
проекта не понравился конкретный результат. Она способствует лоrическому
единству процесса оценки. Наконец, в случае особенно неудачной оценки CTaH
дартизация позволяет проанализировать свои действия и усовершенствовать
процедуру оценки со временем.
Стандартизированные процедуры1 в равной степени полезны в любых проек
тах  в крупных и мелких, в итеративных и последовательных, однако специфи
ка изменяется в зависимости от типа проекта.

186 rлава 17 · а-андартизированные процедуры оценки
17.1. Типичные элементы
v
стандартизированнои процедуры
в соответствии с описанием типичной последовательности формирования oцeH
ки, приведенным в rлаве 16, стандаРТIIзированная процедура оценки:
· по возможности базируется на подсчете и вычислениях, а не на субъектив
ных оценках;
· поощряет применение нескольких альтернативных оценок и сравнение pe
зультатов;
· подразумевает план переС1\10тра оценки в заранее определенных точках
проекта;
· определяет изменения метода оценки в ходе жизненноrо цикла проекта;
· содержит четкое описание неточности оценки;
· определяет, коrда оценка 1\10жет использоваться в качестве основы для
формирования бюджета проекта;
· определяет, коrда оценка может использоваться в качестве основы для
внутренних и внешних обязательств;
· требует архивации оценочных данных и анализа эффеI(ТИВНОСТИ процедуры.
Чтобы стандартизированная процедура оценки справлялась со своими зада
чаМII, очень важно, чтобы орrанизация рассматривала процедуру как стандарт.
Отклонения от процедуры должны объясняться в письмеННО1 виде, и такие слу
чаи должны быть редкими.
Сама процедура должна быть описана в документе CTaHдapTЫ разработ
ки проrраммноrо обеспечения или «Стандартизированная процедура оценки
и в дальнеЙшем подверrаться форrvlальному контролю изменений. В конце проек
та в процедуру MOryT вноситься изменения с целью повышения ее точности в бу
дущих проектах. Изменения Ha xoдy недопустимы  они слишком подвержены
смещениям, подрывающим как точность оценки в конкретном случае, так и эф
фективность процедуры в будущих проектах.
СОВЕТ NQ 77
Определите стандартизированную процедуру оценки на уровне орrанизации и применяйте ее
на уровне отдельных проектов.
17.2. Адаптация оценки для процесса
поэтапноrо контроля
Во мноrих крупных орrанизациях используется определенный жизненный цикл
разработки проrраммноrо обеспечения (SDLC, Software Developтent Life Cycle).
Такие жизненные циклы обычно являются частью процессов поэтапноrо KOHTpO
ля  процессов, определяющих жизненный цикл продуктов в виде нескольких

17.2. Адаптация оценки для процесса поэтапноrо контроля 187
этапов и «контрольных точек (Cooper 2001). К числу компаний, использую
щих процессы поэтапноrо контроля, относятся ЭМ, Agilent, Corning, Еххоп, GE,
Guinness, Hewlett Packard, Intel, Kodak, Proctor & Garnble и мноrие друrие.
На рис. 17.1 показан типичный процесс поэтапноrо контроля.
\ ta.    
Этап О 1 2 3 4 5
Анализ Тестирование
Обнаружение требований Планирование Разработка и проверка Запуск
I<онтрслt-,ная 1 2 3 4 5
ТОЧS<В
Рис. 17.1. Типичный процесс поэтапноrо контроля разработки прЬrраммноrо продукта
Процесс SDLC определяет операции по разработке проrраммноrо обеспече
ния, обычно выполняеI\Iые на каждом этапе. Кроме Toro, он определяет критерии
выхода, на основании которых проекту разрешается завершить один этап и пе
рейти к слеДУIощему (то есть сместиться к следующей контрольной точке). Спе
цифика процесса SD LC сильно зависит от орrанизации. В табл. 17.1 показано,
как SDLC координируется с ТИПИЧНЫ1 процессом поэтапноrо контроля, ориен
тироваННЫl\1 на проrраммный продукт.
Таблица 17.1. Типичный процесс поэтапноrо контроля, ориентированный
на проrраммный продукт (сокращенный вариант)
Этап
о. Обнаружение
1. Анализ
требований
2. Планирование
Основные операции
· Выявление рыночной
возможности
· Оценка технической
приемлемости на высоком
уровне
· Разработка предварительной
экономической модели
· Формирование концепции
продукта
· Разработка рыночных
требований
· Соrласование концепции
с потребителями
· Разработка подробных
требований
· Разработк подробных планов
· Разработка оценки бюджета
· Разработка окончательной
экономической модели
Контрольная
точка
Основной критерий
выхода
· Соrласование
предварительной
экономической
модели
1
2
· Соrласование
концепции продукта
· Соrласование
маркетинrовых
требований
3
· Соrласование
планов разработки
проrpаммноrо продукта
· Соrласование бюджета
· Соrласование
окончательной
экономической модели
продолжение 


188 rлава 17 · Стандартизированные процедуры оценки
Этап
Таблица 17.1 (продолжение)
Основные операции
З. Разработка
4. Тестирование
и контроль
rотовности
S. Запуск
· Основной жизненный цикл
разработки продукта
· Разработка маркетинrовоrо
и оперативноrо планов
· Разработка окончательноrо
плана тестирования
· Исполнение окончательноrо
плана тестирования
· Принятие решения о выпуске
· Исполнение плана
развертывания
· Проведение ретроспективноrо
анализа проекта
· Сбор мнения клиентов
и сообщений о дефектах
· Отслеживание экономических
результатов
Контрольная
точка
Основной критерий
выхода
· Соrласование плана
выпуска nporpaMMHoro
продукта
· Соrласование
маркетинrовоrо
и оперативноrо планов
· Соrласование плана
тестирования
nporpaMMHoro продукта
· Выполнение критериев
выпуска
4
5
с точки зрения оценки, поэтапный контроль создает некоторые проблемы, но
11 открывает ряд возrvl0жностеЙ. Проблемы обусловлены тем фактом, что мноrие
процессы поэтапноrо контроля изначально разрабатывались для оборудования,
потребительских или друrих продуктов, не имеющих отношения к проrраМfам.
Хотя основная структура таких процессов остается полезной, ее приходится
адаптировать к специфике проrраммноrо обеспечения, чтобы она работала с Ta
коЙ же эффективностью, как и при разработке друrих видов продуктов.
Одна из стандартных проблем заключается в том, что разработка часто пред
ставляется в виде одноrо этапа (этап 3 в табл. 17.1). Операции, выполняемые в про
цессе разработки, занимают от 75 до 90 % общеrо объема работы проrраммноrо
проекта, и в общеt\1 случае я бы предпочел видеть на этом этапе несколько проме
жуточных контрольных точек вместо одной точки, обозначаIощей конец этапа.
Это одна из ситуаций, в которых следует периодически пересматривать оценки
во время этапа. Тем самым обеспечивается эффективное планирование и управ
ление проектом независимо от Toro, как относится орrанизация к пересмотру
оценок на в середине этапа.
Вторая стандартная проблема: этапы анализа требований и планирования, опре
деленные в табл. 17.1, часто объединяются в один этап. Фактически это означает,
что контрольная точка 3 находится в фазе сужения конуса неопределенности до
+ 25 %, что может происходить коrда уrодно от 15 до 35 % календарноrо времени
проекта (эти процентные показатели более подробно рассматриваются в rлаве 21).
у частникам проекта, не связанным с технической стороной, часто приходится

r
I
I
I
I
I
17.3. Пример процедуры оценки для последовательных проектов 189
объяснять, какие операции по разработке проrраммноrо обеспечения должны
быть запеРIпены для получения осмысленноrо представления о «контрольноЙ
точке N2 3». Количество и rлубина таких операциЙ часто превышаIОТ ожидаНIIЯ.
Но коrда He технические» участники проекта получат представление о связи
lежду процеССО1 поэтапноrо контроля и жизненным ЦИКЛОI проrраrvПvIноrо про
дукта, процесс SDLC обеспечит i'.fОIЦНУЮ поддержку для стандартизированных
процедур оценки. Привязка диапазонов оценки к раЗЛИЧНЫl\l контрольныrvl точ
Ka1 выrЛЯДIIТ естественно и помоrает реrлаrvlентировать концепцию неопредс
лснности оценки.
В табл. 17.2 показан ПРИ!vIер соответствия rvlежду диапазонаrvIИ оцеНКII 11 про
цессаIИ SDLC.
Таблица 17.2. Типичное соответствие между контрольными точками SDLC и оценками
Контрольная Точность оценки (для оставшейся
точка SDLC части проекта)
1 75 О/о, +300 О/о
Использование оценки
4  1 О О/о, + 1 О О/о
Оценка общеrо представления.
Предназначена исключительно
для BHyтpeHHero использования;
не публикуется за пределами
rpYnnbI разработки
Исследовательская оценка.
Для BHyтpeHHero использования
в rраницах компании;
не публикуется за ее пределами
Бюджетная оценка. Допускается
внешняя публикация верхней
rраницы диапазона. Нижняя rраница
и среднее значение не публикуются
Оценка окончательных обязательств.
Допускается внешняя публикация
среднеrо значения
2 50 О/о, + 100 О/о
3 20 О/о, +25 О/о
СОВЕТ NQ 78
Координируйте стандартизированную процедуру оценки с процессом SDLC, принятым в вашей
орrанизации.
в двух слеДУIОЩИХ разделах представлены примеры стандартизированных про
цедур оценки. В разделе 17.3 описан пример процедуры, используемой в последова
тельных проектах, а в разделе 17.4  пример процедуры для итеративных проектов.
17.3. Пример стандартизированной процедуры
оценки для последовательных проектов
в табл. 17.3 приведен пример стандартизированной процедуры оценки, которая rvlO
жет применяться в последовательных проrраммных проектах. Процедура оценки
предполаrает, что rлавным приоритеТОl\l орrанизации является Функционапьность,

190 rлава 17 · Стандартизированные процедуры оценки
а основная цель оценки заключается в повышении точности оценок стоимости
и сроков.
Таблица 17.3. Пример стандартизированной процедуры оценки для последовательных
проектов  с упором на оценку стоимости и сроков
I. Исследовательская оценка (соrласованное определение продукта)
А. Создайте как минимум одну оценку, используя каждый из перечисленных методов.
1. Один оценщик применяет восходящий метод по структуре трудозатрат (WBS).
2. Один оценщик применяет метод стандартных компонентов.
З. Один оценщик применяет нисходящий метод и оценку по аналоrии с похожими прошлыми
проектами.
Б. Оценщики применяют широкополосный Дельфийский метод и вырабатывают точечную
номинальную оценку (N).
В. Оценки всеrда должны выдаваться в виде диапазонов O,5N2,ON (например, 50 О/о, + 100 О/о).
1. Точечная номинальная оценка, разработанная для использования в этих вычислениях,
не публикуется.
2. Полученные оценки e должны использоваться для формирования бюджета и внешних
обязательств, кроме соrласования бюджета с целью завершения стадии проектирования
продукта.
II. Бюджетная оценка (завершение проектирования продукта)
А. Создайте новые оценки, используя два метода из этапа 1.
1. Восходящий метод по структуре трудозатрат (WBS).
2. Метод стандартных компонентов.
Б. Создайте оценку методом функциональных пунктов.
1. Вычислите функциональные пункты по спецификации требований.
2. Откалибруйте оценочную nporpaMMY по историческим данным своей орrанизации.
З. Оцените номинальный объем работ и сроки с использованием коммерческоrо оценочноrо
nporpaMMHoro пакета.
В. Проводите итеративный пересмотр оценок П.А(l), П.А(2) и II.Б до тех пор, пока не будет
достиrнуто схождение оценок в пределах 5 О/о. Используйте среднюю величину оценки
как номинал N.
r. Вычислите диапазонную оценку 0,8N l,25N.
1. Бюджет определяется на основе показателя 1.0N.
2. Резерв на непредвиденные расходы определяется на основе показателя O,25N.
З. Возможно выделение дополнительноrо резерва на основании исторических данных
роста требований в данной орrанизации.
4. Публикуется только верхняя rраница диапазона (l,25N).
5. Оценка не должна использоваться во внешних обязательствах.
III. Оценка предварительных обязательств (после второй внутренней версии)
А. Постройте восходящую оценку.
1. Создайте подробный список задач.
(а) Список задач должен быть соrласован с руководителями разработки, тестирования
и подrотовки документации.

17.3. Пример процедуры оценки для последовательных проектов 191
2. Поручите каждому разработчику, специалисту по тестированию и друrим участникам
проекта оценить объем работ, необходимых для реализации требований, за которые
он отвечает.
(а) Модули должны оцениваться по лучшему, худшему и ожидаемому случаю.
(б) Номинальные оценки модулей вычисляются по формуле [ЛучшийСлучай +
(4 х ОжидаемыйСлучай) + ХудшийСлучай)/б.
3. Просуммируйте номинальные оценки отдельных модулей.
Б. Сравните оценку II.r с III.A(3). Вычислите номинальную оценку N по следующей формуле:
(2 х БольшаяОценка + МеньшаяОценка)/3.
В. Вычислите диапазонную оценку 1,ON1,lN.
1. Верхняя rраница диапазона (l,lN) может использоваться во внешних публикациях.
2. Внешние обязательства принимаются по оценке 1,lN.
3. Диапазон 1,ON1,lN может использоваться во внутренних публикациях.
IV. Оценка окончательных обязательств (поспе третьей внутренней версии)
А. Сравните оценку с фактическими результатами, полученными на этапе 111.
1. Вычислите заново пересмотренное номинальное значение по формуле: ОставшийсяОбъем
Работ = ЗапланированныйОстатоК/(ФактическийПредшествующийОбъем/
Заплан ированн ы й ПредшествующийОбъем)
2. Добавьте все задачи, не учтенные на шаrе 111.
Б. Сумма IV.A.1 и IV.A.2 может использоваться в качестве Hoвoro номинальноrо объема работ, N.
1. Номинал (l,ON) может использоваться во внешних публикациях.
2. Внешние обязательства MOryт делаться по оценке 1,ON.
3. Диапазон O,9N1,lN может использоваться во внутренних публикациях.
У. Оценка проек-r.а может пересматриваться в любой момент в ответ на значительные
изменения в проектных предпосылках
А. Изменения в предпосылках включают в себя (хотя и не оrраничиваются) расширение
требований, изменения в определениях основных требований, изменения в доступности
персонала и изменения в целевых сроках.
VI. Завершение проекта
А. Соберите и заархивируйте данные по фактическим результатам проекта для использования
в будущем.
Б. Проанализируйте точность каждой оценки.
1. Проанализируйте rлубинные причины всех основных ошибок.
2. Решите, можно ли было достичь той же точности с меньшими усилиями.
3. Предложите изменения в стандартизированной процедуре оценки.
Процедура оценки, показанная в табл. 17.3, содержит все элементы, обычно
присутствующие в подобных процедурах. Она:
· по возможности базируется на подсчете и вычиJlеlпlяx,' а не на субъектив--
нъlX оценках. Вычисление исследовательской оценки (оценка 1 в табл. 17.3)
требует применения декомпозиции со структурой трудозатрат, оценки
по аналоrии и метода стандартных компонентов. Hli один из этих методов
не обладает выдающейся точностью, но каждый из них по крайней мере

192 rлава 17 · Стандартизированные процедуры оценки
не оrраничивается субъективным суждением и сопряжен с определенными
вычислениями;
. поощряет применение нескольких альтернативных оценок и сравнение
результатов. В первых трех оценках (1, II и 111) задействован метод cpaB
нения альтернативных оценок. Альтернативные методы обычно использу
ются на раннеЙ стадии проекта, коrда возможности применения вычисли
тельных l\1етодов еще оrраничены;
. подраЗУl\lевает план пересмотра оценки в заранее определенных точках
проекта. В плане задействованы оценки с 1 по У, что указывает на HaMepe
ние периодическоrо пересмотра оценок. Каждая оценка связывается с оп
ределенными контрольными точками в проекте;
. определяет изменения метода оценки в ходе жизненноrо цикла проекта.
Шаrи отличаются друr от друrа и базируются на совершеНСТВУIОЩИХСЯ
данных, которые были получены в ходе проекта и становятся ДОСТУПНЫl\1И
на более поздних этапах. Ближе к концу проекта ero исторические данные
становятся основным материалом для формирования оценок;
. содержит четкое описание неточности оценки. В каждом этапе процеду
ры заложено выра)кеНllе неточности оценки. Скажем, оценка I.B требует
диапазона 50 , +100, а в оценке IV.Б неточность сужается до + 10 %;
. определяет, коrда оценка может использоваться в качестве основы для
формирования бюджета проекта. Оценка II названа бюджетной oцeH
коЙ». В описании оценки 1 явно указано, что она не может использоваться
в качестве основы для формирования бlоджета;
\
. определяет, коrда оценка может использоваться в качестве основы для
внутренних и внешних обязательств. Оценка 111 называется оценкой
предварительных обязательств», а оценка IV  оценкой окончательных
обязательств». В описаниях более ранних оценок явно указано, что они не
?\IorYT использоваться в качестве основы для принятия внешних обяза
тельств.
17.4. Пример стандартизированной процедуры
оценки для итеративных проектов
в табл. 17.3 приведен пример стандартизированной процедуры оценки, адаптиро
ванной для итеративных проrраммных проектов. Такие процедуры обычно pa
ботают с наибольшей эффективностью в орrанизациях с rодичным бюджетным
циклом. Бюджет фиксируется в начале цикла; это означает, что укомплекто
ванность штата тоже фиксируется. Следовательно, подобные оценки не должны
быть направлены ни на оценку стоимости (которая фиксируется бюджетом), ни
на оценку сроков (которые для rодичных бlоджетных циклов составляют один
rод). Задача оценщика  оценить объем функциональности, которая может быть
реализована с фиксированным штатом за фиксированный промежуток времени.


17.4. Пример процедуры оценки для итеративных проектов 193
Процедура, описанная в табл. 17.4, предполаrает, что итерации находятся под
правильныrvI управлением  каждая итерация доводится до уровня качества, обес
печивающеrо возможность выпуска версии, при выходе каждой версии выполня
ется необходимая «зачистка», отставания от rpафика не накапливаются и т. д.
Таблица 17.4. Пример стандартизированной процедуры оценки для итеративных
проектов  с упором на оценку функциональности
1. Исследовательская оценка (для планирования первой итерации)
А. Запланированная функциональность оценивается с применением абстрактных рейтинrов.
5. Первая итерация планируется с использованием исторических данных орrанизации.
1. Длина итерации не должна превышать одноrо месяца.
2. Оценка для Bcero проекта не создается.
з. Никакие обязательства не принимаются.
11. Плановая оценка (планирование второй и третьей итераций)
А. Вычислите среднее количество абстрактных пунктов на человеконеделю (для калибровки
объема работ).
5. Вычислите среднее количество абстрактных пунктов на календарную неделю (для калибровки
сроков ).
В. Данные II.А и II.В используются для планирования второй и третьей итераций.
1. Длина итерации не должна превышать одноrо месяца.
2. Номинальная оценка Bcero проекта (N) составляется в форме абстрактных пунктов,
которые MOryт быть реализованы при заданном периоде времени и численности штата.
(а) Оценка может использоваться во внутренних публикациях в виде диапазона O,75N1,ON.
(б) Оценка не должна использоваться во внешних публикациях.
(в) Никакие обязательства не принимаются.
111. Оценка для формирования обязательств (после третьей итерации)
А. Вычислите среднее количество абстрактных пунктов на человеконеделю по данным первых
трех итераций (для калибровки объема работ).
5. Вычислите среднее количество абстрактных пунктов на календарную неделю по данным
первых трех итераций (для калибровки сроков).
В. Данные 111.А и 111.5 используются для планирования оставшейся части проекта.
1. Номинальная оценка Bcero проекта (N) составляется в форме абстрактных пунктов,
которые MOryт быть реализованы при заданном периоде времени и численности штата.
(а) Оценка может использоваться во внутренних публикациях в виде диапазона O,9N1,lN.
(б) Во внешних публикациях оценка может использоваться в виде диапазона O,9N 1,ON.
(в) Обязательства принимаются на основе диапазона O,9N1,ON.
IV. Оценка проекта может пересматриваться в любой момент в ответ
на значительные изменения в проектных предпосылках
А. Как минимум калибровка оценок проекта должна обновляться после каждой третьей итерации
с учетом изменений в комплектации штата, повышения производительности и друrих факторов.
У. Завершение проекта
А. Соберите и заархивируйте данные по фактическим результатам проекта для использования
в будущем.
продолжение 
7 ЗаIC. 893


194 rлава 17 . Стандартизированные процедуры оценки
Б. Проанализируйте точность каждой оценки.
1. Проанализируйте rлубинные причины всех основных ошибок.
2. Решите, можно ли было достичь той же точности с меньшими усилиями.
З. Предложите изменения в стандартизированной процедуре оценки.
Процедура оценки, показанная в табл. 17.4, содержит мноrие элементы, обыч
но присутствующие в подобных процедурах. Она: .
. по возможности базируется на подсчете и вычислениях, а не на субъек"
тивных оценках. В оценке 11 задействованы фактические данные, и даль
нейшие оценки вычисляются на основании исторических данных проекта;
. поощряет ПРИ1\fенение нескольких альтернативных оценок и сравнение
результатов. Данная процедура не требует альтернативных оценок. Впро
чеl\1, если вы решили использовать эту процедуру, но считаете, что истори
ческие пункты не обеспечивают достаточной точности проrноза, измените
процедуру и включите в нее дополнительные методы оценки;
. подразумевает план пересмотра оценки в заранее определенных точках
проекта. В планировании задеЙствованы оценки IIII, что указывает на
наl\lерение производить периодический переСfОТР оценок;
. определяет изменения метода оценки в ходе жизненноrо цикла проекта.
Как и в случае с последовательной процедурой, все этапы процедуры отли
чаются друr от друrа на основанпи исторических данных, сrенерированных
проектом;
. содержит четкое описание неточности оценки. В оценке 1 просто сказа
но, что оценка Bcero проекта не производится, а оценка 11 обеспечивает
диапазон неопределенности от 75 до 100 % предполаrаемой функцио
нальности;
. определяет, коrда оценка может использоваться в качестве основы для
формирования бюджета проекта. В данном случае финансовый бюджет
фиксирован;
. определяет, коrда оценка может использоваться в качестве основы д.,ТIЯ
внутренних и внешних обязательств. Оценка 111 называется  оценкоЙ для
формирования обязательств. В описаниях более ранних оценок явно
сказано, что они не MOryT использоваться для принятия внешних обяза
тельств.
17.5. Пример стандартизированной процедуры
v
оценки от проrрессивнои орrанизации
в табл. 17.5 описана процедура оценки, используемая лабораторией разработки
проrpаммноrо обеспечения NASA (NASA SEL), одной из самых передовых opra
низаций по разработке проrpаммноrо обеспечения.


17.5. Пример процедуры оценки от проrрессивной орrанизации 195
Таблица 17.5. Процедура оценки NASA SEL
Входные Выходные данные
данные Входные данные Оценка Оценка Оценка срока Диапазон
Фаза n роекта для оценки размера объема работ неоп peдe
ленности 1
Завершение Количество под 11 000 строк 3000 часов Количество + 75 О/О
анализа систем кода 2 на подсистему подсистем --43 О/о
требований умножается
на 83 недели
и делится
на численность
персонала
Завершение Количество MOДY 190 строк кода 52 часа Количество MO +40 О/о
предварителbl-toro лей (функций на модуль на модуль дулей умножа о
проектирования и/или подпро ется на 1,45 He 29 Уо
rpa м м) дели и делится
на численность
персонала
Завершение Количество HO Строки 0,31 часа Количество + 25 О/о
подробноrо вых и сущecrвен кода = 200 х на строку строк кода YM  20 О/о
проектирования но изменеННВIХ х (N + 0,2R) кода ножается на
моду лей (N). 0,0087 недели
Количество пере и делится на
численность
работанных и He персонала
значительно
измененных MO
дулей (R)
Завершение Текущий размер Текущий раз Объем выпол Затраченное + 10 О/о
реализации в строках кода. мер увеличива ненной работы время увеличи 9 О/о
Объем работы, ется на 26 О/о увеличивается вается на 54 О/о
u (с учетом на 43 О/о (с уче
выполненнои тестирования) том работы по
до настоящеrо завершению)
момента.
Время, затрачен
ное до настояще
ro момента
Завершение Общий объем BЫ Окончатель Объем выпол Затраченное + 5 О/о
тестирования полненной работы ный размер ненной работы время увели 5 О/о
системы nporpaMMHoro увеличивается чивается
проекта cтa на 13 О/о (с уче на 18 О/о
новится из том работы по
вестным завершению)
Источник: Адаптировано по материШlа.А! Maпager's Haпdbook for Software Developтeпt,
Revisiol1 1 (NASA SEL 1990).
1 Чтобы сохранить допуск на текучесть кадров, рост требований и т. д., консервативные
принципы управления рекомендуют использовать оценки, лежаlцие между проrнозируе
мым значением и верхней rpаницей.
2 К строками Koдa относятся все конструкции исходвоrо кода, включая комментарии
и пустые строки.

1


196 rлава 17 . Стандартизированные процедуры оценки


Са?\iая замечательная особенность процедуры оценки NASA SEL заКЛlочается
в том, что она требует меньшей работы для создаНllЯ более точных оценок. Это
характерно для общеrо правила: че?\i более изощреННЫl\fИ становятся ваши oцeH

ки, тем меньше усилий требуется для создания точных оценок.
Конкретные числа в этой процедуре относятся к специфике NASA SEL. Они
были откалиброваны за несколько десятилетий сбора и анализа данных и xapaK

терны для высокоразвитых орrанизаций, занимаIОЩИХСЯ разработкоЙ проrраМl\I

Horo обеспечения. Для друrих орrанизаций они не подходят.
Отличия от процедур, которые 1vl0ryT использоваться
leHee разВИТЫ1\1I1 opra

НlIзациями, весьма поучительны. Впрочеl\l, существует и определенное сходство.
Процедура NASA SEL:
. по возможности базируется на подсчете и вычислениях, а не на субъек

тивных оценках. Процедура NASA SEL интересна Te1vl, что даже ранние
проектные оценки базируются на подсчетах и вычислениях. Объем работ
и сроки никоrда не оцениваются наПРЯМУIО;


.
. поощряет применение нескольких альтернативных оценок и сравнение
результатов. Данная процедура не требует одновре1vlенноrо применения
нескольких альтернативных 1vlетодов в любой l\10
leHT вреl\lени. Лаборато

рпя NASA SEL достаточно долrо собирала и аналИЗИРОВ(L1Jа исторические
данные, что позволяет ей составлять точные оценки с l\lалЫ
IИ УСllЛИЯl\ПI;
. подразумевает план пересмотра оценки в заранее определенных точках
проекта. В табл. 17.5 ОТ?\lечены точки проекта, в которых создаются новые
оценки;


. определяет изменения метода оценки в ходе жизненноrо цикла проекта.
Каждая строка таблицы представляет отдельный
Iетод оценки дЛЯ KOH

кретной точки жизненноrо цпкла проекта;
. содержит четкое описание неточности оценки. В краЙнеl\f праВОl\1 столбце
содержатся величины поправок НОl\fИНально:Й оценки. Первая сноска co

держит хорошую оБЩУIО реКО
fендацию:
...консервативные ПРllНЦIlПЫ
управления реКОl\fендуют использовать оценки, лежащие l\fежду проrНОЗII

pyel\fbIM значениеl\I и верхней rpаницей»;
. определяет, коrда оценка может использоваться в качестве основы
для формирования бюджета проекта. В даННОl\1 случае этот эле?\lент не
выIажен;;


. определяет, коrда оценка может использоваться в качестве основы для
внутренних и внешних обязательств. Эти эле?\'lенты не выражены в проце

дуре наПРЯl\IУЮ. Обратите ВНИl\fание: первая строка таблицы относится
к «завершению анализа требований
. В теРl\lIlнолоrИll NASA SEL «ана.ЛlIЗО
I
тре60ваниЙ
 называется операция, выполняе
lая после «постановки Tpe60

ваниЙ». Таким образом, из таблицы следует, что первая оценка проекта
{o

)I(eT строиться в относительно широкой чаСТII конуса неопределеННОСТll.




Дополнительные ресурсы 197


17.6. Улучшение стандартизированной
процедуры


Если процедура оценки создавалась специально для KOHKpeTHoro случая, оценку
трудно усовершенствовать, потому что вы никоrда не знаете точно, какой из
аспектов оценки привел к появлению неточности. При использовании CTaH

дартизпрованных процедур вам точно известно, каким обраЗОl\I строилась каждая
оценка; это ПО
10жет в будущем повторить удачи и избежать неудач.
После каждоrо проекта эффективность оценок анализируется по нескольким
направлеНИЯ!\-I.
· Насколько ТОЧНЫ
IИ были ваши оценки? Входил ли окончательныЙ pe

зультат во все диапазоны (см. раздел 16.6)?
· Достаточно ли широкими были ваши диапазоны? Нельзя ли было их cy

зить, не утрачивая выявленной изменчивости?
· В какую сторону обычно смещались ваши оценки
 завышения или зани

жения? Или смещення не было и оценки были нейтральными?
· Какие источники стали причиной искажения оценки?
· Какими методами были получены самые точные оценки? Действительно
ли эти методы обеспечивают самые точные оценки, или они просто случай

но обеспечивали лучшую оценку в данном случае?
· Правильно ли было выбрано время для пересмотра оценок? Сколько было
пересмотров
 слишком MHoro, слишком
lало, в самый раз?
· Был ли процесс оценки более сложным, чем требовалось ? Нельзя ли упро

стить ero без потери точности?


СОВЕТ NQ 79
Анализируйте оценки и процедуры получения оценок в своих проектах; это поможет вам повы

сить точность оценок и свести к минимуму затраты на их создание.


Дополнительные ресурсы


Boehm, Barry W.
Software Engineering Economics
. Englewood Cliffs, NJ: Prentice

НаН, Inc., 1981. В rлаве 21 описана процедура оценки проrpаммных проектов, co

стоящая из семи этапов.
Cooper, Robert G. «Winning at New Products: Accelerating the Process From
Idea to Launch». New York, NY: Perseus Book Group, 2001. Купер
 отец процессов
поэтапноrо контроля. В книrе рассказано, как адаптировать процесс поэтапноrо
контроля для ваших потребностей.
McGarry, J ohn, et al.
Practical Software Management: Objective Information for
Decision Makers», Boston, МА: Addison
Wesley, 2002. В разделе 5.21 обсуждаются
t факторы, включаемые в процедуру оценки.
f
r
!
I




198 rлава 17 . Crандартизированные процедуры оценки


NASA SEL. «Manager's Handbook for Software Development», Revision 1, Docu

тent Nuтber SEL
84
101. Greenbelt, MD: Goddard Space Flight Center, NASA, 1990.
В документе приводится более подробное описание методики оценки проrpамм

ных проектов в лаборатории NASA SEL.




Конкретные
проблемы оценки
rлава 18. Специфические проблемы при оценке размера
rлава 19. Специфические проблемы при оценке объема работ
rлава 20. Специфические проблемы при оценке сроков
rлава 21. Оценка параметров планирования
rлава 22. Стили представления оценок
rлава 23. Политика, переrоворы и решение проблем

Специфические
проблемы при
оценке размера
Область применения методов этой rлавы
ФункционаЛЬНblе rолландский метод ЭлемеНТbI GUI
ПУНКТЫ
Что оценивается Размер, Размер, Размер,
функциональность функциональность функциональность
Размер проекта МСБ МСБ МСБ
Стадия разработки Ранняяредняя Ранняя Ранняя
Итеративный или ПОCJ1едовательный Последовательный Последовательный
последовательный
стиль
Возможная точность Высокая Низкая Низкая
После перехода от прямой оценки объема работ и сроков к их вычислению по ис
торическим данным наибольшие трудности возникают при оценке размера. Ите
ративные проекты MorYT использовать оценку размера для определения коли
чества функций, выдаваемых за итерацию, но обычно они в большей степени
концентрируются на методах, предназначенных для оценки функциональности.
Оценка на поздних стадиях последовательных проектов часто оказывается Ha
правленной на восходящие оценки объема работ, созданные людьми, которым
предстоит выполнять эту работу. Таким образом, оценка размера оказывается
наиболее применимой на ранних и средних этапах последовательных проектов.
Целью оценки размера является поддержка долrосрочной проrнозируемости в ши
рокой части конуса неопределенности.
Стандартные метрики оценки размера  строки проrраммноrо кода и функ
циональные пункты  обладают разными достоинствами и недостатками. То же
можно сказать о специализированных методах, созданных орrанизациями для
собственноrо применения. Как правило, создание оценок по разным метрикам

18.1. Проблемы при оценке размера 201
размера и проnерка их схождения/расхождения обеспечивает самые точные
результаты.
В этой rлаве описано, как создать оценку размера. В rлаве 19 объясняется, как
преобразовать оценку размера в оценку объема работ, а в rлаве 20  как преобра
зовать оценку объема работ в оценку срока.
18.1. Проблемы при оценке размера
Существуют различные показатели размера проrраммных проектов, в том числе:
. функции;
. требования;
. сценарии использования;
. функциональные пункты;
. вебстраницы;
. компоненты GUI (ок.на, диалоrовые окна, отчеты и т. д.);
. таблицы баз данных;
. определения интерфейсов;
. классы;
. строки проrраммноrо кода.
На практике для оценки чаще Bcero используются строки проrраммноrо кода
(LOC), поэтому я начну именно с них.
Роль строк кода в оценке размеров
Оценка проrраммных проектов в строках кода имеет как положительные, так
и отрицательные стороны. С одной стороны, у них есть ряд преимуществ.
. Данные по количеству строк кода в прошлых проектах леrко собираются
при помощи служебных проrpамм.
. Во мноrих орrанизациях уже наработан большой объем исторических дaH
ных, выраженных в строках кода.
. Объем работы на строку кода остается более или менее постоянным для
разных языков проrраммирования или, во всяком случае, достаточно близ
ким для практических целей. (Как объясняется в rлаве 5, объем работы на
строку кода в большей степени зависит от размера проекта и типа проrpам
мы, нежели от языка проrраммирования. А вот функциональность одной
строки кода радикально изменяется в зависимости от языка.)
. Измерения n строках кода позволяют выполнять межпроектные сравнения
и оценивать будущие проекты по данным прошлых проектов.
. В большинстве коммерческих оценочных проrрамм оценки объема работ
и сроков в конечном счете основываются на строках кода.

202 rлава 18 · Специфические проблемы при оценке размера
С друrой стороны, строки кода также создают определенные трудности при
оценке размера.
. Упрощенные Iодели вида количество строк кода на человекомесяц под
вержены ошибкам изза llздержек масштаба и заметных различий в CKOpO
сти кодирования для разных типов проrраммноrо обеспечения.
. Строки кода не MoryT использоваться в качестве основы для оценки задач,
порученных отдельным проrраммистам, изза orpoMHbIX различий в произ
водительности.
. Если проект требует более сложноrо кода по сравнению с проектом, ис
пользоваВШИl\IСЯ для калибровки предположений о производительности,
это может нарушить точность оценки.
· Применение метрики LOC при оценке работы по постановке требований,
проектированию и друrих действий, предшествующих созданию кода, BЫ
r лядит противоестественно.
. Строки кода трудно оценивать напрямую и их обычно приходится оцени
вать опосредованно.
· Вы должны заранее тщательно определить, что именно следует считать
строкой кода (это необходимо для предотвращения проблем, описанных
в разделе 8.2).
Некоторые эксперты возражают против использования строк кода в качестве
метрики размера изза проблем, возникающих при попытке анализа производи
тельности в проектах с рааными типами, размерами, языками проrраммирования
и проrpаммистаI\IИ (Jones 1997). Друrие эксперты указывают, что аналоrичные
проблемы встречаются и при использовании друrих метрик размеров, включая
функциональные пункты (Putnarn and l\1yers 2003).
Общая проблема оценки в строках кода, функциональных пунктах и друrих
простых метриках заключается в том, что измерение чеrолибо столь MHororpaH
Horo, как размер проrpаммноrо проекта, в одномерных метриках неизбежно поро
ждает аНОl\Iалии, по крайней мере в отдельных ситуациях (Gilb 1988, Gilb 2005).
Одномерные метрики не применяются для описания экономических моделей
или друrих сложных сущностей. Они даже не применяются для определения луч
шеrо подающеrо в бейсбольной команде  мы учитываем среднее количество по
паданий, пробежек и друrих факторов, но даже после этоrо продолжаем спорить
о смысле этих чисел. Если даже уровень подающеrо нельзя оценить по одному
простому показателю, почему можно полаrать, что простая метрика подойдет для
оценки чеrото настолько сложноrо, как размер проrраммноrо проекта?
Мое личное отношение относительно оценки проектов по строкам кода Ha
поминает высказывание Уинстона Черчилля по поводу демократии. Метрика
LOC  очень плохой способ оценки размера проrраммноrо проекта, но все oc
тальные способы еще хуже. В большинстве орrанизаций, несмотря на все свои
недостатки, метрика LOC остается основным рабочим инструментом для изме
рения размера прошлых проектов и создания ранних оценок новых проектов.

r
18.2. Функциональные пункты 203
Метрика LOC  это liпgua flaпca оценки проrpаммных проектов и обычно xopo
шая отправная точка (при условии, что вы не забываете о ее оrраничениях).
Возможно, ваша среда достаточно сильно отличается от типичной среды про
rpаммирования, и количество строк кода в ней слабо коррелируется с размером
проекта. В этом случае найдите друrой показатель, в большей степени связанный
с размером проекта, подсчитайте ero и заложите в основу своих оценок размера,
как обсуждалось в rлаве 8. Ищите метрику, леrко подсчитываемую, коррелиро
ванную с объемом работ и достаточно универсальную для использования в He
скольких проектах.
СОВЕТ NQ 80
Используйте строки nporpaMMHoro кода для оценки размеров, но помните об общих оrраничени
ях простых метрик, а также специфических опаснях метрики LOC.
18.2. Функциональные пункты
Одной из альтернатив метрики LOC являются функциональные пункты. Это
синтетическая метрика размера проrраМf\1Ы, которая может применяться для
оценки размера проекта на ero ранних стадиях (Albrecht 1979). Функциональные
пункты проще вычислять по спецификациям требований, чем строки кода; кроме
Toro, они формируют основу для вычисления размера в строках кода. Существует
MHoro разных методов для вычисления функциональных пунктов. Стандарт п.од
счета функциональных пунктов поддерживается rpуппой International Function
Point Users Group (IFP1JG) и размещается на вебсайте по адресу www.ifpug.org.
Размер проrpаммы в функциональных пунктах базируется на количестве и слож
ности следующих элементов.
Внешние входныIe элементы  экраны, формы, диалоrовые окна или управляю
щие сиrналы, при помощи которых пользователь или внешняя проrpамма добавля
ет, удаляет и изменяет данные проrpаммы. К этой катеrории относятся все входные
элементы, обладающие уникальным форматом или уникальной лоrикой обработки.
Внешние выходные элементы  экраны, отчеты, диаrpаммы или управляющие
сиrналы, rенерируемые проrраммой для пользователя или внешних проrрамм.
К этой катеrории относятся все выходные элементы, отличающиеся по формату
или лоrике обработки от друrих типов вывода.
Внешние запросы  комбинации входных/выходных элементов, в которых
входному элементу ставится в соответствие простая выходная форма. Термин
происходит из мира баз данных и относится к прямому поиску данных (обычно
по уникальному КЛIОЧУ). В современных rрафичеСКIIХ и вебприложениях rpани
ца между запросами и выходными элементами размыта, но в общем случае за
просы производят выборку данных непосредственно из базы и оrpаничиваются
минимальным форматированием, а выходные элементы поддерживают обработ
ку, комбинирование и обобщение сложных данных с широкими возможностями
форматирования.
Внутренние лоrические файлы  основные лоrические rpуппы пользователь
ских или управляющих данных, находящиеся под полным контролем проrраммы.

204 rлава 18 · Специфические проблемы при оценке размера
Лоrический файл представляет собой один неструктурированный файл или одну
таблицу в реляционной базе данных.
Внешние интерфейсные файлы  файлы, находящиеся под контролем дpy
rих проrpамм, с которыми взаимодействует измеряемая проrрамма. К этой KaTe
rории относятся все основные rруппы лоrических или управляющих данных,
принимаемых или передаваемых проrраммой.
В табл. 8.1 показано, как счетчики входных элементов, выходных элементов
и т. д. преобразуются в нескорректированные функциональные пункты. Количе
ство входных элеIVIентов низкоЙ сложности умножается на 3, количество BЫXOД
ных элементов низкой сложности  на 4 и т. д. Сумма полученных чисел дает
l\lетрику проекта в нескорректированных функциональных пунктах.
Таблица 18.1. Множители для вычисления нескорректированных функциональных пунктов
Характериcrика nporpaMMbI
Внешние входные элементы
Внешние выходные элементы
Внешние запросы
Внутренние лоrические файлы
Внешние интерфейсные файлы
ФункционаЛЬНblе пункты
Н изкая сложность Средняя сложность
х 3 х 4 .
х4
хЗ
х4
х5
х5
х4
х 10
х7
Высокая сложность
хб
х7
хб
х 15
х 10
После суммы нескорректированных функциональных пунктов вычисляется
коэффициент влияния; он основывается на влиянии, оказываемом на проrраl\IМУ
14 фактораlVlИ. Среди примеров таких факторов можно назвать передачу данных,
оперативный ввод данных, сложность обработки и простоту установки. Коэффи
циент влияния лежит в диапазоне от 0,65 до 1,35. После умножения нескорректи
рованной суммы на коэq)фициент влияния вы получаете скорректированную Be
личину в функциональных пунктах.
Если вы читали мои предшеСТВУIощие комментарии о субъективных реryлято
рах>.'>, вероятно, вы уже доrадываетесь, что я думаю о коэффициенте влияния и ero
14 реrуляторах. Два исследования показали, что нескорректированные функцио
нальные пункты в большей степени коррелируются с итоrовым размером, чем
скорректированные (Kelnerer 1987, Gaffney and Werling 1991). Некоторые экспер
ты также рекомендуют исключить оценки низкой сложности» И высокой слож
ности» И классифицировать все счетные показатели как «средние>.'>  тем самым
исключается еще один источник субъективизма (Jones 1997). Стандарт ISOjIEC
20926:2003 базируется на нескорректированных функциональных пунктах.
В табл. 18.2 показан пример составления итоrовой метрики в скорректирован
ных функциональных пунктах. Конкретные значения входных и выходных элемен
тов, запросов, внутренних лоrических и внешних интерфейсных файлов пред
ставлены исключительно для наrлядности.
В показанном при мере размер проекта оценивается в 284 функциональных
пункта. Полученное значение можно напрямую преобразовать в оценку объема
работы (см. rлаву 19) или сначала преобразовать в оценку в строках кода, а от нее
перейти к оценке объема работы.

r
!
18.2. Функциональные пункты 205
Таблица 18.2. Пример вычисления размера в функциональных пунктах
Характеристика nporpaMMbI
Внешние входные элементы
Внешние выходные элементы
Внешние запросы
Внутренние лоrические файлы
Внешние интерфейсные файлы
Нескорректированная сумма
в функциональных пунктах
Коэффициент влияния
Скорректированная сумма
в функциональных пунктах
ФункционалЬНblе пункты
Низкая сложность Средняя сложность
б х 3 = 18 2 х 4 = 8
7 х 4 = 28 7 х 5 = 35
охз=о 2х4=8
О х 4 = О 2 х 10 = 20
2 х 5 = 10 О х 7 = О
Высокая сложность
3 х б = 18
Ох7=0
4 х б = 24
3 х 15 = 45
7 х 10 = 70
284
1,0
284
Терминолоrия метода функциональных пунктов заметно ориентирована на
базы данных, но rpуппа IFPUG неуклонно обновляет правила подсчета функцио
нальных пунктов, и эта меtодика хорошо работает для всех типов проrраммноrо
обеспечения. Исследования показали, что сертифицированные специалисты по
оценке функциональных пунктов обычно выдают показатели, отличающиеся не
более чем на 10 %, так что подсчет функциональных пунктов открывает реальную
возможность сокращения неопределенности, связанной с объемом проекта, в KO
нусе неопределенности на ранней стадии проекта (Stutzke 2005).
СОВЕТ NQ 81
Воспользуйтесь методом функциональных пунктов, чтобы получить относительно точную oцeH
ку размера на ранней стадии проекта.
Преобразование функциональных пунктов в строки кода
Если потребуется перейти от функциональных пунктов к строкам кода, в табл. 18.3
перечислены коэффициенты преобразования для некоторых распространенных
языков проrраммирования.
Скажем, если ваша проrpамма на 285 функциональных пунктов будет реали
зована на Java, из таблицы берется диапазон от 40 до 80 LOC на функциональный
пункт; умножив ero на 284 функциональных пункта, мы получаем оценку разме
ра от 11 360 до 22 720 LOC, с ожидаемым значением 55 х 284 == 15675 LOC. Чтобы
не создавать ложноrо впечатления точности, эти числа можно упростить до диа
пазона 11 00023 000 LOC с ожидаемым значением 16 000 LOC.
Коэффициенты, представленные в таблице, используют широкие диапазо
ны  обычно верхняя rpаница отличается от нижней в 23 раза. Как и во мноrих
друrих оценках, если вам удастся собрать исторические данные о соответствии
между функциональными пунктами и строками кода в вашей орrанизации, это
повысит точность оценок и, вероятно, сузит диапазоны оценок по сравнению со
среднеотраслевыми данными.

206 rлава 18 · Специфические проблемы при оценке размера
Таблица 18.3. Количество команд на функциональный пункт
в разных языках проrраммирование
Язык Команд на функциональный пункт
Минимум Номинал (наиболее Максимум
(1 стандартное вероятное значение) (+1 стандартное
отклонение) отклонение)
Ada 83 45 80 125
Ada 95 30 50 70
С 60 128 170
С# 40 55 80
С++ 40 55 140
Cobol б5 107 150
Fortran 90 45 80 125
Fortran 95 30 71 100
Java 40 55 80
Макроассемблер 130 213 300
Perl 10 20 30
Языки BToporo поколения 65 107 160
(Fortran 77, Cobol, Pascal и т. д.)
Smalltalk 10 20 40
SQL 7 13 15
Языки TpeTbero поколения 45 80 125
(Fortran 90, Ada 83 и т. д.)
Мiсrоsoft Visual Basic 15 32 41
J1С1ТlОЧll11К: Адапlпировано по да1lIlЫ.М .,Estimatiпg Software Costs (]oпes 1998), Software
Cost Est;пlatiotlll};t/l Сосото //» (Вое/1т 2000) и -«Estimatiпg /пteпsive Systeтs»- (Stutzke 2005).
Описание вычисления функционапьных пунктов, приведенное в этом разделе,
дает .1I1ШЬ Becbla поверхностное представление об этой сложной методике. Хотя
эксперты в области вычисления функциональных пунктов IOryT выдавать pe
зультаты, ОТЛllчающиеся в пределах 10 %, результаты вычислений неопытных
оценщиков различаются от 20 до 25 % (Kemerer and Porter 1992, Stutzke 2005).
За дополнительноЙ IIНфОРlациеЙ об ЭТОI leToдe обращайтесь к разделу Допол
НIIтельные pecypcы в конце этой rлавы.
18.3. Упрощенные методы вычисления
функциональных пунктов
При вычислении функциональных пунктов необходимо строку за строкой пере
брать спецификацию требований и буквально подсчитать все входные и BЫXOД
ные элеlенты, фаЙлы и т. д. На это 1\Iожет потребоваться MHoro времени.
Эксперты в области оценки предложили ряд упрощенных методов вычисле
НIIЯ фУНКЦlIональных пунктов. С учеТОl\1 друrих источников изменчивости, при

r
18.3. Упрощенные методы вычисления функциональных пунктов 207
СУТСТВУЮЩИХ В проrpаrvlМНЫХ проектах на ранней стадии, коrда функциональные
пункты еще иrрают важную роль, стремление к минимизации работы, необходи
мой для получения не очень точных оценок, выrлядит уместным.
rолландский метод
Ассоциация метрик проrраммноrо обеспечения Нидерландов (NESMA) пред
лаrает индикативный метод для вычисления функциональных пунктов на
ранней стадии проекта (Stutzke 2005). В этом методе вместо всех BXOДHЫX/BЫ
ходных элементов и запросов учитываются только внутренние лоrические файлы
и внешние интерфейсные файлы. Затем индикативная метрика вычисляется по
следующей фОРlvIуле:
ФОРМУЛА NQ 8
ИндикативныеФункциональныеПункты = (35 х ВнутренниеЛоrическиеФайлы) + (15 х Внешние
ИнтерфейсныеФайлы) .
Коэффициенты 35 и 15 были получены посредством калибровки. В конеЧНОl
итоrе их рекомендуется Зl\fенить калибровочными коэффициентами, получен
u
ными по данным вашеи среды.
l\1етрики, созданные этим методом, уступают по точности метрикам, полу
ченным с использованиеlvI полной lvIетодики вычисления функциональных пунк
тов, описанной в раэделе 18.2. Однако объеf paQOTbI также получается сущест
венно 1\1еньшим, ПОЭТОl\lУ такие приближения MOryT принести пользу при rрубой
оценке.
СОВЕТ NQ 82
Используйте rолландский метод для получения приближенной оценки с минимальными затрата
ми на ранней стадии проекта.
Элементы GUI
Вместо прямоrо вычисления функциональных пунктов 1\IОЖНО начать с под
счета элементов rрафическоrо интерфейса (GUI); это пример опосредованных
методов оценки, о которых было рассказано в rлаве 12. Процесс состоит из сле
дующих шаrов.
1. Подсчитайте количество элементов GUI по катеrориям из табл. 18.4.
2. Преобразуйте количество элементов GUI в количество функциональ
ных пунктов; для этоrо данные, полученные по табл. 18.4, подставляются
в табл. 18.1.
3. Вычислите размер в 'строках кода по отношеНИЯl\l, показаННЫlvI в табл. 18.3.
При использовании этоrо подхода следует ПОНlIl\lать, какая неопределенность
закладывается в вашу оценку. Вероятно, некоторая определенность существует
уже в исходных КОЛliЧествах элементов GUI или ваших оценках. Дополнительная
неопределенность вводится при преобразовании элементов GUI в функциональные

208 rлава 18 · Специфические проблемы при оценке размера
пункты. И наконец, при преобразовании функциональных пунктов в строки кода
ее становится еще больше.
Таблица 18.4. Опосредованный подсчет элементов GUI вместо функциональных пунктов
Сложный интерфейс
Эквивалент в функциональных пунктах
Один внешний входной элемент низкой сложности
для операций добавления, изменения и удаления
С если они поддерживаются), плюс один внешний
запрос низкой сложности
Один внешний входной элемент средней сложности
для операций добавления, изменения и удаления
С если они поддерживаются), плюс один внешний
запрос средней сложности
Один внешний входной элемент высокой сложности
для операций добавления, изменения и удаления
С если они поддерживаются), плюс один внешний
запрос высокой сложности
Один внешний вх{)дной элемент средней сложности
Один внешний входной элемент высокой сложности
Один внутренний лоrический файл низкой сложности
Один внешний входной элемент низкой сложности
для получения данных; один внешний выходной
элемент низкой сложности для выдачи данных
Один внешний входной элемент средней сложности
для получения данных; один внешний выходной
элемент средней сложности для выдачи данных
Один внешний входной элемент высокой сложности
для получения данных; один внешний выходной
элемент высокой сложности для выдачи данных
Не учитываются по отдельности Са только в составе
экрана, с которым они связаны)
Элемент GUI
Простое клиентское окно
Среднее клиентское окно
Сложное клиентское окно
Средний отчет
Сложный отчет
Любой файл
Простой интерфейс
Средний интерфейс
Окно сообщения или диалоrовое окно
СОВЕТ NQ 83
Используйте подсчет элементов GUI для получения приближенной оценки с минимальным объе
мом работы на ранней стадии проекта.
18.4. Сводка методов оценки размера
в этоЙ rлаве и в друrих rлавах книrи были представлены мноrочисленные MeTO
ды оценки размера, в том числе и некоторые методы, оценивающие размер в CTpO
ках кода. В табл. 18.5 приведена сводка методов, представлявшихся до настояще
[о MO!vleHTa.
Содержимое последнеrо столбца в действительности зависит от имеющихся
у вас калибровочных данных. Самыми распространенными (и чаще Bcero приме
няемыми на практике) показатеЛЯlИ раЗl\lера являются функциональные пункты
и строки проrраIl\lноrо кода.

r
I
Таблица 18.5. Методы оценки размера
Дополнительные ресурсы 209
Метод rлава
Метод аналоrий 11
Декомпозиция 10
rолландский метод 18
Оценочные nporpaMMbI 14
Метод функциональных пунктов 18
Нечеткая лоrика 12
rpynnoBbIe обсуждения 13
Элементы GUI 18
Стандартные компоненты 12
Широкополосный Дельфийский 13
метод
Оцениваемый показатель
Функциональность, функциональные пункты,
вебстраницы, компоненты GUI, таблицы баз данных,
определения интерфейсов, строки nporpaMMHoro кода
Функциональность, функциональные пункты,
вебстраницы, компоненты GUI, таблицы баз данных,
определения интерфейсов, строки nporpaMMHoro кода
Функциональные пункты, строки nporpaMMHoro кода
Функциональные пункты, строки nporpaMMHoro кода
Функциональные пункты, строки nporpaMMHoro кода
Функциональные пункты, строки nporpaMMHoro кода
Функциональность, пользовательские истории,
требования, сценарии использования, функциональные
пункты, вебстраницы, компоненты GUI, таблицы
баз данных, определения интерфейсов, классы,
функции/подпроrраммы, строки nporpaMMHoro кода
Функциональные пункты, строки nporpaMMHoro кода
Функциональные пункты, строки nporpaMMHoro кода
Функциональность, пользовательские истории,
требования, сценарии использования, функциональные
пункты, вебстраницы, компоненты GUI, таблицы
баз данных, определения интерфейсов, классы,
функции/подпроrраммы, строки nporpaMMHoro кода
Как упоминалось в rлаве 15, лучшие оценщики обычно применяют несколь
ко методов оценки, а затем проверяют схождение или расхождение между oцeH
ками. Методы, перечисленные в табл. 18.5, предоставляют широкие возможности
для составления альтернативных оценок с последующим сравнением резуль
татов.
СОВЕТ NQ 84
При правильной методолоrии оценка размера становится основой для всех остальных оценок.
Размер создаваемой системы является важнейшим фактором, определяющим ее стоимость. Для
повышения точности используйте альтернативные оценки со сравнением результатов.
Дополнительные ресурсы
Garlnus, David and David Herron. «Function Point Analysis: Measureтent Practices
for Successful Software Projects». Boston, МА: AddisonWesley, 2001. В книrе опи
сана процедура вычисления функциональных пунктов, а также представлен ряд
упрощенных методов.
Jones, Capers. «Applied Software Measureтent: Asstlring Pl.oductivity and Quality,
2d Ed.». New York, NY: McGrawHill, 1997. Джонс в подробностях описывает исто
РИIО функциональных пунктов и представляет apryMeHTbI против метрики LOC.

210 rлава 18 . Специфические проблемы при оценке размера
Stutzke, Richard D. Estiтating Software Intensive Systeтs». Upper Saddle River,
NJ: AddisonWesley, 2005. В rлавах 8 и 9 описаны дополнительные методы оценки
размера, в том числе пункты пользовательских сценариев, прикладные пункты,
вебобъекты и упрощенные методы функциональных пунктов. Также Стуцке
описывает оценку размеров для КОМ?\fерческих продуктов.
www.construx.com/resources/surveyor/. На сайте имеется бесплатная утилита для
подсче'Iа строк кода Construx Surveyor.
www.ifpug.com. rруппа IFPUG является наиболее авторитетным ИСТОЧНИКОI
информации по действующим правилам вычисления функциональных пунктов.
www.nesma.nl. На сайте ассоциации NESMA (Netherlands Software Metrics
Users Association) представлена информация о rолландском методе.

r
Специфические
проблемы
при оценке
объема работ
Область приtt1енения tt1етодов этой rлавы
Неформальное Оценочные Диаrраммы Метод ISBSG
сравнение nporpaMMbI средне-
е прошлыми отраспевых
проектами объемов работ
Что оценивается Объем работ Объем работ Объем работ Объем работ
Размер проекта MC МСБ MC MC
Стадия разработки Ран няя---средняя Ранняя---средняя Ранняя Ранняя
Итеративный или Оба Оба Последова Последова
последовательный u u
тельныи тельныи
стиль
Возможная точность Средняя Высокая Низкаясредняя Низкаясредняя
в большинстве проектов объем работ оценивается по подробному списку задач.
Однако на ранней стадии проекта наиболее ТОЧНЫ?vIИ оказываются оценки объема
работ, вычисленные по оценкам размера. В этой rлаве описаны некоторые спосо
бы вычисления этих ранних оценок.
19.1. Факторы, влияющие на объем работ
Наибольшее влияние на объем работ оказывает раЗ?vIер создаваемой проrра?vIМЫ.
Вторым по важНОСТJI фактором является производительность вашей орrанизации.
В табл. 19.1 представлены сведения о диапазонах производительности между
разными проrpам?vIНЫМИ проекта?vIИ. Данные в таблице демонстрируют опасности,
ВОЗНI1кающие при использовании среднеотраслевых данных и при иrнорировании
эффекта издержек размера. Во встроенных проrра?vIМНЫХ проектах (таких, как
проекты Lincoln Continental и IBM Checkout Scanner) код обычно rенерируется

212 rлава 19 · Специфические проблемы при оценке объема работ
1\Н.:lдленнее, чем в коммерческих проектах вроде MicIosoft Excel. При использова
нии средних данных производительности для неподходящеrо типа проекта
оценка может оказаться ошибочноЙ на порядок и более.
В пределах одной отрасли также возможны значительные различия в произ
водительности. Так, для Мiсrоsоft Excel 3.0 код rенерировался примерно в 1 О раз
быстрее, чем для Lotus 123 У.3, хотя оба проекта были направлены на создание
схожих продуктов и проводились примерно в один период времени.
Даже в paIKax одной орrанизации производительность может различаться
IIзза влияния издержек масштаба и друrих факторов. Так, в проектах Мiсrоsоft
Windows NT код rенерировался rораздо медленнее, чеrvl в друrих проектах MicIO
soft, потому что это были системные, а не прикладные проекты, и они отличались
rораздо большими размера1\IИ.
Таблица 19.1. Примеры различий в производительности среди разных типов
nporpaMMHbIx проектов (* = Оценка)
I
Продукт Эквива- Челове- rод Приблиэи- $/LOC LOC/
.
лент ко-лет созда- тельная чело-
в новых ния стоимость веко-
строках в долларах rод
кода 2006 r.
18М Chief Programmer Теаm Project 83 000 9 1968 1 400 000* $17 9200
Lincoln Continental 83 000 35 1989 2 900 000* $35 2400
18М Checkout Scanner 90 000 58 1989 4 900 000 $55 1600
Мiсrоsoft Word for Windows 1.0 249 000 55 1989 8 500 000* $34 4500
NASA SEL Project 249 000 24 2002 3 700 000* $15 1 О 000
Lotus 123 V.3 400 000 263 1989 36 000 000 $90 1500
Мiсrоsоft Excel 3.0 649 000 50* 1990 7 700 000 $12 13 000
Citibank Teller Machine 780 000 150 1989 22 000 000 $28 5200
Windows NT 3.1 (первая версия) 2 880 000 2000* 194 200 000 000 $70 1400
Космический шаттл 25 600 000 22 096 1989 2 000 000 000 $77 1200
Источники: Chief Programmer Теат Maпagemeпt о! ProductiOll P,.og,"alпrпiпg» (Baker 1972),
Microsoft COlporatioп: Office Busiпess Uпit» (/aпsiti 1994), How to Break the Sоfпоаrе Logjam»
(Schleпder 1989), Software Eпgiпeeriпg Laboratory (SEL) Relatioпships, Models, aпd Maпa
gemellt Rules» (NASA, 1991), Mic1.osoft SeC1"ets» Сusитапо aпd Selby 1995).
Соrласно табл. 19.1, наименьшая производительность в строках кода на чело
векоrод наблюдалась при разработке проrраммноrо обеспечения космическоrо
шаттла, но называть эту rруппу разработчиков непроизводительноЙ было бы
ОllIибкой. Для проектов TaKoro размера вероятность полноrо провала превышает
50 % (Jones 1998). Тот факт, что проект был завершен, сам по себе является круп
ным достижением. По производительности он Bcero на 15 % уступал проекту Win
do\vs NT, несмотря на то, что проrpаМIное обеспечение шаттла в 10 раз превышало
по размеру проект Windows NT.
Если вы не располаrаете историческими данными о производительности вашей
орrанизации, можно использовать среднеотраслевые цифры для разных типов


19.2. Вычисление объема работ по размеру 213
проrрамм: внутренних бизнессистем, критических систем, иrр, драйверов YCT
ройств и т. д. При этом следует остереrаться 10KpaTHЫX различий в производи
тельности разных орrанизаций в пределах одной отрасли. Если вы располаrаете
историческими данными производительности в вашей орrанизации, лучше ис
пользуйте их для преобразования оценки размеров в оценку объема работ, вместо
Toro, чтобы использовать среднеотраслевые данные.
19.2. Вычисление объема работ по размеру
Занявшись вычислением оценки объема работ по оценке размера, мы начнем
сталкиваться с некоторыми слабостями неформальных методов и будем вынуж
дены в большей степени задействовать научные методы.
Вычисление оценки объема работ посредством
неформальноrо сравнения с прошлыми проектами
Если исторические данные проектов лежат в узком диапазоне размеров (скажем,
верхняя rраница отличается от нижней не более чем в 3 раза), вероятно, вы може
те воспользоваться линейной моделью для вычисления оценки объема работ HO
Boro проекта по результатам похожих прошлых проектов. В табл. 19.2 представ
лен пример данных прошлых проектов, которые MOryT стать основой для такой
оценки.
Таблица 19.2. Пример данных о производительности прошлых проектов, заложенных
в основу для оценки объема работ
Проект Размер Срок
(LOC) (календарные
месяцы)
8,2
12,5
4,7
Проект А 33 842
Проект В 97 614
Проект С 7444
Объем работ
(человеко-
месяцы)
21
9
2
Производитель-
ность (LOC/
человеко-месяц)
1612
986
3722
Комментарии
Не используется 
слишком мал для
сравнения
Проект D 54 322 11,3
Проект Е 340 343 24,0
40
533
1358
639
Не используется 
слишком велик для
сравнения
Предположим, вы оцениваете эффективность новой бизнессистемы. По Ba
шей оценке, размер HOBoro продукта составит от 65 000 до 100 000 строк кода
Java, с наиболее вероятным размером в 80 000 строк. Проект С слишком мал, чтобы
использоваться в целях сравнения, потому что ero размер составляет менее 1/3 от
нижней rраницы диапазона. Проект Е слишком велик для использования в целях
сравнения, потому что он более чем в 3 раза превышает верхнюю rраницу. Таким
образом, ваши исторические данные производительности лежат в диапазоне от

214 rлава 19 . Специфические проблемы при оценке объема работ
986 строк кода на человекомесяц (проект В) дО 1612 строк кода на человекоме
сяц (проект А). Деление нижней rpаницы диапазона размера на максимальную
производительность дает нижнюю оценку в 40 человекомесяцев, а деление на
минимальную производительность  верхнюю оценку в 101 человекомесяц. Ta
ким образом, оценка объема работ представляет собой диапазон от 40 до 101 чело
векомесяца.
Хорошее рабочее предположение заключается в том, что диапазон включает
68 % ВОЗIОЖНЫХ результатов (то есть ::t1 стандартное отклонение, если только
у вас нет причин предполаrать иное). По табл. 10.6 можно проверить друrие Bepo
ятности, входящие в диапазон от 40 до 101 человеКОIесяца.
Какой объем работ включается в эту оценку?
Поскольку оценка создавал ась по историческим данным, в нее включен тот объ
ем работ, который задействован в исторических данных. Если в исторические
данные включались работы только по разработке и тестированию и только для
части проекта от завершения требований до тестирования системы,  именно
они будут отражены в оценке. Если в исторические данные также вошли работы
по постановке требований, управлению проектом и подrотовке документации 
значит, они тоже будут присутствовать в оценке. .
В общем случае оценки, основанные на среднеотраслевых данных, включают
всю техническую работу, но не работу по управлению и все операции разра
ботки, кроме требований. На практике данные, включаемые в вычисления cpeд
неотраслевых показателей, не всеrда следуют этим предположениям; отчасти это
объясняет такоЙ разброс в среднеотраслевых данных.
19.3. Вычисление оценки объема работ
.
научными методами
Научные методы оценки дают несколько иные результаты, чем неформальные
сравнения с прошлыми проектами. Если ввести те же предположения в Construx
Estiтate (то есть воспользоваться приведенными историческими данными для
калибровки оценки), вы получите ожидаемый результат в 80 человекомесяцев;
он лежит в середине диапазона, полученноrо менее формальным методом. Construx
Estiтate дает оценку лучшеrо случая (достоверность 20 %) в 65 человекомесяцев
и оценку худшеrо случая (достоверность 80 %) в 94 человекомесяца.
Если откалибровать Construx Estiтate среднеотраслевыми данными вместо
исторических, он выдает номинальную оценку в 84 человекомесяца и rораздо
более широкий диапазон 2080 % от 47 до 216 человекомесяцев. Это лишний раз
показывает, как важно использовать исторические данные там, rде это возможно.
СОВЕТ NQ 85
Используйте оценочные nporpaMMbI, основанные на формальных методах оценки, ДЛЯ более
точноrо вычисления оценки объема работ по имеющейся оценке размера.

19.4. Среднеотраслевые rрафики объема работ 215
19.4. Среднеотраслевые rрафики объема работ
Если вы не располаrаете собственными историческими данными, для rpубой oиeH
ки объема работ можно воспользоваться rpафиком  примеры таких rрафиков
приведены на рис. 19.119.9. Светлая линия на эт:их рисунках представляет общий
объем технических работ проекта (включая разработку, контроль качества и Tec
тирование) при среднеотраслевом уровне производительности. Верняя черная
линия представляет объем работ, на единицу стандартноrо отклонения превы
шающий средний. Я не стал приводить аналоrичную линию на единицу CTaHдapT
Horo отклонения ниже среднеrо. Если вы не располаrаете собственными истори
ческими данными и используете эти rpафики, это rОВОРИ1" о том, что разработка
орrанизована в лучшем случае на среднем уровне. В таких случаях лучше про
явить умеренность в оценке и использовать среднеотраслевые или более низкие
показатели производительности.
100,000
,...... .... ........................ .. ... ........... ............ ... ...... .. ..... ... .. ........ ... ... IF". ................. '". ............ "'''' "'.. ......оо........... ............ ................ ........... ............. .. .. .... ... .......... .... ....... ....... ....... .....оо .........
...... ..11...... .to)........................... .............. .... ,..................... ..... ... ................... ....... . . .. ........ ......... .............. ... ......... .......................v... .... ...,............. ...................... ......... .......... ....... ........
....... . ........... . ............,;.........-:--.""..l1li...l1li8) .............;... ................. l1li iIII-"."" l1li....... l1li.. .... ... .............. ..... ..l1li.11.......... ....O.........iIII-................."'-........ . ...........-::;iIII-.... l1li...->........ . ............ iIII-............... .............!...........?-..........IIII.. ..........IIII../'
......::.................:...::.:.........I/III...............".....:...:........::..:".:"".:"':..II...:.:..:."'''''.-'''':.'''''''''.:''.:..'':::..II...r:;...::..............:IIII:::...:....II::.....t...:.......:".........:........:.::.....iIII-........:.:..:..:...:::::::..........:::::.....:iIII-....1I:...:....II:oI:..iIII.::......"'::;.:....:...:..iIII-::illl-IIII:.....:...::;:............:....:..:................:..:..:.....iIII-........:............ IIII .......:...:....:.
. . .. . .. ....1'
.......  ...............Т ........... ..........,.. ......... . ..... ............... """""'"'.............,..,........... .............. 
... iIII- .......IIII.y..........y.........................:.............;............ iIII-.........<=-..IIII-......,...........у........... .......r!J.......... ..............................':'.................IIII!..........<l.............':'...........II(IIII.............
.... ................. ......................
.....(.of-. .....->.......l1li......................................... iIIIJI..IIII...........................
10,000
..    .  ., .  r .r,. . . .  . .
... ....... .....' ........ ....... .... ........ .. .. ...........l1li..... .... .......illl-4;-... l1li.... . ........................ .................. r..'..... . . .. .... l1li.. ....... ........ .............. ........... ............ .iIII-........v............. ........
................ .....у.. .....-:.. ........,.,..... .......-10. .... l1li..... ........... ..... ........ . ....... . . ...... .... .... .l1li.... l1li........ .........................................l1li...... ........ .............. ...........
... ...iI(.II...iIII-............. ....................................... ....... .... l1li.... ...-.. ..... .,:,0.......... . .. 7  . .. l1li.... .;....... .............iIII-...... ..............0(-.................... iIII-.... ......... ... .............
........;...IIII..IIII..IIII ".11.".... ..................IIII....IIII o(iIII-....IIII.II............ .. .......iIII-..... ........ ... . .  ................... ....l1li....... ......... ......... ......l1li............................... ..............IIII.IIII... ..........
. .
.... ... ... ......у.. ......... ..... ................ .. .
......iIII-.IIII..)........_........................IIII...IIII.......8"......... . .. . .. ...... ........... ..l1li......................................
...l1li... ............!... ........ .................l1li..l1li. ... 7. ........ ........ ............. ........ iIII-.. ........... ............!iIII-.........IIII.. .....iIII-.................. .... ..........iIII- ........11... .............................. ......... ... ......."'.. ...."".?....iIII-....
Человеко-
месяцы
1 000
........ .-11... ........ . , . ..l1li. . ............. . .о{о-....... r. ..... .........у.... ..........  - .l1li......... ....... JI.  .
. ..... .. ;:..:.........  :::::;  =::;.     .  ::    -==
.. .......  ...  ...:::. :.:::::;..:::::.::.:::.::::: .::::..::::::::.::::.:::::::.:=..::::::::. ...:.::.:..:::::::::::::.:.:.::..b::::::::.:.. ..:. ..:;::::.:::.:::..
.......  .... ............................II....-.. ......'I"'t...... ..-::...... ...... 1III.1I.............."t".........  .............. ........ ............t"....... ... ....... ... ....... ..l1li......... ..,.......... ...................А................ .........
.. ... ... , .. ...........l1li......... ..... ....................".................................."t..........IIII.......... ...:...............:l1li..l1li.......-:-.. ...
100
... .................................. .. l1li01 .. <........... ......iIII-.. ..... .... .... .... ...... ....... ........................... ... ......................... . ..".. ......... ....... ......у... .....
... . . --::::::::-:....... ........iIII. . ..... ............ ............у ..... .........:--.. ..............._......;.. ..iIII-"':..;"'. ......у,..................... ... у .. """'"........... .::......... .....iIII- $ ........
. .. ...... .. ........ . ....... . ..... .,..l1li.. ...iIIIIII..... ......tQt....... ............ ....l1li.... .............. ......... ............. .. ..........iIII--:-..iIII-....... ....... . ......у......... .. ........y...........;....................".$...........;:
.. .. . . .: :  .
. :............. . iIII-.......::: . : . IIII.....:....r.........:=............. . ......= . ::::  . ... .....  .... . . =:& . . . ........:
.- ......o:o............. ...............  ......  ......."' .....I ....... ...=..  ..........   .. Ш 
i 
i
!
10
&&&&&&&&&

с;:)" S;:)" " (:)" с;:)" " (:)" " " " С)" " " (:)" с;:)"(:)" .. " .. " <::)" " .. " <::)"
K
Строки кода
Рис. 19.1. Средние объемы работ для проектов реальноrо времени
На rрафиках представлены проекты размером до 250 000 строк кода, а макси
мальный объем работ по некоторым из них превышает 10 000 человекомесяцев.
Для проектов TaKoro размера следует понимать, что применение более МОШ
ных и точных методов оценки способно улучшить планирование и обеспечить
экономию сотен тысяч долларов. Эксперт в области оценки Кейперс Джонс Heoд
нократно отмечал, что применение ручных методов для оценки проектов CBЫ
ше 1000 функциональных пунктов или 100 000 строк кода создает существен
ную ошибку, а отказ от применения оценочных проrрамм в проектах свыше

216 rлава 19 · Специфические проблемы при оценке объема работ
5000 функциональных пунктов или 500 000 строк кода должно рассматриваться
как признак некомпетентности в управлении (Jones 1994, Jones 2005).
100.000
"..."."..". ............  ............... .................................. .  ....... . ....... ....................................................
......... !I!... .....-... '" "'.'" '!I"'" ......... ... ......................  .... ........ .. .... ....'". .... .. ....... . .......у ................. .. ...... .... .. . ...... ..... ..
.' .
.... ....... ......... ......! ........ ":"................,... ........... ... .......;..........!..... ...........................;................ .:...::.... .:................::;: ::::....:.... ..... .....=.::;:...::::::.:;::
.... ....... .......... ...... ...11.. ................... ............ ...................... ........... ....... ........... .....1111'8....:. ... .......O(!II..... ............. ............ ...оф..... l1li.... ........ ......,..................... ....... ............. ...0-......l1li..........l1li....................11............ 
. ..,..
10.000
 ..... ........ ............ .a....iIII............ ... ....... ....... ................. ..... ...... ................ ................................ ........ ..............................l1li..........l1li............ _. _...... _+ _........... r......... ..  . ................II.............
. l1li....... ... .l1li... ........" ..... .... ................ ..l1li....... ........ .......... ...... '" ....... .l1li..... ..... ....... ........... .............. ............. ................ ....r.. ...............  ....... ......... ...... ...... ...... . ...
....... ...........11.... ....... ..... .........."'....... .':'.................l1li...... ;....l1li......... ........................... ..IIII.IIII......IIII..,.......iIII-....IIII......... ...l1li................... . .. .. . . .. 4 . ...l1li..l1li........ l1li.................11. ....11.. .............. ...............
. l1li....... ..;.............. ............................ .............IIII..iIII-....... ................IIII..IIII..iIII-....... ..... ......... . ......................................... . ............... . . . . .4... . ..lIIIi111-................ .11...........l1li.........l1li.... ........... .......11........;........... ..........................
. . . .............. ............... ................... 11-. lIIIi111-lIII.. l1li....... ......... ............................. . .. ..............
. .
....................................................
Человеко
месяцы
1 ,000
".
. . r...... . "" ......... ..... . ... ...... ... .  ...  ...... ....... ... .. . . ..... ....... .... . ..  .J'. 
. ..... .................... ....................  .. .l1li.........l1li...,... .... ...................................... ............................... .........l1li..... ...... .............l1li.......... ...(;l1li...... .........iIII-....у................ ................. .......... ............................. ........ ....
...... .iIII-.... ......11.......  ... .. ....l1li.................. ........................................ ............':'. ......................iIII-....IIII..... ........iMI......IIII.iIII-..... iIII- ....iIII-.. l1li............. ...... ... ...... ......... .......... .......................... ........... ........................l1li........ ..iIII-.... ...
.. .... ... i(-......... .А ... ..........Ifoo........... ............... . . ............ . ................... ... ...... ... .................... ......... ....... ".............". .......01'lIO....... ............ .....
... .........l1li...... ...... ... . .11... ............... ... . ...........;............y..............;:................................................................... .....iIII-.........illl-IIII...IIII.. iIII-................................................,......... ............................. ................l1li................_
. .l1li.:. ....... . . r . ... .. !............)..........:............_.... ......................................."".........--:.. ........................... .. .,.,....... .. r........................................ .......... .........IIii.......................... .. ....
. ... .............. . . ..... ...........................:.............. ..... ...........iIII-..iIII-.....у...............IIII.IIII.. ........... ....... ..........l1li......;................................... ............"................:.. .......iIII-.........IIII..IIII..IIII. 1III.....iIII-..II.....iIII-lIII...IIII....IIII........IIII...........
. ..,.,......iIII- . .. . ........ ..................................................................................... ...........""........l1li....... ......iIII-..............................................II........IIII......tI............................ ..................... ...........;............-.""..........,:,..........
100
 .... .. .. .. . ....... . .. . ..  . .. .    . .  . .   . ... ..
.  . .. .................................... ...  ............................iIII' l1li.l1li.l1li............. ....:...... ... .l1li........................... ....... ...................... ....................... .....iIII-.................-.. ,... ..iIII- ... .............. ..... .
....... : . .............,............................ ."........
......:::::::...::::.::::::::::::::::::: ;..:::.::.:.:::::::..:::: :..:::::.:.:::. :...:::.. ...:::.:.::::::::..::..::::::::::::.::::::...::::::...::.::::::1":::::": :::::::::::: :::..:::::::::::..:: ..::::::::
. . А..... .A........ ... ..... ...... ....:....... .................................rh.. ....."""'.......................... ...........oo"iIII....................Iho..."... .. l1li..
. ..............""...11..... l1li.....................l1li.11 1III........""IIII.IIII.iIII-.iIII-...IIII.. .......11.........11........ .......... ..................................... ........................ ... ..l1li............. l1li.l1li,...........l1li 1III......IIIi..iIII..........IIII...........illl-IIII...........IIII.IIII............IIII........ l1li.11 ........11....11.........
. .
10
&&&&&&&&&&&&&&&&&&&&&&&



Строки кода
Рис. 19.2. Средние объеtt1Ы работ для вароенных сиcrем
10,000
............. ................. ...... ....... .............. ...... .r... .... .. ... ... . . .... .. ... .. ...... .... ....................... .... ............ ..... .............. .................... ..... .. ...... . ... ....... ....r..
. 11....l1li.l1li......... l1li.. .....IIII..............II......,.......I!! 10......,................. ....."'I!!I................ .. 1o.................................!!I'!!I..........IIII......... ........l1li....l1li l1li.,....l1li.....l1li..l1li.l1li.11...l1li..........l1li ...... ..........l1li..."" .....11 .....l1li.11.... ........... ................... ...... .....................
'. .:: l1li..::.....::..........l1li...::......::::::...:::::::.11:....:...:...::....::..........:::...:...:..............::...;:::..:..:...:.....:.....::....::......:........:...:.!............iIII-:....:...IIII.........IIII...::..........:...:....::..:...II...::..:.............IIII..:.......:.II......:........II....:....II:..11:......::...:......:........:::..11:.....:.::....:.........:7..:.....:..: ............. ............ .. .7. .:
. .l1li.................l1li.11...... ...........................,...................... .................;...........,...............!...........................':'........................l1li..............l1li. .......l1li.11 .......l1li........... . . . .. .. . . . .................................
........ .... ........,. .."...... .. """....... ........ .......... ........ .. ...... ............................. ..................
. . .
1.000
. .
......... 1III........................iIII-..... ....""....................... ..................................... ..
....................... ............. ...................................iIII-..............iIII-.... r
. r!  ; l  :
 ......IIII.II.......IIII.....:...........IIII...........iIII-.... ... . а ;Dlr 11.........................-:,...... ....
ф.
................... . ................... r...................................... ........... ...7......... ...............................
.... ..l1li.... ............. ............. ...... ......... ........................ ...... .. .............. .. .........................10 ...........................................iIII-..............
................ .,."............................................ ..... ..,.",.",.", ..................... 
.........11.l1li: ...... .l1li......... ....IIII......;........IIII......jII....it..................... .................... ......... ............ .... .... ............... ... ...l1li......;. ........... ":'""...................iIII-...........IIII..iIII-..................IIII.....11
 . . iIII- . -.. l1li....... ...у..........IIII.. ..... ....... .................... ............... .................................................. ..""'......................4(........ .......................ii.. ...ii............ 1III."..IIII.iIII-..iIII-...............
.. .
. .. . .
. .
... ....................... .. .. .. ....... .......,.............................,.............................. ........ .................IIII..........,;iIII-..........IIII.......IIII.................... .....II.II........IIII............II...........IIII...iIII-.....IIII.IIII.......IIII... .....l1li.....l1li.......................,.....
. .
.' .
....l1li...11....l1li.l1li 11 .. ..11 ........................................II......................................................................................)o....iIII-........iIII-...... .l1li.... ....""......,;..l1li......l1li .1' ..............illl-IIII.IIII.. 1iiI..1III.1III.........IIII...illl-IIII.IIII..........IIII......IIII...IIII....II.............II..........
Человеко
месяцы
100
... ... ... ........ ..... ...... .... ...... ........ .... ...... ...... ............ .r. ........ ...... .7... . ... .7....  . .......... ......... .... ...... .... .............. ........... .... ......4. .... . ....4................ 4
....... .. .... .
 ..........
l1li ........ ................ ... .......-.-...... .............. l1li............ ... ........l1li........ ..........;................
..............."'"........... ;.........................
"".. ..........й... ..."""'-'".... .....
. ............... . ...... ...... """"........... ......... .......... .............""'...........:............................................
1 О ....... ........................ ....... . .................... ..................... .......... .......................................................... .... ........... .......................... ............ ......
.:. :::::::::::::..:;:::- ..: ...::::::::. ...:... .............z'... ..'":.'" ..... ......... .......................... ........ ...........: ..::.::::IIII..:::::::::::::.
........... ..... .............l1li......... ............................................. ...........':"...........................!...........................IIII....iIII-....IIII............IIII...II.IIII.1111 ....IIII......IIII.....iIII-=.............:-:.::.:::::....:.::.::...IIII...::=...... ...l1li....::.:... 11 ...l1li. IIIIJ11'. l1li..:.......l1li.l1li....;
........... .....l1li....................................... ...,.,j... .".............l1li......... . .............. ... ... l1li. l1li.11..l1li.,;,.,l1li....... ..
1
&&&&&&&&&&&&&&&&&&&&&&
crcr


Строки кода
Рис. 19.3. Средние объемы работ для телекоммуникационных проектов

19.4. Среднеотраслевые rрафики объема работ 217
10,000
..........""". ....... ...... ............ .............. ............... .....
.. --....,.,. ..................... ................... ... ..... ............
... .
...
......""""""",..........
........ ... 'l1li'.. . ....iIII. -.............'У'.............у ... 60lil........... ............""'" .............., ........v........'V.......... .....,.. ..'У'"'........................................ .............
. .
. .
. -
. -
.................,........................ ..............l1li..........-::............. ... ...................................... ..........l1li8).l1li..... ................;
. .
............!.........................
1 ,000
.. .. ............ .... .l1li.. .-... ................. ... . +.... .................... . ..... ... .. ... .......... ............... ... _...... __ _ r_ _.....
. ................"Ч"-8о'" ..... > ... . ...........у................. ...... ......II..  ............ ... !........._. ........iIII......................:y......... у ... .................::.. ... ...::...:............::............. ......
........oy...................... ....l1li..................l1li....l1li............. .......;...................l1li......l1li...l1li..-:l1li........ .................... -......l1li.......-.... l1li.. .l1li..........--;.........
...............
. .
. .
........IIII..:IIII..IIII... ................. .............:.....IIII.=:=...==..==...=....=======
Человеко..
месяцы
100
........ ........ .7 r.. . . . ..... . ...... +.............. 7 r..... 7. _. _ _. . _. .. . .... .. о.......... + о...... . r. r. .. _. _. _ _. _. _... ............... . +. +. .. ....... .............. r_ _. _ r. _ _ _... . _ ....... ....... ........ O!".... '"  r. _" ",. _..........."..".. .. ".. ...
. .... ..... ......... ..... ....... ........... ........ ................. .......... ....... ......................... ...... ..........l1li.. ............................. .... ...... "....... ........'У' ....... .......... ... ...... .............. .. ........ ....
.. ... .. .  .. .........IIII........JII'...................................;..IIII...,.... l1li....l1li............................... .....)1'... ....,........IIII.IIII. ....................... ..... ...... ......... .....IIII.. ..l1li....l1li..................;.... .. ............IIII.......IIII
: "':'. .:" ..::.;::::::..:::::::.:::::::.::::::...:::.:: :.::.::::.::.:::..:::::.:.:;:::.:.::..:::::::..::::::..:.:::::::::..:::::::.:.::..:.::...:::::.:::::::::..::::::.::::::::::::::::::::::::::: '::::..:::::::.
. -
. . . .. .............................. ... . )......... . : ......_.................. ......'!....... :........ ..""""................................. ........,; .IIII.IIII......................... ........ ..... ........IIII................................:......................
. . - ....................... ........ ........................у................ ........ . .........,;.,....... .............'Y..........................IIII....................................... .......... ............_....... ........"Y'........................... ... ................""..........
1 О . .. . _   
- .,. ......... ...................................... ................... ......... ........................................................... .......,..... . ..IIII.....IIII........................... ........ .IIII.........IIII.................................. .................l1li........
 :.. .:......:...:....:..:...:..;::......:.:..,::.....:...::IIII.,..:...::....':'.......:::..::.:..:..:.;:IIII......:...:.:....,..........:.............;......:........::..:....:..........:......:...,....;...:,.. .. ..... :.,................:.:...:....!I:.".:..:....:.... . ......:...:..:.:.:.::..:_..... .:....:...:,:............:...:. ......:...:..::_:....
- ".--..IIII........ ........................... ...y.........':'........................................IIII.... ....IIII... ..... .............. ........... ................................... ........................ ....,......... IIII...............___...... ...!....,..... ...........
..... .. .........................у................ ................. ........ ................. .........  ..........."""'...... ...",,"_..... ..............-4IIiI'.. .......... ................................. . У.. .... . .. .......""'........ .................... ......... .... _ .......
. . ........ ...........;... .................!... ..... ....................y...........................JI'........... ....,.........IIII...................................................IIII...__.................... ..................l1li........... ""....................................
. ......l1li....l1li..................: ......... !......,..:........ ...............................:............ ....... ............................... . ............ . ................................... .......... ..IIII.........IIII.............."".._....... ............ ......:............
1
&&&&&&&&&&&@&&&&
cr


Строки кода
Рис. 19.4. Средние объемы работ для системных проrраtt1м и драйверов
10,000
.  .:.::::.:::::.:..::..::.::..:...:::.:::..;: ..:.:::.:.:::.:i::.:::i::..::::;::::::.::..:::.: :.:..::::.:::.::.:....::..:. ;.....::.::.:::.. '::::.:::::'.:.::::.:: :.:.::::::::::..:::::::.;:.... .:
. .
.... .......................................................
Человеко
месяцы
100
"-
.......... .........l1li.........l1li.......... .... ..........
1.000
 .
. . ............... .................. ......... ........ -.. ......... 'У.........
... .................... ..... ........ ......l1li.... .................-'Y'.................... .V... .....;..... .....-;:
..... ...........,. l1li..,....l1li.l1li ".IIII....IIII.. ............,;........
. .
.........l1li... ........... ........................ ........ . ...... ......
IIII'. ".. "У. ........ .... ..................................."W'.. . ...... .......... .. ..... ....l1li.........
...... 'V"........."". .......;........y............:......................, ......l1li--.; ......... _....... ......у.....
..........У .......у--............ ................... . . ............"" ............
11.#......... .......... ..................................................l1li.........
- .
...............
r - . .... ......... ........................................... .................... ............... ....................0li)l........... ...................................
. .
...... ""'.... ..............................".,................................ ......,..... .......... ."..........................
....................... ................ ..... .............. .....
10
... ... ..............r._..r.___.:.::.:,.:.:.:............................r... _.....r.. ._..........................+. ..... .............._.........::.:.:.:.: ......r....._........_.._...._..... . "-'"---: " "."' . .
.... ....':""...................... . ... .................. ....у...... ..":""." 4ыIo".. .........""._
.... .,........................,.. ..-.........................,...,
.  ..... --.................-..... ......:....
...........,.........................
.. ....... ......... ..... ........ ..... ............... .......'11...................11...11-... ........"".........
. .
. .....,......IIII........IIII... ...... ............................IIII l1li......................... .... ..............IIII.......IIII....
. .
......... ..............-=-..........."......................... l1li..l1li..................... ..............
1
&&&&&&&&&&
GGGcrcr
'''''''''''''''''''''''''

Строки кода
Рис. 19.5. Средние объемы работ для научных систем и инженерных
исследовательских проектов

218 rлава 19 . Специфические проблемы при оценке объема работ
10.000
 r....  .................... r_". ....... ..... +............. . . . . . __ .......... .... +. +. ........._....... ... r... ........... ........ .......... ............................ .l1li......... ........... ......l1li... .....11..... .............. ..... ............... ... ..l1li...... ...... ...... ...... ...........
+  l1li..... ......... ................. ...iIII..i111 l1li......l1li.......................... ................"l1li......... ........ ......It.i'I'....... ........ .... ..._ ..... .......... ............... .. ........ ......... . ................ .... l1li ...... ..... ...... .....!..................................................
... .....,;...........11;)0............;.............11..................................... ................. .............,. ......................................... .............. ........).......... ......... ... ........ .......... ........ .................... ....... ............... ....... .......... ..IIII.....jI ........................ ...............
':. .:. .:::::::::::::::.:.:::::::::::::::::.:.:::::::::::::.:::::::::'::::::::;:::::::;:::::::.:'::::::::::::::::"':::::::'::::::::::::::::;::::::::::::::::.:'::::::.:::::::: :::::::::;:::::::::::::::.::::::::;,::::::::
. .. ................y.&................. ... oII4of.............................. .... ....... ............. .................... ,.,...".--.................................. .... ............... ........ . ....... y...................... "NНII ... ........ . .......... ......... ..............
. ......................................................" ........l1li................................................._l1li......l1li................. .....................IIII.........'II............... ................
. . .
.. .... ............................... .......--.............v.......................IIII......IIII...IIII............... ....... .......... .:...........v..............
. ...................... . ................. .......... .................................IIII..
Человеко
месяцы
100
'М
.   .. ... ..... ...... ..,............. .....
. ........................................... ..................................... ..... ..... ....... l1li l1li....................... ................. ......l1li........ l1li.................""......... ...............l1li...............
 .. .... ...... ....... .. ........ ......................l1li.....l1li................. ....... ... .......l1li..l1li... l1li ...........n......... .':'. .....................
. .:...::.::: :..:..:.::::::.;.::::::..; :::..:.... .... : .:::...::..::: .......:J.:::::.:.::::.:..:....: ':...:.:':::::.:::::::::..:;:.::...-:;::.::::::::::::;:. .:....:::.::...:::....::::::::::::::::....:..
1,000
. .....
.........-$ ............. .... .......n.......... . ..... ...................:..... ........... ......... .... .............. ......
l1li............ ..... .......... .. ........... ... .................................. .................... .................. .........................................................................IIII..... ........... ...:......................
..l1li..... ..l1li....... ...............................
....... .. ............................. ..... .......... .........
...... . ..""")o.....
.............
. ... . '. .......:::::-::::: :.:.= .:..:.::.::::.:.:f::.:.:==:::.:::.:::::.::: ;. :::::: :=:::::::..::::.::::::::::::::::::::::::::.:::т..::::
. . .. .................... .................:;.......... ..-................. ..,...... ....................:... ........n-......... .............. ............... .............................. .................................:..... .. ..,.. ..........."........ l1li...... ............ .........;,. .......... ..............
1 О . '.L ........... ""; .. ......... '::'::':'" .... .. .... .. ... ......:........................ ...-:.:::..:....::.:.::........::;:..-:.:::..:....::::.::...............:::.;;.;.:;;.:;..::.::;........:..........:;::::;....-;::;::::,.,
. .t==.y- u  ====:=.  =====:=---==:=::=::==
.. . .:: :  . ': < ..............
1
####
''''''''''''''''''''''''

Строки кода
Рис. 19.6. Средние объемы работ для коммерческих nporpaMMHblx проектов
10.000
.................."............................. ........................... .........................................IIII".............................v..................1III.l1li.............. ..............l1li.... ........... ... l1li............. ........... ... ... .............. l1li.. .... ..........--................
............. ............... . ........................................ ................................................ .......".,... ... ................ ..............
. у......... ............. ....."":"........... . .l1li... ..... . ... . ... ................ ........... ............ ..... ..iIII-IIo... ................. ......... '"":. ................;. .... .... У. ........ .:..... ...... ..... l1li . : ...... ...... ..."," ............""""':'"'................. . ........ ........
........... ...l1li............ ........ .... JI...................... ............... ...........IIII..IIII ..................... .....,.........v..... IIII...IIII............IIII....... ...l1li.................... ......... ...... ...l1li.... ...... ...l1li...... "... ................ )t...........u......... ................................!.............)I.IIII..........
.' ................................... ... ................ ............. .
. .......... ............ ,........;.................:....... . ............. ....:........;.......: ....... -:....... ........"'.......;....... : ........... .....;.. .... ...::.::::: ===7...... .:. =.:.. .... .
............... ...
1.000

... - ........... ..... .................... ..... ... .. .
........................................ ...
. . .. .. 11'1 ............. .........
............. ........у......... ......
.......,...........,........  ...........,.",............................ : ..,.,."""""""'.
.. ............. ..... .........;....... .................... .........l1li. ....l1li..l1li...$+.. ..... .............!.....................IIII.. ........................
.. ..
...... ............. .... ..... ..... ......... ..'Ih-... .....on.. . ...oiI't... .......... ..... ...-............."".... ......,. ...... .-:. .. ... ...........................
.................. .......: ......... ..... . 01' .................. .... .................... . ........ ..... ........... ...... ............ ........ .................
Человеко
месяцы
100
...
... .... ....  +
... l1li.l1li. .........
...................... ................................
... ...............  ......
... .......... .. .. ......... ..... ....................у........ .
. ..
-::_::-:  ::::::.::::.::::.:::.:::::::::::=:.::=::.:=:!:
1 о ...... -'>. ...... .. ............... ..... ... ........ ...... .. . .. .. ....... . ............. ........ ....... .. .............. ..... ........ ..... .... ........................................ .......
..... ......."""'..................l1li. .... -..-..... ...........  ....у.......... ................ . ........ ... ..,"""", .... .......
.,.,.,.. ...........  
. .
. . ..... .........o............................................. ......... .................,..l1li.l1li..l1li..... ........... ........... ... ....... .......... ............. IIII........................................ .................:..............,..... IIII..IIII.IIII.? ...... ...... ..........:............":.............:......... .........
..... ................... ....... ..... ............... ........... ........IIII...........................:.........rI... ...........IIII........... l1li.........l1li...l1li............ ......................<1...,.....................l1li.... ...IIII...IIII.IIII....?IIII......Q...... ..............................................................
...... .......l1li.... ............"""........l1li.l1li.. .......->....................... ......... ......................
...IIII.Ii)......"........................................ ........#...tI ...................
.... ...................................................... ............,;....................................... ............. ......... ..........-4..............0( ..IIII..IIII................................. ........... ...............:-........... ........................................................rt .............IIII..............
1
##########

 
Строки кода
Рис. 19.7. Средние объемы работ для публичных проеКТОI!' интернет"систем

I
Человеко
месяцы
Человеко
месяцы
19.4. Среднеотраслевые rрафики объема работ 219
1 ,000
. . .
. ...... ......... 11...11... ........ l1li..... l1li....l1li.......................11............:,. ......... .. ......... .............. .. . ...... _.11 ... 7.. .
. .
.... ........."........................... ...:;;:.:;:::......:.=........... ...... ... ...... . ..... ......;:...................... . .......l1li..-:-..l1li...........,................. ....
iIII ........... ,.. ........ . .. .... .... ........ :.................... .l1li.. ...l1li......l1li. ........................ ....... .... ......J.........." ............................II.....iIII.. .. .... :'.l1li.
.................................... .... ; ........ .. ...........................l1li......l1li......l1li ....
100
. ..... ............l1li...l1li...... .......... ........................... ... . . ... l1li.l1li....................................... ....... ........
. 
............ iIII........iIII.. ...,............у...................... ..................;......................... ......... .. .......
- .
........... .............. ... .... . . . ..........."'.l1li.....l1li. ............ ............,i,.............. .......... .. ......... ..... ...... ...,..... ......,. ...... ....:.... .... .. ..........................................,.. ..... ... ..... .,......"
......,........ <   .
......................,.........
. -
,
-:-
. .
: ...  .
...... .. ............. . .... ........ ......... .............. .................................._...... ................. . .......v....... h...... . ... iIII-.. ...... .1III...................'V'..............':".............y............. ..IIII................................ l1li..l1li.... iIII-... ....
... . . ...... ....... ."...,.........l1li...... .....iIII-.._ iIII-.... ..............':'_. . ...'У......... ........IIf.......................... ............ .i.............. ; ....... .. . .... .. . .......'!.........у...................... ................ ......l1li....
1 О ........ . .... '" ............................... ....... ........ ........... .... _... ..._... . _ . ... _. .. ...._. ....... ........ . ............... ....... _... ... _ ш . _.. . ...... . _: .... _. ... ........... .
.. .. .... ....... ... ........... .......l1li.... ...... .. .. .... .у............ .......... ............ ............. ... Ikoo. ...... ..""".......... ..... .... .: ............ ............ ..................у.................. .. ... . ....""".. .
........ . ..... .............................iIII-........: .....IIII.....?......illl-illl-..................... ...:...... ................ ....... . ":' ... .......iIII- ................... ......... ..... ................_.:........................................................... ... ........... ....iIII-......................IIII....
....... .... ..........................,................ ........4 ..........................!....................................IIII :............l1li............ .. ..1III..y..IIII-.............................; ........ r ... ........:..............-:,............:-........-:.........II!I,IiII...IIII...iIII-......-:-...............
1III.1III.......................у........... ".......................... ...........,.. .... ....,..IIII.IIII..iIII-..IIII.IIII...... ...... ...............................v..................... .................;..................... ..........iIII-.........IIII.IIII l1lil1li ... ............... ........... .........................
.......... ..""...."""'.......... ..... .-;............-; . ........,. .................. ......... .
.... .................. ......-...-....... ............... -i;................... ........ .................. ..._.........
- .
.. ...
.. ................ .......... ..................l1li... ......... . ..............:..............-:"...........-:............. r .......................... .........""" .......
1
&@@@&&&&@&
с;::) c::::s  <:s с;::) с;::) c::::s с;::) <::s "C5 с5  с5 с5 <::s c::::s c::s c::::s c:::s <:s <:s <:s с5 с;::)
"" " " " " (:)" (:)" " " " <:::)" !::)" " с;:::)" <;:)" " " " " S:::>" С).. " " с;:::)" "

Строки кода
Рис. 19.8. Средние объемы работ для интрасетевых проектов
10,000
. .....". ..................... ... .l1li.................l1li...... ..... ... ...............y.............. ...... .... ...........!..........................J". ...... ... ..... ..... ...... ......... .1Ii..,.... ............ ......... l1li.............. .iIII-..iIII-...............................
 .................................... ....  i    7 ..",..,.."...........................
 .1III"'..""""IIII"."'.iIII-".IIII.illl-IIII""'''''.''.''.':'",,,,,..:::,,..,,,,,,. ... ........ =..........;......... .. :.=::::::..........,...IIII.IIII.....................iIII-...iIII-......'W'...............:.. ....+........ .. .... ................ ................................ :. . ......у.............. ..................... 
. .. . ..  J . . .
- ............................;........: ............ ...........:.......  ....................;._............:.._.....:...._...:..._......................... ............... ;........;........ : ......
1,000
.... .. . ...... .... .........iIII-. 11.01- ....iIII-...IIII..... ..l1li.. ........у .. ... ............... ..... ....... .... ....... ...... ........ ......... .. ... ..... ... ..... ..... .iIII-..... ........ ..... "'. .... iIII-.. .... .......... .........
.. .....с,............ ..... ... .. .. ........ .. .....у..... .l1li..,.. .... ................. ....... . .. .......... ......... .......... ........... ... .. ............ ........... .. ......... .. .. .... .
.. ....... ...... .......... .... .............. .........." ...,....... ......... u ..... ....-.,........ ..l1li.... ....... .. .. . . .....111;.... .................................... ............... ............ ..............-:... ..... ............... ... .......... ........... ... ...........0l\OIII.........
. ...iIII-.IIII l1li..............."".. ........... ......... ............. ..... ........ ....... ...;0. .... . .. ....... .............IIII...a........................... ...................... .................................................................... .... ......... ........... ........
.. .. ............. ......... ......... ....,...___............-.... ,. .. .... ........-........._..........-.................... .... .... ... ........"l1li'..... ...................
. ............. ...........,..... ........... ..................................... 7. .  .. ............ ...... ....... .............,..,...,..l1li.......... ............:- ...... ........................... .......... ....  ...................OiII'......................"""".. .......
. ... ""............._.IIIIIA-. 6.................. ........ ....... .. .............. .....'Y"IIII.....iIII-..................""'.. .....,.. ................. .. ...... ""","," .... .......................у.. ..........,.................IIIIfIIOIO_....--............U_ 111...
100
. .... .... . ш   ............... ..... .__. . . ". .  .
.. .. .. ... ..... .... ................ .... ... ... . .. .. .... . ...."7' .... ..7..7 ... .. ''7..' ....... . ...... .... ..7... ........... r.. ..7 .... .7... r.. ... .r.r. .
... ...... ....... . .......... .. ............... ........iIII-...... .. ....111'" lIII.iIII-...iIII-..IIII}11-IIII... l1li.,... .............................. ........."'............................. .......... ............................... ............. ...... .................. ........ ..... ............................_................ ......._
: ..1III..:...........tII........::..:..: :.. :.. .. .:iIII-...:.............  o!! . .1I!1III..........".........,...............:.:."...o!!.".....lI!lIIIo!!..:...IIII"..IIII.: .:"'IIII..iIII-::.......!I.:.......:"'........:...IIII..........:.:..ri...::...:..III.....::......................,:...:........::. :......iIII-.....::.....:....:...:......::....::........:.,...:.......... :......:....:. ..: ........;..iIII-.......:........ :..:::............:,:.......
4 ... .......... ... .. ..... ............. ..... l1li.......,.....l1li........,. 1III.................IIII.IIII........iIII-.iIII-.........................':'..........-:............ ........... ................,,':"..........:....................................:............................................................................. ................................,
. -..
. .... ..  ,.. . l1li... "'. ...........................<1' ...... .. ................... ..................... ....... .............................l1li..........l1li............ ..............iIII-..iIII-......".........iIII-."......iIII-.... III'".....................................iIII-...................IIII.......IIII... iIII-...iIII-.... .....iIII-.... ...........
. . .... ... ......... ... ......,......... ....................... ,.........................,..........,....'....IIII..........IIII.iIII-...iIII-....V.... IIII ........iIII-...""......."":.. .........ф-............... .........,................................;-......... .................!............ .............V.................... .......
10
 ........ ... ..-. ............ """  .",.  ..
. ...... ............. ........................ ................... ........................l1li...l1li.,.......l1li.. l1li 1III............IIII...illl-IIII.IIII.IIII.. ..........iIII-............................................................ ............. ............................................ .. ...................................iIII-.... ....iIII-......
. ... . .............. ...........Jt..........,......... ..l1li... . ... ...... ..... l1li........... ....l1li........ l1li.l1li.......... .... .. l1li .l1li..l1li...l1li lIIIi111-.......... ................l1li.............................................................................. ...................... ........................ .......... ............ ........... ..............
................................................................................................ .....................................-.. ...... .( .-..-....................
. -
. 4 .................. ......... OiIII,.................................... ..... .................................,..............l1li............. ..l1li. ..iIII-...IIt..............................................ф............ .........."'-........................... ... .....................iIII-......"" . ....... ....... .....
. ..... ........... ........................,.........,...................................... l1li.... . ...IIII................IIII..IIII .......,.. .-. .illl-IIII.........IIII..IIII...................,:,........................................."'......................................,.............................................,.............................
. ...... 1III......................iIII-.......IIII.........iIII-.........................!........!............-:--..........!............ ........................ ........................... .........iIII-.. .iIII-..................iIII-..IIII....,....... _....IIII...........IIII........................................... .........,......,................
1
&&&&&&&&&
c;::)c;::)c;::)c;::)c;::)c:::s


Строки кода
Рис. 19.9. Средние объемы работ для би3нессистем

220 rлава 19 · Специфические проблемы при оценке объема работ
Математическая база таких rрафиков достаточно сложна, поэтому формулы
в книrе не приводятся. Объемы работ по rpафикам отсчитываются по лоrариф
мической шкале. Первая строка над 100 означает 200, вторая  300, первая CTpO
ка над 1000  2000 и т. д.
[рафики получаются похожими друr на друrа, но внимательный анализ точек
данных показывает, что в действительности они весьма различны. Например,
сравните средние и стандартные отклонения над 100 000 строк кода, и вы увиди
те, что объемы работ в человекомесяцах сильно различаются.
По среднеотраслевым rрафикам мы можем пересмотреть оценку примера,
приведенноrо в разделе 19.2. НаПОМНIО, что это был проект бизнессистемы, а ero
раЗlер составлял от 65 000 до 100 000 строк кода. Соrласно рис. 19.9, средний
объем работ для бизнессистемы в 65 000 строк составляет около 85 человекомеся
цев. Средний объем работы для системы в 100 000 строк составит около 170 чело
векомесяцев. Если бы вместо среднеrо значения мы использовали верхнюю rpa
ницу, оценка бы лежала в диапазоне от 300 до 600 человекомесяцев.
СОВЕТ NQ 86
Используйте среднеотраслевые rрафики для получения rрубой оценки объема работ в широкой
части конуса неопределенности. Помните, что в крупных проектах затраты, связанные с приме
нением более мощных методов оценки, быстро окупаются.
19.5. Метод ISBSG
rруппа ISBSG (International Software Benchmarking Standard Group) разработала
,
интересную и полезную методику вычисления объема работ, oCHoBaHHYIO на трех
факторах: размере проrраммноrо проекта в функциональных пунктах, типа среды
разработки и максимальном размере rруппы (ISBSG 2005). Далее приводятся
восемь формул для оценки объема работ для разных типов проектов. Формулы
выдают оценку в человекомесяцах в предположении, что один человекомесяц
составляет 132 часа плотной работы над проектом (то есть за исключением OT
пусков, выходных, обучения, собраний и т. д.). Первая формула общеrо назначе
ния, приrодная для проектов любых типов, базируется на калибровочных дaH
ных примерно 600 проектов. Друrие катеrории калибровались по данным от 63
до 363 проектов.
Тип: общий
ФОРМУЛА NQ 9
ЧеловекоМесяцы = 0,512 х ФункциональныеПункты О ,392 х МаксимальныйРазмерrруппы О ,791.
Тип проекта: проект для больших компьютеров (мейнфреймов)
ФОРМУЛА NQ 10
ЧеловекоМесяцы = 0,685 х ФункциональныеПункты О ,SО7 х МаксимальныйРазмерrруппы О ,4б4.

19.5. Метод ISBSG 221
Тип: проект среднеrо диапазона
ФОРМУЛА NQ 11
ЧеловекоМесяцы = 0,472 х ФункциональныеПункты О ,375 х МаксимальныйРазмерrруппы О ,882.
Тип: настольная система
ФОРМУЛА NQ 12
ЧеловекоМесяцы = 0,157 х ФункциональныеПункты О ,591 х МаксимальныйРазмерrруппы О ,810.
Тип: языки TpeTbero поколения
ФОРМУЛА NQ 13
ЧеловекоМесяцы = 0,425 х ФункциональныеПункты О ,488 х МаксимальныйРазмерrруппы О ,б97.
Тип: языки четвертоrо поколения
ФОРМУЛА NQ 14
ЧеловекоМесяцы = 0,317 х ФункциональныеПункты О ,472 х МаксимальныйРазмерrруппы О ,784.
Тип: доработка существующих проектов
ФОРМУЛА NQ 15
ЧеловекоМесяцы = 0,669 х ФункциональныеПункты О ,338 х МаксимальныйРазмерrруппы О ,758.
Тип: новая разработка
ФОРМУЛА NQ 16
ЧеловекоМесяцы = 0,520 х ФункциональныеПункты О ,385 х МаксимальныйРазмерrруппы О ,8бб.
Предположим, вы создаете оценку объема для настольноrо бизнесприложе
ния в 1450 функциональных пунктов на языке Java (та же система, которую l\lbI
уже оценивали в этой rлаве), а максимальный размер rруппы составляет 7 чело
век. Формула для настольных приложений подсказывает, что объем работы co
ставит 56 человекомесяцев:
0,157 х 1,4500,591 Х 70,810.
Формула для языков TpeTbero поколения дает оценку в 58 человекомесяцев:
0,425 х 1,4500.488 Х 70,697.
Интересная особенность метода ISBSG заключается в том, что формулы для
объема работ зависят от максимальноrо размера rруппы, а команды меньшеrо
размера уменьшают общий объем. Изменение максимальноrо размера rруппы
в этом при мере с 5 до 10 человек приводит к изменеНИIО оценки с 43 до 75 челове
комесяцев. С точки зрения оценки это создает неопределенность. С точки зрс
ния управления проектом эти различия MorYT заставить вас использовать rруп
пу 1\lеньшеrо размера вместо большей (эта тема дополнительно рассматривается
в подразделе «Сокращение срока и раЗl\lер rруппы» раздела 20.6).

222 rлава 19 · Специфические проблемы при оценке объема работ
СОВЕТ NQ 87
Используйте метод ISBSG для получения rрубой оценки объема работ. Сравните ero с друrими
методами и проанализируйте схождение или расхождение оценок.
19. б. Сра внен ие оценок объема работ
Для проверки реалистичности этих оценок можно сравнить четыре разных метода
оценки объема работ, представленные в этой rлаве:
. неформальные сравнения с прошлыми проектами;
. использование оценочных проrpамм;
. использование среднеотраслевых rpафиков;
. метод ISБSG.
На рис. 19.10 показано, как выrлядят диапазоны оценок, полученных этими
методами.
Неформальное
сравнение
с прошлыми
продуктами
Оценка Construx
(исторические
данные)
Среднеотраслевой
rрафик(<<средняя»
линия)
Метод ISBSG
.t. t ...
...

 ... .... ..
...... .. "'"
t
.-. ....
..... .....
о 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170
Человекомесяцы
Рис. 19.10. Диапазоны оценок, полученных методами, рассматриваемыми в этой rлаве.
Относительные размеры точек и толщина линий представляют весовые коэффициенты,
которые я присвоил каждому из представленных методов
На rрафике показан диапазон оценок от 40 до 11 О человеко месяцев. Как в Me
тоде ISБSG, так и на среднеотраслевых rpафиках используются среднеотрасле
вые данные, поэтому я присвоил им меньший вес, чем методам, основанным на
исторических данных. При нефОРlальном сравнении с прошлыми проектами я
присваивал наибольший вес самым похожим проектам (включая максимальное
сходство размеров).
С учетом всех факторов в данном случае я бы представил оценку от 65 до 100 че
ловекомесяцев с ожидаемым результатом в 80 человекомесяцев. Можно бы
ло бы предположить, что ожидаемый результат попадет в середину диапазо
на 65100, но объем работ часто смещается к нижней rpанице диапазона изза
воздействия факторов, описанных в разделе 1.4.

Дополнительные ресурсы 223
СОВЕТ NQ 88
Не все методы оценки равны. При поиске схождения или расхождения между оценками при
сваивайте большие весовые коэффициенты методам, дающим более точные результаты.
Дополнительные ресурсы
Воеhш, Barry, et al. Software Cost Estimation with Cocomo.II». Reading, МА: Addison
Wesley, 2000. Модель оценки Сосоmо 11, описанная в книrе, содержит формулы
для преобразования оценки размеров, выраженной в строках проrраIмноrо кода,
в объем работ. Не забывайте о проблемах субъективных реryляторов».
ISBSG. Practical Project Estimation, 2nd Edition: А Toolkit for Estimating
Software Development Effort and Duration. Victoria, Australia: International Software
Benchlnarking Standards Group, February 2005. В книrе приведено множество по
лезных формул для вычисления оценки объема работ по оценке размера. Книrа
приятно удивляет объективными характеристиками точности своих формул; в нее
включены примеры размеров и тестовых значений, которые MOryT использовать
ся для проверки точности формул.
Putnam, Lawrence Н. and Ware Myers. Measures for Excellence: Reliable Soft
ware Оп Time, Within Budget». Englewood Cliffs, NJ: Yourdon Press, 1992. Модель
Путнэма, описанная в книrе, преобразует оценку размера, выраженную в строках
кода, в оценку объема работ.
I

Специфические
проблемы при
оценке сроков
Область применения методов этой rлавы
&азовая формула Неформапьное Метод оценки Оценочные
для вычисления сравнение nepBoro порядка nporpaMMbI
срока с прошлыми
проектами
Что оценивается Срок Срок Срок Срок
Размер проекта СБ МСБ СБ СБ
Стадия разработки Ранняя Ранняя Ранняя Ранняя
Итеративный или Последовательный Оба Последовательный Оба
v
последовательныи
стиль
Возможная точность Средняя Средняя Низкая Высокая
Немалая часть давления на проект возникает изза предельных сроков, обуслов
ленных обязательствами перед клиентами, проведением выставок, сезонными
продажами, нормативам и друrими календарными датами. Вероятно, именно cpo
, ки вызывают самые жаркие споры при обсуждении оценок.
Как ни парадоксально, при переходе от интуитивных оценок к методам, бази
рующимся на исторических данных, оценка срока превращается в элементарное
вычисление по оценкаl\{ размера и объема работ.
20.1. Базовая формула для вычисления срока
Приближенная оценка срока на ранней стадии проекта может про изводиться по
базовой формуле:
ФОРМУЛА NQ 17
СрокВМесяцах = 3,0 х ЧеловекоМесяцы 1 / 3 .

20.1. Базовая формула для вычисления срока 225
Если вы подзабыли математику, на всякий случай напомню, что показатель
степени 1/3 означает кубический корень.
I1ноrда 3,0 заменяется на 2,0, 2,5, 3,5, 4,0 или друrое число, но основная идея,
по которой срок вычисляется как кубический корень из объема работ, признается
почти всеми экспертами в области оценки (конкретный множитель может быть
получен посредством калибровки по историческим данным орrанизации). Барри
Бем заметил в 1981 rоду, что эта формула стала одним из Cal\fbIX растиражирован
ных результатов в проrраммотехнике (Boehm 1981). Анализ, проводившийся на
протяжении нескольких прошедших десятилетий, подтвердил состоятельность
формулы (Boehm 2000, Stutzke 2005).
Допустим, на построение проекта вам потребуется 80 человекомесяцев. Вычис
ленные по формуле сроки лежат в диапазоне от 8,6 до 17,2 месяца, в зависимо
сти от выбора коэффициента в диапазоне от 2,0 до 4,0. Номинальный срок будет
равен (3,0 х 801/3), то есть 12,9 месяца. (Я не рекомеНДУIО представлять оценку
срока с такой четкостью и привожу ее лишь для Toro, чтобы вам было проще сле
дить за вычислениями.)
СОВЕТ NQ 89 .
Используйте базовую формулу для ранней оценки срока в средних и крупных проектах.
ФОРl\tlула вычисления срока имеет интересные последствия для конуса неоп
ределенности, как показывают числа у правой оси на рис. 20.1.
4х
2х

\
,
"\
\
"
( .....,
"
.,.
.......)':-...:..
'.'« "<-"oY"'....-..:«..
""'А.ун.......n...... .).."Y..H'.:.x"" ...........,.,.:«.,J'.....
.....:.:.:.;,..y.......... ..::..:: :0»;;>::-;0; 
....:-".-.v.. ....JY'.I':"'»',' ..... ,"« 'vo"","" ......
.''''..0.-...... «'yY...
",,,,,.< ......
/"
...:'
I
.
/
11"
/1 I
 r
1.6х
..о -л
t5  :Е  t5 1 .5х
ОфQ)Uо
:I: ,а ,а O:I: 1 25х
ffi \о '8 :Е ..о '
 О '""   1 .ох
af     О,8х
 g R   О,67х
Q)шt:>.
::I: -8-
О.5х
1,25х
..о
1,15х t5 ш
О О
1,1х :I: 
:I: О CtJ
1.0х Q) g. 
ФФ
О.9х r::tO
Q):I:a.
а.ФС:
О.85х t:::r
О О
Q) Ш
О.8х ::I:
о ,25х
О,6х
Время
Рис. 20.1. Конус неопределенности с поправками сроков на правой оси. Неопределенность
сроков rораздо меньше неопределенности объема, потому что срок вычисляется
как бический корень из объема работ
Формула срока является одной из причин, изза которых диапазоны неопре
деленности для объема работ на рис. 20.1 rораздо шире, чем для сроков. Объеl\1
работ возрастает пропорционально объему проекта, тоrда как срок возрастает про
порционально кубическому корню из объема работ.
8 Зах. 893

226 rлава 20 . Специфические проблемы при оценке сроков
Формула срока неявно подразумевает, что размер rpуппы может реryлировать
ся до размера, следующеrо из уравнения. При фиксированном размере rруппы
срок не будет меняться пропорционально кубическому корню объема; он будет
меняться более значительно в зависимостИ от оrраничений размера rруппы. Эта
проблема более подробно рассматривается в разделе 20.7.
Базовая формула для вычисления срока не предназначена для малых проектов
или на поздних фазах больших проектов. Коrда становятся известными :имена
конкретных Лlодей, работающих над проектом, переключайтесь на друrой метод.
20.2. Вычисление срока посредством
неформальных сравнений с прошлыми
проектами
Уильям Ротцхейм (William Roetzheim) предложил оценивать сроки новых про
ектов по соотношеНИIО сроков и объемов работ в лрошлых проектах (Roetzheim
1988, Stutzke 2005). Возьмем те же проекты, которые были использованы в rла
ве 19; для удобства их данные повторены в табл. 20.1.
Таблица 20.1. Пример данных о производительности прошлых проектов, заложенных
в основу для оценки сроков
Проект Размер Срок
(LOC) (календарные
месяцы)
8,2
12,5
4,7
Проект Д
Проект В
Проект С
33 842
97 614
7444
Объем работ
(человеко-
месяцы)
21
9
2
Производитель-
ность (LOC/
человеко-месяц)
1612
986
3722
Комментарии
Не используется 
слишком мал
ДЛЯ сравнения
Проект D
Проект Е
54 322 11,3
340 343 24,0
40
533
1358
639
Не используется 
слишком велик
для сравнения
Ротцхейм предлаrает оценивать срок в месяцах по формуле неформальноrо
сравнения с прошлыми проектами:
ФОРМУЛА NQ 18
ОценкаСрока = ПрошлыйСрок х (оценкаОбъемаРабот/ПрошлыйОбъемРабот) 1/3.
Показатель степени 1/3 используется в тех проектах, которые в книrе OTHece
ны к катеrории средних и крупных (более 50 человекомесяцев). Для более мел
ких проектов следует использовать показатель степени 1/2.
В rлаве 19 объем работ оценивался от 65 до 100 человекомесяцев при наибо
лее вероятной оценке в 80 человекомесяцев. Таким образом, мы получаем oцe
ниваемые сроки из прошлых проектов, приведенные в табл. 20.2.

20.3. Метод оценки nepBoro порядка 227
Таблица 20.2. Оцениваемые сроки из прошлых проектов
Проект Исторические данные
Прошлый срок Прошлый объем
(календарные работ (человеко
месяцы) месяцы)
Проект А 8,2
Проект В 12,5
Проект D 11,3
21
99
40
12,0
10,8
13,2
Оценки
Номинальная
оценка (80
человеко
месяцев)
12,8
11,6
14,2
Высокая
оценка (100
человеко
месяцев)
13,8
12,5
15,3
Низкая оценка
(65 человеко
месяцев)
По методике Ротцхейма диапазон лучшийхудший случай» составляет 10,8
17,3 месяца. Я бы оценил ожидаемый случай простым усреднением трех номи
нальных оценок из таблицы, после чеrо вычислил веРХНЮIО и НИЖНЮIО rраницы
диапазона усреднением верхних и нижних оценок из таблицы. Вычисления дают
НО?vIИНальный срок  12,9 месяца с диапазоном 12,0 13,9 месяца.
СОВЕТ NQ 90
Используйте формулу нефррмальноrо сравнения с прошлыми проектами для ранней оценки
срока в проектах любоrо размера.
20.3. Метод оценки nepBoro порядка
Если известен размер проекта в функциональных пунктах, rруБУIО оценку срока
можно вычислить прямо по нему. Для этой цели используется метод, который
Кейперс Джоне назвал MeTOДOM оценки первоrо порядка» (Jones 1996). Возьми
те суммарный размер в функциональных пунктах и возведите ero в нужную CTe
пень, выбранную из табл. 20.3. Средние показатели степени в таблице получены
на основе анализа нескольких тысяч проектов, проведенноrо Джонсом. Я доба
вил приблизительные оценки лучшеrо и худшеrо случаев, чтобы отразить pacxo
ждения в производительности.
Таблица 20.3. Показатели степени для вычисления сроков по функциональным пунктам
Тип nporpaMMbI
Объектноориентированная nporpaMMa
Клиентсерверная nporpaMMa
Бизнессистемы, интрасетевые системы
Коммерческие пакеты, научные и инженерные системы,
публичные интернетсистемы
Встроенные системы, телекоммуникации, драйверы
устройств, системные nporpaMMbI
Источник: Адаптировано по .материалам .Deterтiпiпg Sotware Schedules Uones 1995с)
и .Estimatiпg Software Costs. Uoпes 1996).
Лучший Средний Худший
0,33 0,36 0,39
0,34 0,37 0,40
0,36 0,39 0,42
0,37 0,40 0,43
0,38 0,41 0,44
Если общее количество функциональных пунктов проекта равно 1450, а ваша op
rанизация занимается разработкой бизнессистем со средней производительностью,

228 rлава 20 . Специфические проблемы при оценке сроков
возведение 1450 в степень 0,39 (14500,39) дает rpубую оценку в 17 календарных
месяцев. Если же ваша орrанизация занимается разработкой бизнессистем и яв
ляется лучшеЙ в своем классе, то 1,450 возводится в степень 0,36, что дает срок
в 14 месяцев. Если же вы разрабатываете объектноориентированные бизнессис
Tef\fbI, показатели степени для объектноориентированноrо проrраммноrо обеспе
чения дают диапазон от 11 до 17 месяцев. Таким образом, можно сделать вывод,
что реальный срок лежит rдето в диапазоне от 11 до 17 месяцев.
Эта методика не заменит более тщательной оценки срока, но она предоставля
ет простое средство получения rрубой оценки, которое все же лучше простых дo
rадок. Кроме Toro, она позволяет быстро проверить задачи на реалистичность.
Если вы хотите разработать бизнессистему в 1450 пунктов за 9 месяцев, поду
l\lайте заново. Для самых передовых орrанизаций срок составит от 11 до 14 меся
цеп, а большинство орrанизаций к передовым не относятся. Метод оценки перво
ro порядка поможет Ba?vI побыстрее узнать, не нужно ли внести изменения в ваши
предположения о функциональности и/или сроках.
СОВЕТ NQ 91
Используйте метод оценки nepBoro порядка для получения неточной (но требующей крайне Ma
лых усилий) оценки срока на ранней стадии проекта.
20.4. Вычисление оценки срока
научными методами
в конечном итоrе неформальные методы плохо подходят для получения точной
оценки. Сроки слишком'сильно изменяются в зависимости от множества факто
ров. Сам:ый простой и точный способ вычисления оценки основан на использова
нии таких вспомоrательных инструментов, как Construx Estimate 1 .
Что произойдет, если мы используем Construx Estimate для вычисления oцeH
ки срока в рассматриваемом примере? При калибровке историческими данными
объемов работы и сроков, представленными в rлаве 19, Construx Estimate вычисля
ет срок в 12,2 календарных месяца, с диапазоном достоверности 2080 % от 11,6
до 12,9 месяца. При среднеотраслевых данных номинал составляет 15,8 месяца,
а дпапазон  от 13,2 до 21,5 месяца!
Расхождения между номинальными значениями J'I диапазонам, вычисленны
ми по историчеСКИl\1 и среднеотраслевым данным, демонстрируют преимущества
от использования исторических данных.
20.5. Сжатие rрафика и размер rpYnnbI
После Toro как номинальная оценка будет вычислена, часто возникает вопрос:
«На сколько можно будет сократить срок в случае необходимости?» Ответ зави
сит от rибкости набора функций. Если из проекта можно исключать те или иные
1 Проrpамму Construx Estimate можно бесплатно заrpузить по адресу w\\rw.construx.com/
estimate.

20.5. Сжатие rрафика и размер rpYnnbI 229
функции, срок IОЖНО сократить насколько потребуется, в зависимости от вашей
rотовности к усечению функций. На выполнение меньшей работы требуется
меньше вреrvIени, что вполне лоrllЧНО.
Если функциональность жестко фиксирована, сокращение срока может быть
достиrнуто только за счет добавления персонала, который бы выполнял больше
работы за меньшее вреl\IЯ... что до определенноrо момента тоже вполне лоrично
За несколько прошедших десятилетий мноrие исследователи, занимающиеся
оценкой проrраммных проектов, анализировали послеДСТВI1Я попыток сжатия
номинальных сроков. Результаты их исследований показаны на рис. 20.2.
Относительный объем работ
(объем для желаемоrо срокаl
объем ДЛЯ номинальноrо срока)
1.4
1.2
Jensen Putnam
. 
't
.

.
.
.
,
1.3
P$N: 1 :
a
нееозм6ЖНQСtl.1
1.1
Webmo
...... Price
0.1
02 03 ОА O O ОЗ ОВ ОЗ
Относительный срок
(желаемый срок!
номинальный срок)
Сосото 11
1.:. 1.2 1.3
.\ '. \. .... ......
'.\ '. ..... ......
\ \ '. ........ ...... .... ....
.\ '. ...... ...
\\. .....
\\. ......
t \.. ..... Метод
.\ '. оценки
 \ Mk 11
.
1.0
0.9
08
аз
ISBSG
Рис. 20.2. Последствия сжатия или расширения номинальных сроков и зона невозможности.
Все исследователи обнаружили, что возможности сжатия срока оrраничены
ИстОЧllик: Адаптирова1l0 по материала.м Softwal.e Siziпg aпd Estimatiпg: Mk //  (Sy
тoпs 1991), Softlf)are Cost Estiтatioп with Сосото 11. (Boehт et al. 2000), «Estiтatiпg Web
Developтeпt Costs: There Are Diffel.ences (Reifer 2002) и P1.actical Project Esl"iтatioп1 2nd
Editioп (ISBSG 2005).
По rоризонтальной оси отсчитывается отношение между номина.ilЬНЫМ и сжа
тым сроками. Скажем, отметка 0,9 означает, что сжатый срок занимает 0,9 от
времени, соотвеТСТВУlощеrо номинальному сроку (то есть 90 % от номинала)
Вертикальная ось представляет общий объем работ, необходимый при сжатии
или расширении срока, по сравнению с номиналом. Значение 1,3 указывает, что
сжатый срок требует в 1,3 раза больше работы, чем номинальный.
Из rрафика на рис. 20.2 можно сделать ряд выводов.

230 rлава 20 . Специфические проблемы при оценке сроков
Сокращение номинальноrо срока приводит к увеличению объема работ. Все
исследователи сошлись на том, что сокращение номинальноrо срока увеличивает
общиЙ объем работ. Если НОIИНальный срок составляет 12 месяцев для rруппы
из 7 человек, то простое увеличение персонала до 12 человек не позволит COKpa
тить срок ДО 7 Iесяцев.
Сокращение сроков приводит к увеличению объема работы по нескольким
причинам.
. В больших rpуппах увеличиваются издержки на координацИIО и управление.
. В больших rруппах увеличивается количество КОММУНИI(ационных путей.
Это создает больше возможностей для недоразумений и увеличивает Bepo
ятность ошибок, которые затем приходится исправлять. Лоренс Путнэм за
метил, что для кратчайшеrо из возможных сроков также характерна наи
большая вероятность ошибок (Putnam and Myers 2003).
. При сжатых сроках большую часть работы приходится выполнять парал
лельно. Чем больше объеtvI перекрывающейся работы, тем выше вероят
ность Toro, что одна часть работы будет завис.еть от незаконченной или дe
фектной части друrой работы, а последующие изменения увеличат объем
необходимой работы по исправлению.
Мнения экспертов по поводу Toro, насколько сокращение сроков увеличивает
объем работ, различаIОТСЯ, но все эксперты сходятся на том, что это явление сущест
вует. Соотношение между срока1И и объемами работ обсуждается в разделе 20.6.
СОВЕТ NQ 92
Не сокращайте оценку СрОКр без увеличения оценки объема работ.
Зона невозможности существует, и с этим ничеrо не сделать. Если 8 человек
IOryT написать проrраМtvlУ за 1 О месяцев, cIorYT ли 80 человек написать ту же
проrрамму за один tvlесяц? А 1600 Лlодей за один день? Неэффективность крайне
ro сжатия сроков становится особенно очевидной на крайних случаях  таких,
как 1600 ЛlодеЙ за один день.
Вычисление пределов менее радикальноrо сжатия сроков является нетривиаль
ноЙ проблемоЙ, но все исследователи сошлись на том, что существует некая зона
невозможности  точка, за пределами которой сжать номинальный срок уже не
удастся. По их общему м:нению, сокращение срока более 25 % номинала невозможно.
30Ha неВОЗ?\-IОЖНОСТИ» показана на рис. 20.2. Сокращение срока разработки
попросту невозможно. Ни за счет более усердной работы. Ни за счет повыше
ния ее эффективности. Ни за счет поиска более современных решений или YBe
личения размера rруппы. Просто невозможно, и все (Symons, 1991, ВоеЬm 2000,
Putnaln and Myers 2003).
СОВЕТ NQ 93
Не сокращайте номинальный срок более чем на 25 О/о. Иначе rоворя, не пытайтесь ввести oцeH
ки в «зону невозможности».
Увеличение срока по отношению к номиналу обычно приводит к сокраще..
нию общеrо объема работ при сокращении размера rруппы. Эксперты также

20.6. Соотношения между сроком и объемом работ 231
сделали общий вывод, что увеличение срока за пределы номинала способствует
уменьшению общеrо объема работ по тем же причинам, по которым сокращение
срока увеличивает объем работ. При увеличении срока появляется возможность
использования rpуппы меньшеrо размера, что снижает проблемы с коммуника
циями и координацией работ. Также снижается перекрытие операций, блаrодаря
чему больше дефектов исправляется своевременно, пока они еще не успели про
никнуть в друrие компоненты и увеличить объем переработки.
Чтобы увеличение срока привело к снижению объема работы, необходимо
уменьшить размер rруппы. Если тот же проект будет поручен тем же участникам
и каждому из них достанется часть от прежней работы, скорее Bcero, вы лишь
ухудшите положение (причины объясняются в разделе 3.1).
СОВЕТ NQ 94
Чтобы снизить стоимость проекта, увеличьте срок и используйте rруппу меньшей численности.
20.6. Соотношения между сроком и объемом работ
в модель оценки Лоренса Путнэма входят эмпирические правила сжатия и pac
ширения сроков, представленные в табл. 20.4.
Таблица 20.4. Рекомендуемые соотношения между сроком и объемом работ
Увеличение/уменьшение срока
 15 О/о
 1 О О/о
5 О/о
Номинал
+ 10 О/о
+20 О/о
+ ЗА О/о
Более ЗА О/о
Увеличение/уменьшение объема работ
+100 О/о
+ 50 О/о
+25 О/о
О О/о
 ЗА О/о
50 О/о
5 О/о
Не практично
Источник: По данным Меasиrеs for Ехсеllепсе (Putпam aпd Myers 1992).
Путнэм предупреждает, что при увеличении срока более чем на 30 % начинает
снижаться эффективность работы, а это, в свою очередь, приводит к увеличению
затрат.
Некоторые специалисты критиковали модель Путнэма за преувеличение по
следствий увеличения и уменьшения сроков, но данные International Software
Benchrnarking Standards Group от 2005 rода демонстрируют очень похожие pe
зультаты (ISBSG 2005). .
Сокращение срока и размер rpYnnbI
При снижении срока ниже номинала возникает еще одна потенциальная проблема:
даже если вы не попадете в «зону невозможности», может оказаться, что размер

232 rлава 20 · Специфические проблемы при оценке сроков
rруппы придется увеличить выше ЭКОНО1\1ически эффективноrо :tvlаксимума. Лоренс
Путнэм провел интереснейшие исследования связей между размером rруппы,
сроками и производительностью для бизнессистем среднеrо раЗIVlера. Получен
ные Иl результаты показаны на рис. 20.3 (Putnam and Myers 2003).
.'300
50
45
40
35
за
Срок 25
(месяцы)
20
15
10
5
О
... .0 Срок . ... .....
.. ..  Объем работы ....... .... ....... .... .
...250
.200
Объем
работы
.. 150 (чеЛО8еко
месяцы)
.
-"'"
. 100
'50
- -- r , .... . ......... .... ............l1li.................. ...... . ...... ... _ . l1li................................... ......._ ........ ... ...l1li....l1li........................... .. .............. ...................... ...... ..
1.5 :i: 3
З:t5
5:f:7
9:f:11
15 :f: 20
о
Размер rpYnnbI
Рис. 20.3. Связь между размером rруппы, сроком и объемом работ в бизнессистемах,
состоящих приблизительно из 57 000 строк кода. В rруппах, состоящих более чем
из 57 человек, увеличивается как объем работы, так и срок
Путнэм проанализировал около 500 бизнеспроектов в диапазоне от 35 000
до 95 000 строк кода (LOC), со среДНИ1 размеРОl\1 57 000 строк. Он разделил эти
проекты па 5 катеrОрllЙ в зависимости от размера rрупп разработки. Различия
в средних раЗ1\1ерах проектов для каждоrо размера rруппы лежали в пределах
3000 CTpOIC Путнэм обнару)кил, что увеличение раЗ:tvlера rру'ппы от диапазона
1,53 до 35 приnодило к уменьшению срока и увеличеНИIО объема работ, чеrо
и следовало ожидать. При увеличении размера rpуппы с 35 до 5 7 срок снова
сокраlцался, а объеlVl работ снова возрастал. Но с увеличением раЗlера rруппы
с 5 7 до 9 11 увеличивШlСЯ как срок, так u обьем работ. А при увеличении размера
rруппы с 15 до 20 срок оставался прежним, но объем работ радикально возрастал.
ПодозреваIО (хотя это Bcero лишь мое личное мнение), что данные Путнэма
доказываIОТ, что издержки маСIlIтаба в проrра:tvlМНЫХ проектах предстаВЛЯIОТ
собоЙ не плавную и постепенно возрастаl()ЩУIО, а скорее ступенчатую ФУН!(ЦИIО
с большими потеРЯПI, резко ПРОЯВЛЯIОЩИМИСЯ на определенных размерах.
ПУТНЭl\1 еще не обобшил свои результаты для друrих типов или размеров про
rpaMl\fHbIX проектов, но в области бизнессистем среднеrо размера ero результаты
весьма важны. ПОХО)l(е, для таких проектов ЭI(ономически оптимальной является
rруппа от 5 до 7 человек. В rруппах большеrо размера ухудшаются как сроки, так
и объемы работ.

I
20.7. Оценка срока и оrраничения численности rруппы 233
СОВЕТ NQ 95
В бизнессистемах среднеrо размера (от 35 000 до 100 000 строк кода) не рекомендуется исполь
зовать rруппы численностью более 7 человек.
20.7. Оценка срока и оrраничения
численности rруппы
В общем случае среДНИI':i размер rруппы вычисляется простым делением оценки
объема работ на срок. Если проект в 80 человекомесяцев оценивается 12месяч
ным сроком, то средний размер rруппы равен количеству человекомесяцев, дe
ленному на срок, или 80/12, то есть от 6 до 7 участников.
Оценки сроков, представленные в этой rлаве, выдают номинальный срок для
проекта при известном объеrvIе работ. Эти методы предполаrают, что незаВИСИIО
от номинальноrо срока вы сможете изменить размер команды до нужноrо уровня.
Если на оцениваемый проект можно будет выделить rруппу из 6 7 участников,
вы сможете обеспечить объем работ в 80 человекомесяцев при сроке в 12 кален
дарных месяцев.
Но что делать, если вы располаrаете Bcero 4 работниками? А если проект уже
достиr той стадии, на которой назначаются индивидуальные задания? А если
доступны 10 человек, каждый из которых свободен на 2/3 времени? А если rpуппа
уже сформирована и период комплектования штата не потребуется? Все перечис
ленные факторы не учитываются в формулах этой rлавы; эти формулы представ
ляют собой методы макрооценки, деЙСТВУIОlцие только на ранних стадиях проек
тов в диапазоне от среднеrо до крупноrо размера.
В средних и крупных проектах численность rруппы обычно доводится до
номинальной от начала до середины проекта, а в отдельных случаях изменения
в rруппе продолжаются до завершающих стадий. В проекте среднеrо размера
MOryT работать в среднем 15 человек, но начаться проект может с 5 человек, дoc
тиrнуть 20 на маI(симуме и закончиться с 1 О участниками.
В меньших проектах чаще используется модель «постоянной коrvlплектации» 
rруппа в полном составе начинает работу в день 1, и это продолжается до конца
проекта. Если срок оценивается в 12 месяцев, но ваши планы ПОI(азывают, что
при фактической доступности персонала для реализации 80 человекомесяцев
потребуется 15 месяцев, то исходная оценка замещается вашими планами.
Основной целью методов оценки сроков, описанных в этой rлаве, является не
предсказание дня завершения работы, а проверка реалистичности ваших планов
в отношении сроков.
После TOI'O как вы оцените сроки и убедитесь в разумности своих планов,
детальные аспекты планирования (кто и коrда доступен) имеют более высокий
приоритет по сравнению с исходной оценкой срока.
СОВЕТ NQ 96
Используйте оценку срока для проверки реалистичности своих планов. Для формирования
окончательноrо rрафика следует применять детальное планирование.

234 rлава 20 . Специфические проблемы при оценке сроков
20.8. Сравнение результатов, полученных
разными методами
в этой rлаве мы использовали пять разных методов оценки срока:
. базовая формула для вычисления срока;
. формула неформальной оценки с ПрОШЛЫl\IИ проектами;
. метод оценки первоrо порядка;
. оценочные проrраммы, откалиброванные среднеотраслевыми данными;
. оценочные проrраммы, откалиброванные историческими данными.
На рис. 20.4 представлено наrлядное сравнение оценок, полученных разными
методами.
Базовая формула
.
 ...... .... ... 
 ... ... ... .. :...
- .... ..
... ..
- 
. .. . I-t
Неформальное сравнение
с прошлыми проектами
Метод оценки nepBoro порядка
Construx Estamate (исторические данные)
6 7 8 9 10 11 12 13 14 15 16 17 18
Календарные месяцы
Рис. 20.4. Диапазоны оценок, которые были получены методами, описанными в этой rлаве.
Относительные размеры точек представляют весовые коэффициенты, присвоенные мной
каждой из оценок. Внешний вид оценок (в том числе и недостаточно хорошо обоснованных)
маскирует фактическое схождение оценок
На первый взrляд может показаться, что схождение оценки срока в этом приме
ре оставляет желать лучшеrо. Одно из возможных улучшений предназначено для
базовой формулы, по которой строилась верхняя линия. Общий диапазон, показан
ный на рис. 20.4, предназначен для коэффициентов базовой формулы в диапазо
не от 2,0 до 4,0. Анализ исторических данных позволяет оценить действительный
диапазон значений коэффициента. В примере, рассмотренном в этой rлаве, коэф
фициенты прошлых проектов лежали в диапазоне от 2,7 до 3,7, в результате чеrо
диапазон сроков, получаемых по базовой формуле, сужается до 11,614,1 месяца.
Я снова присвоил высокий весовой коэффициент оценке, полученной в Construx
Estimate, потому что этот метод относится к катеrории научных, и что еще важ
нее  базируется на исторических данных. Оценки базовой формулы и нефор
мальноrо сравнения с прошлыми проектами я бы поставил на второе место, а при
наличии более надежных данных l\1етод оценки первоrо порядка не использовал
бы вообще.

Дополнительные ресурсы 235
На рис. 20.5 показано схождение оценок CpOI(a после удаления излишне обоб
щенных данных.
Базовая формула
Неформальное сравнение
с прошлыми проектами
Construx Estamate (исторические данные)
6 7 8 9 10 11 12 13 14 15 16 17 18
Календарные месяцы
Рис. 20.5. Диапазоны оценок, которые были получены наиболее точными методами.
После удаления оценок, полученных излишне обобщенными способами, схождение
оценок становится очевидным
Руководствуясь получеi-Iными оценками, я бы представил диапазон от 11,5 до
14 месяцев; вероятно, в этом конкретном случае я бы не стал предоставлять oцeH
ку ожидаемоrо случая. Все методы оценки сроков, представленные в этой rлаве,
применяются в широкой части конуса неопределенности, и отсутствие точечной
оценки на столь ранней стадии проекта будет приемлемым.
СОВЕТ NQ 97
Прежде чем искать схождение или расхождение между оценками, исключите из набора данных
результаты, полученные слишком общими методами.
Дополнительные ресурсы
Putnarn, Lawrence Н. and Ware Myers. Five Core Metrics». New York, NY: Dorset
House, 2003. В rлаве 11 подробно описаны потери производительности, возни
кающие при разработке бизнессистем среднеrо размера в rpуппах, численность
которых превышает 7 человек.
Stutzke, Richard D. «Estirnating SoftwareIntensive Systems». Upper Saddle River,
NJ:AddisonWesley, 2005. Стуцке описывает несколько дополнительных методов
для оценки сроков; как правило, для них требуются более обширные математиче
ские вычисления, чем для методов, представленных в этой rлаве.

Оценка
пара метров
планирования
,;
fраница между оценкой проекта и планированием проекта широка и расплывча
та. fvlноrие пара1етры планирования нуждаются в оценке: какой объе1 работы
следует выделить на конструирование, тестирование, постановку требований
и проектирование; сколько тестеров должно приходиться на одноrо разработчика;
сколько человекочасов может быть выделено тому или иному проекту за кален
дарную неделю или 1есяц; каким должен быть буфер риска; и множество друrих
показателей, неоБХОДИМрIХ для целей планирования.
КОI"да проект выходит на уровень планирования, рассматриваемый в этой rла
I3С, цели планирования обычно начинают конфликтовать с целями оценки. Ha
IIp]I1ep, после Toro как вы оцените размер буфера РИСI(а, все последующее плани
РОI3ание управления буфером риска будет направлено на снижение ero величины
(то есть фактически на то, чтобы сделать ero оценку недействительной).
Оценку параlVlетров планирования трудно назвать оценкой в чистом виде:
взаимосвязь fvlежду мелкоструктурными целям:и и оценками должна быть IIHTeH
сивной и итеративноЙ. Целью оценки в этом контексте является проверка реали
стичности исходных планов. Начиная с этоrо момента, на первый план выходят
планирование и управление проектом, а оценки уступают им.
!{ороче rоворя, планирование решает, как вести проект, а оценка  какую вe
ЛИЧИllУ следует заложить в план. Именно этой теме посвящена настоящая rлава.
21.1. Оценка операционной структуры проекта
Одним из важных решений из области планирования должно стать распределе
вие объема работ по требованиям, разработке архитектуры, конструироваНИIО,
тестированию и сопровождению системы. Эти решения должны приниматься как
для последовательных, так и для итеративных проектов. ДРУI"ИМИ словами, вопрос
не в TO1, сколько вреlени следует отвести на ту или иную фазу, а в том, какой
объе1 работ следует закрепить за операциями при их выполнении.


..
21.1. Оценка операционной структуры проекта 237
Оценка объема работ по разным техническим операциям
Обратите внимание: распределеиие, описа1lи0е в этом разделе, oCJloaallo Jla AlO1l0
лuтuой (не деКОАtпозирова1lНОЙ) оценке объема работ, описанной в lЛаве 19.
В табл. 21.1 приведена процентная структура общеrо объема работ с распреде
лением по операциям архитектуры, конструирования и тестирования систеl\-IЫ
(KLOC означает тысячи строк проrpаммноrо кода»). Вследствие эффекта издер
жек масштаба, описанноrо в rлаве 5, доля объема работ, выделяемоrо на каждую
операцию, зависит от размера проекта. Требования и управление обычно OTHO
сятся к особым случаям» и обсуждаются позже.
Таблица 21.1. Примерная структура объема работ в проектах разноrо размера
Размер Операция
Архитектура Конструирование Тестирование системы
1 KLOC 11 О/о 70 О/о 19 О/о
25 KLOC 1 б О/о 57 О/о 27 О/о
125 KLOC 18 О/о 53 О/о 29 О/о
500 KLOC 19 О/о 44 О/о 37 О/о
ИСlпОЧ1Lикu: Albrecht 1979; Boehт 1981; G/G$S 1982; Boehт, Gray, aпd Seewaldt 1984; Boddie 1987;
Card 1987; Gl"ady 1987; МсСаlТУ, Waligora, aпd McDerтott 1989; Putпaт aпd Myel"S 1992;
B,'ooks 1995;]oпes 1998;]oпes 2000; Boehт et al, 2000; Putпaт aпd Mye,"s 2003; Boehт aпd
Тите," 2004; Stutzke 2005.
Данные, приведенные в табл. 21.1, являются прuБЛИJlсеннъu.tu. Они зависят от
при меняемых методов, от выбора модели жизненноrо цикла, от эффективности
работы по КОНТРОЛIО качества JI множества друrих факторов. В I(онеЧНОf итоrе
вы должны построить собственную таблицу по историческим данным своеЙ opra
низации. Впрочем, пока это не будет сделано, используйте данные из табл. 21.1
как отправную точку и отреryлируйте оценку для KOHKpeTHoro типа оценивае10
ro проекта при помощи коэффициентов из табл. 21.5.
Оценка объема работ по требованиям
В табл. 21.1 не включены работы, связанные с требованиями. Если оценка объема
работ производилась по среднеотраслевым данным производительности, учтите,
что в этих данных операции, связанные с требоваНИЯIИ, обычно не учитываются
(впрочем, бывают и исключения; это одна из причин, изза которых в cpeДHeOT
раслевых данных встречается такой разброс).
Оценка, созданная BaM по собственным историческим данным, Iожет ВКЛIО
чать или не включать данные требований в зависимости от Toro, учитываются ли
они в использованных исторических данных.
Модели оценки, в том числе Сосото 11 и модель Путнэма, предполаrают, что по
лученные с их помощью монолитные оценки не включают работу по требованиям.
Одна из причин заключается в том, что доля работы по требованиям изменяется

238 rлава 21 · Оценка параметров планирования
в большей степени, чем доля друrих операциЙ. Бы можете беrло проЙтись по Tpe
бованиям и очень приблизительно определить большой набор, для реализации KO
Toporo потребуются rеркулесовы усилия. С друrой стороны, можно потратить
больше времени и определить меньший набор качественных требований с более
эффективной реализациеЙ.
С учетом Bcero сказанноrо, в табл. 21.2 представлены приблизительные про
центы от общеrо объема работ, которые следует отводить на работу по требовани
яf в проектах разных размеров. Базовая оценка объема работ увеличивается на
процент, приведенный в таблице; результат определяет суммарный объем всех
технических операций с учетом работ по требованиям.
Таблица 21.2. Приблизительная доля работ по требованиям в проектах разных размеров
Размер Приращение базовой оценки
1 KLOC 5 О/о
25 KLOC 5 О/о
125 KLOC 8 О/о
500 KLOC 1 О О/о
ИСlпОЧllики: те же, что для табл. 21.1.
Оценка объема работ по управлению
Как н в случае с требованиями, монолитная оценка объема работ не учитывает
работы, относящиеся к :управлению, если только они не учитываются в исполь
зуемых ваIИ исторических данных. Б табл. 21.3 пред ставлены приблизительные
проценты от общеrо объема работ, которые следует отводить на управляющие
операции в проектах разных размеров. Базовая оценка объема работ также увели
чивается на про цент, приведенный в таблице; результат определяет суммарный
объеl\1 всех технических операций с учеТОf управления.
Таблица 21.3. Приблизительная доля управляющих операций в проектах разных размеров
Размер Приращение базовой оценки из табл. 21.1
(без учета работы по требованиям)
1 О О/о
12 О/о
14 О/о
17 О/о
1 KLOC
25 KLOC
125 KLOC
500 KLOC
Источники: те же, что для табл. 21.1.
Оценка общеrо объема работ
Для простоты вычислений в табл. 21.4 приведены распределения работ по требо
ваниям, архитектуре, конструированию, тестироваНИIО системы и управлению
для проектов разных размеров.

21.1. Оценка операционной структуры проекта 239
Таблица полезна в том случае, коrда данные, которые использовались для Ka
либровки вашей монолитной оценки объема работ, включали работы по требова
ниям и управлению.
Таблица 21.4. Распределение объема работ в проектах разноrо размера
Операция
Требования Архитектура Конструирование Тестирование Управление
и планирование системы
1 KLOC 4 О/о 10 О/о б 1 О/о 1 б О/о 9 О/О
25 KLOC 4 О/о 14 О/о 49 О/о 23 О/о 1 О О/о
125 KLOC 7 О/о 15 О/о 44 О/о 23 О/о 11 О/о
500 KLOC 8 О/о 15 О/о 35 О/о 29 О/о 13 О/о
Источники: те же, что для табл. 21.1.
Поправки для типов проектов
Как было указано в rлаве 5, объем работы зависит от типа проекта. Кроме Toro,
тип влияет на процентное распределение объемов работ по разным типам опера
ций. В табл. 21.5 перечислены поправки, которые необходимо внести в номиналь
ное распределение в зависимости от типа проекта.
Таблица 21.5. Приблизительные поправки для распределения операций
в зависимости от типа проекта
Операция
Бизнес-систеМbI,
внутренние
интрасетеВblе
систеМbI
 3 О/о
 7 О/о
+ 5 О/о
 7 О/о
Встроенные систеМbI,
телекоммуникации,
драйверы устройств,
систеМНblе nporpaMMbI
+ 20 О/о
+ 10 О/о
 1 О О/о
+6 О/о
Коммерческие nporpaMMbI,
наУЧНblе и инженерные
пакеты, публичные
интернет-системы
20 О/о
5 О/о
+ 2 О/о
+9 О/о
Требования
Архитектура
Конструирование
Тестирование
системы
Управление
+ 3 О/о
+ 3 О/о
 15 О/о
Источники: Putпam aпd Myers 1992;joпes 1998;joпes 2000; Boehm et al, 2000; Putпam aпd
Myers 2003; Boehm aпd Tumer 2004; Stutzke 2005.
СОВЕТ NQ 98
При распределении объема работы проекта следует учитывать размер проекта, тип проекта,
а также операции, заложенные в калибровочных данных, использованных для создания исход
ной монолитной оценки.
Пример распределения объема работы
Предположим, вы разрабатываете бизнессистему, которая, соrласно вашей oцeH
ке, будет состоять из 80 000 строк кода (1450 функциональных пунктов) и займет
около 80 человекомесяцев. В основном распределении из табл. 21.1 представлены

240 rлава 21 . Оценка параметров планирования
проценты ДЛЯ проектов в 25 KLOC и 125 KLOC. Проект размером 80 KLOC Ha
ХОДИТСЯ примерно посередине между этими двумя размерами, поэтому мы будем
использовать средние арифметические процентов для 25 и 125 KLOC. В COOTBeT
ствии с полученными данными, 17 % объема выделяется на архитектуру (13,6 че
ловекомесяца), 55 %  на конструирование (44,0 человекомесяца), а 28 %  на
тестирование системы (22,4 человекомесяца). Таблица 21.2 рекомендует увели
чить работу по требованиям на 6,5 % (5,2 человекомесяца), а в соответствии с
табл. 21.3, работа по управлению проектом возрастает на 13 % (10,4 человекоме
сяца). Затем в табл. 21.6 базовое распределение объема работ умножается на по
правочные коэффициенты для проектов бизнессистем.
Таблица 21.6. Применение поправочных коэффициентов к номинальному распределению
объема работ в зависимости от типа проекта
Операция Номинальное Поправка
распределение для бизнес-
(человеко- систем
месяцы)
5,2
13,6
44,0
22,4
+ 5 О/о
Итоrовое
распределение
(в человеко-
месяцах)
.
5,0
12,6
46,6
20,8
Итоrовое
распределение
(в процентах)
Требования
Архитектура
Конструирование
Тестирование
системы
 3 О/о
4 О/О
 7 О/о
13 О/о
51 О/о
22 О/о
 7 О/о
Управление
итоrо
10,4
95,6
+ 3 О/о
10,7
95,7
1 О О/о
100 О/о
в дaHHO1 примере номинальная и итоrовая оценки объеf\1а работы составля
ют 95,6 и 95,7 человекомесяца соответственно. Небольшое несовпадение резуль
татов обусловлено ошибками окруrления.
Следует хорошо понимать, что это распределение работ по фазам является
приближенным, а проценты лишь представляют отправные точки для планирова
НIIЯ. После Toro как оценка выведет вас на прав ильный путь планирования, ис
ходные оценки уступают детальному планированию.
Соотношения между численноcrью разработчиков
и тестеров
Один из самых частых вопросов из области планирования: Сколько разработчи
ков должно приходиться на одноrо тестера?» Некоторые типичные соотношения
перечислены в табл. 21.7.
Данные в таблице были получены орrанизациями, с которыми моя компания
и я сотрудничали последние 10 лет.
Как видно из таблицы, соотношения очень сильно изменяются даже в преде
лах одноrо вида проrраммных проектов. Это вполне объяснимо, потому что co
отношение, хорошо подходящее для конкретной компании или проекта, зави
сит от стиля разработки, сложности тестируемой проrраммы, соотношения

21.2. Оценка срока ДЛЯ разных операций 241
объемов cTaporo и HOBoro кода, квалификации тестеров относительно квалифи
кации разработчиков, степени автоматизации тестирования и множества друrих
факторов.
Таблица 21.7. Примеры соотношений между численноcrью разработчиков и тестеров
Среда
Типичные бизнессистемы (внутренние интрасети,
информационноуправляющие системы и т. д.)
Типичные коммерческие системы (открытые интернет
системы, коммерческие nporpaMMHbIe продукты и т. д.)
Научные и инженерные проекты
Типичные системные проекты
Системы, критические по безопасности
Мicrоsоft Windows 2000
Проrраммное обеспечение космическоrо шапла NASA
Типичные наблюдаемые
соотношения
3:1  20:1 (часто специалистов
по тестированию вообще нет)
1:15:1
5: 1  20: 1 (часто специалистов
по тестированию вообще нет)
1:15:1
5:1  1:2
1:2
1:10
Б конечном итоrе соотношение численности разработчиков и тестеров опре
деляется скорее планированием, а не оценкоЙ, то есть тем, что вы намерены cдe
лать, а не проrнозами Toro, что нужно сделать.
21.2. Оценка срока ДЛЯ разных операций
Распределение календарноrо времени по разным операциям и фазам проекта
также в большей степени определяется факторами планирования, а не оценками.
Б табл. 21.8 представлено примерное распределение сроков по основным техни
ческим операциям для разных размеров проектов. Конечно, было бы удобнее, ec
ли бы числа в таблице не были выражены в виде диапазонов. [рафик выполнения
этих операций зависит от Toro, коrда освободятся те или иные работники, в какоЙ
степени им приходится совмещать работу над оцениваемым проектом с друrими
задачами, и от друrих факторов. Б этом отношении распределение сроков подвер
жен о большей изменчивости, чем распределение объема работ.
Размер
Таблица 21.8. Примерное распределение сроков в проектах разноrо размера
1 KLOC
25 KLOC
125 KLOC
500 KLOC
Архитектура
1525 О/о
1530 О/о
20---35 О/о
2Q.--40 О/о
Операция
Конструирование
505 О/о
500 О/о
455 О/о
40---55 О/о
Тестирование системы
1520 О/о
20---25 О/о
20---30 О/о
20---35 О/о
Источники: Boehm 1981; Pиtпaт aпd Myers 1992; Boehm et а/, 2000; Putпam aпd Myers 2003;
Stutzke 2005.
9 Зах. 893

242 rлава 21 . Оценка параметров планирования
Как и в случае с объеIОМ работ, сроки для работ по требоваНИЯf обычно oцe
ниваются в процентах от базовой оценки срока. В табл. 21.9 представлены про
центы, прибавляе!vlые к базовому сроку для работ по требоваНИЯI.
Таблица 21.9. Приблизительное увеличение срока для работ по требованиям
в проектах разных размеров
Размер Приращение базовой оценки
1 KLOC llб О/о
25 KLOC 1220 О/о
125 KLOC 1З22 О/о
500 KLOC 2+- ЗО О/о
Источники: Boehm 1981; Putnaт aпd Myers 1992; Boehm et а/, 2000; Putnam aпd Myel 2003;
Stutzke 2005.
В высокоитеративных проектах распределение сроков производится при каж
дой итерации. Если же проект относится к последовательно'1У типу, сроки pac
пределяются для фаз Bcero проекта.
.
СОВЕТ NQ 99
При распределении сроков между различными операциями следует учитывать размер проекта,
ero тип и методолоrию разработки.
Как II В случае с распределениеI\'1 объеI\'lа работ по операЦИЯI\I, распределение
сроков проще Bcero выполняется при наличии исторических данных.
t
21.3. Преобразование оценки в планируемый
объем работы
Оценки объема работы обычно выражаются в «человеКОlесяцCL'{», «че..7Iовекоднях»
или друrих сходных показателях. Такие показатели выражают uдеаilЫlЫЙ объе;м
работы, коrда каждый l\lесяц работы соответствует ОДНОl\'lУ каJIендарНОI\'IУ l\lесяцу.
МаЙк Кон (Mike Cohn) описывает различия l\fежду IIдеалЬНЫl 11 плаНllруе
MbIl\1 BpervleHervl, сравнивая их с иrpОВЫf\f И реальным Bpe'leHeI\1 в aI\lepIlKaHCKOl\I
футболе (Cohn 2006). НОрl\Iальная иrpа в аfерикаНСКОI\1 футболе продолжается
60 минут иrpовоrо вреI\'lени. По HaCTeHHbIl\f часаf она Iожет занять от 2 до 4 часов.
Аналоrично, планировщик проrраl\Il\lноrо проекта не должен предполаrать,
что один человек способен выполнить объеl\1 работы в один человеКОI\lесяц за
один календарныЙ l\lесяц. Ero раБОЧllЙ lесяц» разбавляется отпускаl\ПI, BЫXOД
НЫl\.1И И обучениеl\f; он l\10жет одновре!\lенно работать на несколько проектов; Ha
конец, ВОЗl\10ЖНЫ и друrие причины.
РаССl\fатривая преобразованпе идеальноrо объеfа работы в плаНI'IруеI\IЫЙ, He
оБХОДIIl\10 учитывать следующие факторы.
. Какое время заложено в калибровочные данные, использованные при
создании оценки объеl\lа работ? Включены ли в Hero работы, связанные

21.4. Оценка стоимости 243
с управлением, требованиями и тестированием или только непосредствен
ная разработка? Учтены ли сверхурочные? Предположения, включенные
в калибровочные данные, автоматически переходят в оценку работы.
· В каком количестве проектов будут одновременно работать проrраrvlМИСТЫ?
Если проrраммист делится между двумя проектами, то для выдачи одноrо
месяца «целенаправленной» работы ему потребуется два и более месяца.
· Учтены ли в калибровочных данных выходные, отпуска, болезни, время
обучения, поддержка ToproBbIx выставок, работа с клиентами, поддержка
эксплуатируемых систем и т. д.? Если нет, придется включить эти отвле
кающие факторы» при преобразовании оцениваемоrо объема работы в пла
нируемый.
Перечисленные факторы сильно зависят от орrанизации. Если вы работаете
в орrанизации, в которой rpуппа может сосредоточиться на одном проекте, в пред
положения можно заложить от 40 до 50 часов целенаправленноrо рабочеrо Bpe
мени в неделю. Я видел некоторые компании, в которых эта цель была достиrну
та. Обычно в таких компаниях внутренняя мотивация участников чрезвычайно
сильна; rруппы невелики; ,участники rрупп молоды и не переrружены семейными
обязательствами; компания предлаrает значительные финансовые стимулы, а pa
бочая среда не отяrощена бюрократизмом и корпоративными мероприятиями.
Если вы работаете в большой, устоявшейся орrанизации, в которой часто
происходят корпоративные собрания, а большинство Лlодей работает по 40 часов
в неделю, вероятно, только от 20 до 30 часов будет направлено на работу над про
ектом, причем эти часы MOryT делиться между двумя и более проектами.
Информация о том, сколько в среднем времени в день работник может посвя
тить конкретному проекту, различается. Кейперс Джонс сообщает, что в среднем
технические работники в день выделяют около 6 часов на целенаправленную pa
боту над своими проектами, или 132 часа в месяц (Jones 1998). Модель Сосоmо 11
предполаrает 152 часа целенаправленной работы в месяц (Boehm et al. 2000). KOH
кретное количество часов существенно зависит от специфики орrанизации; как
и в предыдущих случаях, старайтесь получить собственные данные, основанные
на прошлых проектах вашей орrанизации.
За ссылками на дополнительную информацию по проблемам планирования
обращайтесь к разделу Дополнительные ресурсы» в конце rлавы.
21.4. Оценка СТОИМОСТИ
Теоретически оценка стоимости представляет собой тривиальную функцию от
объема работы. Тем не менее получение оценки стоимости проекта усложняется
целым рядом факторов.
Сверхурочные работы
Допускает ли ваша орrанизация некомпенсируемые сверхурочные работы? Если
допускает, то некоторый процент оцениваеfоrо объема работ может не учитывать
ся в оценке стоимости. Использует ли ваша орrанизация временных раБОТНИI(ОВ

244 rлава 21 . Оценка параметров планирования
или ПОДРЯДЧИКОВ, получающих более высокую оплату за переработку? В таких
случаях вклад части оцениваемоrо объема работы в формирование стоимости MO
жет оказаться выше среднеrо.
Выбор типа затрат
в некоторых орrанизациях стоимость проекта вычисляется на базе «прямых за
трат», то есть затрат, напрямую приписываемых конкретному работнику (зарпла
та, налоrи, премии и т. д.). В друrих орrанизациях при расчете стоимости проекта
используются «обременяющие затраты с учетом полных корпоративных затрат,
которые не ассоциируются с конкретными работниками (аренда, корпораТИDные
налоrи, затраты служб кадров, продаж, маркетинrа и т. д.). В зависимости от раз
мера орrанизации, объема невозмещаемой инфраструктуры, стоимости офисноrо
пространства и друrих факторов, бремя расходов в процентах от зарплаты работ
ника [ожет составлять от 30 до 125 % и выше.
Друrие прямые затраты
Некоторые проекты также требуют затрат на командировки, специализирован
ный инструментарий, оборудование и т. д. Эти затраты тоже должны включаться
в оценку стоимости.
За ссылками на дополнительную информацию по этой теме обращайтесь к раз
делу Дополнительные pecypcы в конце rлавы.
21.5. Оценка дефектообразования и исправления
Дефектообразование в проrpаммном проекте является функцией объема работы
и размера проекта, поэтому количество дефектов тоже может оцениваться зара
нее. Информация о вероятном количестве дефектов приrодится для планирова
ния объема работ, направленных на их исправление.
Кейперс Джонс описывает один из способов анализа дефектообразования, oc
нованный на размере проrраммы в функциональных пунктах (] ones 2000). Как
показано в табл. 21.10, из данных Джонса следует, что в типичном проекте на
один функциональный пункт создается около 5 дефектов. Этот показатель COOT
ветствует примерно 50 дефектам на 1000 строк проrраммноrо кода (в зависимо
сти от используемоrо языка проrраммирования).
Таблица 21.10. Типичная частота дефектообразования в различных операциях
Операция Среднее количество создаваемых дефектов
Требования Один дефект на функциональный пункт
Архитектура 1,25 дефекта на функциональный пункт
Конcrруирование 1,75 дефекта на функциональный пункт
Документация 0,60 дефекта на функциональный пункт
Некорректные исправления 0,40 дефекта на функциональный пункт
итоrо 5,0 дефекта на функциональный пункт

21.5. Оценка дефектообразования и исправления 245
Друrой фактор, вносящий свой вклад в издержки масштаба, заключается в том,
что в крупных проектах на строку кода обычно rенерируется больше дефектов;
это повышает объем работы по исправлению ошибок, что, в свою очередь, повы
шает затраты проек'(а. В табл. 21.11 представлена зависимость плотности ошибок
для разных размеров проекта.
Таблица 21.11. Размер проекта и плотность ошибок
Размер проекта (в строках кода) Типичная плотность ошибок
< 2К 25 ошибок на KLOC
2K 16К Q.--40 ошибок на KLOC
1БК4К 0,550 ошибок на KLOC
64K512K 270 ошибок на KLOC
>512К 4---100 ошибок на KLOC
Источник: Program Quality aпd Progl.ammer Productivity» (]oпes 1977), Estilпatiпg Soft:«Jare
Costs» (]oпes 1998).
Среднеотраслевые частоты дефектообразования изменяются более чем на по
рядок. Исторические данные прошлых проектов повысят точность оценки.
СОВЕТ NQ 100
Используйте среднеотраслевые или исторические данные для оценки предполаrаемоrо количе
ства дефектов в вашем проекте.
Оценка работы по исправлению дефектов
Дефектообразование  лишь одна из частей формулы планирования. Друrой
частью является исправление дефектов. В проrpаммной отрасли накопился дoc
таточно большой объем данных по эффективности основных методов исправле
ния дефектов. В табл. 21.12 представлены данные об эффективности исправле
ния дефектов 1 для анализа, обсуждения, модульноrо тестирования, тестирования
системы и друrих распространенных методов.
Таблица 21.12. Эффективность исправления дефектов
Фаза удаления
Неформальный обзор архитектуры
Формальный анализ архитектуры
Неформальный обзор кода
Формальный анализ кода
Моделирование или макетирование
Минимальная
эффективность
25 О/о
45 О/о
20 О/о
45 О/о
35 О/о
Модальная
эффективность
35 О/о
55 О/о
25 О/о
60 О/о
65 О/о
Максимальная
эффективность
40 О/о
65 О/о
35 О/о
70 О/о
80 О/о
продолжение -#
1 Defect Removal Rate (Efficiency) == (Количество исправленных дефектов)j(Количество
исправленных дефектов + Количество дефектов, обнаруженных после начала поставок
продукта).  Прuмеч. перев.

246 rлава 21 · Оценка пара метров планирования
Таблица 21.12 (продолжение)
Фаза удаления Минимальная Модальная Максимальная
эффективность эффективность эффективность
Персональная проверка кода 20 О/о 40 О/о 60 О/о
Модульное тестирование 15 О/о 30 О/о 50 О/о
Тестирование новых функций 20 О/о 30 О/о 35 О/о
(компонентов)
Интеrрационное тестирование 25 О/о 35 О/о 40 О/о
Реrрессионное тестирование 15 О/о 25 О/о 30 О/о
Системное тестирование 25 О/о 40 О/о 55 О/о
Бетатестирование в малом 25 О/о 35 О/о 40 О/о
масштабе « 10 мест)
Бетатестирование в большом 60 О/о 75 О/о 85 О/о
масштабе (> 1000 мест)
Источник: По материалам Prograттiпg Productivity» (Jo19.es 1986а), Software DefectReтovaZ
Efficieпcy» (]oпes 1996) u  What We Have Leamed АЬоиt Fightiпg Defects» (Shull et a12002).
Важную роль здесь иrрает диапазон от минимальной до максимальной эффек
тивности; как обычно, исторические данные вашей орrанизации помоryт полу
чить более точную оценку.
Пример оценки эффективноcrи исправления дефектов
Объединение информации из таблиц дефектообразования и исправления позволяет
оценить количество дефектов, которые останутся в окончательной версии вашей
проrpаммы (и конечно, помоrает спланировать действия по удалению большеrо
или меньшеrо количества дефектов, в зависимости от ваших критериев качества).
Предположим, имеется система в 1000 функциональных пунктов. Оценка по
данным Джонса из табл. 21.10 показывает, что проект будет содержать около
5000 дефектов. В табл. 21.13 описаны результаты их поэтапноrо устранения с при
менением стандартной стратеrии, состоящей из персональной проверки кода,
модульноrо тестирования, интеrpационноrо тестирования, системноrо тестиро
вания и бетатестирования в малом масштабе.
Таблица 21.13. Пример типичной процедуры образования и устранения дефектов
(для системы размером в 1000 функциональных пунктов)
Операция
Изменения в количестве
дефектов
+ 1000 дефектов
+ 1250 дефектов
+1750 дефектов
---40 О/о
+600 дефектов
 30 О/о
Общее количество
внесенных дефектов
1000
2250
4000
4000
4600
4600
Остается
дефектов
1000
2250
4000
2400
3000
2100
Требования
Архитектура
Конструирование
Персональная проверка кода
Документация
Модульное тестирование

21.5. Оценка дефектообразования и исправления 247
Операция Изменения в количестве Общее количество Остается
дефектов внесенных дефектов дефектов
Интеrрационное  35 О/о 4600 2100
тестирование
Системное тестирование O О/о 4600 1365
Некорректные исправления +400 дефектов 5000 1219
Бетатестирование в малом 35 О/о 5000 792
масштабе
Дефектов остается ----84 О/о 5000 72 (16 О/о)
v
в окончательнои версии
Получается, что типичный подход к исправлению дефектов устранит из про
rpaMMbI только около 84 % ошибок, что примерно соответствует стандартам
отрасли (Jones 2000). Как обычно, числа, полученные этим способом, являются
приближенными.
В табл. 21.14 показано, как может проходить исправление дефектов в лучших
орrанизациях. Предполаrается, что rpуппа внесет в проект те же 5000 дефектов.
Однако на этот раз в число методов удаления дефектов войдет моделирование
требований, формальный анализ архитектуры, персональная проверка кода,
модульное, интеrpационное и системное тестирование, а также бетатестирование
в большом масштабе. Как видно из таблицы, комбинация этих методов должна
привести к удалению из проrраммноrо продукта около 95 % дефектов.
Таблица 21.14. Пример самой надежной процедуры образования и устранения дефектов
(для системы размером в 1000 функциональных пунктов)
Операция Изменения в копичecrве Общее количество Остается
дефектов внесенных дефектов дефектов
Требования + 1000 дефектов 1000 1000
Моделирование требований  65 О/о 1000 350
Архитектура + 1250 дефектов 2250 1600
Формальный анализ  55 О/о 2250 720
архитектуры
Конструирование + 1750 дефектов 4000 2470
Документация + 600 дефектов 4600 3070
Персональная проверка кода  40 О/о 4600 1842
Модульное тестирование  30 О/о 4600 1289
Интеrpaционное тестирование  35 О/о 4600 838
Системное тестирование ....40 О/о 4600 503
Некорректные исправления + 400 дефектов 5000 903
Бетатестирование в малом .... 735 О/о 5000 226
масштабе
Дефектов остается 95 О/о 5000 226 (5 О/о)
v
в окончательнои версии

248 rлава 21 . Оценка параметров планирования
Как и в предыдущем примере, излишняя четкость оценки в 226 дефектов не
поддерживается используемыми данными.
СОВЕТ NQ 101
Данные эффективности исправления дефектов позволяют оценить количество дефектов, KOTO
рые будут удалены из nporpaMMbI вашими методами контроля качества перед выпуском оконча
тельной версии.
Лоренс Путнэм при водит два дополнительных эмпирических правила исправ
ления дефектов. Если вы хотите перейти от 95 % надежносТИ к 99 % надежно
сти, долю «основной сборки» в сроке следует увеличить на 25 %. Чтобы перейти
от 99 к 99,9 % надежности, заложите в срок еще 25 % (РиtпаПl and Myers 2003).
(В терминолоrии Путнэма понятия надежность» и процент исправления дe
фектов перед выпуском» эквивалентны.)
Дальнейшая оценка атрибутов качества  весьма непростая тема, в значитель
ной мере опирающаяся на научные методы оценки. В секции «Дополнительные
ресурсы» в конце rлавы рассказано, rдe найти дополнительную информацию.
21.6. Оценка риска и резервные буферы
На интуитивном уровне все мы понимаем, что в проектах с повышенным риском
следует предусмотреть увеличенные буферы для непредвиденных обстоятельств,
а в проектах с малым риском можно обойтись небольшим буфером. Но каким
именно должен быть размер буфера?
,
При анализе рисков обычно учитываются их возможные последствия и Bepo
ятности. В табл. 21.15 показан пример таблицы рисков с указанием вероятности,
влияния риска и причиняемоrо ущерба.
Таблица 21.15. Пример таблицы рисков для сроков проекта
Риск Вероятность пияние (срок) Ущерб (срок)
1 5 О/о 15 недель 0,75 недели
2 25 о/о 2 недели 0,5 недели
3 25 о/о 8 недель 2 недели
4 50 о/о 2 недели 1 неделя
итоrо 4,25 недели
Влияние риска, умноженное на ero вероятность, обычно называется ущербом
(Risk Exposиre, RE). Со статистической точки зрения ущерб представляет собой
ожидаемое значение» риска, или ту величину, на KOTOPYIO, как nредnолаzается,
увеличится срок изза наличия риска. Для рисков, перечисленных в табл. 21.15,
базовый срок проекта увеличивается на 4,25 недели. С вероятностью 50 % срок
возрастет на большую величину и с вероятностью 50 %  на меньшую.
Суммарный ущерб является хорошей отправной точкой для количественноrо
буферноrо планирования. Если вам нужна более твердая уверенность в том, что
проект будет выдан вовремя, запланируйте буфер, размер KOToporo превышает

21.7. Друrие эмпирические правила 249
величину cYMMapHoro ущерба. Если повышенный риск нарушения сроков вас не
пуrает, планируйте буфер меньшеrо размера.
Впрочем, ущерб  это лишь часть общей картины. Если в табл. 21.15 риск 1
или 3 реализуется, проект выйдет за пределы cBoero ожидаемоrо буфера в 4,25 Heдe
ли. Эти события маловероятны, однако вы должны проанализировать последст
вия конкретных рисков перед тем, как остановиться на итоrовом размере буфера.
Риски в табл. 21.15 представлены только с точки зрения возможноrо наруше
ния срока. Любой риск также может создавать уrрозу для объема работ, стоимо
сти, функциональности, качества или прибыли. В табл. 21.16 показан пример таб
лицы рисков, включающей сроки, стоимость и прибыль.
Таблица 21.16. Пример расширенной таблицы рисков
Риск Вероят- Влияние Ущерб Влияние Ущерб
ность (срок) (срок) (стоимость) (стоимость)
5 О/о 15 недель 0,75 недели $150 000 $7500
25 О/о 2 недели 0,5 недели $20 000 $5000
25 О/о 8 недель 2 недели $80 000 $20 000
50 О/о 2 недели l' неделя $20 000 $10 000
4,25 недели $42 000
1
2
3
4
итоrо
Влияние Ущерб
(прибыль) (прибыль)
$10 000 000 $500 00
$0 $0
$500 000 $125 000
$0 $0
$625 000
При планировании необходимо выделить отдельные буферы для срока, объе
ма работ, стоимости, функциональности и качества. Эти буферы лишь отдаленно
связаны друr с друrом.
Помните, что влияние и вероятности рисков  величины оцениваемые, а точ
ность сводноrо ущерба не превышает точности данных, которые использовались
при ее вычислении.
СОВЕТ NQ 102
Используйте суммарный ущерб рисков вашеrо проекта в качестве отправной точки при пла
нировании буферов. Проанализируйте отдельные аспекты конкретных рисков и постарайтесь
понять, не должен ли запланированный буфер быть больше или меньше cyMMapHoro ущерба.
Управление рисками  довольно сложная область, в которой научные методы
оценки MorYT cbIrpaTb важную роль. В секции Дополнительные ресурсы» в KOH
це rлавы рассказано, rде найти дополнительную информацию.
21.7. Друrие эмпирические правила
Приведу еще несколько эмпирических правил, которые MOryT использоваться для
друrих аспектов планироания.
. Административная и бюрократическая поддержка увеличивают базовую
оценку объема работ на 510 % (Stutzke 2005).
. Техническая поддержка (настройка лабораторноrо оборудования, YCTa
новка новых проrрамм и т. д.) увеличивает базовую оценку объема работ
на 24 % (Stutzke 2005).

250 rлава 21 · Оценка параметров планирования
. Поддержка управления конфиrурациями/сборкой увеличивает базовую
оценку объема работ на 28 % (Stutzke 2005).
. Резервируйте от 1 до 4 % в месяц на расширение требований (Jones 1998).
. Переход от разработки, производимой одной компанией на одной площад
ке, к совместным распределенным разработкам увеличивает объем работ
на 25 % (Boehm et al 2000).
. Переход от разработки, производимой одной компанией на одной площад
ке, к международной удаленной (outsource) разработке увеличивает объем
работ на 40 % (Boehm et al 2000).
. Если разработчики впервые имеют дело с новым языком проrраммирова
ния и инструментарием, объем работ увеличивается на 2040 % по cpaBHe
НИIО со знакомым языком и инструментарием (Boehm et al 2000).
. Если разработка впервые производится в новой среде, объем работ увели
чивается на 2040 % по сравнению с разработкой в знакомой среде (Boehm
et al 2000).
Дополнительные ресурсы
Boehln, Barry W. «Software Engineering Economics. Englewood Cliffs, NJ: Prentice
НаН, Inc., 1981. Хотя это издание отчасти устарело с выходом «Software Cost
Estimation with Сосото II (см. ниже), в нем содержатся интересные, подробные
таблицы объемов работ и распределения сроков по различным операциям.
Boehm, Barry et al. «Sbftware Cost Estimation with Сосоmо II. Reading, МА:
Addison Wesley, 2000. В приложении А книrи Бема описано распределение объ
ема работ и сроков для каскадных проектов, а также проектов на базе MBASE
и Rational Unified Process. В таблице А.10 (которая в действительности состоит
из шести таблиц) при водится подробное распределение сроков и объемов по раз
личным операциям.
Cohn, Mike. «Agile Estimating and Planning, Englewood Cliffs, NJ: Prentice НаН
PTR, 2006. В rлаве 5 книrи Кона хорошо объясняются различия между идеаль
ным и плановым объемом работ.
DeMarco, Тот, and Timothy Lister. «Waltzing with Bears: Managing Risks оп
Software Projects, New York, NY: Dorset House, 2003. Доступное введение в управ
ление риска1vlИ в проrpаммных проектах.
Fenton, Norman Е., and Shari Lawrence pfleeger. Software Metrics: А Rigorous
and Practical Approach», Boston, МА: PWS Publishing Company, 1997. В rлаве 10
подробно обсуждается оценка надежности проrpаммноrо продукта. Если вы не
любите уравнения с rpеческими символами и математическими знаками, эта кни
ra не для вас.
Jones. Capers. «Estimating Software Costs. New York, NY: McGrawHill, 1998.
[лава 14 книrи Джонса содержит подробное, снабженное примерами описание
структуры расходов в разных типах орrанизаций. [лава 21 объясняет, как неопла
ченные сверхурочные работы отражаются на оценке стоимости.

Дополнительные ресурсы 251
Jones, Capers. «Software Assessments, Benchmarks, and Best Practices. Reading,
МА: AddisonWesley, 2000. Некоторые данные, представленные в этой книrе, об
новлены или расширены по сравнению с теми данные, которые были представле
ны в Estimating Software Costs».
Putnarn, Lawrence Н. and Ware Myers. «Measures for Ехсеllепсе: Reliable Soft
ware Оп Tirne, Within Budget. Englewood Cliffs, NJ: Yourdon Press, 1992. Путнэм
и Майерс приводят ряд полезных эмпирических правил. Общий контекст кни
rи  подробное математическое объяснение модели оценки Путнэма.
Stutzke, Richard D. «Estimating SoftwareIntensive Systems». Upper Saddle River,
NJ: AddisonWesley, 2005. В rлаве 12 описаны методы распределения объема pa
бот, основанные на моделях Сосоmо 81 и Сосоmо 11. [лавы 15 и 23 фокусируются
на подробной оценке стоимости. Основной темой книrи Стуцке является оценка
стоимости проекта и друrие вопросы, относящиеся к затратам, и в ней встречаются
мноrочисленные полезные советы по этой теме. В разделах 12.1 и 12.2 обсуждают
ся связи между объемом работ, продолжительностью и доступностью персонала.
Tockey, Steve. «Return оп Software. Boston, МА: Addison Wesley, 2005. В rла
ве 15 книrи Токи хорошо описана методика определения стоимости, включая pac
пределение непроизводительных затрат разными методами калькуляции и по
тенциальные опасности, связанные с некоторыми методами.
СОВЕТ NQ 103
Планирование и оценка  взаимосвязанные темы, а тема планирования слишком обширна, что
бы ее можно было изложить в одной rлаве книrи, посвященной оценке проrраммных прdектов.
Читайте специализированную литературу по планированию.

250 rлава 21 · Оценка параметров планирования
. Поддержка управления конфиrурациями/сборкой увеличивает базовую
оценку объеl\lа работ на 28 % (Stutzke 2005).
. Резервируйте от 1 до 4 % в месяц на расширение требований (Jones 1998).
. Переход от разработки, производимой одной компанией на одной площад
ке, к совместным распределенным разработкам увеличивает объем работ
на 25 % (Boehm et al 2000).
. Переход от разработки, производимой одной компанией на одной площад
ке, к международной удаленной (outsource) разработке увеличивает объем
работ на 40 % (Boehm et аl 2000).
. Если разработчики впервые имеют дело с новым языком проrраммирова
иия и инструментарием, объем работ увеличивается на 2040 % по cpaBHe
НИIО со знакомым языком и инструментарием (Boehm et al 2000).
. Если разработка впервые производится в новой среде, объем работ увели
чивается на 2040 % по сравнению с разработкой в знакомой среде (Boehm
et al 2000).
Дополнительные ресурсы
Boehln, Barry W. «Software Engineering Economics. Englewood Cliffs, NJ: Prentice
НаН, Inc., 1981. Хотя это издание отчасти устарело с выходом «Software Cost
Estimation with Сосото II (см. ниже), в нем содержатся интересные, подробные
таблицы объемов работ и распределения сроков по различным операциям.
Boehm, Barry et al. «$oftware Cost Estimation with Сосото II. Reading, МА:
Addison Wesley, 2000. В приложении А книrи Бема описано распределение объ
el\la работ и сроков для каскадных проектов, а также проектов на базе MBASE
и Rational Unified Process. В таблице А.10 (которая в действительности состоит
из шести таблиц) приводится подробное распределение сроков и объемов по раз
личным операциям.
Cohn, Mike. «Agile Estimating and Planning, Englewood Cliffs, NJ: Prentice НаН
PTR, 2006. В rлаве 5 книrи Кона хорошо объясняются различия между идеаль
ным и плановым объемом работ.
DeMarco, Тот, and Timothy Lister. «Waltzing with Bears: Managing Risks оп
Software Projects, New York, NY: Dorset House, 2003. Доступное введение в управ
ление рискаl\lИ в проrpаммных проектах.
Fenton, Norman Е., and Shari Lawrence Pfleeger. «Software Metrics: А Rigorous
and Practical Approach», Boston, МА: PWS Publishing Сотрапу, 1997. В rлаве 10
подробно обсуждается оценка надежности проrраммноrо продукта. Если вы не
любите уравнения с rреческими символами и математическими знаками, эта кни
ra не для вас.
Jones. Capers. «Estimating Software Costs. New York, NY: McGrawHill, 1998.
[лава 14 книrн Джонса содержит подробное, снабженное примерами описание
структуры расходов в разных типах орrанизаций. [лава 21 объясняет, как неопла
ченные сверхурочные работы отражаются на оценке стоимости.

Дополнительные ресурсы 251
Jones, Capers. «Software Assessments, Benchmarks, and Best Practices>.>. Reading,
МА: AddisonWesley, 2000. Некоторые данные, представленные в этой книrе, об
новлены или расширены по сравнению с теми данные, которые были представле
ны в «Estimating Software Costs>.>.
Putnam, Lawrence Н. and Ware Myers. «Measures for Ехсеllепсе: Reliable Soft
ware Оп Tirne, Within Budget». Englewood Cliffs, NJ: Yourdon Press, 1992. Путнэм
и Майерс приводят ряд полезных эмпирических правил. Общий контекст кни
rи  подробное математическое объяснение модели оценки Путнэма.
Stutzke, Richard D. «Estimating SoftwareIntensive Systems>.>. Upper Saddle River,
NJ: AddisonWesley, 2005. В rлаве 12 описаны методы распределения объема pa
бот, основанные на моделях Сосото 81 и Сосото 11. [лавы 15 и 23 фокусируются
на подробной оценке стоимости. Основной темой книrи Стуцке является оценка
стоимости проекта и друrие вопросы, относящиеся к затратам, и в ней встречаются
мноrочисленные полезные советы по этой теме. В разделах 12.1 и 12.2 обсуждают
ся связи между объемом работ, продолжительностью и доступностью персонала.
Tockey, Steve. «Return оп Software». Boston, МА: Addison Wesley, 2005. В rла
ве 15 книrи Токи хорошо описана методика определения стоимости, включая pac
пределение непроизводительных затрат разными методаl\-IИ калькуляции и по
тенциальные опасности, связанные с некоторыми методами.
СОВЕТ NQ 103
Планирование и оценка  взаимосвязанные темы, а тема планирования слишком обширна, что
бы ее можно было изложить в одной rлаве книrи, посвященной оценке nporpaMMHbIX проектов.
Читайте специализированную литературу по планированию.


Стили
представления
оценок
Область применения методов этой rлавы
Выбор стиля представления в соответствии с точностью оценки
Размер, объем работы, срок, функциональность
Что оценивается
Размер проекта
Стадия разработки
Итеративный или
последовательный
стиль
МСБ
Ранняяпоздняя
Оба
Возможная точность
Стиль представления оценки создает определенное впечатление относительно ее
точности. Если стиль представления подразумевает необоснqпанную точность,
вы сами закладываете предпосылки для непростоrо обсуждения самой оценки.
В этой rлаве представлено несколько способов представления оценок.
22.1. Представление предположений,
заложенных в оценку
ВажнейшеЙ практикой представления оценки является документирование пред
положений, заложенных в этой оценке. Предположения делятся на несколько Ka
теrорий:
. обязательные функции;
. необязательные функции;
. rлубина проработки тех или иных функций;
. доступность ключевых ресурсов;

22.1. Представление предположений, заложенных в оценку 253
. зависимость от третьих сторон;
. основные неизвестные факторы;
. основные факторы влияния и чувствительность оценки;
. качество оценки;
. предполаrаемое использование оценки.
Ниже показан при мер оценки, представленной с документированными пред
положениями. Документирование предположений помоrает сформировать впе
чатление об изменчивости, заложенной в проrpаммном проекте.
Пример документирования предположений оценки
Оце1iка проекта
Базовая оце1tка срока составляет 6 кале1tдарuых "месяцев; по Ilашему М1tе1tuю,
ее точность лежит в пределах 25 %. Эта оценка может быть взята за OC1tOBY
формирова1iUЯ б10д:JlCета, 1tO 1te MO:JICem использоваться для пРИllЯтuя вuешних
обязательств. Оце1lка базируется 1ta следующих предположе1tUЯX.
1. Три ключевых теxuическux руководителя приступят к работе ис1ulючи
тельuо иад проекmом с 15 марта.
2. Все разработчики и специалисты по тестирова1iИ10 приступят к работе
ИСЮ110читель1tо 1iaa проектом с 15 апреля.
З. Подсистема форматироваuuя zрафики будет получе1iа от субподрядчика
с приемлемьLМ качеством к 1 aBzycma.
4. БuзuесправWlа ие потребуют об1tовле1tuя.
5. Степеиь необходимой И1iтеzрации с систеАtой FooBar неизвест1lа. В даll1tуЮ
оце1iКУ заложеио 250 человекочасов работы по И1lтеzрации. Если потребу
ется больший объем работы, оцеику для Bcezo проекта также придется пe
рес)иотреть.
6. В проекте потребуется 1te более 5 1tOBbLX отчетов.
7. Новый И1tструме1iтарий разработки обеспечит прирост производитеЛЬ1tо
сти 1ia 20 % и более по срав1iе1iИЮ с проlШlЬLМИ проектами.
8. Количество д1tей отпусков по болеЗ1tи будет ме1tьше cpea1iezo, потому что
большая часть проекта выпОЛ1lЯется в лет1iее время.
9. После настУrUlенuя дат, указа1i1iЬLX в пунктах 1 и 2, перСО1lШl1lе будет 01п
влекаться 1ia поддержку предыдущих версий npozpaм..мbl.
10. По крайней мере 80 % кода базы aa1i1lbLX из версии 2.0 удастся использовать
пOBmOP1iO без модификаций.
В случае нарушеuuя этих предположе1tИЙ оце1tКУ придется пересмотреть.
Этот подход также может приrодиться в ситуациях, коrда вас заставляют
сформировать оценку на базе предположений, которые вам кажутся нереали
стичными (таких, как предположения 79). Бы беретесь за дело и составляете
оценку, но документируете заложенные в нее предположения. Если работа над
проектом пойдет так, что оценка станет недействительной, вы всеrда сможете co
слаться на предположения как на основу для пересмотра оценки.

I
254 rлава 22 . Стили представления оценок
СОВЕТ NQ 104
Документируйте и сообщайте предположения, заложенные в оценке.
22.2. Выражение неопределенности
Ктпочевой проблемой в представлении оценки является документирование ее неоп
ределенности способом, который бы ясно выражал неопределенность и повышал
до максимума вероятность конструктивноrо, KoppeKTHoro использоваНI1Я оценки.
В этом разделе описано несколько способов передачи неопределенности в оценках.
Квалификаторы «плюс/минус»
Оценка с квалификатором «плюс/минус» имеет вид «6 месяцев + 2 месяца» или
«$600 000 +$200 000 $100 000». В подобных обозначениях указывается как Be
личина, так и направление неопределенности. Формулировка 6 месяцев + 1/2
месяца  1/2 месяца» rоворит о том, что оценка BeGbMa точна, и существует ДOCTa
точно высокая вероятность ее достижения. Формулировка 6 месяцев +4 месяца
 1 месяц означает, что точность оценки оставляет желать лучшеrо, а шансы на
ее реализацию невелики.
При выражении оценки с квалификатором ПJiюс/минус следует учитывать
величину квалификаторов и их смысл. На практике квалификаторы часто выби
раются достаточно большими для Toro, чтобы они включали одно стандартное OT
клонение с каждой стороны базовой оценки. При таком подходе все равно OCTaeT
ся 16 % вероятность TorQ, что фактический результат превысит верхнюю rраницу
оценки, и 16 % вероятность Toro, что он окажется под нижней rраницей. Если вам
нужно обеспечить более 68 % вероятности в середине диапазона в одно CTaH
дартное отклонение, используйте соответствующие квалификаторы (в табл. 10.6
приведен список стандартных отклонений и связанных с ними вероятностей).
Подумайте, должен ли «минусовой» квалификатор совпадать с «плюсовым».
Для объемов работ и сроков «минусовой квалификатор обычно меньше плюсо
Boro по причинам, объясненным в разделе 1.4.
Впрочем, у квалификаторов «плюс/минус» имеются и свои слабости: по мере
прохождения оценки по орrанизации она обычно усекается до минимума. В OT
дельных случаях менеджеры упрощают оценку из нежелания учитывать измен
чивость, заложенную в оценке. Чаще оценка упрощается изза Toro, что их Ha
чальники или корпоративная бюджетная система принимают только точечные
оценки, выраженные в виде отдельных чисел. Используя эту методику, убедитесь
в том, что вас устроит точечная оценка, оставшаяся после преобразования диапа
зона в упрощенную форму.
Квантификация рисков
Квантификация рисков представляет собой комбинацию квалификаторов «плюс/
минус и предположений проекта. В результате квантификации риски ассоци
ИРУIОТСЯ с конкретными последствиями, как показано в табл. 22.1.

22.2. Выражение неопределенноcrи 255
Таблица 22.1. Пример оценки с квантификацией рисков
Оценка: 6 месяцев, +5 месяцев, ...1 месяц
Пocnедcrвия Описание риска
+ 1,5 месяца Версия потребует более 20 О/о новых возможностей по сравнению с версией 2.0
+1 месяц Подсистема форматирования rpaфики БУДf!f доставлена позднее, чем планировалось
+ 1 месяц Новый инструментарий разработки БУДf!f работать не так хорошо, как планировалось
+1 месяц Не удастся заново использовать 80 О/о кода из предыдущей версии
+0,5 месяца Средняя заболеваемость персонала в летние месяцы будет средней (а не пониженной)
---0,5 месяца 1000/0e комплектование разработчиков завершено к 1 апреля
---0,5 месяца Новый инструмент разработки будет работать лучше, чем планировалось
Б этом относительно простом примере внимание направлено исключительно
на риски для сроков. Б реальной ситуации, помимо последствий рисков для cpo
ков, MOryT быть перечислены основные последствия рисков для объемов и фУНl(
циональности. Следует помнить, что речь идет о методике представления оценки.
Ее целью является передача информации о рисках нетехническим ключевым уча
стникам проекта. Чтобы не переrружать их подробной информацией о рисках,
постарайтесь сосредоточиться на МОНQЛИТНЫХ, укрупненных рисках.
При документировании источников неопределенности предоставьте OTBeTCT
венным участникам проекта информацию, которая может использоваться для co
кращения рисков, и заложите основу для объяснения изменений в оценках в слу
чае реализации какихлибо из рисков.
Если проект уже достиr достаточно зрелоrо состояния для принятия обяза
телъств, риски из табл. 22.1 MOryT оказаться рисками для выполнения обяза
тельств, а не рисками для оценки.
Представленный пример не отражает общей неопределенности проекта, обуслов
ленной воздействием конуса неопределенности. Если обязательства еще не при
нимались, возможно, вам также придется учесть и этот вид неопределенности.
СОВЕТ NQ 105
Вы должны четко понимать, какая неопределенность отражается в представлении оценки: He
определенность самой оценки или же неопределенность, влияющая на вашу возможность BЫ
полнения обязательств.
Коэффициенты достоверности
Один из вопросов, которые часто задаются о сроках  «Какова вероятность Toro,
что мы управимся к этой дaTe? Коэффициенты достоверности позволят вам OT
ветить на этот вопрос и привести оценку вроде той, что представлена в табл. 22.2.
Для приближенной оценки интервалов можно воспользоваться оценкой «наи
более вероятноrо» результата и множителями из табл. 4.1, соответствующими
фазе проекта.
Как упоминалось в rлаве 2 и в друrих местах книrи, избеrайте излишне YBe
ренных ( «достоверных на 90 % ) оценок, если только вы не располаrаете количе
ственными показателями, подтверждающими столь высокие проценты.

...,.
256 rлава 22 · Стили предcrавления оценок
Таблица 22.2. Пример оценки с коэффициентами достоверности
Дата выдачи
15 января
1 марта
1 ноября
Вероятность выдачи не позднее запланированной даты
20 о/о
50 О/о
80 о/о
Также ПОДУl\'lайте, стоит ли представлять оценки с низкой достоверностью.
Теоретическая возможность результата еще не означает, что ero нужно включать
в таблицу. Вряд ли комунибудь придет в rолову приводить варианты, вероятные
на 1 % или 0,0001 %. Представление только тех вариантов, вероятность которых
составляет не менее 50 %  вполне разумная стратеrия оценки.
СОВЕТ NQ 106
Не представляйте ответственным сторонам проекта маловероятные результаты.
Некоторые воспринимают визуальные данные' лучше, чем данные в таблич
ной форме, поэтому вы также можете создать более наrлядное представление 
такое, как показано на рис. 22.1.
90 о/о
ЗО О/О
 
 НОЯ
.А 

....rv
 Июн
Апр
-Mi1
I.Фее
I
Феs
1
Янв
I
Янв
t
80 О/о
70%
60%
Уровень
достоверности
50 0/0
40 0/0
20 о/о
1 О 0.k
Янв Фее Мар Ап Май Июн Июл Aer Сен Окт Ноя Дек
Дата выдачи
Рис. 22.1. Пример наrлядноrо представления оценок с разной достоверностью в процентах
СОВЕТ NQ 107
Подумайте, не заменить ли текстовое представление оценки rрафическим.
Сценарные оценки
Сценарные оценки являются разновидностью оценок с коэффициентами дoc
товерности. Оценка представляется для лучшеrо случая, худшеrо случая и Te
кущеrо случая в сочетании с обязательствами (или запланированноrо случая).

22.2. Выражение неопределенности 257
Промежутки между запланированным и лучшим/худшим случаями дают пред
ставление об изменчивости, заложенной в проект, и ОПТИl\IИСТИЧНОСТИ плана.
Если запланированный случай заметно смещен к лучшему исходу, это указы
вает на оптимизм планирования. Б табл. 22.3 представлен ПРИ!vlер сценарных
оценок.
Таблица 22.3. Пример сценарных оценок
Случай
Лучший случай (оценка)
Запланированный случай (обязательство)
Текущий случай (оценка)
Худший случай (оценка)
Оценка/обязательство
15 января
1 марта
1 апреля
1 ноября
Интерес представляют отношения между дата?\1И. Если запланированныii слу
чай совпадает с лучшим, а текущий  с худшим, у вашеrо проекта большие He
приятности!
Используя эту методику, будьте rOToBbI оБЪЯСНllТЬ ключевым участникаrvI IIрО
екта, что должно произойти для достижения лучшеrо или худшеrо случая. CKO
рее Bcero, они захотят узнать об обеих возможностях.
На рис. 22.2 показан пример визуальноrо представления информации TaKoro
рода.
90 О/о
Худший случай:
ноябрь
80 0/0
Уровень
достоверности
50%
70010 Текущий случай
(50/50): апрель
60 0/0
40%
ЗО 0/0
20 0/0
10%
Яна Фев Мар Апр Май Июн Июл ABr Сен Окт Ноя Дек
Дата выдачи
Рис. 22.2. Пример наrлядноrо представления сценарных оценок
Б зависимости от Toro, чему уделяется основное внимание при управлении 
срокам или функциональности, сценарная оценка может быть выражена в rOToB
ности функций, а не в календарных дата. Б табл. 22.4 показано возможное пред
ставление сценарной оценки для функциональности.

258 rлава 22 · Стили представления оценок
Таблица 22.4. Пример сценарной оценки для функциональности
Случай
Лучший случай (оценка)
Оценка/обязательство
100 О/о функций уровня 1
100 О/о функций уровня 2
100 О/о функций уровня 3
100 О/о функций уровня 1
100 О/о функций уровня 2
50 О/о функций уровня 3
100 О/о функций уровня 1
80 О/о функций уровня 2
О О/о функций уровня 3
100 О/о функций уровня 1
20 О/о функций уровня 2
О О/о функций уровня 3
.
Запланированный случай (обязательство)
Текущий случай (оценка)
Худший случай (оценка)
rрубая оценка дат и периодов времени
Старайтесь представлять свои оценки в единица, соответствующих точности
базовых данных оценки. Если оценки являются приближенными, используйте
очевидно rрубые оценки (Mы сделаем это во втором квартале», или Проект
потребует 10 человеколет») вместо создающих ложное впечатление точных
чисел: «<Мы сделаем это к 21 мая» или Ha проект потребуется 15 388 человеко
часов»). Рассмотрите возможность использования следующих единиц:
. rоды;
· кварталы;
· месяцы;
· недели.
Помимо четкоrо выражения приближенности оценки, у rрубых оценок есть
еще одно преимущество: упрощение оценки не приведет к потере информации.
Оценка 6 месяцев, +3 месяца,  1 месяц» может быть упрощена до 6 месяцев».
Оценка BO втором квартале» защищена от подобных упрощений.
По мере продвижения по конусу неопределенности единицы измерения Bpe
мени постепенно сокращаются. В начальной части конуса оценка может пред
ставляться в кварталах; позднее, коrда вы начнете создавать восходящие оценки
на основании объемов работ отдельных задач, вероятно, можно будет перейти на
месяцы и недели, а в конечном итоrе и на дни.
22.3. Диапазоны (любоrо типа)
в книrе уже неоднократно rоворилось о том, что диапазоны позволяют наиболее
адекватно отразить неточность, из начально заложенную в разных точках конуса
неопределенности. Диапазоны объединяются с друrими приемами, описаННЫIИ


22.3. Диапазоны (любоrо типа) 259
в этой rлаве (то есть диапазоны в rрубых периодах времени, диапазоны с кванти
фикацией рисков и т. д.).
Представляя оценку в виде диапазона, попробуйте ответить на следующие BO
просы.
· Какой уровень вероятности должен быть включен в диапазон? Оrpани
читься ли + 1 стандартным отклонением (68 % возможных исходов), или
диапазон должен быть шире?
· Как диапазоны воспринимаются бюджетными и отчетными процессами
вашей компании? Учтите, что во мноrих компаниях бюджетные и отчет
ные процессы отказываются принимать диапазоны, и последние часто
упрощаются по причинам, никак не связаННЫI с оценкой проrраммноrо
обеспечения, например: Бюджетная электронная таблица нашей компа
нии не позволяет вводить диапазоны. Принимайте во ВНИl\lание оrpаниче
ния, которым приходится подчиняться вашему руководству.
· Устроит ли вас средняя точка диапазона? Иноrда руководство упрощает
диапазоны, публикуя их НИЖНIОЮ rраницу. Однако чаще при невозможно
сти использования диапазона вычисляется средняя точка, которая исполь
зуется в качестве оценки.
· Нужно ли представлять весь диапазон или только часть диапазона от
номинальной оценки до верхней rраницы? Проекты со BpeMeHel\I чаще
увеличиваются, чем уменьшаются, и оценки обычно ошибаются в нижнюю
сторону. Нужно ли представлять полный диапазон оценки от нижней до
верхней rраницы или можно представить только часть диапазона от номи
нала до верхней rраницы?
· Нельзя ли объединить диапазоны с друrими приемами представления
оценок? Подумайте о том, чтобы представить оценку в диапазонном виде,
а затем привести список предположений или воспользоваться квантифика
цией рисков.
СОВЕТ NQ 108
Используйте стиль представления оценок, который бы подчеркивал передаваемую вами инфор
мацию о точности оценки.
Полезность диапазонноrо представления оценок
Возможно, KTOTO из руководства решит, что представление оценки в виде широко
ro диапазона делает ее бесполезной. На самом деле происходит друrое: представ
ление оценки в виде широкоrо диапазона точно передает бесполезность оценки!
Не представление делает оценку бесполезной, а неопределенность, заложенная
в самой оценке. Невозможно исключить неопределенность из оценки, представляя
ее без неопределенности. Тем самым вы лишь иrнорируете неопределенность, но
это лишь обернется всем во вред.
Два крупнейших профессиональных сообщества разработчиков проrраммно
ro обеспечения  IEEE Cornputer Society и Association of Coтputing Machinery 
совместно решили, что включение неопределенности в оценку относится к числу

260 rлава 22 . Стили представления оценок
профессиональных обязанностей разработчиков. Статья 3.9 этическоrо кодекса
разработчика IEEECS/ АСМ rласит:
«Разработчики дОЛЖ1-lЫ следить за тем, чтобы их продукты и модификации
соответствовали высочаЙШШl профессиональнъ/м' стандартам. В част1l0сти, раз
работчики обязаны по обстоятельствам:
3.09 Обеспечивать реалистичную количествеll11УЮ оценку стоимости, сроков,
персонала, качества и результатов всех проектов, в которых 01lИ работают WlИ
собираются работать, и обеспечить анализ неопределенности в таких oцeHKax.
(выделено автором).
Иначе rоворя, ВКЛlочение неопределенности в оценку  это не любезность,
а этическая ответственность разработчика.
Диапазоны и обязательства
I(оrда руководство сопротивляется ПРИНЯТИIО диапазонных оценок, иноrда оно
на самом деле сопротивляется включению оценки в обязательства. В таких
случаях следует представить широкий диапазон оценки и указать, что в оценке
существует слишкоrvl большая доля неопределенности для принятия осмыслен
ных обязательств.
После сокращения неопределенности до уровя, который позволяет прини
мать обязательства, диапазоны обычно не являются оптимальным средством BЫ
ра)l(ения обязательств. Диапазон оценки наrлядно представляет саму природу
обязательств  сопряженных с большей или меньшеЙ степенью риска, однако
сами обязательства обычно должны выражаться в виде отдельных чисел.
СОВЕТ NQ 109
Не пытайтесь выражать обязательства в диапазонной форме. Обязательства должны быть более
конкретными.
Дополнительные ресурсы
Gotterbarn, Don, Keith Miller, and Simon Rogerson. Colnputer Society and АСМ
Approve Software Engineering Code of Ethics, IEEE Computer, October 199,
рр. 8488 (www.computer.org/computer/codeofethics.pdf). В статье рассказано, как
ПРИНИlался этический кодекс разработчика, и приводится ero полныЙ текст.

Политика,
neperOBopbI
и решение
проблем
Область применения методов этой rлавы
Что оценивается
Размер проекта
Стадия разработки
Итеративный или последовательный стиль
Возможная точность
Принципиальные neperOBopbI
Размер, объем работы, срок, функциональность
МСБ
Ранняяпоздняя
Оба
Филип Метцrер (Philip Metzger) MHoro лет назад заметил, что технические
специалисты хорошо составляют оценки, но плохо их защищаIОТ (Metzger 1981).
у меня нет оснований полаrать, что за прошедшие rоды технические специали
сты научились лучше защищать свои оценки. В этой rлапе описаны причины, по
которым возникают трудности с принятием оценок, и методика, помоrающая yc
пешно вести переrоворы по поводу оценок.
23.1. Особенности руководства
Первая проблема в переrоворах по оценкам обусловлена спецификой личности
людей, участвующих в переrоворах. Технические специалисты обычно склонны
к интроверсии. Около 3/4 технических работников ЯВЛЯIОТСЯ интровертами, в OT
личие от 1/3 Bcero населения (МсСоппеll 2004Ь). Мноrие технические специали
сты нормально ладят с друrими ЛIОДЬМИ, но В области конфликтных социальных
взаимодействий они не сильны.
В переrоворах по поводу проrpаммных проектов обычно участвует техниче
ский персонал и администраторы или технический персонал и маркетолоrи. Дже
ральд Байнберr (Gerald Weinberg) указывает, что маркетолоrи и администраторы
обычно по крайней мере на 10 лет старше и занимают более высокие должности,

262 rлава 23 . Политика, neperOBopbI и решение проблем
чем технические специалисты. Кроме Toro, переrоворы являются одним из OCHOB
ных аспектов их работы (Weinberg 1994). Друrими словами, переrоворы по по
воду оценок ведутся между интровертамитехнарями» и опытными профессио
нальными переrоворщиками.
С учетом этоrо обстоятельства становится понятно, почему технические спе
циалисты относятся к переrоворам примерно так же, как к удалению зубов без
наркоза. Факторы, затрудняющие переrоворы с руководящими работниками,
вряд ли изменятся в обозримом времени. В табл. 23.1 перечислены некоторые из
этих факторов.
Таблица 23.1. Десять основных характеристик администраторов
1. Администраторы всеrда требуют то, что хотят получить.
2. Администраторы всеrда пытаются получить то, что хотят, если не вышло с первоrо раза.
З. Администраторы склонны прощупывать почву до тех пор, пока не обнаружат ваше слабое
место.
4. Администраторы не всеrда знают, что невозможно, но всеrда знают, что было бы полезно
для бизнеса, если бы было возможно. ·
5. Администраторы настойчивы. Собственно, без этоrо они бы не стали администраторами.
б. Администраторы будут уважать вас, если вы будете настойчивы. На самом деле они считают,
что вы будете настойчивы только при крайней необходимости.
7. Администраторы хотят, чтобы вы в своей работе руководствовались интересами
орrанизации.
8. Администраторы стремятся исследовать как можно больше вариантов, чтобы добиться
максимальной коммерческой эффективности.
9. Администраторам извест;tО о бизнесе, рынке и о компании MHoro TaKoro, что неизвестно вам.
Их приоритеты проекта MOryт отличаться от ваших.
10. Администраторы всеrда стремятся получить четкие проrнозы и обязательства на ранней
стадии (действительно, это было бы крайне полезно для дела  если бы было возможно).
Как правило, администраторы обладают этими характеристиками, потому что
это полезно для орzа1luзацuu. Не рассчитывайте, что эти характеристики коrдани
будь изменятсяl
СОВЕТ NQ 110
Поймите, что администраторы настойчивы по своей природе и по должности, и планируйте об
суждение оценок соответствующим образом.
Возможно, переrоворы по поводу оценок  одна из составляющих вашей
работы, которая вам не нравится, но никто не обещал, что ваша работа будет на
100 % приятной. Я обнаружил, что простое осознание Toro факта, что я не люблю
переrоворы, помоrает мне вести их более конструктивно.
23.2. Влияние политических факторов на оценки
Реакция руководства на оценки проrpаммных проектов зависит от ряда факто
ров, не относящихся к технической стороне дела.

23.2. Влияние политических факторов на оценки 263
Внешние оrранич.ения
Довольно часто руководство беспокоится о важных внешних факторах, треБУIО
щих выдать проrраммный продукт к заданной дате или в пределах заданной
стоимости. Может действовать внешний, жестко фиксированный предельный
срок (например, сезон рождественских продаж, выставка и т. д.). Аналоrично,
стоимость проекта может оrpаничиваться условиями тендера; руководство счита
ет, что компания не получит заказ, если выставленные требования будут ДOCTa
точно высокими для покрытия издержек.
Факт существования внешних требований еще не означает, .что эти требования
MOryT быть выполнены. Тем не менее вы должны дать понять руководству, с KO
торым имеете дело, что все требования поняты и вы относитесь к ним серьезно.
СОВЕТ NQ 111
Учитывайте воздействие внешних факторов. Ваши собеседники должны видеть, что вы пони
маете коммерческие требования и их важность.
Бюджет и даты
.
Во мноrих компаниях даты выдачи проектов также зависят от квартальноrо деле
ния. КОIпании сообщают о своих затратах и доходах ежеквартально. Иноrда бы
вает проще перенести проект на более позднюю дату, чем переносить более paH
нюю дату на предыдущий квартал. Если вы предложите назначить срок выдачи
проекта на 15 июля, возможно, на вас будут давить с предложениями перенести
ero на 30 июня (то есть на второЙ квартал вместо TpeTbero). Но если предложить
в качестве даты выдачи 15 сентября, ближе к концу TpeTbero квартала, может OKa
заться, что на эту дату руководство соrласится скорее, чем на 15 июля, потому что
у Hero будет меньше стимулов сдвиrать выдачу на предыдущий квартал. Этот
фактор действует еще сильнее на rраницах отчетных rодов.
Переrоворы по поводу оценок и обязательств
В одних обстоя.тельствах переrоворы уместны, в друrих  нет. Мы не ведем пере
rOBopbI по поводу непреложных фактов (скажем, температуры поверхности Солнца
или объема Великих Озер), а просто принимаем их как данность. Аналоrично,
оценка проrpаммноrо проекта является результатом аналитической деятельно
сти и обсуждать ее нерационально. Однако рационально обсудить обязательства,
связанные с оценкой. Обсуждение может выrлядеть примерно так:
ТеX1lический руководитель: По нашей оце1lке, nроект займет от 5 до 7 месяцев.
Впрочем, сейчас мы еще находимся в раllней части конуса неоnределеllности,
поэтому оценка будет уточияться в ходе работы.
Администратор: От 5 до 7 месяцев  слишком большой разброс. Нельзя ли l1pO
сто использовать оценку в 5 месяцев?
ТеX1lическuй руководитель: Мы должны различать оцеllКИ и обязательства.
Оценку я uз.менить не мOlУ, потому что она бьиш получена в результате cepb
езных вычислений. Тем 1le менее моя zpyпna может СОlЛаситься на срок в 5 Me
сяцев, если мы все СОlЛасимся на подобный уровень риска.

264 rлава 23 · Политика, neperOBopbI и решение проблем
Администратор: Ничеzо не nо1lЯJl. А в чем разница?
Технический руководитель: Наш диапазон от 5 до 7 месяцев включает од1l,О
стандартное отклонение в каждую сторону от медианной оценки в 6 месяца.
Это означает, что вероятность завершения за 7 месяцев равиа 84 %. Наши
оцеllКИ nоказывают, что вероятность соблюдения 5месячных обязательств
составляет Bcezo 16 %.
Администратор: Нам нужна более чем 50 % уверенность в сроке, по которому
заключаются обязательства, но 84 %  более консервативная оценка, чем
HYJlCиO. Какой срок МОЖ1l0 считать достоверны,м' на 75 %?
Технический руководитель: СОlЛасно нашим вычислениям, около 6,5 месяца.
Ад.АlИ1lистратор: На нем и остановимся.
Технический руководитель: Доzоворuлись.
Мноrие технические специалисты считают, что подобный диалоr вредит Kapь
ерному росту. По собственному опыту Mory сказать, что все совсем наоборот.
Если вы rOToBbI пережить неприятные разrоворы (и если при этом PYKOBOДCTBye
тесь интересами своей орrанизации), в действительности это лишь способствует
вашеЙ карьере. Настоящий вред карьере приносит друrое  принятие необосно
ванных, нереалистичных обязательств, которые не удается выполнить.
СОВЕТ NQ 112
Обсуждайте обязательства, но не оценки.
Что делать, если ваша оценка не принята
,
Разработчики и менеджеры иноrда беспокоятся, что слишком высокая оценка
приведет к отклонению проекта. Это 1l0РМально. Высшее руководство обладает
11 ответственностью, и правом решить, что проект экономически не оправдан.
Коrда технический персонал занижает оценку проекта, он скрывает от PYKOBOД
ства важную информацию, необходимую для принятия эффективных решений,
и фактически мешает ему принимать решения. В результате ресурсы компании
отвлекаются с экономически оправданных проектов на экономически неоправ
данные. Хорошие проекты поддерживаются недостаточно, а плохие проекты
получают излишнюю поддержку. Этот сценарий чрезвычайно вреден для дела
II обычно плохо кончается для людей, добившихся принятия проектов, которые
IIзначально принимать не следовало.
Ответственность техническоrо персонала за обучение
Если вы хотите rарантировать успех своих проrpаммных проектов, расскажите
ответственным участникам, не связанным с технической стороной, об опасностях
произвольноrо урезания оценок сроков и стоимости без соответствующеrо COKpa
щения объема работы. Расскажите о конусе неопределенности, о различиях .меж
ду оценками, целями и обязательствами. По собственному опыту MOry сказать,
что эти идеи отлично воспринимаются в контексте попыток действовать в инте
ресах орrанизации.

23.3. Решение проблем и принципиальные переrоворы 265
СОВЕТ NQ 113
Расскажите ответственным участникам, не связанным с технической стороной проекта, о прин
ципах эффективной оценки nporpaMMHbIx проектов.
ПОМИМО обучения нетехнических участников проекта займитесь изучение1
основных принципов, приоритетов и слабых мест вашей отрасли  это поможет
вести дискуссии по поводу оценок на конструктивном уровне.
23.3. Решение проблем и принципиальные
neperOBopbI
в своей книrе Rapid Developrnent от 1996 rода я охарактеризовал обсуждение
оценок термином переrоворы. С течением времени я все меньше и меньше YBe
рен в том, что переrоворы являются наиболее конструктивным подходом к дис
куссиям, возникающим BOKpyr оценок стоимости, срока и функциональности.
В переrоворах участвуют стороны с конфликтующими интересами, а их целью
является распределение пироrа» между двумя и более сторонами. При aHTa
rонистических переrоворах каждая сторона пытается захватить как можно боль
тую часть, и любые приобретения одной стороны автоматически оборачиваются
потерями для друrой стороны. При совместных переrоворах каждая сторона
ищет способы увеличения пироrа, но в конечном счете пироr все равно
делится.
В переrоворах по поводу проrраммноrо обеспечения делить нечеrо. В пере
rOBopax со специалистами по продажам, маркетинry или администрацией мы
сидим за одним столом. Вопрос вовсе не ставится в виде Mы выиrpаем, а они
проиrpали . скорее, MЫ все проиrрываем или MЫ все выиrрываем». Наши
интересы совпадают. Мы либо закладываем основу для успеха проrраМIноrо
проекта, который оборачивается успехом для всех, либо создаем условия для ero
неудачи, также всеобщей. Следовательно, обсуждения по поводу оценок про
rpaMMHbIx проектов нельзя назвать пepezoBopa.мu в традиционном понимании.
Более правильной моделью для дискуссий между техническим персоналом,
отделами продаж, маркетинrа, администрацией и друrими ответственными CTO
ронами является совместное решение проблемы. Мы все работаем на общую
цель, делимся своим опытом в разных областях и создаем решение, которое в KO
нечном счете отвечает интересам бизнеса. .
СОВЕТ NQ 114
Относитесь к обсуждению оценок как к решению проблемы, а не как к neperoBopaM. Поймите,
что все ответственные участники проекта находятся на одной стороне. Либо все вместе проиr
рывают, либо все вместе выиrрывают.
Осознав, что речь идет не о конфликте интересов, а о совместном решении
проблем, мы, технические специалисты, конструктивно подходим к обсуждению
целей, оценок и обязательств. Остается только направить друrих участников об
суждения на такой же конструктивный путь.

266 rлава 23 · Политика, neperoBopbI и решение проблем
Переrоворы как совместное решение проблем
Даже если мы знаем, что речь идет о совместном решении проблем, те люди, с KO
торыми мы обсуждаем оценку, MOryT решить, что они участвуют в традиционных
переrоворах. Существует MHoro разных стратеrий ведения переrоворов. Одни
стратеrии основаны на силе переrоворных позиций, устрашении, дружелюбии,
стремлении добиться похвалы или заслужить расположение. Друrие стратеrии
базируются на обмане и искусных психолоrических маневрах.
Поскольку процесс обсуждения оценок переходит между оценками, целями,
обязательстваrvIИ и планами, обсуждение невозможно четко разделить на чис
Tыe переrоворы и чистое решение проблем. Обычно вам придется иметь дело
с обоими элементами.
В числе хороших стратеП1Й, заполняющих разрыв между переrоворами и реше
нием проблем, rvlОЖНО назвать метод принципиальных переrоворов, описанный
в книrе Getting to Yes» (Fisher and Ury 1991). Метод называется переrоворами,
но ero участники рассматриваются как лица, занимающиеся решением задач. Метод
не зависит от переrоворных приемов; кроме Toro, он объясняет, как реаrировать
на их применение друrими сторонами Метод основан на идее создания беспроиr
рышных альтернатив. Он достаточно хорошо работает, коrда используется только
вами, и еще лучше  если он используется также 'и друrой стороной.
Стратеrия состоит из четырех составляющих:
. отделение людей от проблемы;
. сосредоточение на интересах, а не позициях;
,
. разработка вариантов, обеспечивающих взаимный выиrрыш;
. применение объективных критериев.
Все составляющие метода описываются в следующих секциях.
Отделение людей от проблемы
В обсуждениях оценок задействованы, вопервых, люди, а BOBTOpЫX, интересы
и позиции. Там, rде возникает конфликт личных качеств (например, личных Ka
честв технических работников и специалистов по маркетинry), дискуссия Hepeд
ко заходит в тупик.
Прежде Bcero постарайтесь понять позицию дрyrой стороны. Менеджеры час
то становятся заложниками устарелой политики своей орrанизации. В HeKOTO
рых орrанизациях принципы финансирования проrpаммных проектов оказыва
ются несовместимыми с методами разработки проrраммноrо обеспечения. Такие
орrанизации не разрешаIОТ менеджерам запрашивать финансирование только на
то, чтобы разработать требования и планы и выработать хорошую оценку. Чтобы
получить средства на осмысленную оценку, менеджер должен сначала д.обиться
финансирования Bcero проекта. К моменту получения осмысленной оценки ему
становится неудобно (и даже небезопасно для карьеры) возвращаться и запраши
вать финансирование в реальном объеме. Люди, занимающие самые высокие по
сты в таких ОРI'анизациях, должны лучше понять принципы оценки проrpаммноrо


23.3. Решение проблем и принципиальные переrоворы 267
обеспечения, чтобы ввести в действие практику финансирования, поддерживаю
щую эффективную разработку проrраммноrо обеспечения.
В дискуссиях TaKoro рода считайте себя советником по оценкам проrpаммных
проектов; это поможет избежать вхождения в роль противника. Старайтесь CBoe
v
временно возвращать дискуссию к достижению целеи, полезных для компании.
Также полезно убрать эмоции из предмета обсуждения. Иноrда для этоrо про
ще Bcero дать собеседникам «выпустить пар». Не реаrируйте эмоционально на
эмоции собеседников; дайте им возможность высказаться. Скажите чтонибудь
вроде: «Я вижу, что мы столкнулись С серьезными проблемами, и хочу убедиться
в том, что я в полной мере понимаю позицию нашей компании. Что еще вы може
те сказать о нашей ситуации?» Коrда собеседники завершать объяснения, соrла
ситесь со всем услышанным и снова выразите свое желание найти решение, под
ходящее для орrанизации. Друrие составляющие процесса принципиальных
переrоворов помоryт вам сформулировать это решение.
СОВЕТ NQ 115
Нападайте на проблему, а не на людей.
Сосредоточение на интересах, а не позициях
Предположим, вы продаете свою машину, чтобы купить новую лодку. Вы рассчи
тали, что для покупки нужной вам лодки потребуется $10 000. Потенциальный
покупатель обращается к вам и предлаrает $9000. Вы rоворите: «Я ни при каких
условиях не расстанусь с машиной менее чем за $10 000». Покупатель отвечает:
«Я MOry заплатить $9000, но это мой максимум». .
Переrоворы TaKoro рода сосредоточены на позициях, а не на интереса. Пози
цией называются переrоворные утверждения настолько узкие, что выиrpыш oд
ной стороны означает проиrрыш друrой.
Теперь, допустим, покупатель rоворит: «Я действительно не MOry заплатить
выше $9000, но я слышал, что вы хотите купить новую лодку. По случайности
я являюсь реrиональным дистрибьютором крупной компании, торryющей лод
ками. Я MOry продать вам лодку на $2000 дешевле, чем любой друrой продавец.
Что вы теперь скажете на мое предложение? На этот раз предложение выrлядит
весьма заманчиво  вы получите на $1000 больше, чем если бы покупатель про
сто соrласился на исходную цену.
Интересы шире переrоворных позиций; если вы направите свое внимание на
них, перед вами откроется целый мир новых возможностей. Рассмотрим следую
щий сценарий:
Администратор: Версия GigaBlat 4.0 ншt нужна через 6 месяцев.
ТеX1lический руководитель: Мы тщательно оценWlИ проект. К сожшитию, oцeH
1ш пОКйЗывают, что /tf,bl не сможем выдать elO менее чем за 8 месяцев.
Администратор: ЭтОlО недостаточно. ПрОlра.м.ма действительно 1lУЖllа через
6.месяцев.
Технический руководитель: Нам действительно HYJlC1la вся заявленная фУНК
циональность? Если урезать достаточное количество функций, мы сможем за
вершить работу за 6 месяцев.

268 rлава 23 · Политика, переrоворы и решение проблем
Администратор: Урезать ФУНКЦИОllШlЬНОсть нельзя. В этой версии мы и так co
кратWlИ ее до AtUHUМYMa. Нам нужны все функции, и не позже че.АJ через 6 месяцев.
Технический руководитель: Какой lЛавllЫЙ фактор определяет 6меСЯЧ1lЫЙ срок?
ВОЗМОJlC1l0, НQ.iИ удасrпся найти взаимоприемлемое решение.
Администратор: Через 6 месяцев состоится ежеzодllая торzовая выставка.
Пропустив ее, мы ЛИШШlСЯ возможности продемонстрировать пpozpa.м..мy .мHO
lИМ Ba:нC1lbL Юlиента.м. Фактически это задержит ци1Ul прода]/с на целый lOa.
Те:171ический руководитель: Я действительно не MOZY обещать выдать оконча
тельную версию к торzовой выставке. Но я MOZY поручиться, что бетаверсuя
будет zomoBa к выставке, а предоставленный мной специалист будет знать OC
новные проблемы и СJ"ИО]lCет управлять проzрам.мой так, что 01lа не «упадет»
во вреАt.Я выставки. Что вы на это скажете?
АдМИ1lистратор: Если вы обещаете, что пpozpaм.мa будет работать без сбоев,
Аtеня это устроит.
ТеХ'llический руководитель: ДоzоворWlИСЬ.
Важнейшее различие между типичными переrоворами и решением проблем
посредством обсуждения интересов состоит в том, что переrоворы обычно замо
раживаются» на позициях. Поворотным моментом в этом диалоrе стал вопрос
техническоrо руководителя о rлавном факторе, определяющем 6месячный срок.
Дllалоr переКЛIОЧИЛСЯ со спора о позициях на попытки понять интересы компа
нин и решить базовую проблему. Сосредоточившись на интересах, вы с большей
вероятностью найдете взаимоприемлемое решение.
,
Разработка вариантов, обеспечивающих взаимный выиrрыш
Ваш СIIльнейший союзник при обсуждении оценок  не оценка, а ваше умение
1Iредлаrать вариаllты планирования, о которых ничеrо не известно нетехническим
участникам. Вы держите ключ от сейфа с техническими знаниями, и по этой при
чине ответственность за выдачу творческих решений ложится в большей степени
на ваши плечи. И1енно вы должны предложить полный спектр возможностей
и ](ОIПрОМИССОВ.
В табл. 23.2 перечислены некоторые варианты планирования, которые часто
помоrаIОТ выйти из тупика.
Таблица 23.2. Варианты планирования, которые часто помоraют выйти из тупиковой ситуации
Варианты, относящиеся к функциональности
Перемещение части желательных функций в версию 2. Мало кому действительно необходимо
получить сразу все, что они просили
Применение итеративноrо подхода. Выдавайте nporpaMMY в версиях 0.2, 0.4, 0.6, 0.8 и 1.0,
начиная с реализации важнейшей функциональности
Полное исключение некоторых возможностей. В первую очередь исключаются возможности,
связанные с максимальными затратами
Использование «метода футболки» для первоочередной реализации функций, обладающих
наибольшей коммерческой ценностью

23.3. Решение проблем и принципиальные переrО80рЫ 269
Упрощенная реализация некоторых функций. Такие функции реализуются до определенной
степени, но делаются менее изощренными
Ослабление подробных требований по каждой функции. Определите свою задачу как максимальное
приближение к требованиям с использованием существующих компонентов
Построение конуса неопределенности, ориентированноrо на функциональность. Определите
одни функции как «абсолютно обязательные», друrие как «абсолютно лишние» и третьи как
«возможные». Предложите план сужения функциональноrо конуса неопределенности по мере
продвижения проекта
Варианты, относящиеся к ресурсам
Увеличение ЧИOlенности разработчиков или тестеров, если проект еще находится на ранней стадии
Наем внештатноrо персонала, если проект еще находится на ранней стадии
Введение высокопроизводительноrо техническоrо персонала (например, экспертов по предметной
области или дополнительных ведущих разработчиков)
Увеличение административной поддержки
Повышение уровня поддержки разработчиков
Расширение участия конечных пользователей или клиентов. Включите в проект на полный
рабочий день пользователя с правом принятия обязывающих решений по поводу
функциональности продукта
,
Расширение участия руководства, позволяющее ускорить принятие решений
Передача части работы друrой rруппе (но помните о проблемах интеrрации, которые при этом
возникнут)
Выделение 100 О/о ресурсов на проект. Участники проекта не должны делить свое рабочее время
между новым и старым проектом, или несколькими новыми проектами
Варианты, относящиеся к срокам
Составление «дорожной карты оценок» с изложением плана пересмотра и уточнения оценок
Использование диапазонных или rрубых оценок, уточняемых по мере продвижения проекта
Поиск способов планирования для достижения определенных целей по срокам, стоимости или
функциональности, по мере уточнения требований и планов
Задержка некоторых обязательств до завершения следующей фазы проекта (то есть работы,
необходимой для сужения конуса неопределенности)
Выполнение однойдвух коротких итераций для калибровки производительности и последующее
принятие обязательств на основании полученных данных
rлавное  предотвратить перепалки типа «Я не MOlY это сделать». Може
Te. «Нет, ие MOlY».  MO)l(eTe!  He MOlY!!! Представьте набор вариантов
и сосредоточьте обсуждение на них. Не включайте заведомо невозможные ваРJl
анты в свой набор. Старайтесь не rоворить «Нет, это неВОЗlVIОЖНО; вместо этоrо
направьте дискуссию на то, что возможно. Чем больше вы представите вариан
тов, работающих на блаrо орrанизации, тем проще вам будет показать, что вы
находитесь на одной стороне с человеком, с которым решается проблема.
СОВЕТ NQ 116
Выдайте как можно больше вариантов планирования, поддерживающих цели вашей орrанизации.
и одно предупреждение: в атмосфере мозrовоrо штурма», возникающеЙ в ходе
свободной дискуссии при решении проблем, леrко соrласиться на решение, которое

270 rлава 23 · Политика, neperOBopbI и решение проблем
вам в тот момент кажется удачным. Однако на следующее утро идея выrлядит
уже не столь привлекательно. В этоЙ ситуации действуют предупреждения, при
веденные в разделе 4.8. Не приниrvrайте жестких обязательств, пока у вас не будет
достаточно времени для спокойноrо анализа их последствий.
СОВЕТ NQ 117
В процессе cOBMeCТHoro решения проблем не принимайте поспешных обязательств, основанных
на импровизированных оценках.
Применение объективных критериев
В нашем деле есть одна странность: если тщательно выверенная оценка значи
тельно превышает желаемую, клиент или начальник часто попросту иrнорирует
ее (Jones 1994). Такое возможно даже в том случае, если оценка была получена
в оценочной проrрамме, или представлена внешним экспертом, или орrанизация
известна частыми превышениями своих оценок в прошлом. Подверrать COMHe
нию оценку  абсолютно допустимо и даже полезно. Проиrнорировать оценку
и заменить ее своими домыслами  нет.
Коrда принципиальные переrоворы переходят в решение проблем, вы ищете
разумное соrлашение, оцениваемое по какимлибо объективным CTaндapTaM.
Вы можете спорить с собеседниками относительно Toro, какие объективные CTaH
дарты являются наиболее подходящими, но относитесь без предвзятости к пред
лаrаемым им стандартам. Что еще важнее, не поддавайтесь давлению  только
принципам. Чтобы поддержать дискуссию, основанную на принципах, необходимо
определить, кто является компетентной стороной в каждом аспекте дискуссии.
Технический персонал и техническое руководство формирует оценку
Вы лучше друrих понимаете техничеСКУIО часть работы и создание оценок для
нее. Следовательно, вы должны быть основным авторитетом в оценке.
Нетехнические ответственные стороны формирует цели
Администраторы, специалисты по продажам и маркетинry вследствие своей по
зиции обычно лучше понимают потребности и приоритеты бизнеса. По этой при
чине они являются основными авторитетами по бизнесцелям.
Технический инетехнический персонал совместно формируют обязательства
Цели и оценки в конечном итоrе сходятся в обязательствах. Если вам удастся
достичь соrлашения относительно Toro, что вы авторитетны в оценке, а друrие
стороны  в целях, большая часть дискуссии естественным образом сосредоточится
на обязательствах. Определяющим принципом должно стать достижение соrла
шения относительно Toro, какие обязательства будут лучшими для орrанизации.
В этих дискуссиях необходимо учитывать следующие рекомендации.
· Не обсуждайте саму оценку. Объясните собеседникам, чем оценка отли
чается от обязательств. Постоянно направляйте дискуссию на достижение
обязательств, отвечающих интересам орrанизации.
· Настаивайте на том, что оценка должна быть подrотовлена компетент..
ной стороной. Самым КОI\'lпетентным оценщиком нередко оказываетесь вы;

Дополнительные ресурсы 271
в друrих случаях им может быть независимая rруппа оценки. Такие rруп
пы эффективны, прежде Bcero, потому, что они не имеют субъективной за
интересованности ни в выдаче проrраммы за кратчайшее возможное время,
ни в том, чтобы избежать тяжелой работы. Если дискуссия зациклится на
теме самой оценки, предложите передать оценку третьей стороне и соrла
ситесь принять результат. Попросите друrие стороны сделать то же самое.
· Вариация на эту тему  привлечение консультанта или внешнеrо эксперта
для анализа сроков. Посторонний эксперт иноrда вызывает больше дo
верия, чем знакомый. Некоторые орrанизации также добивались успеха,
используя оценочные проrраммы. После Toro как технический персонал
откалибрует проrрамму для KOHKpeTHoro проекта, они моrли леrко и объек
тивно проанализировать последствия различных решений.
· Ссылайтесь на стандартизированную процедуру оценки вашей орrаниза..
ции. Предварительное принятие стандартизированной процедуры оценки
часто позволяет избежать дискуссий по поводу Toro, кто должен создавать
оценку. Вы можете просто сказать: Наша процедура не позволяет обсуж
дать саму оценку. Давайте лучше поrоворим об основных предположениях
оценки (таких, как размер проекта) и о том уровне риска, при котором для
орrанизации будет оправдано принятие обязательств по данному проекту.
· Не поддавайтесь эмоциям. Люди обладают разной восприимчивостью
к давлению, но если ваши клиенты, менеджеры, специалисты по маркетин
ry и друrие стороны хотят, чтобы вы приняли на себя невыполнимые обя
зательства, на мой взrляд, лучше Bcero вежливо и твердо отстаивать свои
убеждения. Лучше задраить люки и пережить бурю, связанную с непри
ятными оценками, на ранней стадии проекта, чем yparaH нарушений сроков
и перерасхода бюджета.
В действительности никто не выиrрывает от принятия заведомо невыполни
мых целей, хотя некоторым людям кажется иначе. Отстаивая решения, COOTBeT
ствующие реальным деловым потребностям вашеrо начальства и клиентов, вы
лишь повышаете свою репутацию. Обеспечьте предсказуемость и помоrите вашей
орrанизации соблюдать принятые обязательства.
СОВЕТ NQ 118
Чтобы выйти из тупика, возникшеrо в дискуссии, почаще возвращайтесь к вопросу: «Что будет
лучше ДЛЯ нашей орrанизации?»
Дополнительные ресурсы
Fisher, Roger, William Ury, and Bruce Patton. Getting to Yes, Second Edition».
New York, NY: Penguin Books, 1991. В книrе приводится подробное описание CTpa
теrии принципиальных переrоворов, представленной в этой rлаве. Книrа coдep
жит массу интересных примеров и хорошо читается даже в том случае, если вы не
интересуетесь проблемами переrоворов.

1
Проверка
разумности оценки
Следующий вопросник поможет определить, какую пользу текущая оценка при
несет при управлении проектом. 3а каждый положительный ответ начисляется
одно очко.
1. Использовалась ли стандартизированная процедура при создании оценки?
2. Был ли процесс оценки свободен от давления, способноrо повлиять на pe
зультаты?
3. Если по поводу 'Оценки проводились переrоворы, обсуждались ли в них
только входные параl\1етры оценки (без обсуждения результатов или caMO
ro процесса оценки)?
4. Соответствует ли четкость представления оценки ее точности? (Например,
выражается ли оценка в виде диапазона или rpубоrо приближенноrо значе
ния на ранних стадиях проекта?)
5. Была ли оценка получена с применением нескольких альтернативных J\.le:'
тодов, приводящих к сходным результатам?
6. Сравнимы ли предположения о производительности, заложенные в основу
оценки, с производительностью, фактически достиrнутой в прошлых про
ектах аналоrичноrо размера?
7. Составляет ли оцениваемый срок по меньшей мере 2,0 х ЧеловекоМесяцы 1 / З ?
(То есть находится ли оценка за пределами зоны невозможности?)
8. Участвовали ли в создании оценки люди, которым предстоит выполнять
работу?
9. Была ли оценка проанализирована экспертом в области оценки?
10. Включен ли в оценку ненулевой допуск для проектных рисков, влияющих
на объем работы и сроки?

Результат 273
11. Входит ли оценка в серию оценок, точность которой постепенно повышает
ся с переходом в узкую часть конуса неопределенности?
12. Учтены ли в оценке все элементы проекта, включая создание проrpаммы yc
тановки, утилит преобразования данных, адаптацию старых систем и т. д.?
итоrо:
Процедура проверки взята из КllИl «5oftware Estimatioп Стива Макконнела (Мiсrоsоft
P,-ess, 2006), <9 2006 5teve МсСоппеП. Alllights reseпJed. Копирование разреше1l0 при условии
сохранеllИЯ aaHHolo уведомлеиuя об авторском праве.
Результат
1 o 12  оценка обладает высокой точностыо.
7 9  оценка достаточно хороша для управления проектом, но, скорее Bcero,
несколько оптимистична.
<6  оценка подвержена существенному смещеНИIО и/или слишком опти
мистична, а ее точности недостаточно для осмысленноrо управления проектом.
t
1 О Зах. 893

Ответы на воп росы
теста из rлавы 2
Вопрос
Температура поверхности Солнца
Широта Шанхая
Площадь континента Азия
rOA рождения Александра MaKeдoHcкoro
Общая стоимость американской валюты, находившейся
в обращении в 2004 r.
Общий объем Великих Озер'
Мировые кассовые сборы фильма «Титаник»
Общая длина линии побережья Тихоrо океана
Количество названий книr, опубликованных в США с 1776 r.
Максимальный зафиксированный вес rолубоro кита
Описание
6000 ос
310 северной широты
44 390 000 квадратных километров
356 до н. э.
719,9 миллиарда долларов
6,8 х 1020 кубических метров
6,8 х 1023 литров
1,835 миллиарда долларов
135 663 километров
22 миллиона
170 тонн

Рекомендации
по оценке
nporpaMMHbIX
проектов
rлава 1
СОВЕТ NQ 1
Не путайте оценки, цели и обязательства.
СОВЕТ NQ 2
Коrда вас просят предоставить оценку, определите, что именно нужно спрашивающему  oцeH
ка или план достижения цели.
СОВЕТ NQ 3
Сталкиваясь с точечной «оценкой», спросите себя, действительно ли это число является oцeH
кой или на самом деле перед вами цель.
СОВЕТ NQ 4
Если вы сталкиваетесь с точечной оценкой, скорее Bcero, ее вероятность отлична от 100 О/о.
Спросите себя, какова вероятность получения этоrо числа.
rлава 2
СОВЕТ NQ 5
Не предоставляйте процентные оценки достоверности (особенно «достоверные на 90 О/о»), если
только они не поддерживаются количественными методами.
СОВЕТ NQ б
Избеrайте искусcrвенноrQ сужения диапазонов. Следите за тем, чтобы диапазоны, используе
мые в оценках, не искажали вашеrо представления о достоверности оценки.
СОВЕТ NQ 7
Если вы испытываете воздействие, направленное на сужение диапазона, убедитесь в том, что
оно идет извне, а не рождается внутри вас.

276 Приложение В . Рекомендации по оценке проrраммных проектов
rлава 3
СОВЕТ NQ 8
Избеrайте намеренной недооценки. Потери от недооценки превышают потери от переоцен
ки. Если вас беспокоит возможная переоценка, решайте проблемы посредством планирования
и управления, а не за счет смещения оценки.
СОВЕТ NQ 9
Несоответствие между деловыми целями и оценкой проекта следует рассматривать как ценную
информацию о возможной неудаче проекта. Принимайте меры на ранней стадии, KorAa еще
можно чтото сделать.
СОВЕТ NQ 10
Мноrие орrанизации ценят предсказуемость выше, чем срок разработки, затраты или rибкость.
Обязательно выясните, какие показатели считаются приоритетными в вашем случае.
r па ва 4
СОВЕТ NQ 11
Проанализируйте воздействие конуса неопределенности на точность вашей оценки. Ваша оцен-
ка не может быть более точной, чем это возможно на текущей позиции проекта внутри конуса.
СОВЕТ NQ 12
Не надейтесь, что конус неопределенности будет сужаться сам собой. Вы должны заставить ero
сужаться, устраняя источники неопределенности из проекта.
СОВЕТ NQ 13
Учитывайте наличие Ko\iyca неопределенности, закладывая в своих оценках заранее опреде--
ленную амплитуду неопределенности.
СОВЕТ NQ 14
Учитывайте наличие конуса неопределенности, разделяя оценку на две составляющие: один
специалист дает количественную оценку, а друrой оценивает ее неопределенность.
СОВЕТ NQ lS
Не рассчитывайте, что совершенствование методики оценки само по себе обеспечит более точ
ную оценку в хаотических проектах. Невозможно точно оценивать процесс, который вами не
контролируется. На первом шаrе важнее избавиться от хаоса, чем совершенствовать оценку.
СОВЕТ NQ 16
В условиях нестабильных требований следует ориентироваться на стратеrии управления проек-
том вместо стратеrий оценки (или совместно с ними).
СОВЕТ NQ 17
Включайте в оценку время для всех видов требований  заявленных, неявных и нефункцио
нальных. Ничто не создается «из ничеrо», и ваша оценка не должна подразумевать, будто воз
можно обратное.
СОВЕТ NQ 18
Учитывайте в оценке все необходимые действия, связанные с разработкой проrраммноrо обес
печения, не только проrраммирование и тестирование.

rлава 6 277
СОВЕТ NQ 19
В проектах, продолжительность которых превышает несколько недель, следует предусматри
вать допуск для дополнительных факторов: праздников, отпусков по болезни, времени обуче
ния, собраний.
СОВЕТ NQ 20
Не уменьшайте оценки, полученные от разработчиков,  скорее Bcero, они и без Toro излишне
оптимистичны.
СОВЕТ NQ 21
Избеrайте включения «реryляторов» В свои оценки. Хотя может показаться, будто реryляторы
улучшают точность, на самом деле они вводят в оценку субъективность и снижают реальную
точность.
СОВЕТ NQ 22
Не давайте импровизированных оценок. Даже если потратить на оценку Bcero 15 минут, она бу
дет более точной.
СОВЕТ NQ 23
Количество значащих цифр в оценке (ее четкость) должно соответствовать точности оценки.
.
r па ва 5
СОВЕТ NQ 24
Приложите соответствующие усилия ДЛЯ оценки размера проrраммы, над которой вы работае
те. Размер вносит наиболее значительный вклад в определение объема работы и сроков.
СОВЕТ NQ 25
Не следует предполаrать, что объем работ линейно зависит от размера проекта. Рост происхо
дит по экспоненте.
СОВЕТ NQ 26
Используйте специализированные проrраммы для вычисления влияния издержек масштаба.
СОВЕТ NQ 27
Если ранее вы уже завершали предыдущие проекты, размер которых незначительно отличается
от размера оцениваемоrо проекта (в диапазоне, в котором самый большой проект превосходит
самый мелкий не более чем в 3 раза), для оценки HOBoro проекта можно смело использовать
масштабный коэффициент (скажем, количество строк кода на человекомесяц).
СОВЕТ NQ 28
В своей оценке учитывайте тип разрабатываемой проrраммы  в отношении влияния на объем
работы и сроки этот фактор является вторым по значимости.
r па ва б
СОВЕТ NQ 29
При выборе метода оценки следует учитывать оцениваемый показатель, размер проекта, cтa
дию разработки, стиль разработки и требуемую точность.

278 Приложение В . Рекомендации по оценке nporpaMMHbIX проектов
rлава 7
СОВЕТ NQ 30
Считайте везде, rде это возможно. Если счет невозможен..... вычисляйте. Используйте оценки,
полученные на основании одноrо лишь экспертноrо суждения, только в крайнем случае.
СОВЕТ NQ 31
Найдите счетный показатель, который может использоваться для осмысленноrо измерения co
держания работы в вашей среде.
СОВЕТ NQ 32
Соберите исторические данные, которые позволят вам вычислить оценку по счетным показа
телям.
СОВЕТ NQ 33
Не пренебреrайте возможностями простых, rрубых оценочных моделей..... таких, как средний
объем работы на дефект, средний объем работы на вебстраницу, средний объем работы на ис
торию пользователя и средний объем работы на сценаРIl1Й использования.
СОВЕТ NQ 34
Не используйте экспертные суждения для подrонки оценок, полученных на основании ВЫЧИС11е
ний. Подобная «экспертиза» обычно лишь ухудшает точность оценки.
СОВЕТ NQ 35
Стройте свои оценки производительности на исторических данных. Производительность вашей
орrанизации в прошлом дает наилучшее представление о ее производительности в будущем.
СОВЕТ NQ 3б
Исторические данные помоrают избежать решений, имеющих политическую подоплеку и возни
кающих из предположений типа «Моя rpynna ниже cpeдHero».
rлава 8
СОВЕТ NQ 37
При сборе исторических данных для оценок убедитесь в том, что вы понимаете смысл показа
телей, и не изменяйте ero между проектами.
СОВЕТ NQ 38
Собирайте исторические данные как можно раньше после начала проекта.
СОВЕТ NQ 39
Орrанизуйте периодический сбор исторических данных во время работы над проектом. Это
позволит вам позднее построить профиль выполнения проекта, базирующийся на собранных
данных.
СОВЕТ NQ 40
Используйте данные, полученные в ходе текущеrо проекта (проектные данные), для создания
высокоточных оценок для оставшейся части проекта.

rлава 10 279
СОВЕТ NQ 41
Там, rде это возможно, используйте для калибровки оценок проектные или исторические дaH
ные вместо среднеотраслевых. Помимо повышения точности оценок, исторические данные
сокращают разброс оценок, обусловленный неопределенностью предположений по поводу про
изводительности.
СОВЕТ NQ 42
Если в настоящий момент у вас еще нет исторических данных, начните собирать их как можно
скорее.
rлава 9
СОВЕТ NQ 43
Оценки уровня задач следует поручать людям, непосредственно анимающихся выполнением
соответствующей работы.
СОВЕТ NQ 44
Создание оценок для лучшеrо и худшеrо случаев стимулирует мышление и nOMoraeT учесть весь
возможный диапазон возможных результатов.
.
СОВЕТ NQ 45
Используйте контрольные списки для улучшения индивидуальных оценок. Составляйте и веди
те собственные контрольные списки.
СОВЕТ NQ 46
Сравнивайте оценки с фактическими результатами, чтобы повышать качество своих оценок со
временем.
rлава 10
СОВЕТ NQ 47
Разбейте общую оценку на фраrменты, чтобы воспользоваться действием закона больших чисел:
ошибки в сторону завышения и занижения до определенной степени компенсируют друr друrа.
СОВЕТ NQ 48
Используйте обобщенную структуру трудозатрат nporpaMMHbIx проектов (WBS), чтобы не за
быть о типовых операциях.
СОВЕТ NQ 49
Используйте упрощенную формулу среднеквадратическоrо отклонения для вычисления coдep
жательных оценок лучшеrо и худшеrо случаев в проектах, состоящих из 10 и менее задач.
СОВЕТ NQ 50
Используйте сложную формулу стандартноrо отклонения для вычисления содержательных CBOД
ных оценок лучшеrо и худшеrо случаев в проектах, состоящих из 10 и более задач.
СОВЕТ NQ 51
Не исполЬЗУЙТе деление диапазона между лучшим и худшим случаями на б при вычислении отклон
ний стандартных оценок. Выбирайте делитель в эавиО1МОСТИ от точности диапазонов ваших оценок.

280 Приложение В . Рекомендации по оценке nporpaMMHbIX проектов
СОВЕТ NQ 52
Направьте усилия на повышение точности оценок ожидаемоrо случая. Если отдельные оценки точ-
ны, то и их объединение не создаст проблем. С друrой стороны, если отдельные оценки неточны,
объединение станет возможным лишь после Toro, как вы найдете способ повысить их точность.
rлава 11
СОВЕТ NQ 53
Оценивайте новые проекты, сравнивая их с похожими прошлыми проектами. Постарайтесь раз
бить оценку минимум на пять фраrментов.
СОВЕТ NQ 54
Не решайте проблему неопределенности смещением оценки. Постарайтесь отразить неопреде-
ленность в самой оценке.
СОВЕТ NQ 55
Используйте нечеткую лоrику для оценки размера nporpaMMbI в строках кода.
СОВЕТ NQ 56
Рассматривайте метод стандартных компонентов как средство для получения оценки размера
с минимальными усилиями на ранних стадиях проекта.
СОВЕТ NQ 57
Метод абстрактных рейтинrов используется для получения ранней оценки объема работ и cpo
ков проекта, и в основу ero закладываются данные Toro же проекта.
СОВЕТ NQ 58
Будьте внимательны при вычислении оценок, в которых используются числовые рейтинrовые
шкалы. Убедитесь в том, что числовые катеrории на шкале действительно ведут себя как числа,
а не как отвлеченные катеrории вроде «малый», «средний» или «большой».
СОВЕТ NQ 59
Используйте метод футболки, чтобы помочь не-техническим сторонам проекта принять реше
ния по включению или исключению тех или иных функций в широкой части конуса неопреде
ленности. ·
СОВЕТ NQ 60
Используйте опосредованные методы для оценки количества тестовых сценариев, дефектов,
страниц документации и любых друrих показателей, которые трудно оценивать напрямую.
СОВЕТ NQ 61
ПОДСЧИТblвайте тот показатель, который проще Bcero считается и обеспечивает максимальную
точность в вашей среде. Соберите калибровочные данные и используйте их для создания oцeH
ки, адаптированной к вашей среде.
rлава 13
СОВЕТ NQ 62
Используйте rpynnoBoe обсуждение для повышения точности оценки.


rлава 16 281
СОВЕТ NQ 63
Используйте широкополосный Дельфийский метод для формирования оценок на ранней стадии
проекта, в незнакомых системах, а таюке тоrда, коrда в проекте задействовано несколько раз
нородных дисциплин.
rлава 14
СОВЕТ NQ 64
Используйте оценочные проrраммы для лоrической проверки оценок, созданных ручными MeTO
дами. Оценки крупных проектов должны в большей степени опираться на коммерческие oцe
ночные проrраммы.
СОВЕТ NQ 65
Не относитесь к результатам оценочной nporpaMMbI как к божественному откровению. Прове
ряйте их на соответствие здравому смыслу точно так же, как любую друryю оценку.
rлава 15
СОВЕТ NQ 66
Используйте несколько альтернативных методов оценки и проанализируйте совпадения или
расхождения результатов.
СОВЕТ NQ 67
Если разные методы оценки приводят к разным результатам, попытайтесь выявить факторы,
изза которых возникают различия. Продолжайте оценивать проект заново до тех пор, пока pe
зультаты, полученные разными методами, не будут расходиться в пределах 5 О/о.
СОВЕТ NQ 68
Если деловая цель противоречит нескольким сходящимся оценкам, лучше доверьтесь оценкам.
rлава 16
СОВЕТ NQ 69
Не оспаривайте результаты оценки, а принимайте их как данность. Изменение результата может
производиться только одним способом: изменением входных данных и повторным вычислением.
СОВЕТ NQ 70
Сначала сконцентрируйтесь на оценке размера. Затем вычислите объем работ, сроки, стоимость
и функциональность по оценке размера.
СОВЕТ NQ 71
Проводите повторную оценку.
СОВЕТ NQ 72
Переходите от неточных оценок к более точным по мере продвижения работы над проектом.
СОВЕТ NQ 73
Коrда проекr будет rOToB к назначению индивидуальных заданий, переходите на восходящую оценку.

282 Приложение В · Рекомендации по оценке nporpaMMHbIX проектов
СОВЕТ NQ 74
Если оценка пересчитывается в результате нарушения промежуточных сроков, новая оценка
должна базироваться на фактическом ходе проекта, а не на запланированных показателях.
СОВЕТ NQ 75
Представляйте свои оценки в таком виде, чтобы они уточнялись по мере продвижения проекта.
СОВЕТ NQ 76
Сообщайте о своих планах nOBTopHoro проведения оценки заранее.
rлава 17
СОВЕТ NQ 77
Определите стандартизированную процедуру оценки на уровне орrаниэации и применяйте ее
на уровне отдельных проектов.
СОВЕТ NQ 78
Координируйте стандартизированную процедуру оценки с процессом SDLC, принятым в вашей
орrанизации.
СОВЕТ NQ 79
Анализируйте оценки и процедуры получения оценок в своих проектах; это поможет вам повы
сить точность оценок и свести к минимуму затраты на их создание.
СОВЕТ NQ 80
Используйте строки npor;PaMMHoro кода для оценки размеров, но помните об общих оrpаничениях
простых метрик, а также специфических опасностях метрики LOC.
СОВЕТ NQ 81
Воспользуйтесь методом функциональных пунктов, чтобы получить относительно точную oцeH
ку размера на ранней стадии проекта.
СОВЕТ NQ 82
Используйте rолландский метод для получения приближенной оценки с минимальными затрата
ми на ранней стадии проекта.
СОВЕТ NQ 83
Используйте подсчет элементов GUI для получения приближенной оценки с минимальным объе
мом работы на ранней стадии проекта.
СОВЕТ NQ 84
При правильной методолоrии оценка размера становится основой для всех остальных оценок.
Размер создаваемой системы является важнейшим фактором, определяющим ее стоимость.
Для повышения точности используйте альтернативные оценки со сравнением результатов.
СОВЕТ NQ 85
Используйте оценочные nporpaMMbI, основанные на формальных методах оценки, для более
точноrо вычисления оценки объема работ по имеющейся оценке размера.

,
rлава 20 283
СОВЕТ NQ 86
Используйте среднеотраслевые rрафики для получения rрубой оценки объема работ в широкой
части конуса неопределеннасти. Помните, что в крупных проектах затраты, связанные с приме
нением более мощных методов оценки, быстро окупаются.
СОВЕТ NQ 87
Используйте метод ISBSG для получения rрубой оценки объема работ. Сравните ero с друrими
методами и проанализируйте схождение или расхождение оценок.
СОВЕТ NQ 88
Не все методы оценки равны. При поиске схождения или расхождения между оценками при
сваивайте большие весовые коэффициенты методам, дающим более точные результаты.
rлава 20
СОВЕТ NQ 89
Используйте базовую формулу для ранней оценки срока в средних и крупных проектах.
СОВЕТ NQ 90
Используйте формулу неформальноrо сравнения с прошлыми проектами для ранней оценки
срока в проектах любоrо размера.
СОВЕТ NQ 91
Используйте метод оценки nepBoro порядка для получения неточной (но требующей крайне Ma
лых усилий) оценки срока на ранней стадии проекта.
СОВЕТ NQ 92
Не сокращайте оценку срока без увеличения оценки объема работ.
СОВЕТ NQ 93
Не сокращайте номинальный срок более чем на 25 О/о. Иначе rоворя, не пытайтесь ввести oцeH
ки в «зону невозможности».
СОВЕТ NQ 94
Чтобы снизить стоимость проекта, увеличьте срок и используйте rpynny меньшей численности.
СОВЕТ NQ 95
В бизнессистемах cpeдHero размера (от З5 000 до 100000 строк кода) не рекомендуется исполь
зовать rpYnnbI численностью более 7 человек.
СОВЕТ NQ 96
Используйте оценку срока для проверки реалистичности своих планов. Для формирования
окончательноrо rрафиа следует применять детальное планирование.
СОВЕТ NQ 97
Прежде чем искать схождение или расхождение между оценками, исключите из набора данных
результаты, полученные слишком общими методами.

284 Приложение В · Рекомендации по оценке nporpaMMHbIX проектов
СОВЕТ NQ 98
При распределении объема работы проекта следует учитывать размер проекта, тип проекта,
а также операции, заложенные в калибровочных данных, использованных для создания исход
ной монолитной оценки.
СОВЕТ NQ 99
При распределении сроков между различными операциями следует учитывать размер проекта,
ero тип и методолоrию разработки.
СОВЕТ NQ 100
Используйте среднеотраслевые или исторические данные для оценки предполаrаемоrо количе
ства дефектов в вашем проекте.
СОВЕТ NQ 101
Данные эффективности исправления дефектов позволяют оценить количество дефектов, KOTO
рые будут удалены из nporpaMMbI вашими методами контроля качества перед выпуском оконча
тельной версии.
СОВЕТ NQ 102
Используйте суммарный ущерб рисков вашеrо проекта в качестве отправной точки при плани
ровании буферов. Проанализируйте отдельные аспекты конкретных рисков и постарайтесь
понять, не должен ли запланированный буфер быть больше или меньше cyMMapHoro ущерба.
СОВЕТ NQ 103
Планирование и оценка  взаимосвязанные темы, а тема планирования слишком обширна, что
бы ее можно было изложить в одной rлаве книrи, посвященной оценке nporpaMMHbIx проектов.
Читайте специализированную литературу по планированию.
СОВЕТ NQ 104
Документируйте и сообщайте предположения, заложенные в оценке.
СОВЕТ NQ 105
Вы должны четко понимать, какая неопределенность отражается в представлении оценки: He
определенность самой оценки или же неопределенность, влияющая на вашу возможность BЫ
полнения обязательств.
СОВЕТ NQ 106
Не представляйте ответственным сторонам проекта маловероятные результаты.
СОВЕТ NQ 107
Подумайте, не заменить ли текстовое представление оценки rрафическим.
СОВЕТ NQ 108
Используйте стиль представления оценок, который бы подчеркивал передаваемую вами инфор
мацию о точности оценки.
СОВЕТ NQ 109
Не пытайтесь выражать обязателbqва в диапазонной форме. Обязательства должны быть более
конкретными.

r
1
rлава 20 285
СОВЕТ NQ 110
Поймите, что администраторы настойчивы по своей природе и по должности, и планируйте об
суждение оценок соответствующим образом.
СОВЕТ NQ 111
Учитывайте воздействие внешних факторов. Ваши собеседники должны видеть, что вы пони
маете коммерческие требования и их важность.
СОВЕТ NQ 112
Обсуждайте обязательства, но не оценки.
СОВЕТ NQ 113
Расскажите ответственным участникам, не связанным с технической стороной проекта, о прин
ципах эффективной оценки проrраммных проектов.
СОВЕТ NQ 114
Относитесь к обсуждению оценок как к решению проблемы, а не как к переrоворам. Поймите,
что все ответственные участники проекта находятся на одной стороне. Либо все вместе проиr
рывают, либо все вместе выиrрывают.
СОВЕТ NQ 115
Нападайте на проблему, а не на людей.
СОВЕТ NQ 116
Выдайте как можно больше вариантов планирования, поддерживающих цели вашей орrанизации.
СОВЕТ NQ 117
В процессе cOBMeCТHoro решения проблем не принимайте поспешных обязательств, основанных
на импровизированных оценках.
СОВЕТ NQ 118
Чтобы выйти из тупика, возникшеrо в дискуссии, почаще возвращайтесь к вопросу: «Что будет
лучше для нашей орrанизации?»

Библиоrрафия
AbdelHarnid, Т., and S. Madnick, 1986. Irnpact of Schedule Estirnation оп Software
Project Беhаviоr, IEEE Software, 3, 4 (July 1986), рр. 70 75.
Albrecht, Allan J., 1979. Measuring Applicaion Developrnent Productivity.
Proceedings of theJoint SНАRЕ/GUIDЕ/IБМ Application Developrnent Symposiurn,
October 1979: 8392.
Albrecht, А., and J. Gaffney, Software Function, Source Lines of Code, and
Development Effort Prediction: А Software Science Validation», IEEE Transactions
оп Software Engineering, SE9(6),.1983, рр. 639648.
Armour, Phillip, 2002. Ten Unrnyths of Project Estirnation, Cornrnunications of
the АСМ, Novernber 2002, рр. 15 18.
Armstrong, J. Scott, ed., 200 1. Principles of forecasting: А handbook for researchers
and practitioners». Боstоп, МА: Kluwer Academic Publishers.
Arnone, Michael, 2005. Azrni: Sentinel Won't Repeat Mistakes, Federal Computer
Week, Septernber 13,2005.
Associated Press, 2003. Боstоп's 'Бig Dig' Opens to Public: Tunnel Project is
Five Years Беhiпd Schedule, Бilliопs Over Бudgеt. МSNБС.соrn, Decernber 20,2003.
Баkеr, F. Terry, 1972. Chief Prograrnrner Теаrn Managernent of Production Prog
ramming, IБМ Systerns Journal, vol. 11, по. 1, 1972, рр. 56 73.
Баsili, V.R., and Б.Т. Perricone, 184. Software Errors and Cornplexity: An Ern
pirical Investigation». Comrnunications of the АСМ, v. 27, 1984, рр. 4252.
Баstапi, Farokh, and Sitharama Iyengar, 1987. TЬe Effect of Data Structures оп
the Logical Cornplexity of Prograrns. Cornmunications of the АСМ, vol. 30, по. 3,
рр. 250259.
Бесk, Kent, and Martin Fowler, 2001. Planning Extrerne Prograrnrning, Боstоп,
МА: AddisonWesley.
Бесk, Kent, 2004. Extrerne Prograrnrning Explained: Ernbrace Change, 2d ed.,
Reading, МА: AddisonWesley.
Бепtlеу,Jоп, 2000. Prograrnrning Pearls, 2d ed., Reading, МА: AddisonWesley.

Библиоrрафия 287
Боеhm, Бarry, and Richard Turner, 2004. «Баlanсiпg Agility and Discipline: А Guide
for the Perplexed, Боstоп, МА: Addison Wesley.
Боеhm, Баrrу, et al., 1995. «Cost Models for Future Software Life Cycle Processes:
СОСОМО 2.0, «Annals of Software Engineering», Special Volume оп Software
Process and Product Measurement, j.D. Arthur and S.M. Henry Eds., Amsterdam,
Netherlands: j.C Баltzеr AG, Science Publishers.
Боеhm, Баrrу W., and Philip N. Papaccio, 1988. «Understanding and Controlling
Software Costs, IEEE Transactions of Software Engineering», v. 14, по. 1 О, October
1988,рр. 14621477.
Боеhm, Баrry W., 1981. Software Engineering Economics», Engle\\7ood Cliffs,
Nj: Pl.entice НаН.
Боеhm, Баrrу W., 1987Ь. Industrial software metrics top 10 list», IEEE Software,
vol. 4, no.9 (September 1987), рр. 8485
Боеhm, Баrry W., Т.Е. Gray, and Т. Seewaldt, 1984. Prototyping versus specifying:
А multiproject experiment, IEEE Transactions оп Software Engineering, vol. SE10
(Мау 1984), рр. 290303.
Боеhm, Баrrу, et al., 2000. Software Cost Estimation with Сосоmо II, Reading,
МА: AddisonWesley
Бrооks, Frederick Р., Jr., 1975. «The Mythical ManMonth, Reading МА: Addison
Wesley.
Бrооks, Frederick Р., Jr., 1995. «The Mythical ManMonth: Essays оп Software
Engineering, Anniversary Edition (2nd Ed), Reading МА: AddisonWesley.
Car and Driver, 2004. 2005 Charting the Changes  БМW, Car and Driver»,
Ovtober 2004.
Card, D,avid N., 1987. A Software Technology Evaluation Program, «Information
and Software Technology», v. 29, по. 6,july/August 1987, рр. 291300.
Cockburn, Alistair, 2001. Agile Software Development», Боstоп, МА: Addison
Wesley.
Cohn, Mike, 2005. Agile Estimating and Planning, Upper Saddle River, Nj:
Prentice НаН PTR.
Conte, S.D., Н.Е. Dunsmore, and V.Y. Shen, 1986. Software Engineering Metrics
and Models», Menlo Park, СА: Бепjаmiп/Сummiпgs.
Coombs, Paul, 2003. IT Project Estimation: А Practical Guide to the Costing of
Software», Cambridge, United Kingdom: Cambridge University Press.
Cooper, Robert G., 2001. Winning at New Products: Accelerating the Process
from Idea to Launch, New York, NY: Perseus Бооks Group.
CosteHo, Scott Н., 1984. «Software engineering under deadline pressure, АСМ
Sigsoft Software Engineering Notes, 9:5 October 1984, рр. 1519.
Crosstalk, june 2002.
Crosstalk, April 2002.
Curtis, Бill, 1981. Substantiating Programmer Variability», Proceedings of the
IEEE, vol. 69, no.7, р. 846.
Curtis, Бill, 1981. Software Psychology: The Need for an Interdisciplinary Program»,
«Proceedings of the IEEE», vol. 74, no.8 (August 1986), рр. 1092 1106.
Cusumano, Michael, and Richard W. Selby, 1995. Microsoft Secrets», New York,
NY: The Free Press.

288 Библиоrрафия
Davis, J ohn Stephen, and Richard J. LeBlanc, 1998. A Study of the Applicability
of Complexity Measures, IEEE Transactions оп Software Engineering, у. 14, по. 9,
September 1988, рр. 13661372.
DeMarco, Тот, and Timothy Lister, 1985. «Programmer Performance and the
Effects of the Workplace, Proceedings of the 8th International Conference оп
Software Engineering, August 1985, рр. 268272.
DeMarco, Тот, and Timothy Lister, 1999. Peopleware: Productive Projects and
Teams>.'>, 2d ed., New York, NY: Dorset House.
DeMarco, Тот, and Timothy Lister, 2003. Waltzing with Bears: Managing Risks
оп Software Projects>.'>, New У ork, NY: Dorset House.
DeMarco, Тот, 1982. Controlling Software Projects>.'>, New York, NY: Yourdon
Press.
Evangelist, Michael, 1984. Program Complexity and Programming Style, «Proc.
1st. Int. Conf. Data Engineering, New York, NY: IEEE Computer Society Press,
рр. 531541.
Fenton, Norman Е., and Shari Lawrence pfleeger" 1997. «Software Metrics: А Rigo
rous and Practical Approach, Boston, МА: PWS Publishing Сотрапу.
Fisher, Roger, William Ury, and Bruce Patton, 1991. Getting to Yes>.'>, 2d ed., New
У ork, NY: Penguin Books.
Gaffney, John Е., Jr., and Richard Werling, 1991. Estimating Software Size from
Counts of Externals, А Generalization of Function Points, Herndon, V А: Software
Productivity Consortium document number SPC91094N.
Garmus, David, and David Herron, 2001. Function Point Analysis: Measurement
Practices for Successful oftware Projects>.'>, Boston, МА: AddisonWesley.
Glib, Тот, 1988. Principles of Software Engineering Management>.'>, Wokingham,
England: Addison Wesley.
Glib, Тот, 2005. «Competitive Engineering: А Handbook for Systems Engineering,
Requirements Engineering, and Software Engineering using Planguage, Amsterdam,
Netherlands: Elsevir.
Glass, Robert L., 1994. IS Field: Stress Up, Satisfaction Down>.'>, «Software
Practitioner>.'>, Nov. 1994, рр. 1,3.
Goldratt, Eliyahu М., 1997. Critical Chain», Great Barrington, МА: The North
River Press.
Gorla, N., А.С. Benander, and В.А. Benander, 1990. Debugging Effort Estimation
Using Software Metrics>.'>, «IEEE Transactions оп Soft\vare Engineering>.'>, у. 16, по. 2,
February 1990, рр. 223231.
Gotterbarn, Don, Keith Miller, and Simon Rogerson. Computer Society and АСМ
Approve Software Engineering Code of Ethics>.'>, IEEE Computer>.'>, October 1999,
рр. 8488. www.computer.org/computer/code"of"ethics.pdf.
Grady, Robert В., 1992. Practical Software Metrics for Project Management And
Process Improvement>.'>, Englewood Cliffs, NJ: Prentice НаН PTR.
Grady, Robert В., and Deborah L. Caswell, 1987. Software Metrics: Establishing
а Company..Wide Program, Englewood Cliffs, NJ: Prentice НаН.
Gross, Neil, et al. Software Неll», Business Week>.'>, Nov. 6, 1999, р. 104.


Библиоrрафия 289
Harvey, N., 2001. ImprovingJudgement in Forecasting>.'> in Principles of forecasting:
А handbook for researchers and practitioners>.'>, Ed., J .S. Arll1strong, Boston, МА: Юuwеr
Academic Publishers, рр. 5980.
Heemstra, F.J., and R.j.Custers, 1991. Function Point Analysis: Evaluation of
а Software Cost Estimation Model>.'>. «European journal of Information Systems»
1(4): 223237.
HeeInstra, F.j., W.j.A.Siskens, and Н. уап der Stelt, 1989. Kostenbeheersing Бij
Automatiseringsprojecten: Ееп Empirisch Onderzoek>.'>, «Infomatie», vol. 31, no.1 (1989)
cited in (Putnam and Myers 2003).
Henry, Sallie, and Dennis Kafura, 1984. The Evaluation of Software Systenls'
Structure Using Quantitatiye Software Metrics>.'>, SoftwaI'e  Practice and Experience»,
vol. 14, по. 6 (] ипе 1984), рр. 561  73.
Herbsleb, james, et al., Benefits of СММ Based Software Process ImproveInel1t:
Initial Results>.'>, Pittsburgh: Software Engineering Institute, Document CMU /SEI 
94TR13, August 1994.
Hihn, j., and Н. HabibAgahi, 1991. «Cost Estimation of Software Intensive Projects:
а Survey of Current Practices», International Conference оп Software Engineering,
IEEE COlnputer Society Press, Los Alamitos, СА: 276287.
Host, М., and С. Wohlin, 1998. Ап Experimental Study of Individual Subjectivc
Effort Estimations and Combinations of the Estimates>.'>, International Conference
оп Software EngineeI'ing, Kyoto, japan, IEEE Computer Society, Los Alamitos, СА:
332339.
Humphrey, Watts S., 1995. A Discipline for Software Engineering>.'>, Reading,
МА: Addison Wesley.
Iansiti, Marco, 194. Microsoft Corporation: Office Бusiпеss Unit», HarvaI'd
Business School Case Study, 9691 033, Revised Мау 31, 1994, Boston, МА: Harval.d
Business School.
IEEE Software>.'>, Nov /Dec 2001 Issue.
IFPUG, вебсайт: www.ifpug.org.
ISBSG 2001. Practical Project Estimation: А Toolkit for Estimating Softwarc
Development Effort and Duration>.'>, Australia: International Software Benchmarking
Standards Group, March 2001.
ISBSG 2005. «Practical Project Estimation, 2nd Edition: А Toolkit for Estimating
Software Development Effort and Duration>.'>, Australia: International Software Bench
lnarking Standards Group, February 2005.
ISOjIEC 20926:2003. «Software Engineeril1g  IFPUG 4.1 Unadjusted functional
size measurement method  Counting practice manual>.'>. International Organization
for Standardization, 2003.
jacobson, Ivar, Grady Booch, james Rumbaugh, 1999. «The Unified Software
Development Process», .Reading, МА: Addison Wesley.
jones, Capers, 1996. Software DefectReInoval Efficiency>.'>, IEEE Computer>.'>,
April 1996.
jones, Capers, 2005. «Software Engineering: The State of the Art in 2005», Ver
sion 5, Software Productivity Research Whitepaper, February 11, 2005.
jones, Capers, 1986. Programming Productivity>.'>, New York, NY: McGrawHill.

290 Библиоrрафия
Jones, Capers, 1994. «Assessтent and Control of Software Risks, Englewood Cliffs,
NJ: У ourdon Press.
Jones, Capers, 1995с. «Deterтining Softwa!"e Schedules, «IEEE Coтputer»,
February 1994, рр. 7375.
Jones, Capers, 1997. «Applied Software Measurement: Assuring Productivity and
Quality», 2d ed., New York, NY: McGrawHill.
Jones, Capers, 1998. Estiтating Software Costs», New York NY: McGrawHill.
Jones, Capers, 2000. «Software Assessments, Benchmarks, and Best Practices»,
Reading, МА: Addison  W esley.
Jergensen М., 2002. «А Review of Studies оп Expert Estiтation оп Software
Developтent Effort».
Jergensen М., and D.I.K. Sjeberg, 2002. «The Impact of Customer Expectation оп
Software Developтent Effort Estiтates», International Journal of Project Мапа
gement.
Josephs, R., and E.D. Hahn, 1995. «Bias and ACCUl"acy in Estimates of Task
Dtll.ation, «Оrgапizаtiопаl Behavior and Нип1ап Decision Process», 61(2): 202213.
Kemerer, C.F., 1987. «An Empirical Validation of Soft\\?are Cost Estiтation Models»,
«Commtlnications of the ACM, 30(5), 1987, рр. 416429.
Keтerer, Chris, and Benjaтin Porter, 1992. «Iтproving the Reliability of Function
Point Measureтent: An Empirical Study, «IEEE Transactions оп Software Engine
ering», vol. 18, по. 11, Noveтber 1992, Page 1011.
Kitchenha111, В., S.L. pfleeger, В. МсСоll, and S. Eagall, 2002. «А Case Study of
Maintenance Estiтation Accuracy», <<journal of Systeтs and Software».
Knorr, Eric, 2005. «Anatoтy of ап IT Disaster: How the FBI Blew It», InfoWorld,
March 21,2005.
Krasner, Jerry, 2003. «Eтbedded Software Development Issues and Challenges»,
Embedded l\'larket Forecasters whitepaper, www.embeddedforecast.com.
Lais, Sarni, 2003. «Watch your step: Сап major efforts avoid more slipups?», «Govern
ment Computer News, vol. 22, по. 34, 12/15/03.
Laranjera, Luiz, 1990. «Software Size Estiтation оп ObjectOriented Systeтs» ,
«IEEE Transactions оп Software Engineering», Мау 1990.
Larsen, Richard J., and Morris L. Marx, 2001. «An Introduction to Mathematical
Statistics and Its Applications», 3rd ed., Upper Saddle River, NJ: Prentice НаН.
Lawlis, Dr. Patricia К., Capt. Robert М. Flowe, and Capt. James В. Thordahl, 1995.
«А Correlational Study of the СММ and Software Developтent Performance»,
Crosstalk, Septeтber 1995.
Lederer, Albert L., and Jayesh Prasa9, 1992. «Nine Managelnent Guidelines for
Better Cost Estimating», Coттunications of the АСМ», February 1992, рр. 5 1 59.
Libby, R., and R.K. Blashfield, 1978. «Perforтance of а Composite as а Function
of the Number of Judges», «Organizational Behaviour and Huтan Performance»
21(2): 121129.
Liт, ].S., and М. O'Connor, 1996. «Judgemental Forecasting With Time Series
and Causal Information», «International Journal of Forecasting» 12(1): 139153.
МсСаЬе, Тот, 1976. «А Coтplexity Measure, IEEE Transactions оп Software
Engineering, Voluтe SE2, Number 12 (Deceтber 1976), рр. 308320.

Библиоrрафия 291
МсСоппеН, Steve, 1993. «Code Complete, Redmond, W А: Мiсrоsоft Press, 1993.
МсСоппеll, Steve, 1996. Rapid Development», Redmond: W А: Мiсrоsоft Press.
McConnell, Steve, 1998. «Software Project SUI.vival Guide, Redmond, W А:
Мiсrоsоft Press.
McConnell, Steve, 2000. «Sitting оп the Suitcase, «IEEE Software, Мау /
June 2000.
МсСоппеН, Steve, 2002. «Real Quality for Real Engineers», «IEEE Soft\vare»,
Marchj April, 2002.
МсСоппеll, Steve, 2004а. «Code Complete, 2d ed., Redmond, W А: Мiсrоsоft Press.
МсСоппеll, Steve, 2004Ь. «Professional Software Development», Boston, МА:
AddisonWesley.
McGarry, John, et al., 2002. «Practical Software Measurement: Objective Infor
mation for Decision Makers, Boston, МА: Addison Wesley.
McGraw, Gary, 2003. «From the Ground Up: The DIMACS Soft\vare Security
Workshop, IEEE Security & Privacy», MarchjApril2003. Volume 1, Number 2,
рр. 5966.
Metzger, Philip W.., 1981. «Managing а Programming Project», 2d ed., Englewood
Cliffs, NJ: Prentice НаН.
Mills, Harlan D., 1983. «Software Productivity», Bostol1, l\tIA: Little, BI'own,
рр. 7181.
Mohanty, S.N., 1981. «Software Cost Estimation: Present and Future, Software 
Practice and Experience, 11, рр. 1 03 121.
Mosemann, Lloyd К., 11, 2002. «Did We Lose Our Religion?» Crosstalk, Allgust 2002,
рр. 22 25.
NASA SEL, 1990. «Manager's Handbook for Software Developlnent, Revision 1».
Document number SEL84101. Greenbelt, MD: Goddard Space Flight Center, NASA.
NASA SEL, 1991. «Software Engineering Laboratory (SEL) Relationships, Models,
and Management Rules, SEL91101, February 1991.
NASA SEL, 1995. «Software Management Guidebook», Document Number NASA
GB00194, Greenbelt, М: Goddard Space Flight Center, NASA, June 1995.
NASA, «ISD Wideband Delphi Estimation», Number 580PROGRAMMER01601,
September 1, 2004, http://software.gsfc.nasa.gov/AssetsApproved/PA1.2.1.2.pdf.
Niessink, F., and Н. van Vliet, 1997. «Predicting Maintenance Effort With Fllnction
Points, International conference оп software maintenance, Bari, Italy, IEEE Coтp
uter Society, Los Alamitos, СА, рр. 3239.
Park, R.E., 1996. «А Manager's Checklist for Validating Software Cost and Schedule
Estimates, American Programn1er 9(6), рр. 3035.
Paynter,J., 1996. «Project Estimation Using Screenflow Engineering, International
Conference оп Softwar Engineering: Education and Practice, Dunedin, New Zealand,
IEEE Computer Society Press, Los Alamitos, СА, pp.150 159.
Pehrson, Ron J., 1996. Software Development for the Boeing 777, CrossTalk,
January 1996.
pfleeger, Shari La\vrence, Felicia Wu, and Rosalind Lews, 2005. «Software Cost
Estimation and Sizing Methods, Santa Monica, СА: T11e Rand Corporation.

292 Библиоrрафия
Pietrasanta, Alfred М., 1990. Alfred М, Pietrasanta оп Improving the Software
Process, Software Engineering: Tools, Techniques, Practices>.'>, vol. 1, по. 1 (Мау j
J ипе 1990), pp.2934.
Pitterman, Bill, 2000. Telcordia Technologies: The Journey to High Maturity»,
IEEE Software», July 2000, рр. 8996.
Prechelt, Lutz, 2000. An Empirical Comparison of Seven Progralnlning Language>.'>,
IEEE Computer>.'>, October 2000, рр. 2329.
Putnam, Lawrence Н., and Ware Myers, 1992. Measures for Ехсеllепсе: Reliable
Software Оп Time, Within Budget>.'>. Englewood Cliffs, NJ: Yourdon Press.
Putnam, Lawrence Н., and Ware Myers, 1997. «Industrial Strength Software:
Effective Management Using Measurement», Wasl1ington, DC: IEEE Computer
Society Press.
Putnam, Lawrence Н., and Ware Myers, 1999. Get the Estimate Right, American
Programmer», July 1999, рр. 412.
Putnam, Lawrence Н., and Ware Myers, 2003. Five Core Metrics>.'>, New York,
NY: Dorset House.
Reifer, Donald J., 2002. Estimating Web Developn1ent Costs: There Are Diff
erences, CrossTalk, June 2002, рр. 13 17.
Roetzheim, WiHiam Н., 1988. Structured Computer Project Management, Engle
wood Cliffs, NJ: Prentice НаН.
Rule, Grant, 1998. From Stutzke.
Rule, Grant, 2000. Bees and the Art of Estimating». IEEE Software>.'>, Novemberj
December 2000.
Sackman, Н., Erikson, W.J., Grant, Е.Е., 1968. Exploratory Experimental Studies
Comparing Online and Qffline Programming Performance>.'>. «Communications of the
АСМ>.'>, v. 11, по. 1, January 1968, рр. 3 11.
Sanchez, Roberto, 1998.  UW Learns а Lesson>.'>, «Seattle Times>.'>, April12, 1998,
page В1.
Schlender, Brenton, 1989. How to Break the Software Logjam, «Fortune>.'>,
September 25, 1989.
Schneider, Geri, and Jason Р. Winters, 2001. Applying Use Cases>.'>, 2d ed.,
Boston, МА: Addison Wesley Longman.
Schwaber, Кеп, and Mike Beedle, 2002. ЛgНе Software Development with Scrum>.'>,
Englewood Cliffs, NJ: Prentice НаН.
Sheppard, S.B., et al., 1978. Predicting Programmers' Ability to Modify Software,
TR 783881003, General Electric Сотрапу, Мау 1978.
Sheppard, S.B., et al., 1979. Modern Coding Practices and Programmer Perfor
тапсе>.'>, IEEE Computer>.'>, по. 12, Dec 1979, рр. 41 49.
Shull, et al.,2002. What We Have Learned About Fighting Defects, Proceedings,
Metrics 2002, IEEE; рр. 2492S8.
Smi\:h, John, 1999. The Estimation of Effort Based оп Use Cases, Rational
Software Whitepaper TP171, October 1999.
Standish Group, The, 1994. «Charting the Seas of Information Technology»,
Dennis, МА: The Standish Group.
Stutzke, Richard D., 2005. Estimating SoftwareIntensive Systems, Upper Saddle
River, NJ: Addison Wesley.

Библиоrрафия 293
Symons, Charles, 1991. Soft\vare Sizing and EstiInating: Mk 11 FPA (Funct"iol1
Point Analysis »), Chichestel': J ohn Wiley & Sons.
T11e Age, 2005. «W aiter, thel'e is а bllg in InY Prius,  The Age», www.theage.com.au.
Мау 25, 2005.
Tbe American Heritage Dictionary, Second College Edition, 1985.
The Irish Tiтes, 2005. HSE to suspend rollout of 150т cOn1puter system»,
October 4, 2005.
Tockey, Steve, 2005, Return оп Software», Boston, МА: AddisonWesley.
Todd, Р., and 1. Benbasat, 2000. «Inducing Compensatory Information Processing
Through Decision Aids That Facilitate Effort Reduction: ап Experimental Assessment»,
«] ournal of Behavioural Decision Making, 13( 1): рр. 91  106.
U niversity of Southern California, Cocolno 11 Model Dcfinition Manllal, ver
sion 1.4, undated (circa 1997).
Valett, J., and F.E. McGarry, 1989. A Summary of Soft\vare Measurement Ex
periences in the Software Engineering Laboratory, «Journal of Systems and Softwal'c,
9(2), рр. 137  148.
Уап Genuchten, Michael, 1991. W11Y Is Software Late? Ап Empirical Study of
Reasons for Delay in Software Development, IEEE Transactions оп Software Engi
neering SE17, по. 6 (June), рр. 582590.
Уи, John, 2004. Lessons Learned in PI'ocess Improve111ent», SEPG 2004.
Walston, С.Е., and С.Р. Felix, 1977. A Method of Progl'amming MeasureInent
and Estimation, IBM Systems Journal», v. 16, по. 1, 1977, рр. 54 73.
Ward, William Т., 1989Ь. «Soft\\'al'e Defect Pl'evention Usiпg McCabe's CompIexity
Metric, Hewlett Packard Journal, April 1989, рр. 6468.
Weinberg, Gerald М., and Edward L. Schulman, 1974. Goals and Performancc in
Computer Programming, vol. 16, по. 1, рр. 7077.
Weinberg, Gerald М., 1994. «Quality Software Managemel1t, Vol. 3, Congruent
Action, New York, NY: Dorset House.
Weyuker, ElaineJ., 1988. Evaluating Complexity Measllres, IEEE TI'ansactions
оп Software Engineering, v. 14, по. 9, September 1988, рр. 13571365.
Wheeler, David А., 2001. More than а Gigabuck: Estirnating GNU/Linux's Size»,
http://www.dwheeler.com/sloc.
Wiegers, Karl, 2000. «Stop Promising Miracles, Software Developn1ent, Feb
ruary 2000.
Wiegers, Karl, 2003. «Software Requirements: Thorny Issues and Practical Advice»,
Redmond, W А: Мiсrоsоft Press.
Withers, Bud, 1999. Take Ме Out to Ballpark, «Seattle Times», July 11, 1999,
рр. S3S4.
Zultner, Richard Е., 1999. Project Estilnation \\,ith Critical Chain: ThirdGeneration
Risk Management, «AI?el'ican Programlner, July 1999, рр. 412.

Алфавитный указатель
А
Angel (Analogy Software Tool), 169
А
с
Chaos Report (Standish Group), 42
Сосото 11, модель, 64,79, 169
Construx Estimate, проrpамма, 76, 169
Costar, проrpамма, 169
абстрактные рейтинrи, 149
административная поддержка, 249
аналоrия, метод оценки, 137
арбитРаж, 166
Б
к
Knowledge PLAN, проерамма, 169
базовая формула для вычисления
срока, 224
бизнеслоrика, 141
больших чисел, закон, 124, 145
буферы, 248
бюджет, точность, 46
бюджетное планирование сроков, 263
Е
Estimate Express, проrpамма, 169
р
PERT, метод, 118
PriceS, проrpамма, 169
в
R
RUP, процесс, 92
величина относительной ошибки, 119
внешние входные элементы, 203
внешние выходные элементы, 203
внешние запросы, 203
внешние интерфейсные файлы, 204
внешние политические оrpаничения, 263
внутренние версии, 31
внутренние лоrические файлы, 203
восходящие оценки, 122
вычислительные методы, 98
s
Scrum, стиль разработки, 92
SEER, проrpамма, 169
SLIMEstimate, проrpамма, 169
r
w
WBS, 126
rолландский метод, 207
rpупповое обсуждение оценок, 156

д
данные
исторические, 97, 102
калибровка, 96, 102
проектные, 102
среднеотраслевые, 102
счетные методы, 97
декомпозиция, 122
Дельфийский метод, 158
дефекты, 106
диапазоны, 116
документирование процедуры оцснки, 186
достоверность, 27
3
закон больших чисел, 124, 145
закон Паркинсона, 40
зона невозможности, 230
и
идеальный объем работы, 242
издержки масштаба, 73, 86
импровизированные оценки, 49
интерпретируемые языки, 81
исторические данные, 102
итеративная разработка, 57, 91
к
календарные сроки
оценка, 224
предсказусмость, 47
калибровка, 102, 109
исторические данныс, 109
оценочные проrраммы, 164
качество проrpамм, 46
квалификаторы, ПЛIОС/МИНУС, 254
квантификация рисков, 254
компилируемые языки, 81
контроль качества, 237
контрольные списки задач, 119
конус неопределенности, 52
л
лучший сл уч ай , С ц сна рии U , 27 54 116
, ,
м
масштаб, издержки, 86
метод оценки первоrо порядка, 227
Алфавитный указатель 295
мстоды оценки, 90
альтсрнативные, 170
выбор, 90
метод футболки, 152
опосредоваНllЫС, 143
по аналоrllИ, 137
счетныс, 96
модели оцснки, 79
MOHTe Карло, моделирование, 164
н
наиболес всроятныЙ случаЙ, оцснка, 118
недооценка, 40
незнакомая среда, 250
lIеобосноваНIIЫЙ ОI1ТIIМIIЗ1\1, 63, 128
IIсопределенность, выраженис, 254
непредвиденные события, 31
нечеткая лоеика, 144, 208
о
обсуждение оценок,' 156, 178, 181
объективныс критерии, 270
объем работы
вычисление, 213
и сроки, 231
опенка, 211
проrраммы, 164
сбор данных, 107
объем раБОТ!>I, идеальный, 242
обязательства, 23, 142, 182, 270
опосредованныс методы, 143
оптимизм, необосноваllНЫЙ, 63, 128
отладка, 245
относитсльная ошибка, 119
оценка стоимости, 243
оценки
определение, 22
пересмотр, 183
планы, 23
ХОрОШIIС, 28
оценочные I1porpaMMbI, 163
калибровка, 168
список, 168
ошибка оцснки, 51
импровизация, 66
конус неопрсделенности, 52
необосноваНIIЫЙ оптимизм, 63
политика, 261
пропущенныс операции, 61

296 Алфавитный указатель
n
Паркинсона, заl(ОН, 40
IIcperoBopbI, 263
персоценка, 40
планирование проектов
оценка, 23
параметры, 236
планы, 142
I10ЛСЗIlОСТЬ оценки, 32
I1ЛIОС/МИIlУС, }(BaJJJ HP 11 каторы, 254
IIОСJIсдовательная разработка, 91
поэтапная выдача, 92
IIредсказуемость, 47
ПРlIнципиальные переrоворы, 266
lIрОIIУIценные онсрации, 61
процесс поэтапноrо контроля, 186
llРОЦССС разработки
контрольныс ТОЧI(И, 187
стадин, 92
lIРЯ!\1ые затраты, 244
р
размер проекта, 43, 71
распределсние объема работ, 238
РСlУЛIlРУlОlцие факторы, ocoтo 11, 81
рСЗСрВIIЫI't буфер, 248
РИСl(И, КllаНТllфикация, 254
рост требований, 59
с
сверхурочные, КОМIlснсация, 243
сводныс оцснки лучшсrоjхудшеrо
случая, 133
соБЫТIIЯ, непредвидснные, 31
сокраlltенис сроков, 228
срсднсотраслевые rрафики объема, 215
стандартизированная процсдура, пример, 192
стиль разработки, 91
СТОIIМОСТЬ
оценка, 243
строки IIporpaMMHoro кода, 71
структурированные экспертные оценки, 115
студенческий синдром, 40
субъективность, 64
схождение оценок, 170
счстные методы, 96
функциональные ПУIlI(ТЫ, 203
т
точечные оценки, 25, 116
точность оценок
выражсние неопределеНIIОСТИ, 254
историческис данные, 103
преимущества, 45
чсткость, 68
у
управлсние проектом, 30
устранение десректов, 244
уточненис оцснок, 179
ф
ФибонаЧЧll, послсдовательность, 151
формированис оценки, 175
функционалы IОСТЬ
дефекты, 244
классификация, 145
Фун}(ционалЫlые ПУIIКТЫ, 203
х
хаотичсские процессы разработки, 58
ХОрОlllая оценка, определение, 28
худший случай, сценарий, 27, 116
ц
цели, 22
ч
четкость, 68
чтоесли, анализ, 166
ш
ширина диапазона оцеН}<lI, 37
широкополосный Дельфийский
метод, 158
э
ЭВОЛIОЦИОНlIое макстирование, 91
экспертные суждения, 100, 114
экстремальнос проrpаммирование, 92
эффективность устранения дефектов, 245

Стив Макконнелл
Сколько стоит проrраммный проект
Заведующий редакцией
Ведущий редактор
Научный редактор
Технический редактор
Литературный редактор
Художник
Корректор
Верстка
А. Кривцов
А. Пасечник
Е. Матвеев
С. Романов
А. Пасечник
Л. Адуевская
В. Листова
Р. rриluанов
Совместный проекr издательства «Русская Редакция»
и издательства «Питер»
.  у с с к А Я   д А К  И Я
ппТЕРФ
Подписано в печать 17.01.07. Формат 70х100/16. Уел. п. л. 24,51. Тираж 2000. Заказ 893
000 «Питер Пресс», 198206, СанктПетербурr, Петерrофское шоссе, д. 73, лит. А29.
Налоrовая льrота  общероссийский классификатор продукции ОК 00593, том 2; 95 3005  литература учебная.
Ornечатано с rOТOBblX диапозитивов в ОАО «Техническая книra».
190005, СанктПетербурr, Измзйловский пр., д. 29.

... .....;rg".:::;..
. ,'.I:'t"\ . . ..
. 'j!\\Ф ........  \
,. ..\;:;:::;.:;'7}
.... -:. ;::: в .
.....':'.
.-,
. ..
;:'-c ,,:
. '\ .", .,. 
,. ' .
. ..,..... :. ',:
. -:", ",
с
1: -'
1Ila.
. '" ., .
:.....- ...-....'"МI.=.' .:......
. к'" ," ','.:_" ,.,:.- .':. :, :, ..-:--:-:' '.::. .:'
.ю. . ,..;  .., RК,Л., _ ,'"
. , .
..4.:...::::t 
..':'.:::-,:";"
:. .,\.
,;:i.ir: ::  >: '».
..:...... . J' - .
:. - . .. .. х _ ......
...1/:. . .:.....:.
. ASP., .0
. ,. .. .. . . .... );:
.. 1«'..111...., _ 
,
.::' .:.:::,.
." ".....
. .
npOrpaMMpoвa..e
с- МСn&lJNRIН '.0:' _' :.
Windows .fcJrms
.  .:....,
.,,' I :tН'ШI ....... 
'"
c._
.: t-"':
".сОС ,
C ,-
 ..
СО :1 . WЕННЫЙ КОД
.. ( . . , .
" .: . . ." I no . ., .
 . t'" J:
. ,.1:. __
rYllcB.9: ...:S.-, ".', .Л .,.пrQфЕ_И,ОНf\'nОВ
. , ".-; , .- ;..;. ..",. - . ,.',....,...;
,.И',.Н/1.i"" ,:_':::_:' ::.':::.,." ',.,:' ,
азначенные:IP'. пporраммисrов
: В, t;истемнЪJX аДННИС7раТОРОВi созданы rypy
: «\.',a: ,,:ф:рмн)(];е0l!9:Н ,р.f!.ва_,*bI::-:
"',rHJ:Ь:Ha вопро(:ы _ реДI('О8ещемые_.
)1 соврннIi'l(омitьют.ерн лратуре>
, -
:.' (Co.SMqiHMIi;.i;iPoe& эмiеЛа: 9Мя. f.iвдщ.i-."
. ....... '".. ..... ...... '"' '" '" '" ",:'Й':дilr.ЩJщfВ(i::qеiP)'
..'t.
:\:1__'" . "1 ...
'\,:. II\"*'.
&'I;\\"'» ::
Джеффрн Рихтер
CLR via С#. Проrраммирование на платформе' Мiсrоsоft
.NEТ Framework 2.0 на языке С#. Мастер-класс. 656 стр.., 2007 r..
Эта книrа  подробное описание BHyrpeHHero устройства и функционировани
общеязыковой исполняющей среды (CLR) Microsoft ..NET Fraтework версии 2.0..
В ней раскрыта система типов .NEТ Framework и разъяснены способы управления
ИИ.. Представлены концепции проrраммирования с широким использованием
библиотеки FCL. относящиеся ко всем языкам. ориентированным на работу с NEТ
Framework. Ообое внимание уделено обобщениям. управлению асинхронными
операциями и синхронизации потоков Книrа ориентирована на разработчиков
любых видов приложений на платформе с .NEТ Framework.
Дина 3спознто
Мiсrоsоft ASP.NEТ 2.0. Уrлубленное изучение.
Мастер-класс. 592 СТР.1 2006 r.
Эта книrа...... подробное руководство для профессионалов.разработчиков
приложений ASRNEТ. В ней раскрыты тонкости BHyrpeHHero фуннционирования
исполняющей среды ASRNEТ 2.0 и возможности ее конфиryрирования. детально
описан ПJ?оцесс выполнения,nрил,?жений  cpe.цCTBa ПОЗВОЛЯЮЩИЕ;! сдел.аrъ 
надежными. эффективными и хорошо защищенными. Вы узнаете. как создавать
пользовательские элементы управления освоите новые навиrационные средства
ASRNET 2.0 и научитесь формировать оптимальное представление данных
с помощью новых элементов управления.
Чарльз Летцольд
Проrраммирование с использованием Мiсrоsоft
Windows Forms. Мастер-класс. 4З2'стр., 2006 r.
В этой книrе подробно рассказывается о создании nporpaMM для Мiсrоsoft Windows
с использованием языка С# и библиотеки классов Windows Forms. входящей в Micro"
soft .NEТ Framework 2.0. Вы научитесь создавать новые HeCTaHдaPTHЫ и комбиниро..
вать существующие элементы управления. а также разрабатывать панели инструмен
Т08. меню и строки состояния, используя ПОЯВИ8шиеся в .NEТ Framework 2.0. новые
элементы управления. узнаете о новом механизме динамическоrо размещения
элементов управления на форме и о при вязке элементов управления к данным.
Стив Макконнелл
Совершенный код. Мастер-класс. 896 стр.., 2005 r.
Каков бы НИ был ваш профессиональный уровень. с какими бы средствами
разработки вы ни работали. какова бы ни была сложность вашеrо проекта
в этой книrе вы найдете нужную информацию, она заставит вас размышлять
и поможет создать совершенный код.
Это исчерпывающее исследование тактических аспектов создания хорошо
спроектированных nporpaMM. Книrа Макконнелла OXBTЫBaeT такие разные темы
как архитектура. стандарты кодирования. тестирование. нтеrрация и суть
разработки по- (rради Буч автор книrи .ObJect Solutions.).
1II РУССКАЯ РАКИЯ
www.rusedit com
f:>/ ппTEp<t
www mlcrosoftcom
www.piter.com

r
I
,
:. .  ...
....-:::
.'.., .:
"" t::;.: .
. .;.:.."..
. ':jo}. .: О.' ,." .
'1:. _ ..:
": 
.:0... .,., ".
,l' '.. .. .....:f :
. "..-::;: .'
.: '.: :.:'{.:': :.. : ,..," .... ;
, ::-.( :.:..' .' :: '.'
:..", :....-. . .... . rl' .
::0.......,;.-.. ,'..
..........:
 : ,. .
. ....,;..: .
. .=--... ". .
. ." r ,:,
"'::":' ".
:.-:..'
,'.
, '.'" <..
- -:; ".0(
.. :'.,.
: ,
.... ,.
..' % ,::. :-: '. " .... :";;,' ".::..
.' .... ..:.:: '.:;"1':'
:. ........: . : . .
.". .:': -::. .. . : ':..: .: .3'". '..
. ::., :.. "".... . ..
. . <'.: ....... . .
>.'
:=--=:-
. ..Mec ..
".".. . -.. .. ....., .
. . .
.
"
."..:,." .
.O(.r:. .
.:.- ....
,.,:.
".' ',:'';'''' . ". .;.......';....w..
..:
:.;( -..;.о,.,
.
.
". :...
. .
. .
0"0-",..." ..
y.r"/).1' . . . . .
. . .
.... - ".".::.".., о'. .....
.. --/
'".." .
:( :"
о ." ": "''x .;..  ....
: ....".." : 0"0 ...: . .". _ : t:.. . _: ...-.;:_ t -" .....
.: ./..:..' '. ....{ .'

. . -. - :
..--=-/,
, .
.....
.
.
,
:..,z'.
." ": ::.";.::'"...: 
..,
. J'-.. .
-. .. .
. J'A.O. . - .'.,-
. J".:- ".0
'f0-
-.: ..0 :.
. ,.".. .'. ,.'
. . f" :".;.". .
.. . . .:. .:.
'ее
,." (II!
" 1!'
r ..' . . .J ' . ': . ' . !: l . . . . . >-...... . r
:-=': : .: r .: :.  .. J.. ::J:"99f
: . -
,..... .: ......ry
:.." ".. .-:;"
.
-''-v' '.  Ж..' ':Уб ::.,
O,. - eV:>
.  :. : ....... ':;.;.;..::: : .;: .:.. ::-. >.-: :. ..:I.:.'.". '.. .::.. -.: .:" '...::..: $ /.s :.. .:.".. "-.. ;...
'Р.. '. !xe'o' ..... 0: 'НЯ'е.JtШi["Л1@:' ,<'e' . ,.. ..
>ПРЩК'::>: : :'. ,:: х; е, :-'f
_:.::'-
.
. . .
". ": ::;:':=-' ..;.... ,":., . .." ."
. .
.. JI"-:."
:.. ...
 '-: ......
..,;. 
/
... {' ........;...v ft
" .' :Jь.uЙ  t (о :П SO :. . ru
. . .:-:. ..:-:. :." ..1'.«. ." .z' . . -
.. (
. .. .
.;-:
.' /'\.

; J
"'..; 7 ...:
:.
:\'
:"':.
."'.....
.. -  ..... ". ..
." . . ".' .'"11
_. .
.' ......w..;.:
...e :iTh;оо@JJiJИДР9: седироссийс,
о.. -..:: :..-.." :):"".< ..)-. <.:... '..., ,
'. (}1] [Щ)[1lе.ДИ.Ч;СJ<И.. .ИД8:НИ..,
 . . .......:'... : . . .
. ..
..

КЛУБ
.'::i@Й\::j1::
.-...... ..........
....:...... . :,.;.:.',
.... ....
. . . . . . .
Основанный Издательским домом «Питер» В 1997 rоду, книжный клуб «Профессионал» собирает
в своих рядах знатоков cBoero дела, которых объединяет тяra к знаниям и любовь к книrам. Для
членов клуба проводятся различные мероприятия и, разумеется, предусмотрены привилеrии.
Привилеrии дпя членов клуба:
· карта члена «Клуба Профессионал»;
· бесплатное получение клубноrо издания  журнала «Клуб Профессионал»;
· дисконтная скидка на всю приобретаемую литературу в размере 10% или 15%;
· бесплатная курьерская доставка заказов по Москве и СанктПетербурry;
· участие во всех акциях Издательскоrо дома «Питер» В розничной сети на льrотных условиях.
Как ВС1УПить в клуб?
Для вступления в «Клуб Профессионал» вам необходимо:'
· совершить покynку на сайте www.piter.com или в фирменном маraзине Издательскоrо дома
«Питер» на сумму от 800 рублей без учета почтовых расходов или стоимости курьерской до-
ставки;
· ознакомиться с условиями получения карты и сохранения скидок;
· выразить свое соrласие вступить в дисконтный клуб, отправив письмо на адрес:
postbook@piter.com ;
· заполнить анкету члена клуба (зареrистрированным на нашем сайте этоrо делать не надо).
Правила дпя членов «Клуба Профессионал»:
· для продления членства в клубе и получения скидки 1 0%, в течение каждых шести месяцев
нужно совершать покупки на общую сумму от 800 Ю 1500 рублей, без учета почтовых расходов
или стоимости курьерской доставки;
· Если же за указанный период вы выкупите товара на сумму от 1501 рублей, скидка будет увели
чена до 15% от розничной цены издательства.
Заказать наши книrи вы можете любым удобным для вас способом:
· по телефону: (812) 703-73-74;
· по электронной почте: postbook@piter.com;
· на нашем сайте: 'NWW.piter.com;
· по почте: 197198, Санкт-Петербурr, ajя 619 ЗДО «Питер Пост».
При оформлении заказа укажите:
· ваш реrистрационный номер (если вы являетесь членом клуба), фамилию, имя, отчество, теле
фон, факс. e-mail;
· почтовый индекс. реrион. район, населенный пункт, улицу. дом, корпус. квартиру;
· название книrи. автора, количество заказываемых экземпляров.
пЗDATnbcKпlt DOM
!!rf!@

,.
r
ппTEP@J
Нет времени
ХОДИТЬ ПО маrазинам?
' ';':. ''''
наберите:
www.piter.com
Здесь вы найдете:
Все книrи издательства сразу
Новые книrи ........... в момент выхода из типоrрафии
И нформаци ю о кн И re .......... отзы вы, рецензи и, отры вки
Старые книrи ........... в библиотеке и на СО
. ,...
и наконец, вы ниrде не купите
наши книrи дешевле!

....
книrА-ПОЧТОИ
ЗАКАЗАТЬ книrи ИЗДАТЕЛьскоrо ДОМА ссПИТЕР»
МОЖНО люБы
M удоБны
M ДЛЯ ВАС СПОСОБОМ:
· по телефону: (812) 703-73-74;
· по электронному адресу: postbook@piter.com;
· на нашем сервере: www.piter.com;
· по пете: 197198, Санкт-Петербурr, а/я 619,
ЗАЙ «Питер Пост».
Bbl МОЖErЕ вы
рАтьb ОДИН ИЗ ДВУХ СПОСОБОВ ДОСТАВКИ
И оплАты
 ИЗДАНИЙ:
,..........,.
 Наложенным платежом с оплатой заказа при получении посылки на
ближайшем почтовом отделении. Цены на издания приведены ориентиро-
вочно и включают в себя стоимость пересылки по пете (но без учета
авиатарифа). Книrи будyr высланы нашей службой ссКниrа-почтой»
в течение /Jf3yx недель после получения заказа или выхода книrи из печати.
,..........,.
 Оплата наличными при курьерской доставке (для жителей Москвы
и Санкт-Петербурrа). Курьер доставит заказ по указанному адресу
в удобное для вас время в течение трех дней.
ПРИ ОФОРМЛЕНИИ ЗАКАЗА УКАЖИТЕ:
· фамилию, имя, o1'-lecтвo, телефон, факс, e-mail;
u u u
· почтовыи индекс, реrион, раион, населенныи пункт,
улицу, дом, корпус, квартиру;
· название книrи, автора, код, количество заказываемых
экземпляров.
Вы можете заказать бесплатный
журнал «Клуб Профессионап»
пЗQArпbCKпп QOM
РйппТЕР@
 WWW.PITER.COM

!f
п3йАТЕпьскпЬ .аом
f)йппТЕР@
 WWW.PITER.COM
СПЕЦИАЛИСТАМ
книжноrо БИЗНЕСА!
ПРЕДСТАВИТЕЛЬСТВА ИЗДАТЕЛьскоrо ДОМА ссПИТЕР»
преДl1аrают эксклюзивный ассортимент компьютерной, медицинской,
психолоrической, экономической и популярной литературы
РОССИЯ
Москва М. «Павелецкая», 1 й Кожевнический переулок, д.1 о; тел.jфакс (495) 2З438 15,
2557067, 2557068; email: sales@piter.msk.ru
Санкт-Петербурr М. «Выборrская», Б. Сампсониевский пр., д. 29а;
тел./факс (812) 7037373, 7037372; email: sales@piter.com
Воронеж Ленинский пр., д. 169; тел.jфакс (4732) 394З62, 3961 70;
email: pitervrn@comch.ru
Екатеринбурr УЛ. 8 Марта, д. 2676, офис 202;
тел./факс (343) 256З437, 256З428; email: piterural@isnet.ru
,
Нижний HOBrOpOA УЛ. Совхозная, д. 13; тел. (8312) 412731;
email: office@nnov.piter.com
Новосибирск ул. НемировичаДанченко, д. 104, офис 502;
тел./факс (383) 211 93 18, 211 27  18, 3142389; email: office@nsk.piter.com
Ростов-на-Дону УЛ. Ульяновская, д. 26; тел. (8632) 6991 22, 6991 зо;
email: piterug@rostov.piter.com
Самара УЛ. Молодоrвaрдейская, д. 33, литер А2, офис 225; тел. (846) 277 89 79;
email: pitvolga@samtel.ru
УКРАИНА
Харьков ул. Суздальские ряды, д. 12, офис 1 o 11; тел./факс (1 038067) 5455564,
(1038057) 751  1 002; email: piter@kharkov.piter.com
Киев пр. Московский, д. 6, кор. 1, офис 33; тел./факс (1038044) 4903568, 490-3569;
email: office@kiev.piter.com
БЕЛАРУСЬ
Минск УЛ. Притыцкоrо, д. 34, офис 2; тел./факс (1037517) 201 48-79, 201 4881 ;
еmаil: office@minsk.piter.com
 Ищем зарубежных партнеров или посредников, имеющих выход на зарубежный рынок.
 Телефон ДЛЯ связи: (812) 703-73-73.
E-mail: grigorjan@piter.com
 Издательский дом ссПитер» приrлашает к сотрудничеству авторов.
 06ращайтесь по телефонам: Санкт-Петербурr  (812) 703-73-72,
Москва.... (495) 974-34-50.
 Заказ книr для вузов и библиотек: (812) 70373-73.
 Специальное предложение  email: kozin@piter.com

пЗDATEпbCKпп DOM
РАпптс-р@
  WWW.P/TER.COM
УВАЖАЕМЫЕ rоспоДА!
книrи И3ДАТЕЛьскоrо ДОМА ссПИТЕР»
ВЫ МОЖЕТЕ ПРИО&РЕСТИ
ОПТОМ И В РОЗНИЦУ
У НАШИХ РЕrиоНАЛЬНЫх ПАРТНЕРОВ.
Башкортостан
Уфа, «Азия», ул. rorоля, д. 36, офис 5,
тел./факс (3472) 5O39OO, 51 8544.
Email: asiaufa@ufanet.ru
Красноярск, «Книжный мир»,
тел/факс (3912) 27-3971.
Email: book world@pubIic. krasnet. ru
Дальний Восток
Владивосток, «Приморекий торrовый дом книrи»,
тел/факс (4232) 2382 12.
Е-таil: bookbase@mail.primorye.ru
Нижневартовск, «Дом книrи»,
тел. (3466) 2327 14, факс 235950.
Email: book@nvartovsk.wsnet.ru
Хабаровск, «Мире»,
тел. (4212) 305447, факс 22 7330.
E-mail: salebook@bookmirs.khv.ru
Новосибирск, «Т ОПкниra»,
· тел. (3832) 36 1 0-26, факс 36 1 027.
Email: office@top-kniga.ru
htt.p:/ /www.topkniga.ru
Хабаровск, «Книжный мир»,
тел. (4212) 3285-51, факс 328250.
Emajl: postmaster@worldbooks.kht.ru
'Тюмень, «Дpyr» ,
тел./факс (3452) 21 34-82.
Email: drug@tyumen.ru
Европейские реrионы России
Арханrельск, «Дом книrи»,
тел. (8182) 65-41 34" факс 6541 34.
Email: book@atnet.ru
Тюмень, «Фолиант»,
тел. (3452) 27 36-06, факе 27 36 11.
Е- mail: foliant@tyumen.ru
Калининrpaд, «Вестер» ,
тел./факс (0112) 21 5628, 21 62-07.
E-mail: nshibkova@vester.ru
http://www.vester.ru
Татарстан
Казань, «Таис»,
тел. (8432) 72-3455, факс 72-27-82.
Email: tais@bancorp.ru
Северный Кавказ
Ессентуки, «Pocr,ы», ул. Октябрьская, 424,
тел/факс (87934) 9309.
. Е-таil: rOSSY@kmw.ru
Сибирь
Иркутск, «ПродаЛитЪ»,
тел. (3952) 59-13 70, факс 51 зо 70.
Eтail: prodalit@irk.ru
http://www.prodalit.irk.ru
Урал
Екатеринбурr, мaraэин  14,
ул. Челюскинцев, Д. 23,
тел./факс (3432) 53-24-90.
Email: gvardia@mail.ur.ru
Екатеринбурr, «Валео-книra»,
ул. Ключевская, д. 5,
тел./факс (3432) 42-56OO.
Email: valeo@etel.ru
Иркутск, «АнтеЙ-книra»,
тел./факс (3952) ЗЗ42-47.
Email: antey@irk.ru
Челябинск, ТД «Эврика», ул. Барбюса, д. 61,
тел./факс (3512) 524923.
E mail :evrika@chel.surnet.ru