Проблемы при оценке размера

Существуют различные показатели размера программных проектов, в том числе: функции; требования; сценарии использования; функциональные пункты; веб-страницы; компоненты GUI (окна, диалоговые окна, отчеты и т.

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

Роль строк кода в оценке размеров

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

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

Некоторые эксперты возражают против использования строк кода в качестве метрики размера из-за проблем, возникающих при попытке анализа производительности в проектах с разными типами, размерами, языками программирования и программистами (Jones 1997). Другие эксперты указывают, что аналогичные проблемы встречаются и при использовании других метрик размеров, включая функциональные пункты (Putnam and Myers 2003).

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

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

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

Метрика LOC — это lingua franca оценки программных проектов и обычно хорошая отправная точка (при условии, что вы не забываете о ее ограничениях).

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

СОВЕТ № 80

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