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

Стандартные метрики оценки размера — строки программного кода и функциональные пункты — обладают разными достоинствами и недостатками. То же можно сказать о специализированных методах, созданных организациями для собственного применения. Как правило, создание оценок по разным метрикам размера и проверка их схождения/расхождения обеспечивает самые точные результаты.

В этой главе описано, как создать оценку размера. В главе 19 объясняется, как преобразовать оценку размера в оценку объема работ, а в главе 20 — как преобразовать оценку объема работ в оценку срока.

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

Существуют различные показатели размера программных проектов, в том числе:.

• функции;.

• требования;.

• сценарии использования;.

• функциональные пункты;.

• веб-страницы;.

• компоненты GUI (окна, диалоговые окна, отчеты и т. д.);.

• таблицы баз данных;.

• определения интерфейсов;.

• классы;.

• строки программного кода.

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

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

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

• Данные по количеству строк кода в прошлых проектах легко собираются при помощи служебных программ.

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

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

• Измерения в строках кода позволяют выполнять межпроектные сравнения и оценивать будущие проекты по данным прошлых проектов.

• В большинстве коммерческих оценочных программ оценки объема работ и сроков в конечном счете основываются на строках кода.

С другой стороны, строки кода также создают определенные трудности при оценке размера.

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

• Строки кода не могут использоваться в качестве основы для оценки задач, порученных отдельным программистам, из-за огромных различий в производительности.

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

• Применение метрики LOC при оценке работы по постановке требований, проектированию и других действий, предшествующих созданию кода, выглядит противоестественно.

• Строки кода трудно оценивать напрямую и их обычно приходится оценивать опосредованно.

• Вы должны заранее тщательно определить, что именно следует считать строкой кода (это необходимо для предотвращения проблем, описанных в разделе 8.2).

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

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

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

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

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

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

СОВЕТ № 80 -.

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

18.2. Функциональные пункты.

Одной из альтернатив метрики LOC являются функциональные пункты. Это синтетическая метрика размера программы, которая может применяться для оценки размера проекта на его ранних стадиях (Albrecht 1979). Функциональные пункты проще вычислять по спецификациям требований, чем строки кода; кроме того, они формируют основу для вычисления размера в строках кода. Существует много разных методов для вычисления функциональных пунктов. Стандарт подсчета функциональных пунктов поддерживается группой International Function Point Users Group (IFPUG) и размещается на веб-сайте по адресу

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

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

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

Внешние запросы — комбинации входных/выходных элементов, в которых входному элементу ставится в соответствие простая выходная форма. Термин происходит из мира баз данных и относится к прямому поиску данных (обычно по уникальному ключу). В современных графических и веб-приложениях граница между запросами и выходными элементами размыта, но в общем случае запросы производят выборку данных непосредственно из базы и ограничиваются минимальным форматированием, а выходные элементы поддерживают обработку, комбинирование и обобщение сложных данных с широкими возможностями форматирования.

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

Логический файл представляет собой один неструктурированный файл или одну таблицу в реляционной базе данных.

Внешние интерфейсные файлы — файлы, находящиеся под контролем других программ, с которыми взаимодействует измеряемая программа. К этой категории относятся все основные группы логических или управляющих данных, принимаемых или передаваемых программой.

В табл. 8.1 показано, как счетчики входных элементов, выходных элементов и т. д. преобразуются в нескорректированные функциональные пункты. Количество входных элементов низкой сложности умножается на 3, количество выходных элементов низкой сложности — на 4 и т. д. Сумма полученных чисел дает метрику проекта в нескорректированных функциональных пунктах.

Таблица 18.1. Множители для вычисления нескорректированных функциональных пунктов

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

