Когда проект выходит на уровень планирования, рассматриваемый в этой главе, цели планирования обычно начинают конфликтовать с целями оценки. Например, после того как вы оцените размер буфера риска, все последующее планирование управления буфером риска будет направлено на снижение его величины (то есть фактически на то, чтобы сделать его оценку недействительной).

Оценку параметров планирования трудно назвать оценкой в чистом виде: взаимосвязь между мелкоструктурными целями и оценками должна быть интенсивной и итеративной. Целью оценки в этом контексте является проверка реалистичности исходных планов. Начиная с этого момента, на первый план выходят планирование и управление проектом, а оценки уступают им.

Короче говоря, планирование решает, как вести проект, а оценка — какую величину следует заложить в план. Именно этой теме посвящена настоящая глава.

21.1. Оценка операционной структуры проекта.

Одним из важных решений из области планирования должно стать распределение объема работ по требованиям, разработке архитектуры, конструированию, тестированию и сопровождению системы. Эти решения должны приниматься как для последовательных, так и для итеративных проектов. Другими словами, вопрос не в том, сколько времени следует отвести на ту или иную фазу, а в том, какой объем работ следует закрепить за операциями при их выполнении.

Оценка объема работ по разным техническим операциям.

Обратите внимание: распределение, описанное в этом разделе, основано па монолитной (не декомпозированной) оценке объема работ, описанной в главе 19.

В табл. 21.1 приведена процентная структура общего объема работ с распределением по операциям архитектуры, конструирования и тестирования системы (KLOC означает «тысячи строк программного кода»). Вследствие эффекта издержек масштаба, описанного в главе 5, доля объема работ, выделяемого на каждую операцию, зависит от размера проекта. Требования и управление обычно относятся к «особым случаям» и обсуждаются позже.

Таблица 21.1. Примерная структура объема работ в проектах разного размера

Источники: Albrecht 1979; Boehm 1981; Glass 1982; Boehm, Gray, andSeewaldt 1984; Boddie 1987; Card 1987; Grady 1987; McGairy, Waligora, and McDermott 1989; Putnam and Myers 1992; Brooks 1995; Jones 1998; Jones 2000; Boehm et al, 2000; Putnam and Myers 2003; Boehm and Turner 2004; Stutzke 2005.

Данные, приведенные в табл. 21.1, являются приближенными. Они зависят от применяемых методов, от выбора модели жизненного цикла, от эффективности работы по контролю качества и множества других факторов. В конечном итоге вы должны построить собственную таблицу по историческим данным своей организации. Впрочем, пока это не будет сделано, используйте данные из табл. 21.1 как отправную точку и отрегулируйте оценку для конкретного типа оцениваемого проекта при помощи коэффициентов из табл. 21.5.

Оценка объема работ по требованиям.

В табл. 21.1 не включены работы, связанные с требованиями. Если оценка объема работ производилась по среднеотраслевым данным производительности, учтите, что в этих данных операции, связанные с требованиями, обычно не учитываются (впрочем, бывают и исключения; это одна из причин, из-за которых в среднеотраслевых данных встречается такой разброс).

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

Модели оценки, в том числе Cocomo II и модель Путнэма, предполагают, что полученные с их помощью монолитные оценки не включают работу по требованиям. Одна из причин заключается в том, что доля работы по требованиям изменяется в большей степени, чем доля других операций. Вы можете бегло пройтись по требованиям и очень приблизительно определить большой набор, для реализации которого потребуются геркулесовы усилия. С другой стороны, можно потратить больше времени и определить меньший набор качественных требований с более эффективной реализацией.

С учетом всего сказанного, в табл. 21.2 представлены приблизительные проценты от общего объема работ, которые следует отводить на работу по требованиям в проектах разных размеров. Базовая оценка объема работ увеличивается на процент, приведенный в таблице; результат определяет суммарный объем всех технических операций с учетом работ по требованиям.

Источники: те же, что для табл. 21.1.

Оценка объема работ по управлению.

Как и в случае с требованиями, монолитная оценка объема работ не учитывает работы, относящиеся к управлению, если только они не учитываются в используемых вами исторических данных. В табл. 21.3 представлены приблизительные проценты от общего объема работ, которые следует отводить на управляющие операции в проектах разных размеров. Базовая оценка объема работ также увеличивается на процент, приведенный в таблице; результат определяет суммарный объем всех технических операций с учетом управления.

Таблица 21.3. Приблизительная доля управляющих операций в проектах разных размеров

