Специфические проблемы при оценке сроков

Специфические проблемы при оценке сроков

Область применения методов этой главы
Базовая формула для вычисления срока
Неформальное сравнение с прошлыми проектами
Метод оценки первого порядка
Оценочные.
программы
Что оценивается
Срок
Срок
Срок
Срок
Размер проекта
-СБ
М С Б
-СБ
-СБ
Стадия разработки
Ранняя
Ранняя
Ранняя
Ранняя
Итеративный или.
последовательный.
стиль
Последовательный
Оба
Последовательный
Оба
Возможная точность
Средняя
Средняя
Низкая
Высокая
Немалая часть давления на проект возникает из-за предельных сроков, обусловленных обязательствами перед клиентами, проведением выставок, сезонными продажами, нормативам и другими календарными датами. Вероятно, именно сроки вызывают самые жаркие споры при обсуждении оценок.
Как ни парадоксально, при переходе от интуитивных оценок к методам, базирующимся на исторических данных, оценка срока превращается в элементарное вычисление по оценкам размера и объема работ.
20.1. Базовая формула для вычисления срока.
Приближенная оценка срока на ранней стадии проекта может производиться по базовой формуле:.
ФОРМУЛА № 17 -.
СрокВМесяцах = 3,0 х ЧеловекоМесяцы
Если вы подзабыли математику, на всякий случай напомню, что показатель степени 1 /3 означает кубический корень.
Иногда 3,0 заменяется на 2,0, 2,5, 3,5, 4,0 или другое число, но основная идея, по которой срок вычисляется как кубический корень из объема работ, признается почти всеми экспертами в области оценки (конкретный множитель может быть получен посредством калибровки по историческим данным организации). Барри Бем заметил в 1981 году, что эта формула стала одним из самых растиражированных результатов в программотехнике (Boehm 1981). Анализ, проводившийся на протяжении нескольких прошедших десятилетий, подтвердил состоятельность формулы (Boehm 2000, Stutzke 2005).
Допустим, на построение проекта вам потребуется 80 человеко-месяцев. Вычисленные по формуле сроки лежат в диапазоне от 8,6 до 17,2 месяца, в зависимости от выбора коэффициента в диапазоне от 2,0 до 4,0. Номинальный срок будет равен (3,0 х 80
), то есть 12,9 месяца. (Я не рекомендую представлять оценку срока с такой четкостью и привожу ее лишь для того, чтобы вам было проще следить за вычислениями.).
СОВЕТ №89 -;-.
Используйте базовую формулу для ранней оценки срока в средних и крупных проектах.
Формула вычисления срока имеет интересные последствия для конуса неопределенности, как показывают числа у правой оси на рис. 20.1.
Рис. 20.1. Конус неопределенности с поправками сроков на правой оси. Неопределенность сроков гораздо меньше неопределенности объема, потому что срок вычисляется как кубический корень из объема работ
Время
Формула срока является одной из причин, из-за которых диапазоны неопределенности для объема работ на рис. 20.1 гораздо шире, чем для сроков. Объем работ возрастает пропорционально объему проекта, тогда как срок возрастает пропорционально кубическому корню из объема работ.
Формула срока неявно подразумевает, что размер группы может регулироваться до размера, следующего из уравнения. При фиксированном размере группы срок не будет меняться пропорционально кубическому корню объема; он будет меняться более значительно в зависимости от ограничений размера группы. Эта проблема более подробно рассматривается в разделе 20.7.
Базовая формула для вычисления срока не предназначена для малых проектов или на поздних фазах больших проектов. Когда становятся известными имена конкретных людей, работающих над проектом, переключайтесь на другой метод.
20.2. Вычисление срока посредством неформальных сравнений с прошлыми проектами.
Уильям Ротцхейм (William Roetzheim) предложил оценивать сроки новых проектов по соотношению сроков и объемов работ в .прошлых проектах (Roetzheim 1988, Stutzke 2005). Возьмем те же проекты, которые были использованы в главе 19; для удобства их данные повторены в табл. 20.1.
Таблица 20.1. Пример данных о производительности прошлых проектов, заложенных в основу для оценки сроков
Проект
Размер.
(LOC)
Срок.
(календарные.
месяцы)
Объем работ.
(человеко-.
месяцы)
Производительность (LOC/ человеко-месяц)
Комментарии
Проект А
33 842
8,2 ■
21
1612
Проект В
97 614
12/5
9
986
Проект С
7444
4,7
2
3722
Не используется — слишком мал для сравнения
Проект D
54 322
11,3
40
1358
Проект Е
340 343
24,0
533
639
Не используется — слишком велик для сравнения
Ротцхейм предлагает оценивать срок в месяцах по формуле неформального сравнения с прошлыми проектами:.
ФОРМУЛА № 18 -.
ОценкаСрока = ПрошлыйСрок х (ОценкаОбъемаРабот/ПрошлыйОбъемРабот)
Показатель степени 1/3 используется в тех проектах, которые в книге отнесены к категории средних и крупных (более 50 человеко-месяцев). Для более мелких проектов следует использовать показатель степени 1/2.
В главе 19 объем работ оценивался от 65 до 100 человеко-месяцев при наиболее вероятной оценке в 80 человеко-месяцев. Таким образом, мы получаем оцениваемые сроки из прошлых проектов, приведенные в табл. 20.2.
Проект
Исторические данные
Оценки
Прошлый срок (календарные месяцы)
Прошлый объем работ (человекомесяцы)
Низкая оценка (65 человекомесяцев)
Номинальная оценка (80 человекомесяцев)
Высокая оценка(100 человекомесяцев)
Проект А
8/2
21
12,0
12,8
13,8
Проект В
12/5
99
10,8
11,6
12/5
Проект D
11,3
40
13,2
14/2
15,3
По методике Ротцхейма диапазон «лучший-худший случай» составляет 10,8— 17,3 месяца. Я бы оценил ожидаемый случай простым усреднением трех номинальных оценок из таблицы, после чего вычислил верхнюю и нижнюю границы диапазона усреднением верхних и нижних оценок из таблицы. Вычисления дают номинальный срок в 12,9 месяца с диапазоном 12,0-13,9 месяца.
СОВЕТ № 90 -
-.
Используйте формулу нефррмального сравнения с прошлыми проектами для ранней оценки срока в проектах любого размера.
20.3. Метод оценки первого порядка.
Если известен размер проекта в функциональных пунктах, грубую оценку срока можно вычислить прямо по нему. Для этой цели используется метод, который Кейперс Джонс назвал «методом оценки первого порядка» (Jones 1996). Возьмите суммарный размер в функциональных пунктах и возведите его в нужную степень, выбранную из табл. 20.3. Средние показатели степени в таблице получены на основе анализа нескольких тысяч проектов, проведенного Джонсом. Я добавил приблизительные оценки лучшего и худшего случаев, чтобы отразить расхождения в производительности.
Таблица 20.3. Показатели степени для вычисления сроков по функциональным пунктам
Тип программы
Лучший
Средний
Худший
Объектно-ориентированная программа
0,33
0,36
0,39
Клиент-серверная программа
0,34
0,37
0,40
Бизнес-системы, интрасетевые системы
0,36
0,39
0,42
Коммерческие пакеты, научные и инженерные системы, публичные интернет-системы
0,37
0,40
0,43
Встроенные системы, телекоммуникации, драйверы устройств, системные программы
0,38
0,41
0,44
Источник: Адаптировано по материалам «Determining Sotware Schedules» (Jones 1995c) и «Estimating Software Costs» (Jones 1996).
Если общее количество функциональных пунктов проекта равно 1450, а ваша организация занимается разработкой бизнес-систем со средней производительностью,
Рис. 19.5. Средние объемы работ для научных систем и инженерных исследовательских проектов
Строки кода
возведение 1450 в степень 0,39 (1450
) дает грубую оценку в 17 календарных месяцев. Если же ваша организация занимается разработкой бизнес-систем и является лучшей в своем классе, то 1,450 возводится в степень 0,36, что дает срок в 14 месяцев. Если же вы разрабатываете объектно-ориентированные бизнес-системы, показатели степени для объектно-ориентированного программного обеспечения дают диапазон от И до 17 месяцев. Таким образом, можно сделать вывод, что реальный срок лежит где-то в диапазоне от 11 до 17 месяцев.
Эта методика не заменит более тщательной оценки срока, но она предоставляет простое средство получения грубой оценки, которое все же лучше простых догадок. Кроме того, она позволяет быстро проверить задачи на реалистичность. Если вы хотите разработать бизнес-систему в 1450 пунктов за 9 месяцев, подумайте заново. Для самых передовых организаций срок составит от 11 до 14 месяцев, а большинство организаций к передовым не относятся. Метод оценки первого порядка поможет вам побыстрее узнать, не нужно ли внести изменения в ваши предположения о функциональности и/или сроках.
СОВЕТ №91 -:-.
Используйте метод оценки первого порядка для получения неточной (но требующей крайне малых усилий) оценки срока на ранней стадии проекта.
20.4.
Вычисление оценки срока научными методами.
В конечном итоге неформальные методы плохо подходят для получения точной оценки. Сроки слишкомсильно изменяются в зависимости от множества факторов. Самый простой и точный способ вычисления оценки основан на использовании таких вспомогательных инструментов, как Construx Estimate
Что произойдет, если мы используем Construx Estimate для вычисления оценки срока в рассматриваемом примере? При калибровке историческими данными объемов работы и сроков, представленными в главе 19, Construx Estimate вычисляет срок в 12,2 календарных месяца, с диапазоном достоверности 20-80 % от 11,6 до 12,9 месяца. При среднеотраслевых данных номинал составляет 15,8 месяца, а диапазон — от 13,2 до 21,5 месяца!.
Расхождения между номинальными значениями и диапазонам, вычисленными по историческим и среднеотраслевым данным, демонстрируют преимущества от использования исторических данных.
20.5.
Сжатие графика и размер группы.
После того как номинальная оценка будет вычислена, часто возникает вопрос: «На сколько можно будет сократить срок в случае необходимости?» Ответ зависит от гибкости набора функций. Если из проекта можно исключать те или иные функции, срок можно сократить насколько потребуется, в зависимости от вашей готовности к усечению функций. На выполнение меньшей работы требуется меньше времени, что вполне логично.
Если функциональность жестко фиксирована, сокращение срока может быть достигнуто только за счет добавления персонала, который бы выполнял больше работы за меньшее время... что до определенного момента тоже вполне логично.
За несколько прошедших десятилетий многие исследователи, занимающиеся оценкой программных проектов, анализировали последствия попыток сжатия номинальных сроков. Результаты их исследований показаны на рис. 20.2.
Источник: Адаптировано по материалам «Software Sizing and Estimating: Mk //» (Symons 1991), «Softzmre Cost Estimation with Cocomo //» (Boehm et al. 2000), «Estimating Web Development Costs: There Are Differences» (Reifer 2002) и «Practical Project Estimation», 2nd Edition (ISBSG 2005).
По горизонтальной оси отсчитывается отношение между номинальным и сжатым сроками. Скажем, отметка 0,9 означает, что сжатый срок занимает 0,9 от времени, соответствующего номинальному сроку (то есть 90 % от номинала). Вертикальная ось представляет общий объем работ, необходимый при сжатии или расширении срока, по сравнению с номиналом. Значение 1,3 указывает, что сжатый срок требует в 1,3 раза больше работы, чем номинальный.
Из графика на рис. 20.2 можно сделать ряд выводов.
Сокращение номинального срока приводит к увеличению объема работ. Все.
исследователи сошлись на том, что сокращение номинального срока увеличивает общий объем работ. Если номинальный срок составляет 12 месяцев для группы из 7 человек, то простое увеличение персонала до 12 человек не позволит сократить срок до 7 месяцев.
Сокращение сроков приводит к увеличению объема работы по нескольким причинам.
• В больших группах увеличиваются издержки на координацию и управление.
• В больших группах увеличивается количество коммуникационных путей. Это создает больше возможностей для недоразумений и увеличивает вероятность ошибок, которые затем приходится исправлять. Лоренс Путнэм заметил, что для кратчайшего из возможных сроков также характерна наибольшая вероятность ошибок (Putnam and Myers 2003).
• При сжатых сроках большую часть работы приходится выполнять параллельно. Чем больше объем перекрывающейся работы, тем выше вероятность того, что одна часть работы будет зависеть от незаконченной или дефектной части другой работы, а последующие изменения увеличат объем необходимой работы по исправлению.
Мнения экспертов по поводу того, насколько сокращение сроков увеличивает объем работ, различаются, но все эксперты сходятся на том, что это явление существует. Соотношение между сроками и объемами работ обсуждается в разделе 20.6.
СОВЕТ № 92 -.
Не сокращайте оценку срока без увеличения оценки объема работ.
Зона невозможности существует, и с этим ничего не сделать. Если 8 человек могут написать программу за 10 месяцев, смогут ли 80 человек написать ту же программу за один месяц? А 1600 людей за один день? Неэффективность крайнего сжатия сроков становится особенно очевидной на крайних случаях — таких, как 1600 людей за один день.
Вычисление пределов менее радикального сжатия сроков является нетривиальной проблемой, но все исследователи сошлись на том, что существует некая «зона невозможности» — точка, за пределами которой сжать номинальный срок уже не удастся. По их общему мнению, сокращение срока более 25 % номинала невозможно.
«Зона невозможности» показана на рис. 20.2. Сокращение срока разработки попросту невозможно. Ни за счет более усердной работы. Ни за счет повышения ее эффективности. Ни за счет поиска более современных решений или увеличения размера группы. Просто невозможно, и все (Symons, 1991, Boehm 2000, Putnam and Myers 2003).
СОВЕТ №93 -.
He сокращайте номинальный срок более чем на 25 %. Иначе говоря, не пытайтесь ввести оценки в «зону невозможности».
Увеличение срока по отношению к номиналу обычно приводит к сокращению общего объема работ при сокращении размера группы. Эксперты также сделали общий вывод, что увеличение срока за пределы номинала способствует уменьшению общего объема работ по тем же причинам, по которым сокращение срока увеличивает объем работ. При увеличении срока появляется возможность использования группы меньшего размера, что снижает проблемы с коммуникациями и координацией работ. Также снижается перекрытие операций, благодаря чему больше дефектов исправляется своевременно, пока они еще не успели проникнуть в другие компоненты и увеличить объем переработки.
Чтобы увеличение срока привело к снижению объема работы, необходимо уменьшить размер группы. Если тот же проект будет поручен тем же участникам и каждому из них достанется часть от прежней работы, скорее всего, вы лишь ухудшите положение (причины объясняются в разделе 3.1).
СОВЕТ № 94 -.
Чтобы снизить стоимость проекта, увеличьте срок и используйте группу меньшей численности.
20.6. Соотношения между сроком и объемом работ.
В модель оценки Лоренса Путнэма входят эмпирические правила сжатия и расширения сроков, представленные в табл. 20.4.
Таблица 20.4. Рекомендуемые соотношения между сроком и объемом работ
Увеличение/уменьшение срока
Увеличение/уменьшение объема работ
-15 %
+100 %
-10 %
+50 %
-5%
+25 %
Номинал
0%
+10 %
-30 %
+20 %
-50 %
+30 %
-65%
Более 30 %
Не практично
Источник: По данным «Measures for Excellence» (Putnam and Myers 1992).
Путнэм предупреждает, что при увеличении срока более чем на 30 % начинает снижаться эффективность работы, а это, в свою очередь, приводит к увеличению затрат.
Некоторые специалисты критиковали модель Путнэма за преувеличение последствий увеличения и уменьшения сроков, но данные International Software Benchmarking Standards Group от 2005 года демонстрируют очень похожие результаты (ISBSG 2005).
Сокращение срока и размер группы.
При снижении срока ниже номинала возникает еще одна потенциальная проблема: даже если вы не попадете в «зону невозможности», может оказаться, что размер группы придется увеличить выше экономически эффективного максимума. Лоренс Путнэм провел интереснейшие исследования связей между размером группы, сроками и производительностью для бизнес-систем среднего размера. Полученные им результаты показаны на рис. 20.3 (Putnam and Myers 2003).
Размер группы.
Рис. 20.3. Связь между размером группы, сроком и объемом работ в бизнес-системах, состоящих приблизительно из 57 000 строк кода. В группах, состоящих более чем из 5-7 человек, увеличивается как объем работы, так и срок.
Путнэм проанализировал около 500 бизнес-проектов в диапазоне от 35 000 до 95 000 строк кода (LOC), со средним размером 57 000 строк. Он разделил эти проекты на 5 категорий в зависимости от размера групп разработки. Различия в средних размерах проектов для каждого размера группы лежали в пределах 3000 строк. Путнэм обнаружил, что увеличение размера группы от диапазона.
1,5-3 до 3-5 приводило к уменьшению срока и увеличению объема работ, чего и следовало ожидать. При увеличении размера группы с 3-5 до 5-7 срок снова сокращался, а объем работ снова возрастал. Но с увеличением размера группы с 5-7 до 9-11 увеличивался как срок, так и объем работ. А при увеличении размера группы с 15 до 20 срок оставался прежним, но объем работ радикально возрастал.
Подозреваю (хотя это всего лишь мое личное мнение), что данные Путнэма доказывают, что издержки масштаба в программных проектах представляют собой не плавную и постепенно возрастающую, а скорее ступенчатую функцию с большими потерями, резко проявляющимися на определенных размерах.
Путнэм еще не обобщил свои результаты для других типов или размеров программных проектов, но в области бизнес-систем среднего размера его результаты весьма важны. Похоже, для таких проектов экономически оптимальной является группа от 5 до 7 человек. В группах большего размера ухудшаются как сроки, так и объемы работ.
В бизнес-системах среднего размера (от 35 ООО до 100 ООО строк кода) не рекомендуется использовать группы численностью более 7 человек.
20.7. Оценка срока и ограничения численности группы.
В общем случае средний размер группы вычисляется простым делением оценки объема работ на срок. Если проект в 80 человеко-месяцев оценивается 12-месячным сроком, то средний размер группы равен количеству человеко-месяцев, деленному на срок, или 80/12, то есть от б до 7 участников.
Оценки сроков, представленные в этой главе, выдают номинальный срок для проекта при известном объеме работ. Эти методы предполагают, что независимо от номинального срока вы сможете изменить размер команды до нужного уровня. Если на оцениваемый проект можно будет выделить группу из 6-7 участников, вы сможете обеспечить объем работ в 80 человеко-месяцев при сроке в 12 календарных месяцев.
Но что делать, если вы располагаете всего 4 работниками? А если проект уже достиг той стадии, на которой назначаются индивидуальные задания? А если доступны 10 человек, каждый из которых свободен на 2/3 времени? А если группа уже сформирована и период комплектования штата не потребуется? Все перечисленные факторы не учитываются в формулах этой главы; эти формулы представляют собой методы макрооценки, действующие только на ранних стадиях проектов в диапазоне от среднего до крупного размера.
В средних и крупных проектах численность группы обычно доводится до номинальной от начала до середины проекта, а в отдельных случаях изменения в группе продолжаются до завершающих стадий. В проекте среднего размера могут работать в среднем 15 человек, но начаться проект может с 5 человек, достигнуть 20 на максимуме и закончиться с 10 участниками.
В меньших проектах чаще используется модель «постоянной комплектации» — группа в полном составе начинает работу в день 1, и это продолжается до конца проекта. Если срок оценивается в 12 месяцев, но ваши планы показывают, что при фактической доступности персонала для реализации 80 человеко-месяцев потребуется 15 месяцев, то исходная оценка замещается вашими планами.
Основной целью методов оценки сроков, описанных в этой главе, является не предсказание дня завершения работы, а проверка реалистичности ваших планов в отношении сроков.
После того как вы оцените сроки и убедитесь в разумности своих планов, детальные аспекты планирования (кто и когда доступен) имеют более высокий приоритет по сравнению с исходной оценкой срока.
СОВЕТ № 96 -.
Используйте оценку срока для проверки реалистичности своих планов. Для формирования окончательного графика следует применять детальное планирование.
20.8. Сравнение результатов, полученных разными методами.
В этой главе мы использовали пять разных методов оценки срока:.
• базовая формула для вычисления срока;.
• формула неформальной оценки с прошлыми проектами;.
• метод оценки первого порядка;.
• оценочные программы, откалиброванные среднеотраслевыми данными;.
• оценочные программы, откалиброванные историческими данными.
На рис. 20.4 представлено наглядное сравнение оценок, полученных разными методами.
Рис. 20.4. Диапазоны оценок, которые были получены методами, описанными в этой главе. Относительные размеры точек представляют весовые коэффициенты, присвоенные мной каждой из оценок. Внешний вид оценок (в том числе и недостаточно хорошо обоснованных) маскирует фактическое схождение оценок
6 7 8 9 10 11 12 13 14 15 16 17 18 Календарные месяцы
На первый взгляд может показаться, что схождение оценки срока в этом примере оставляет желать лучшего. Одно из возможных улучшений предназначено для базовой формулы, по которой строилась верхняя линия. Общий диапазон, показанный на рис. 20.4, предназначен для коэффициентов базовой формулы в диапазоне от 2,0 до 4,0. Анализ исторических данных позволяет оценить действительный диапазон значений коэффициента. В примере, рассмотренном в этой главе, коэффициенты прошлых проектов лежали в диапазоне от 2,7 до 3,7, в результате чего диапазон сроков, получаемых по базовой формуле, сужается до 11,6-14,1 месяца.
Я снова присвоил высокий весовой коэффициент оценке, полученной в Construx Estimate, потому что этот метод относится к категории научных, и что еще важнее — базируется на исторических данных. Оценки базовой формулы и неформального сравнения с прошлыми проектами я бы поставил на второе место, а при наличии более надежных данных метод оценки первого порядка не использовал бы вообще.
На рис. 20.5 показано схождение оценок срока после удаления излишне обобщенных данных.
Рис. 20.5. Диапазоны оценок, которые были получены наиболее точными методами. После удаления оценок, полученных излишне обобщенными способами, схождение оценок становится очевидным
6 7 8 9 10 11 12 13 14 15 16 17 18 Календарные месяцы
Руководствуясь полученными оценками, я бы представил диапазон от 11,5 до 14 месяцев; вероятно, в этом конкретном случае я бы не стал предоставлять оценку ожидаемого случая. Все методы оценки сроков, представленные в этой главе, применяются в широкой части конуса неопределенности, и отсутствие точечной оценки на столь ранней стадии проекта будет приемлемым.
СОВЕТ № 97 -.
Прежде чем искать схождение или расхождение между оценками, исключите из набора данных результаты, полученные слишком общими методами.

Популярные статьи

Свежие статьи