Модель конструктивных затрат(Constructive Cost Model) относится к числу наиболее широко применяемых технологий оценивания. Основанная на регрессии модель была разработана Барри Б. Боэмом в начале 1970 годов. Было анализировано 63 программных проекта различных типов. При этом оценивался фактический размер(LOC), понесенные трудозатраты, а также фактическая длительность разработки ПО.

6.2.1 Общее описание регрессионных моделей

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

· Метод регрессии применяется для создания количественного прогноза значения одной переменной, полученного на основе значений других переменных.

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

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

В линейных моделях значения параметра вычисляется по формуле ax+b, где a и b константы. Для их определения используется метод наименьших квадратов.

6.2.2 Режимы модели COCOMO

В модели COCOMO используются 3 режима, с помощью которых классифицируется сложность системы, а также среды разработки.

Рис. 6.2 Режимы модели COCOMO

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

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

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

6.2.3 Уровни модели COCOMO

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

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

· Промежуточный уровень. На этом уровне используются сведения о размере, режиме и 15 дополнительных параметров для определения необходимых трудозатрат. Дополнительные переменные называются драйверами затрат и имеют отношение к атрибутам продукта, персонала, компьютера и проекта, которые могут влиять на конечные трудозатраты. Произведение драйверов затрат называется корректировочным множителем среды(Environmental adjustment factor, EAF).

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

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

6.2.4 Базовая модель COCOMO

Входная переменная, используемая для оценки трудозатрат - количество строк кода KLOC. Для вычисления трудозатрат, выраженных в человеко-месяцах, используется следующая экспоненциальная формула:

Трудозатраты Е = a * (размер)b,

где а и b - константы, определенные на этапе регрессивного анализа(в зависимости от проекта), размер - тысячи строк кода(KLOC).

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

Таблица 6.1. Базовые формулы оценки необходимых для разработки времени и трудозатрат в модели СОСОМО

Очень просто можно определить среднюю численность персонала:

S = Е / TDEV

и производительность:

P = размер / трудозатраты.

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

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

6.2.5 Промежуточная модель COCOMO

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

Кроме показателя KLOC входными данными в этом случае являются значение драйверов затрат:

Трудозатраты(Е) = a * (размер)b * С,

где С - фактор корректировки трудозатрат (Effort adjustment factor, EAF)

C = C1 * C2 * … * Cn

Ci = 1 - драйвер затрат не применим

Ci > 1 - драйвер увеличивает затраты

Ci < 1 - драйвер уменьшает затраты

Таблица 6.2. Формулы для оценки трудозатрат в промежуточной модели СОСОМО

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

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

Таблица 6.3. Категории драйверов затрат в промежуточной модели COСOMO

Атрибуты программного продукта

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

· требуемая надежность - как правило, применяется в системах реального времени;

· размер базы данных - в основном применяется в приложениях обработки данных;

· сложность продукта - ограничения на время выполнения.

Атрибуты, связанные с аппаратными средствами

Другие атрибуты имеют отношение к компьютерной платформе и могут применяться в качестве средства поддержки, а также при наличии работы; которая должна быть выполнена:

· ограничения времени выполнения - применяются в том случае, когда быстродействие процессора является ограниченным;

· ограничения основного хранилища - применяются в случае, когда размер памяти является ограниченным;

· изменяемость виртуальной машины -- включает аппаратное обеспечение и операционную систему на целевом компьютере;

· оборотное время компьютера -- применяется при разработке.

Атрибуты проекта

Атрибуты, связанные с практикой и инструментами:

· практика современного программирования -- структурные или ОО-технологии;

· современные инструменты программирования-- CASE-инструменты, хорошие отладчики, инструменты, используемые при выполнении тестирования;

· сжатие (или расширение) графика-- отклонение от идеала всегда удручает, но меньшая степень отклонения всегда лучше, чем большая.

Атрибуты персонала

Некоторые атрибуты применяются для описания исполнителей работ:

· способности аналитика;

· опыт в создании приложений;

· способности программиста;

· опыт в области виртуальных машин, включая операционную систему и аппаратное обеспечение;

· опыт в области языков программирования, включая инструменты и практику.

Другие драйверы затрат

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

· изменяемость требований -- некоторые из них являются ожидаемыми, однако большинство из них могут представлять значительную проблему;