Источники: те же, что для табл. 21.1.

Оценка общего объема работ.

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

Таблица полезна в том случае, когда данные, которые использовались для калибровки вашей монолитной оценки объема работ, включали работы по требованиям и управлению.

Таблица 21.4. Распределение объема работ в проектах разного размера

Источники: те же, что для табл. 21.1.

Поправки для типов проектов.

Как было указано в главе 5, объем работы зависит от типа проекта. Кроме того, тип влияет на процентное распределение объемов работ по разным типам операций. В табл. 21.5 перечислены поправки, которые необходимо внести в номинальное распределение в зависимости от типа проекта.

Таблица 21.5. Приблизительные поправки для распределения операций в зависимости от типа проекта

Источники: Putnam and Myers 1992; Jones 1998; Jones 2000; Boehm et al, 2000; Putnam and Myers 2003; Boehm and Turner 2004; Stutzke 2005.

СОВЕТ № 98 -.

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

Пример распределения объема работы.

Предположим, вы разрабатываете бизнес-систему, которая, согласно вашей оценке, будет состоять из 80 ООО строк кода (1450 функциональных пунктов) и займет около 80 человеко-месяцев. В основном распределении из табл. 21.1 представлены проценты для проектов в 25 KLOC и 125 KLOC. Проект размером 80 KLOC находится примерно посередине между этими двумя размерами, поэтому мы будем использовать средние арифметические процентов для 25 и 125 KLOC. В соответствии с полученными данными, 17 % объема выделяется на архитектуру (13,6 человеко-месяца), 55 % — на конструирование (44,0 человеко-месяца), а 28 % — на тестирование системы (22,4 человеко-месяца). Таблица 21.2 рекомендует увеличить работу по требованиям на 6,5 % (5,2 человеко-месяца), а в соответствии с табл. 21.3, работа по управлению проектом возрастает на 13 % (10,4 человеко-месяца). Затем в табл. 21.6 базовое распределение объема работ умножается на поправочные коэффициенты для проектов бизнес-систем.

Таблица 21.6. Применение поправочных коэффициентов к номинальному распределению объема работ в зависимости от типа проекта

В данном примере номинальная и итоговая оценки объема работы составляют 95,6 и 95,7 человеко-месяца соответственно. Небольшое несовпадение результатов обусловлено ошибками округления.

Следует хорошо понимать, что это распределение работ по фазам является приближенным, а проценты лишь представляют отправные точки для планирования. После того как оценка выведет вас на правильный путь планирования, исходные оценки уступают детальному планированию.

Соотношения между численностью разработчиков и тестеров.

Один из самых частых вопросов из области планирования: «Сколько разработчиков должно приходиться на одного тестера?» Некоторые типичные соотношения перечислены в табл. 21.7.

Данные в таблице были получены организациями, с которыми моя компания и я сотрудничали последние 10 лет.

Как видно из таблицы, соотношения очень сильно изменяются даже в пределах одного вида программных проектов. Это вполне объяснимо, потому что соотношение, хорошо подходящее для конкретной компании или проекта, зависит от стиля разработки, сложности тестируемой программы, соотношения объемов старого и нового кода, квалификации тестеров относительно квалификации разработчиков, степени автоматизации тестирования и множества других факторов.

Таблица 21.7. Примеры соотношений между численностью разработчиков и тестеров

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

21.2. Оценка срока для разных операций.

Распределение календарного времени по разным операциям и фазам проекта также в большей степени определяется факторами планирования, а не оценками. В табл. 21.8 представлено примерное распределение сроков по основным техническим операциям для разных размеров проектов. Конечно, было бы удобнее, если бы числа в таблице не были выражены в виде диапазонов. График выполнения этих операций зависит от того, когда освободятся те или иные работники, в какой степени им приходится совмещать работу над оцениваемым проектом с другими задачами, и от других факторов. В этом отношении распределение сроков подвержено большей изменчивости, чем распределение объема работ.

Таблица 21.8. Примерное распределение сроков в проектах разного размера

Источники: Boehm 1981; Putnam and Myers 1992; Boehm et al, 2000; Putnam and Myers 2003; Stutzke 2005.

Как и в случае с объемом работ, сроки для работ по требованиям обычно оцениваются в процентах от базовой оценки срока. В табл. 21.9 представлены проценты, прибавляемые к базовому сроку для работ по требованиям.

Таблица 21.9. Приблизительное увеличение срока для работ по требованиям

