Введение [13]
Благодарности [17]
Об авторе [19]
От издательства [20]
Часть I. Основные принципы оценки [21]
Глава 2. Какой из вас оценщик? [34]
Глава 3. О точности оценки [39]
Глава 4. Откуда берутся ошибки оценки? [50]
Глава 5. Факторы, влияющие на оценку [71]
Часть II. Базовые методы оценки [89]
Глава 7. Подсчет, вычисление, экспертная оценка [95]
Глава 8. Калибровка и исторические данные [102]
Глава 9. Индивидуальные экспертные оценки [114]
Глава 10. Декомпозиция и сводные оценки [122]
Глава И. Оценка по аналогии [136]
Глава 12. Опосредованные оценки [143]
Глава 13. Экспертные оценки в группах [156]
Глава 14. Оценочные программы [163]
Глава 15. Использование альтернативных оценок [170]
Глава 16. Формирование оценок в правильно оцениваемых проектах [175]
Глава 17. Стандартизированные процедуры оценки [185]
Часть III. Конкретные проблемы оценки [199]
Глава 19. Специфические проблемы при оценке объема работ [211]
Глава 20. Специфические проблемы при оценке сроков [224]
Глава 21. Оценка параметров планирования [236]
Глава 22. Стили представления оценок [254]
Глава 23. Политика, переговоры и решение проблем [263]
Приложение А. Проверка разумности оценки [274]
Приложение Б. Ответы на вопросы теста из главы 2 [276]
Приложение В. Рекомендации по оценке программных проектов [277]
Библиография [288]
Алфавитный указатель [296]
Text
                    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О сроков и объемов рабо