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

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

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

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

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

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

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

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

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

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

Кейперс Джонс описывает один из способов анализа дефектообразования, основанный на размере программы в функциональных пунктах (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 представлены данные об эффективности исправления дефектов1 для анализа, обсуждения, модульного тестирования, тестирования системы и других распространенных методов.

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

продолжение amp;

1 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). (В терминологии Путнэма понятия «надежность» и «процент исправления дефектов перед выпуском» эквивалентны.)

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