24.3.1. Модель сосомо

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

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

2. Модель популярна и ценится среди широкого круга пользователей.

3. Она прошла достаточно долгий путь развития со времени первого появления в 1981 году, была усовершенствована для разработки ПО на языке Ada, последняя версия модели опубликована в 2000 году.

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

Моделью СОСОМО 81 предусмотрена разработка программного обеспечения в соответствии с каскадной моделью, причем предполагается, что большая часть системы разрабатывается "с нуля". Однако со времени первой версии данной модели было сделано несколько фундаментальных изменений в целях ее усовершенствования. Теперь модель допускает производство ПО путем компоновки повторно используемых компонентов, связывая их между собой с помощью какого-либо языка сценариев. Сегодня прототипирование и пошаговая разработка – наиболее распространенные модели создания программного продукта. Во многих случаях используются серийные компоненты, доступные на рынке программных продуктов. Кроме того, существующие программы модифицируются в целях создания нового программного обеспечения. Поддержка CASE-средств уже стала доступной для многих видов работ по созданию ПО.

Таблица 24.5. Модель СОСОМО 81

Сложность проекта	Формула*	Описание
Простой проект	РМ = 2.4 (KDSI)1.05 х М	Простые проекты для небольших команд разработчиков
Средней сложности	РМ = 3.0 (KDSI)1.12 х М	Более сложные проекты, при разработке которых члены команды могут ощущать нехватку опыта и знаний соответствующих систем
Проект встроенной системы	РМ = 3.6 (KDSI)1.20 х М	Сложные проекты, где ПО является частью комплекса аппаратных и программных средств, других технических механизмов и устройств

* В этих формулах РМ (от Person-Months) обозначает человеко-месяцы, KDSI (от thousand (Kilo-) of Delivered Source Instructions) - количество инструкций (в тысячах) в конечной программе (общепринятая единица измерения объема работ по программированию).

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

Модель СОСОМО 2 охватывает три описанных ниже уровня:

1. Уровень предварительного прототипирования. Для определения необходимых затрат осуществляется оценка размера системы на основе объектных точек прототипа с помощью простой формулы "размер-производительность".

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

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

Уровень предварительного прототипирования

Этот уровень был введен в модель СОСОМО для оценки затрат на прототипирование проектов, а также для тех проектов, в которых программное обеспечение разрабатывалось путем сборки уже существующих компонентов. Здесь оценка затрат основана на подсчете взвешенных объектных точек, деленных на стандартное значение производительности. Производительность зависит от опыта и способностей разработчика, а также от возможностей CASE-средств, используемых для поддержки процесса разработки. В табл. 24.6. показаны различные уровни производительности, которые были предложены разработчиками модели.

Таблица 24.6. Производительность, выраженная в объектных точках

Опыт и возможности программиста	Очень низкие	Низкие	Средние	Высокие	Очень высокие
Уровень и возможности CASE-средств	Очень низкие	Низкие	Средние	Высокие	Очень высокие
Производительность (количество объектных точек в месяц)	4	7	13	25	50

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

РМ = (NOP х (1 – % многократного использования/100))/ PROD.

Здесь РМ – это затраты, выраженные в человеко-месяцах, NOP – количество объектных точек, a PROD – производительность, как показано в табл. 24.6.

Уровень предварительного проектирования

На этом этапе оценка основана на стандартной формуле алгоритмических моделей, а именно:

затраты = А х размер 8 х М.

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

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

Множитель М является произведением семи показателей, характеризующих проект и процесс создания ПО, а именно: надежность и уровень сложности разрабатываемой системы (RCPX), повторное использование компонентов (RUSE), сложность платформы разработки (PDIF), возможности персонала (PERS), опыт персонала (PREX), график работ (SCED) и средства поддержки (FCIL). Это позволяет провести оценивание по шестибалльной шкале, где число 1 будет соответствовать самым малым значениям этих показателей, а число 6 - самым высоким значениям. С другой стороны, их можно вычислить путем комбинирования значений более детализированных показателей, которые используются на постархитектурном уровне.

