Анализ существующих моделей оценки стоимости разработки программного обеспечения

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

Согласно ежегодно публикуемому обзору группы The Standish Group, в среднем превышение стоимости проектов от первоначальной сметы составляет 178% для крупных компаний, 182% для средних компаний и 214% для небольших компаний.[2]

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

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

Основными причинами ошибок оценки являются:

• -    неопределённость на ранних стадиях проектирования;

• -    несовершенство организации процесса разработки;

• -    неполные технические требования;

• -    оптимистическая и субъективная оценка трудоемкости задач.

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

Получение точных оценок путем несложных расчетов позволяет решить алгоритм модели оценки стоимости. Модель оценки стоимости используется в следующих случаях:

• -    решение делать ли инвестиции, или принять иные финансовые решения, касающиеся разработки программного обеспечения;

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

• -    решение о снижении затрат, времени, функциональности, качества продукта при ограничении ресурсов на разработку.

• -    распределение задач по исполнителям или решение о покупке готовых компонентов разрабатываемой системе.

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

Методы и модели оценки стоимости ПО делятся на две группы: неалгоритмические методы ( Price-to-win , оценка по Паркинсону, экспертная оценка, оценка по аналогии) и алгоритмические модели ( SLIM и COCOMO ).

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

• 1.    Метод Price-to-win состоит в том, что независимо от предполагаемых реальных затрат на разработку проекта, оценка стоимости ПО корректируется в соответствии с пожеланиями заказчика. Price-to-win фактически является политикой проведения переговоров с клиентом, поэтому часто применяется компаниями, не имеющими средств для качественной оценки проектов. Применение метода может привести к нехватке ресурсов для выполнения проекта, невыполнению сроков сдачи проекта и как результат – потеря контракта или банкротство компании разработчика.

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

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

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

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

Модели оценки стоимости ПО представляет собой одну или несколько функций, которые описывают зависимость между характеристиками проекта и затратами на его реализацию. По типу используемых функций модели разделяют на линейные, мультипликативные, степенные. По использованию исторических данных разделяют на эмпирические и аналитические. Наиболее часто реализуемыми и хорошо документированными моделями являются модель Путнэма SLIM (степенная, аналитическая) и модель COCOMO (степенная, эмпирическая) [4].

Модель SLIM, созданная Лари Путнэмом из компании Quantitative Software Mangement, основана на анализе жизненного цикла программного продукта в териминах релеевского распределения персонала проекта во времени. Она поддерживает наиболее популярные методы измерения размера кода, в том числе и функциональные точки. Это позволяет использовать кривую для оценки графика проекта и его дефектов. Для изменения формы кривой используется коэффициент наращивания мощностей MBI (Manpower Buildup) и технологический коэффициент фактора продуктивности PF (Productivity factor). В программной реализации SLIM можно сохранять и анализировать информацию, полученную от других, завершенных проектов, и затем использовать ее для калибровки модели, или же если такая информация отсутствует, тогда пользователь может ответить на ряд наводящих вопросов, чтобы рассчитать значения MBI и PF на основе существующей базы данных.

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

Продуктивность рассчитывается по формуле:

P = -, E где P – продуктивность в единицах измерения программного кода на человеко месяц; S – размер программного продукта рассчитанный по одной из методик подсчета размера кода (функциональные точки, количество строк); E – объем усилий, направленных на разработку, оцениваемый в человека месяцах.

Кривая Рейлайха, которая используется для распределения усилий, моделируется выражением:

определения

_ 2

m (t) = 2 • K • a • t • e , где m(t) – коэффициент потребности в персонале в момент времени t; K – общие трудозатраты проекта в человека годах; a – фактор ускорения.

Фактор ускорения вычисляется по формуле:

a = —г, 2t2 d где td – время разработки.

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

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

C

K 1/3 +14/3 , где S – количество строк в программном обеспечении.

С – фактор среды, зависящий от технологии.

K – общие трудозатраты для всего проекта в чел.-годах.

t d – ограничения времени разработки программного продукта согласно графику.

Фактор среды вычисляется по формуле:

S

К1/3 , ,4/3 , K + td где коэффициенты K и td определяются на базе данных, полученных от старых проектов с размером S. Значение C калибруется и может применяться для последующих оценок.

