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

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

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

Обратите внимание: распределение, описанное в этом разделе, основано па монолитной (не декомпозированной) оценке объема работ, описанной в главе 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. Примеры соотношений между численностью разработчиков и тестеров

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