Таким образом, оценка затрат вычисляется по следующей формуле:

РМ = А х размер 8 х М + РМm,

где М = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED.

Последнее слагаемое в формуле (PMm) обозначает фактор, используемый в случаях, когда значительная часть кода генерируется автоматически. При этом часть кода всегда требуется вводить вручную, но уровень производительности все равно будет выше, чем при полностью ручном вводе. Затраты РМm рассчитываются отдельно по приведенной ниже формуле, а затем добавляются к оценке затрат на введенный вручную код.

PMm = (ASLOC x (AT/100))/ ATPROD,

где ASLOC- это количество строк кода, произведенных автоматическим способом, ATPROD - уровень производительности автоматической генерации кода. Однако следует заметить, что требуется также выполнение определенных работ для согласования сгенерированного кода с остальной частью системы. Объем этих работ зависит от процента автоматически сгенерированного кода во всей системе (коэффициент AT). Фактически производительность зависит от количества созданных программных модулей. Чем меньше объем сгенерированного кода, тем больший объем работ необходим для интеграции его с другими кодами системы.

Постархитектурный уровень

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

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

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

• Степень повторного использования компонентов. Если степень повторного использования программных компонентов значительна, в оценку количества строк разрабатываемого кода необходимо внести поправки. Однако в [309] показано, что расходы на повторное использование компонентов не всегда линейно зависят от размера этих компонентов, так как требуют затрат на их подбор и на то, чтобы разобраться с их возможностями и интерфейсами; кроме того, могут потребоваться затраты на внесение изменений в эти компоненты.

Оценка затрат на повторное использование компонентов в модели СОСОМО 2 рассчитывается по следующей формуле:

ESLOC = ASLOC  (АА + SU + 0.4 DM + 0.3 СМ + 0.3 1М)/100.

Здесь ESLOC – количество строк нового кода, ASLOC – количество строк повторно используемого кода, требующего изменений, DM – процент изменений в архитектуре системы, СМ – процент измененного кода, a IM – процент затрат на интеграцию повторно используемого программного обеспечения. Коэффициент SU зависит от затрат на адаптацию повторно используемых программных компонентов и колеблется в пределах от 50 (для сложного неструктурированного кода) до 10 (для грамотно написанного объектно-ориентированного кода). Коэффициент АА отображает затраты на начальную оценку возможности повторного использования компонентов. Его значение колеблется от 0 до 8. Показатель степени в формуле расчета затрат в модели СОСОМО 1 имеет три возможных значения, которые соотносятся с различными уровнями сложности проекта. С возрастанием уровня сложности проекта увеличивается значимость размера системы. Однако отрицательный эффект размера системы можно нивелировать с помощью организационных мероприятий, что учтено в модели СОСОМО 2. Здесь показатель степени рассчитывается с учетом пяти показателей, которые описаны в табл. 24.7. Они отсчитываются по шестибалльной шкале от низшего (5 баллов) до наивысшего (0 баллов) уровня. Значения показателей суммируются, сумма делится на 100, результат прибавляется к числу 1.01, после чего получается значение показателя степени.

Таблица 24.7. Показатели, используемые при расчете показателя степени в модели СОСОМО 2