Источники: Boehm 1981; Putnam and Myers 1992; Boehm et al, 2000; Putnam and Myers 2003; Stutzke 2005.

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

СОВЕТ № 99 -.

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

Как и в случае с распределением объема работ по операциям, распределение сроков проще всего выполняется при наличии исторических данных.

21.3. Преобразование оценки в планируемый объем работы.

Оценки объема работы обычно выражаются в «человеко-месяцах», «человеко-днях» или других сходных показателях. Такие показатели выражают идеальный объем работы, когда каждый месяц работы соответствует одному календарному месяцу.

Майк Кон (Mike Cohn) описывает различия между идеальным и планируемым временем, сравнивая их с игровым и реальным временем в американском футболе (Cohn 2006). Нормальная игра в американском футболе продолжается 60 минут игрового времени. По настенным часам она может занять от 2 до 4 часов.

Аналогично, планировщик программного проекта не должен предполагать, что один человек способен выполнить объем работы в один человеко-месяц за один календарный месяц. Его «рабочий месяц» разбавляется отпусками, выходными и обучением; он может одновременно работать на несколько проектов; наконец, возможны и другие причины.

Рассматривая преобразование идеального объема работы в планируемый, необходимо учитывать следующие факторы.

• Какое время заложено в калибровочные данные, использованные при создании оценки объема работ? Включены ли в него работы, связанные.

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

• В каком количестве проектов будут одновременно работать программисты? Если программист делится между двумя проектами, то для выдачи одного месяца «целенаправленной» работы ему потребуется два pi более месяца.

• Учтены ли в калибровочных данных выходные, отпуска, болезни, время обучения, поддержка торговых выставок, работа с клиентами, поддержка эксплуатируемых систем и т. д.? Если нет, придется включить эти «отвлекающие факторы» при преобразовании оцениваемого объема работы в планируемый.

Перечисленные факторы сильно зависят от организации. Если вы работаете в организации, в которой группа может сосредоточиться на одном проекте, в предположения можно заложить от 40 до 50 часов «целенаправленного» рабочего времени в неделю. Я видел некоторые компании, в которых эта цель была достигнута. Обычно в таких компаниях внутренняя мотивация участников чрезвычайно сильна; группы невелики; .участники групп молоды и не перегружены семейными обязательствами; компания предлагает значительные финансовые стимулы, а рабочая среда не отягощена бюрократизмом и корпоративными мероприятиями.

Если вы работаете в большой, устоявшейся организации, в которой часто происходят корпоративные собрания, а большинство людей работает по 40 часов в неделю, вероятно, только от 20 до 30 часов будет направлено на работу над проектом, причем эти часы могут делиться между двумя и более проектами.

Информация о том, сколько в среднем времени в день работник может посвятить конкретному проекту, различается. Кейперс Джонс сообщает, что в среднем технические работники в день выделяют около 6 часов на целенаправленную работу над своими проектами, или 132 часа в месяц (Jones 1998). Модель Cocomo II предполагает 152 часа целенаправленной работы в месяц (Boehm et al. 2000). Конкретное количество часов существенно зависит от специфики организации; как и в предыдущих случаях, старайтесь получить собственные данные, основанные на прошлых проектах вашей организации.

За ссылками на дополнительную информацию по проблемам планирования обращайтесь к разделу «Дополнительные ресурсы» в конце главы.

21.4. Оценка стоимости.

Теоретически оценка стоимости представляет собой тривиальную функцию от объема работы. Тем не менее получение оценки стоимости проекта усложняется целым рядом факторов.

Сверхурочные работы.

Допускает ли ваша организация некомпенсируемые сверхурочные работы? Если допускает, то некоторый процент оцениваемого объема работ может не учитываться в оценке стоимости. Использует ли ваша организация временных работников или подрядчиков, получающих более высокую оплату за переработку? В таких случаях вклад части оцениваемого объема работы в формирование стоимости может оказаться выше среднего.

Выбор типа затрат.

В некоторых организациях стоимость проекта вычисляется на базе «прямых затрат», то есть затрат, напрямую приписываемых конкретному работнику (зарплата, налоги, премии и т. д.). В других организациях при расчете стоимости проекта используются «обременяющие затраты» с учетом полных корпоративных затрат, которые не ассоциируются с конкретными работниками (аренда, корпоративные налоги, затраты служб кадров, продаж, маркетинга и т. д.). В зависимости от размера организации, объема невозмещаемой инфраструктуры, стоимости офисного пространства и других факторов, бремя расходов в процентах от зарплаты работника может составлять от 30 до 125 % и выше.