Модель COCOMO , созданная Барри Боэмом, первоначально основывалась на результатах анализа 63 программных преоктов различных типов. При этом оценивался фактический размер кода, трудозатраты, а также фактическая длительность разработки.

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

–

органический режим,

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

Точность оценки зависит от уровня детализации, который может быть базовым (для выполнения оценки используется только значение размера кода и сведения о текущем режиме), промежуточным (добавляются значения 15 дополнительных переменных, которые получают оценку по 6-бальной шкале) и детализированным (добавляются дополнительные переменные).

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

E = a■Sb, где a и b – константы, определяемые на этапе регрессионного анализа (в зависимости от проекта); E – трудозатраты в чел.-мес; S – размер кода в тыс. строк.

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

Композиционные модели призваны объединить преимущества двух-трех методов оценки в единое целое, и тем самым увеличить точность расчетов.

С течением времени и ростом требованиям к системам, модель СОСОМО оказалась устаревшей в значительной своей части. Непосредственно по этой причине и ряд других немаловажных проблем, была разработана модель СОСОМО II , впервые опубликованная в 1999 году. [6]

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

COCOMO II использует модели композиции приложения (объектные указатели), раннего этапа проектирования и этапа пост-архитектуры. Они заменили базовый, промежуточный и детализированный этапы модели COCOMO . Модель композиции приложения позволяет брать в расчет современные методы разработки, например, такие, как создание прототипа. Поскольку при визуальной разработке оценка размера продукта с помощью строк кода не всегда является верной. Вместо этого в модели используются объектные указатели. Это количество экранных форм, отчетов, модулей, каждый из которых соотносится с одним из трех уровней – простой, средний и сложный в соответствии с уровнем сложности.[1]

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

Effort = A ■ Size, где Size – оценка размера форм, отчетов, компонентов и модулей будущей системы (каждый элемент оценивается с коэффициентом от 1 до 10 в зависимости от сложности),

A – коэффициент, который учитывает возможное повторное использование части компонентов и производительность разработки, зависящую от опыта команды разработчиков и применяемых инструментов и оценивается числом от 4 до 50.[6]

В таблице 1 приведен сравнительный анализ наиболее успешно применяемых моделей SLIM и COCOMO II [5].

Таблица 1 – сравнительный анализ моделей SLIM и COCOMO II

Группа факторов	Факторы	SLIM	COCOMO II
Атрибуты размера	Количество инструкций в коде	+	+
	Функциональные точки	+	+
	Объектно-ориентированные метрики	+	+
Атрибуты программы	Тип	+	-
	Сложность	+	+
	Язык	+	+
	Повторное использование	+	+
	Требуемая надежность	-	+
Атрибуты компьютера	Ограничение ресурсов	+	+
	Устойчивость платформы	-	+
Атрибуты персонала	Возможности персонала	+	+
	Текучесть кадров	-	+
	Опыт персонала	+	+
Атрибуты проекта	Инструментарий и техники	+	+
	Распределенность	+	+
	Ограничение расписания	+	+
	Зрелость проекта	+	+
	Сплоченность команды	+	+
	Запросы безопасности	-	-
	Множественная разработка	-	+
Этапы	Начало работ	+	+
	Уточнение требований	+	+
	Исполнение	+	+
	Сопровождение	+	+

По результатам анализа можно сделать вывод, что преимущество отдается модели COCOMO II . Среди ее сильных сторон можно выделить следующие:

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

• -    легка в использовании;

• -    поддерживает современный процесс разработки программного обеспечения;

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

Проведенный обзор моделей, позволяет сделать следующие выводы:

• 1.    Существующие методы и модели оценки стоимости описывают трудозатраты не различая явным образом затраты персонала компании

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

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

• 4.    При доработке системы не учитывается сложность ее архитектуры, и глубина доработки. Современные сложные программные комплексы имеют большую иерархическую программную архитектуру, и учет этого фактора является очень важным, так как в сложных системах доработка одного программного компонента, обязательно влечет изменения других, связанных с ним компонентах.

• 5.    Информация, необходимая для расчета многих параметров, может отсутствовать на ранних этапах проекта, а их предполагаемая оценка может быть ошибочной.

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

Следовательно необходима разработка методики оценки трудозатрат на модернизацию уже существующего программного продукта.

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