· изменяемость машины, предназначенной для разработки - нестабильные ОС, компиляторы, CASE-инструменты и т.д.;

· требования безопасности -- применяются для классифицированных программ;

· доступ к данным - иногда является весьма затрудненным;

· влияние стандартов и навязанных методов;

· влияние физического окружения.

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

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

Поскольку драйверы затрат являются мультипликативными, в случае, если драйвер затрат не влияет на трудозатраты, его значение равно 1. При этом конечное значение C не изменяется. Подобные драйверы затрат называются нормальными либо "номинальными". Например, если опыт в области языков программирования (LEXP) команды в рассматриваемой организации больше, чем аналогичный показатель в любой другой организации в этом городе, значение LEXP будет оставаться равным 1. Это связано с тем, что превосходящие способности в области языков программирования нормируются в данной среде. Оценщик может выполнять поиск условий, при наступлении которых возрастает показатель трудозатрат (произведение всех драйверов затрат превышает 1) либо значение этого показателя уменьшается (произведение всех драйверов затрат меньше 1). При поиске применяется критерий «обычности» для данной среды. Как правило, объем трудозатрат увеличивается в случае, если применяется новая технология, команда разработчиков только что сформирована либо состоит из неопытных в данной области программистов, имеет место повышенная сложность технологической проблемы либо имеют место другие условия, отличные от стандартных. Если же требуется меньше трудозатрат, то это означает, что подобные проблемы были успешно разрешены ранее.

6.2.6 Пример реализации промежуточной модели COCOMO

В качестве практической реализации метрики я разработал приложение (приложение 1), которое позволяет оценить в рамках модели COCOMO характеристики проекта на ранних стадиях жизненного цикла: значение EAF(Effort adjustment factor), оценки трудозатрат (в человеко-месяцах), а также ожидаемую продолжительность проекта и среднюю производительность работы персонала. Входными данными являются размер проекта в KLOC и соответствующие драйверы затрат. Также приведены комментарии для каждого драйвера и возможных принимаемых значений.

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

Если, например, проект сблокированного режима, то получаем трудозатраты 44.82 чел/мес. Для сравнения, в базовой модели COCOMO трудозатраты будут соответственно 39.56 чел/мес. Если при выполнении проекта привлечь более квалифицированный персонал, увеличив, соответственно PCAP и LEXP с номинальных значений до высоких, трудозатраты будут равны 36.62 чел/мес. Если при этом затраты на персонал возрастают с $1700 до $2000 на чел/мес., то разница в затратах будет следующая:

44,82 чел/мес. * $1700 / чел/мес. = $76194

36.62 чел/мес. * $2000 / чел/мес. = $73240

Разница равна $2954.

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

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

Хотя рассмотренные 15 драйверов затрат способствуют лучшему использованию сред, в которых отсутствуют либо оказывают незначительное влияние хронологические данные, они не могут применяться одинаковым образом в нескольких организациях либо даже в одной организации на протяжении длительного периода времени. Данные из 63 оригинальных проектов Боэма могут применяться до тех пор, пока не будут собраны фактические данные. После того как станут доступными фактические данные, с их помощью будут изменены исходные данные, а модель будет калиброваться до тех пор, пока она не будет полностью соответствовать данному типу приложения и данной организационной среде либо среде и приложению одновременно. Многие производители поддерживают автоматизированные инструменты, предназначенные для выполнения оценок, имеющих заданные размер и сложность. Многие из этих инструментов обеспечивают автоматизированную поддержку добавления фактических данных и калибровку модели путем изменения показателя, коэффициента, значений драйвера затрат либо всех трех параметров одновременно. Калиброванная модель может быть создана путем использования пяти точек данных (проект, для которого определяются размеры, временной период, а также трудозатраты, которые являются наблюдаемыми).

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

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

6.2.7 Детализированная модель COCOMO

Детализированная модель COCOMO является наиболее сложной. Она включает следующие дополнительные шаги.

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