Другие прямые затраты.

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

За ссылками на дополнительную информацию по этой теме обращайтесь к разделу «Дополнительные ресурсы» в конце главы.

21.5. Оценка дефектообразования и исправления.

Дефектообразование в программном проекте является функцией объема работы и размера проекта, поэтому количество дефектов тоже может оцениваться заранее. Информация о вероятном количестве дефектов пригодится для планирования объема работ, направленных на их исправление.

Кейперс Джонс описывает один из способов анализа дефектообразования, основанный на размере программы в функциональных пунктах (Jones 2000). Как показано в табл. 21.10, из данных Джонса следует, что в типичном проекте на один функциональный пункт создается около 5 дефектов. Этот показатель соответствует примерно 50 дефектам на 1000 строк программного кода (в зависимости от используемого языка программирования).

Таблица 21.10. Типичная частота дефектообразования в различных операциях

Другой фактор, вносящий свой вклад в издержки масштаба, заключается в том, что в крупных проектах на строку кода обычно генерируется больше дефектов; это повышает объем работы по исправлению ошибок, что, в свою очередь, повышает затраты проекта. В табл. 21.11 представлена зависимость плотности ошибок для разных размеров проекта.

Источник: «Program Quality and Programmer Productivity» (Jones 1977), «Estimating Software Costs» (Jones 1998).

Среднеотраслевые частоты дефектообразования изменяются более чем на порядок. Исторические данные прошлых проектов повысят точность оценки.

СОВЕТ № 100 -.

Используйте среднеотраслевые или исторические данные для оценки предполагаемого количества дефектов в вашем проекте.

Оценка работы по исправлению дефектов.

Дефектообразование — лишь одна из частей формулы планирования. Другой частью является исправление дефектов. В программной отрасли накопился достаточно большой объем данных по эффективности основных методов исправления дефектов. В табл. 21.12 представлены данные об эффективности исправления дефектов

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

Таблица 21.12. Эффективность исправления дефектов

продолжение &

Defect Removal Rate (Efficiency) = (Количество исправленных дефектов)/(Количество исправленных дефектов + Количество дефектов, обнаруженных после начала поставок продукта). — Примеч. перев.

Таблица 21.12 (продолжение)

Источник: По материалам «Programming Productivity» (Jones 1986а), «Software Defect-Removal Efficiency» (Jones 1996) и «What We Have Learned About Fighting Defects» (Shull et al 2002).

Важную роль здесь играет диапазон от минимальной до максимальной эффективности; как обычно, исторические данные вашей организации помогут получить более точную оценку.

Пример оценки эффективности исправления дефектов.

Объединение информацйи из таблиц дефектообразования и исправления позволяет оценить количество дефектов, которые останутся в окончательной версии вашей программы (и конечно, помогает спланировать действия по удалению большего или меньшего количества дефектов, в зависимости от ваших критериев качества).

Предположим, имеется система в 1000 функциональных пунктов. Оценка по данным Джонса из табл. 21.10 показывает, что проект будет содержать около 5000 дефектов. В табл. 21.13 описаны результаты их поэтапного устранения с применением стандартной стратегии, состоящей из персональной проверки кода, модульного тестирования, интеграционного тестирования, системного тестирования и бета-тестирования в малом масштабе.

Таблица 21.13. Пример типичной процедуры образования и устранения дефектов (для системы размером в 1000 функциональных пунктов)

Получается, что типичный подход к исправлению дефектов устранит из программы только около 84 % ошибок, что примерно соответствует стандартам отрасли (Jones 2000). Как обычно, числа, полученные этим способом, являются приближенными.

В табл. 21.14 показано, как может проходить исправление дефектов в лучших организациях. Предполагается, что группа внесет в проект те же 5000 дефектов. Однако на этот раз в число методов удаления дефектов войдет моделирование требований, формальный анализ архитектуры, персональная проверка кода, модульное, интеграционное и системное тестирование, а также бета-тестирование в большом масштабе. Как видно из таблицы, комбинация этих методов должна привести к удалению из программного продукта около 95 % дефектов.

Таблица 21.14. Пример самой надежной процедуры образования и устранения дефектов (для системы размером в 1000 функциональных пунктов)

Как и в предыдущем примере, излишняя четкость оценки в 226 дефектов не поддерживается используемыми данными.

СОВЕТ № 101 -.

Данные эффективности исправления дефектов позволяют оценить количество дефектов, которые будут удалены из программы вашими методами контроля качества перед выпуском окончательной версии.

