В данной модели для вывода формул использовался статистический подход — учитывались реальные результаты огромного количества проектов. Автор оригинальной модели — Барри Боэм (1981) —дал ей название СОСОМО 81 (Constructive Cost Model) и ввел в ее состав три разные по сложности статистические подмодели [1].
Иерархию подмоделей Боэма (версии 1981 года) образуют:
q базисная СОСОМО — статическая модель, вычисляет затраты разработки и ее стоимость как функцию размера программы;
q промежуточная СОСОМО — дополнительно учитывает атрибуты стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды;
q усовершенствованная СОСОМО — объединяет все характеристики промежуточной модели, дополнительно учитывает влияние всех атрибутов стоимости на каждый этап процесса разработки ПО (анализ, проектирование, кодирование, тестирование и т. д.).
Подмодели СОСОМО 81 могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:
q распространенный тип — небольшие программные проекты, над которыми работает небольшая группа разработчиков с хорошим стажем работы, устанавливаются мягкие требования к проекту;
|
|
q полунезависимый тип — средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;
q встроенный тип — программный проект разрабатывается в условиях жестких аппаратных, программных и вычислительных ограничений.
Уравнения базовой подмодели имеют вид
Е=аb x(KLOC) [чел-мес];
D = cb x (E) [мес],
где Е — затраты в человеко-месяцах, D — время разработки, KLOC — количество строк в программном продукте.
Коэффициенты аb, bb, сb, db берутся из табл. 2.14.
Таблица 2.14. Коэффициенты для базовой подмодели СОСОМО 81
Тип проекта | аb | bb | сb | db |
Распространенный | 2,4 | 1,05 | 2,5 | 0,38 |
Полунезависимый | 3,0 | 1,12 | 2,5 | 0,35 |
Встроенный | 3,6 | 1,20 | 2,5 | 0,32 |
В 1995 году Боэм ввел более совершенную модель СОСОМО II, ориентированную на применение в программной инженерии XXI века [21].
В состав СОСОМО II входят:
q модель композиции приложения;
q модель раннего этапа проектирования;
q модель этапа пост-архитектуры.
Для описания моделей СОСОМО II требуется информация о размере программного продукта. Возможно использование LOC-оценок, объектных указателей, функциональных указателей.
Модель композиции приложения
Модель композиции используется на ранней стадии конструирования ПО, когда:
q рассматривается макетирование пользовательских интерфейсов;
q обсуждается взаимодействие ПО и компьютерной системы;
q оценивается производительность;
q определяется степень зрелости технологии.
|
|
Модель композиции приложения ориентирована на применение объектных указателей.
Объектный указатель — средство косвенного измерения ПО, для его расчета определяется количество экранов (как элементов пользовательского интерфейса), отчетов и компонентов, требуемых для построения приложения. Как показано в табл. 2.15, каждый объектный экземпляр (экран, отчет) относят к одному из трех уровней сложности. Здесь места подстановки измеренных и вычисленных значений отмечены прямоугольниками (прямоугольник играет роль метки-заполнителя). В свою очередь, сложность является функцией от параметров клиентских и серверных таблиц данных (см. табл. 2.16 и 2.17), которые требуются для генерации экрана и отчета, а также от количества представлений и секций, входящих в экран или отчет.
Таблица 2.15. Оценка количества объектных указателей
Тип объекта | Количество | Вес | Итого | ||
Простой | Средний | Сложный | |||
Экран | х1 | х2 | х3 | = 0 | |
Отчет | х2 | х5 | х8 | = 0 | |
3GL компонент | х10 | = 0 | |||
Объектные указатели | = 0 |
Таблица 2.16. Оценка сложности экрана
Экраны | Количество серверных (срв) и клиентских (клт) таблиц данных | ||
Количество представлений | Всего < 4 (< 2 срв, <3клт) | Всего < 8 (2-3 срв, 3-5 клт) | Всего > 8 (>3срв, >5клт) |
<3 | Простой | Простой | Средний |
3-7 | Простой | Средний | Сложный |
>8 | Средний | Сложный | Сложный |
Таблица 2.17. Оценка сложности отчета
Отчеты | Количество серверных (срв) и клиентских (клт) таблиц данных | ||
Количество представлений | Всего < 4 (< 2 срв, < 3 клт) | Всего < 8 (2-3 срв, 3-5 клт) | Всего > 8 (>3срв, > 5 клт) |
0 или 1 | Простой | Простой | Средний |
2 или 3 | Простой | Средний | Сложный |
>4 | Средний | Сложный | Сложный |
После определения сложности количество экранов, отчетов и компонентов взвешивается в соответствии с табл. 2.15. Количество объектных указателей определяется перемножением исходного числа объектных экземпляров на весовые коэффициенты и последующим суммированием промежуточных результатов.
Для учета реальных условий разработки вычисляется процент повторного использования программных компонентов %REUSE и определяется количество новых объектных указателей NOP:
NOP = (Объектные указатели) х [(100 - %REUSE) /100].
Для оценки затрат, основанной на величине NOP, надо знать скорость разработки продукта PROD. Эту скорость определяют по табл. 2.18, учитывающей уровень опытности разработчиков и зрелость среды разработки.
Проектные затраты оцениваются по формуле
ЗАТРАТЫ = NOP /PROD [чел.-мес],
где PROD — производительность разработки, выраженная в терминах объектных указателей.
Таблица 2.18. Оценка скорости разработки
Опытность / возможности разработчика | Зрелость / возможности среды разработки | PROD |
Очень низкая | Очень низкая | |
Низкая | Низкая | |
Номинальная | Номинальная | |
Высокая | Высокая | |
Очень высокая | Очень высокая |
В более развитых моделях дополнительно учитывается множество масштабных факторов, формирователей затрат, процедур поправок.