Показатель	Пояснение
Новизна проекта	Отображает предыдущий опыт организации в реализации проектов данного типа. Очень низкий уровень этого показателя означает отсутствие опыта, наивысший уровень указывает на компетентность организации-разработчика в данной области ПО
Гибкость процесса разработки	Отображает возможность изменения процесса разработки ПО. Очень низкий уровень этого показателя означает, что процесс определен заказчиком заранее, наивысший – заказчик определил лишь общие задачи без указания конкретной технологии процесса разработки ПО
Анализ архитектуры системы и рисков	Отображает степень детализации анализа рисков, основанного на анализе архитектуры системы. Очень низкий уровень данного показателя соответствует поверхностному анализу рисков, наивысший уровень означает, что был проведен тщательный и полный анализ всевозможных рисков
Сплоченность команды	Отображает степень сплоченности команды и их способность работать совместно. Очень низкий уровень этого показателя означает, что взаимоотношения в команде сложные, а наивысший – что команда сплоченная и эффективная в работе, не имеет проблем во взаимоотношениях
Уровень развития процесса разработки	Отображает уровень развития процесса создания ПО в организации-разработчике. Оценка этого показателя основывается на вопроснике модели СММ

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

Для оценки показателя степени используются перечисленные ниже показатели проекта.

1. Новизна проекта. Это новый проект для организации, данный показатель имеет низкий уровень (оценивается в 4 балла).

2. Гибкость процесса разработки. Нет вмешательства заказчика – уровень показателя очень высокий (оценивается в 1 балл).

3. Анализ архитектуры системы и рисков. Анализ не был проведен – уровень данного показателя очень низкий (оценивается в 5 баллов).

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

5. Уровень развития процесса разработки. Определенное управление проектом имеет место – показатель оценивается как обычный (3 балла).

Сумма значений всех этих показателей составляет 16 баллов, поэтому значение показателя степени будет равно 1.17.

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

1. Характеристики программного продукта, которые определяются системными требованиями.

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

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

4. Характеристики проекта, учитывающие определенные параметры и показатели проекта разработки ПО.

Таблица 24.8. Проектные характеристики, формирующие стоимость проекта

Характеристики программного продукта
RELY	Требуемая надежность системы
CPLX	Сложность системных модулей
DOCU	Объем необходимой документации
DATA	Размер используемой базы данных
RUSE	Процент повторного использования компонентов
Характеристики аппаратных средств
TIME	Показатели, ограничивающие время исполнения
PVOL	Возможность изменения платформы разработки
STOR	Ограничение объема памяти
Характеристики персонала
АСАР	Способности лиц, выполняющих анализ проекта
PCON	Сплоченность команды разработчиков
РЕХР	Опыт программирования в данной области ПО
РСАР	Способности программистов
АЕХР	Опыт аналитика проекта в данной области ПО
LTEX	Опыт применения данного языка программирования и средств разработки
Характеристики проекта
TOOL	Использование вспомогательных программных средств
SCED	Уплотнение графика работ
SITE	Количество работ, выполняемых в разных местах, и качество коммуникаций

В табл. 24.9 показан пример того, каким образом эти характеристики влияют на предварительную оценку затрат. Показатель степени 1.17, полученный в предыдущем примере, RELY, CPLX, STOR, TOOL и SCED являются основными характеристиками, формирующими стоимость проекта. Все другие характеристики имеют значение 1, поэтому не влияют на оценку затрат.

Таблица 24.9. Расчет оценки затрат

Значение показателя степени	1.17
Размер системы (с учетом повторного использования компонентов и возможного изменения требований)	128 000 DSI*
Начальная оценка по модели СОСОМО без учета проектных характеристик	730 человеко-месяцев
Надежность системы	Очень высокая, множитель 1.39
Сложность системных модулей	Очень высокая, множитель 1.3
Ограничение объема памяти	Высокое, множитель 1.21
Использование вспомогательных средств	Низкое, множитель 1.12
График работ	Ускоренный, множитель 1.29
Уточненная оценка по модели СОСОМО	2306 человеко-месяцев
Надежность системы	Очень низкая, множитель 0.75
Сложность системных модулей	Очень низкая, множитель 0.75
Ограничение объема памяти	Нет, множитель 1
Использование вспомогательных средств	Очень высокое, множитель 0.72
График работ	Нормальный, множитель 1
Уточненная оценка по модели СОСОМО	295 человеко-месяцев

* DSI (Delivered Source Instructions) - количество инструкций в конечной программе.

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

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