6. Cocomo 2: модель композиции приложения

Автор конструктивной модели стоимости - Барри Боэм (1995) дал ей название COCOMO(COnstructiveCOstModel). COCOMO II является наследником первоначальной модели и более подходящей для оценивания современных проектов разработки ПО.

Модель композиции приложения используется на ранней стадии разработки ПО, когда:

• рассматривается макетирование пользовательских интерфейсов;

• обсуждается взаимодействие ПО и компьютерной системы;

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

• определяется степень зрелости технологии.

Модель композиции приложения ориентирована на применение объектных указателей.

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

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

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

Оценка сложности отчетавыполняется следующим образом: в зависимости от количества представлений экранов (0-1, 2-3, 4…) и количества серверных и клиентских таблиц данных, значения сопоставляются с таблицей и выбирается сложность (простой, средний, сложный)

Для учета реальных условий разработки вычисляется процент повторно используемого программных компонентов %REUSE и определяется количество новых объектных указателейNOP: .

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

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

- зрелость среды разработки.

Эти характеристики (очень низкая, низкая, номинальная, высокая, очень высокая) соотносятся в таблице, и выбирается численное значение PROD.

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

7.Cocomo 2: модель раннего этапа проектирования

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

A – масштабный коэффициент (равен 2.5);

B – показатель, отражающий нелинейную зависимость затрат от размера проекта;

М_e – множитель поправки, зависящий от 7 формирователей затрат, характеризующих продукт, процесс и персонал;

ЗАТРАТЫ_auto – слагаемое, отражающее затраты на автоматически генерируемый программный код.

Значение показателя степени B изменяется в диапазоне [1.01;1.26], зависит от пяти масштабных факторов W_i и вычисляется по формуле: . Оценки масштабных факторов могут принимать одно из шесть значений: от очень низкой (5) до очень высокой (0). Множитель поправки M_e зависит от набора формирователей затрат, для каждого из которых определяется оценка по 6-и бальной шкале: 1 – очень низкий уровень, 6 – очень высокий уровень. Множитель поправки определяется по формуле: . Формирователи затрат для раннего этапа проектирования:

• PERS – Возможностиперсонала (Personnel Capability);

• RCPX – Надежностьисложностьпродукта (Product Reliability and Complexity);

• RUSE – Требуемое повторное использование (RequiredReuse);

• PDIF – Трудностьплатформы (Platform Difficulty);

• PREX – Опытностьперсонала (Personnel Experience);

• FCIL – Средства поддержки (Facilities);

• SCED – График (Schedule).

Слагаемое ЗАТРАТЫ_auto используется, если некоторый процент программного кода генерируется автоматически. Поскольку производительность такой работы значительно выше, чем при ручной разработке кода, требуемые затраты вычисляются отдельно, по следующей формуле: , где

• KALOC – количество строк автоматически генерируемого кода,

• AT – процент автоматически генерируемого кода (от кода всей системы),

• ATPROD – производительность автоматической генерации.