Лоренс Путнэм приводит два дополнительных эмпирических правила исправления дефектов. Если вы хотите перейти от 95 % надежности к 99 % надежности, долю «основной сборки» в сроке следует увеличить на 25 %. Чтобы перейти от 99 к 99,9 % надежности, заложите в срок еще 25 % (Putnam and Myers 2003). (В терминологии Путнэма понятия «надежность» и «процент исправления дефектов перед выпуском» эквивалентны.).

Дальнейшая оценка атрибутов качества — весьма непростая тема, в значительной мере опирающаяся на научные методы оценки. В секции «Дополнительные ресурсы» в конце главы рассказано, где найти дополнительную информацию.

21.6. Оценка риска и резервные буферы.

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

При анализе рисковобычно учитываются их возможные последствия и вероятности. В табл. 21.15 показан пример таблицы рисков с указанием вероятности, влияния риска и причиняемого ущерба.

Таблица 21.15. Пример таблицы рисков для сроков проекта

Влияние риска, умноженное на его вероятность, обычно называется ущербом (Risk Exposure, RE). Со статистической точки зрения ущерб представляет собой «ожидаемое значение» риска, или ту величину, на которую, как предполагается, увеличится срок из-за наличия риска. Для рисков, перечисленных в табл. 21.15, базовый срок проекта увеличивается на 4,25 недели. С вероятностью 50 % срок возрастет на большую величину и с вероятностью 50 % — на меньшую.

Суммарный ущерб является хорошей отправной точкой для количественного буферного планирования. Если вам нужна более твердая уверенность в том, что проект будет выдан вовремя, запланируйте буфер, размер которого превышает величину суммарного ущерба. Если повышенный риск нарушения сроков вас не пугает, планируйте буфер меньшего размера.

Впрочем, ущерб — это лишь часть общей картины. Если в табл. 21.15 риск 1 или 3 реализуется, проект выйдет за пределы своего ожидаемого буфера в 4,25 недели. Эти события маловероятны, однако вы должны проанализировать последствия конкретных рисков перед тем, как остановиться на итоговом размере буфера.

Риски в табл. 21.15 представлены только с точки зрения возможного нарушения срока. Любой риск также может создавать угрозу для объема работ, стоимости, функциональности, качества или прибыли. В табл. 21.16 показан пример таблицы рисков, включающей сроки, стоимость и прибыль.

Таблица 21.16. Пример расширенной таблицы рисков

При планировании необходимо выделить отдельные буферы для срока, объема работ, стоимости, функциональности и качества. Эти буферы лишь отдаленно связаны друг с другом.

Помните, что влияние и вероятности рисков — величины оцениваемые, а точность сводного ущерба не превышает точности данных, которые использовались при ее вычислении.

СОВЕТ № 102 -.

Используйте суммарный ущерб рисков вашего проекта в качестве отправной точки при планировании буферов. Проанализируйте отдельные аспекты конкретных рисков и постарайтесь понять, не должен ли запланированный буфер быть больше или меньше суммарного ущерба.

Управление рисками — довольно сложная область, в которой научные методы оценки могут сыграть важную роль. В секции «Дополнительные ресурсы» в конце главы рассказано, где найти дополнительную информацию.

21.7. Другие эмпирические правила.

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

• Административная и бюрократическая поддержка увеличивают базовую оценку объема работ на 5-10 % (Stutzke 2005).

• Техническая поддержка (настройка лабораторного оборудования, установка новых программ и т. д.) увеличивает базовую оценку объема работ на 2-4 % (Stutzke 2005).

• Поддержка управления конфигурациями/сборкой увеличивает базовую оценку объема работ на 2-8 % (Stutzke 2005).

• Резервируйте от 1 до 4 % в месяц на расширение требований (Jones 1998).

• Переход от разработки, производимой одной компанией на одной площадке, к совместным распределенным разработкам увеличивает объем работ на 25 % (Boehm et al 2000).

• Переход от разработки, производимой одной компанией на одной площадке, к международной удаленной (outsource) разработке увеличивает объем работ на 40 % (Boehm et al 2000).

• Если разработчики впервые имеют дело с новым языком программирования и инструментарием, объем работ увеличивается на 20-40 % по сравнению со знакомым языком и инструментарием (Boehm et al 2000).

• Если разработка впервые производится в новой среде, объем работ увеличивается на 20-40 % по сравнению с разработкой в знакомой среде (Boehm et al 2000).