Анализ драйверов затрат производится отдельно для каждого компонента. Подсистемы и модули наследуют драйверы затрат системы. Они называются: RELY, VIRT, TURN, MODP, TOOL и SCED. Модули наследуют драйверы затрат подсистемы. Эти драйвера называются: DATA, TIME, STOR, АСАР, АЕХР (проявляется тенденция к применению одних и тех же модулей внутри подсистемы). Драйверы затрат модуля имеют такие названия: KLOC, AAF, CPLX, PCAP, VEXP и LEXP. Драйвер AAF является новым -- результат адаптации существующих модулей. Дополнительная информация доступна до этапа изменения существующего ПО -- благодаря этим данным обеспечиваются более корректные оценки. Как правило, большинство создаваемых программных продуктов не разрабатываются "с нуля", а являются результатом повторного использования существующих модулей, реализуемых с помощью новейших методов (например, объектно-ориентированных). Использование детализированной модели СОСОМО зачастую эквивалентно дополнительным трудозатратам. Следует отметить, что затраты на этапе повторного использования не всегда равны нулю. Ведь не обойтись без трудозатрат на этапе работы с существующим кодом и разработки соответствующего интерфейса. Затраты на переписывание системы могут быть меньшими, чем продолжение ее поддержки (по причине энтропии структуры). Однако переписывание старой системы может быть более дорогостоящим, чем создание "новой" системы. Распространено мнение, согласно которому точка экономической безубыточности достигается в результате изменения 20% кода; после прохождения точки безубыточности повторное использование кода не будет эффективным.

Действия по разработке проекта разбиваются на фазы. В работах Боэма (Boehm) используются четыре основных фазы: требования (RQ), разработка проекта продукта (PD), детализированный дизайн продукта (DD), кодирование и тестирование разрабатываемого модуля (CUT). Интеграция и тестирование (IT), а также поддержка (MN) описываются на протяжении всего жизненного цикла. Фазы могут применяться для разбиения систем, подсистем, и/или модулей. На каждой фазе могут применяться различные множители трудозатрат. Различные значения множителей драйверов затрат устанавливаются на каждом из трех уровней иерархии программных продуктов (система, подсистема, модуль), а также на каждой фазе (RPD, DD, CUT, IT) внутри иерархий.

6.2.8 Преимущества и недостатки модели COCOMO

Ниже перечислены преимущества модели СОСОМО:

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

· применяемый в данном случае процесс является повторяемым;

· метод позволяет добавлять уникальные факторы корректировки, связанные с данной организацией;

· он является достаточно универсальным и может поддерживать различные "режимы" и "уровни";

· идеально подходит для проектов, между которыми нет существенных отличий относительно размера, сложности или протекания процесса;

· возможна высшая степень калибровки с опорой на предыдущий опыт;

· обязательная документация;

· простота в применении.

Ниже перечислены недостатки модели СОСОМО:

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

· игнорируется документация и другие требования;

· игнорируются атрибуты заказчика -- навыки, кооперирование, знания и способность к реагированию;

· слишком упрощается влияние вопросов безопасности;

· игнорируются проблемы обеспечения безопасности ПО;

· не учитывается среда разработки ПО;

· игнорируются уровни взаимодействия персонала;

· игнорируются многие вопросы, связанные с аппаратным обеспечением

· все уровни зависят от оценки размера - точность оценки размера влияет на точность оценки трудозатрат, времени разработки, подбор персонала и оценку производительности;

· оценки, основанные на опыте, могут быть некорректными по причине устаревания используемых хронологических данных;

· существует зависимость между знаниями по драйверам затрат и количеством времени, затраченного на каждой фазе.

Также в этой модели исключаются следующие компоненты:

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

· менеджмент (обычно выполняется менеджмент на уровне строк, а не общий менеджмент);

· накладные расходы;

· расходы на командировки и другие побочные расходы;

· системная интеграция и поддержка тестирования;

· поддержка тестовых полей;

· компьютеры;

· источники поставок;

· определенное место в офисе.

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

При использовании модели СОСОМО предполагается наличие очень простого базового уровня трудозатрат, используемого при управлении конфигурацией и обеспечении качества. В этом случае используется примерно 5% общего бюджета (основываясь на типичной коммерческой практике, принятой при использовании модели СОСОМО). Показатели затрат могут быть увеличены в 2-4 раза при разработке современного ПО с учетом сложности современных программных продуктов.

Согласно Боэму (Boehm), трудозатраты изначально были распределены таким образом, чтобы 30% приходилось на дизайн, 30% на кодирование и тестирование модуля, а 40% на интеграцию и тестирование.

Рис. 6.3 Фазы, включенные в модель COCOMO.

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

6.3 Модель COCOMO II