Метрики программной продукции: трудоёмкость разработки программного обеспечения и модель COCOMO II

Сегодня производство программного обеспечения обязательно должно оцениваться не только по качеству [1,2] и ряду других важных характеристик [3], но и по стоимости производства.

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

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

• -    задачи, которые будет выполнять ПО;

• -    задача разработки ПО (разработка архитектуры, написание кода, тестирование);

• -    задачи поддержки (менеджмент, см);

• -    дополнительные затраты (командировки, оборудование);

• -    используемые инструменты;

• -    опытность разработчиков.

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

Для её выполнения есть большое количество моделей, но, к сожалению, большинство из них устарели и недостаточно отражают современное состояние сферы ИТ.

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

Другой пример: метод оценки Use Case Point (UCP) который был разработан в 1993 году [6]. Этот метод основан на использовании для оценки размера программного обеспечения примеров из унифицированного языка моделирования (Unified Modeling Language - UML). UCP оценивает такие элементы как: исполнители, техническая сложность и сложность среды. Сама же оценка производится по формуле:

UCP = (UUCW + UAW) x TCF x ECF где UUCW - нескорректированный вес прецедента,

UAW - нескорректированный вес исполнителя,

TCF - коэффициент технической сложности,

ECF - коэффициент сложности среды.

Эта система оценки более полно учитывает всё разнообразие факторов разработки и рисков [7,8], однако, вышеуказанные факторы не охватывают все многообразие возможных оценок проекта.

Найти идеальный подход к решению проблемы оценки трудоёмкости и, следовательно, стоимости программного обеспечения затруднительно, но модель оценки COCOMO II, по-нашему мнению, охватывает большинство сторон разработки и именно поэтому она стала такой популярной и широко используемой технологией оценки.

COnstructive COst MOdel (разработанная модель стоимости) – это модель, созданная Барри Боэмом. Представляет собой алгоритмическую модель оценки стоимости разработки программного обеспечения, для работы с которой также нужно собирать данные о разрабатываемых проектах, которые позже будут использоваться в расчетных формулах [9]. Для использования этой модели используется регрессионная формула с параметрами [10].

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

• -    с её помощью создаётся прогнозирование одной переменой (количественное и качественное), которое зависит от значения других переменных;

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

Модель COCOMO – II это наследник более ранней модели COCOMO, которая была представлена ещё в 1981 г. Новая модель имеет в своей основе современные идеи и приспособлена к текущим методологиям разработки программных средств (например, к спи- ральной и итеративной моделям жизненного цикла ПО).

В COCOMO – II можно различить две стадии оценки: начальная или предварительная на начальном этапе и детальная после проработки архитектуры.

Преимуществами оценочной системы COCOMO – II являются:

• -    проста применения;

• -    факторы корректировки оценки

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

• -    процесс, который применяется

является повторяемым;

• -    прежний опыт позволит макси

мально точно откалибровать оценку;

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

• -    является универсальной, потому

что умеет поддерживать разные так называемые «уровней» и «режимов»;

Но, к сожалению, в модели оценки COCOMO – II присутствуют и недостатки, основными из них являются следующие:

• -    опыт имеет свойство устаревать, поэтому оценки, сделанные на его основе, не всегда соответствует актуальному состоянию развития проекта;

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

• -    уровни взаимодействия персона

ла не учитываются;

• -    IDE не учитывается;

• -    большинство вопросов, связан

ных с АО, не учитываются;

По концепции Боэма, изначально трудозатраты делились следующим образом:

• -    30% на дизайн;

• -    30% на тестирование и кодиро

вание;

• -    40% на тестирование и интегра

цию;

На рисунке 1 изображены фазы COCOMO-II.

Рисунок 1. Фазы, включаемые в COCOMO-II

Для того, чтобы успешно применять модель оценки COCOMO – II следует накапливать настолько больше данных, насколько это возможно, особенно оценок и тех результатов, которые получились фактически. Также стоит пригото- виться к выполнению повторной оценки и её перепроверке с самых начальных стадий, и калибровке моде-ли/инструмента в соответствии с теми потребностями, которые выдвинет конкретная организация.