Если вы читали мои предшествующие комментарии о «субъективных регуляторах», вероятно, вы уже догадываетесь, что я думаю о коэффициенте влияния и его 14 регуляторах. Два исследования показали, что нескорректированные функциональные пункты в большей степени коррелируются с итоговым размером, чем скорректированные (Kemerer 1987, Gaffney and Werling 1991). Некоторые эксперты также рекомендуют исключить оценки «низкой сложности» и «высокой сложности» и классифицировать все счетные показатели как «средние» — тем самым исключается еще один источник субъективизма (Jones 1997). Стандарт ISO/IEC 20926:2003 базируется на нескорректированных функциональных пунктах.

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

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

Терминология метода функциональных пунктов заметно ориентирована на базы данных, но группа IFPUG неуклонно обновляет правила подсчета функциональных пунктов, и эта методика хорошо работает для всех типов программного обеспечения. Исследования показали, что сертифицированные специалисты по оценке функциональных пунктов обычно выдают показатели, отличающиеся не более чем на 10 %, так что подсчет функциональных пунктов открывает реальную возможность сокращения неопределенности, связанной с объемом проекта, в конусе неопределенности на ранней стадии проекта (Stutzke 2005).

СОВЕТ № 81 -.

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

Преобразование функциональных пунктов в строки кода.

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

Скажем, если ваша программа на 285 функциональных пунктов будет реализована на Java, из таблицы берется диапазон от 40 до 80 LOC на функциональный пункт; умножив его на 284 функциональных пункта, мы получаем оценку размера от 11 360 до 22 720 LOC, с ожидаемым значением 55 х 284 = 15675 LOC. Чтобы не создавать ложного впечатления точности, эти числа можно упростить до диапазона 11 000-23 000 LOC с ожидаемым значением 16 000 LOC.

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

Таблица 18.3. Количество команд на функциональный пункт в разных языках программирование

Источник: Адаптировано по данным «Estimating Software Costs» (Jones 1998), «Software Cost Estimation with Cocomo II» (Boehm 2000) и «Estimating Intensive Systems» (Stutzke 2005).

Описание вычисления функциональных пунктов, приведенное в этом разделе, дает лишь весьма поверхностное представление об этой сложной методике. Хотя эксперты в области вычисления функциональных пунктов могут выдавать результаты, отличающиеся в пределах 10 %, результаты вычислений неопытных оценщиков различаются от 20 до 25 % (Kemerer and Porter 1992, Stutzke 2005). За дополнительной информацией об этом методе обращайтесь к разделу «Дополнительные ресурсы» в конце этой главы.

18.3. Упрощенные методы вычисления функциональных пунктов.

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

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

Голландский метод.

Ассоциация метрик программного обеспечения Нидерландов (NESMA) предлагает «индикативный» метод для вычисления функциональных пунктов на ранней стадии проекта (Stutzke 2005). В этом методе вместо всех входных/выходных элементов и запросов учитываются только внутренние логические файлы и внешние интерфейсные файлы. Затем индикативная метрика вычисляется по следующей формуле:.

ФОРМУЛА № 8 -.

ИндикативныеФункциональныеПункты = (35 х ВнутренниеЛогическиеФайлы) + (15 х ВнешниеИнтерфейсныеФайлы).

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

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

СОВЕТ № 82 -.

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

Элементы GUI.

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

1.

Подсчитайте количество элементов GUI по категориям из табл. 18.4.

2.

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

3.

Вычислите размер в строках кода по отношениям, показанным в табл. 18.3.

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

пункты. И наконец, при преобразовании функциональных пунктов в строки кода ее становится еще больше.

Таблица 18.4. Опосредованный подсчет элементов GUI вместо функциональных пунктов Элемент GUI Эквивалент в функциональных пунктах

Простое клиентское окно.

Среднее клиентское окно.

Сложное клиентское окно.

Средний отчет Сложный отчет Любой файл Простой интерфейс.

Средний интерфейс.

Сложный интерфейс.

Окно сообщения или диалоговое окно.

СОВЕТ № 83 -.

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

18.4. Сводка методов оценки размера.

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

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

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

СОВЕТ № 84 -.

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