Расчёт экономико-параметрических моделей Демарко в программном проекте

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

До сих пор не существует методики, дающей абсолютно точный результат, поэтому используются различные приближённые методы оценки [1-2]. Один из таких методов был разработан американским инженером-программистом Томом ДеМарко. Его метод основывается на эмпирических данных, т. е. на прошлом опыте разработки программного обеспечения (ПО): «Опытный менеджер скажет, что лучший способ узнать длину пути – это пройти его» [3].

Дать оценку стоимости программного проекта очень сложно, так как она состоит из множества элементов, каждый из которых необходимо учитывать. Одним из таких важных элементов является качество. Качество подразделяется на внешнее – способность удовлетворить потребности конечного пользователя, и внутреннее – удобство и простота реализации для разработчиков. Важными показателями качества являются следующие принципы: ясность и измеримость значений, функциональная пригодность, надёжность, применимость, эффективность, сопровождаемость продукта и его переносимость [4-6]. Кроме того, при оценке стоимости программного обеспечения, следует учитывать конкуренцию, т. к. заказчика может не устроить стоимость разработки или её сроки при наличии альтернативного разработчика. Это влечёт за собой дополнительные траты [7]. Ещё три параметра, которые используются для оценки проекта по разработке программного обеспечения: стоимость аппаратных средств и ПО, расходы на командировки и обучения персонала и расходы на сам персонал [8].

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

Функциональные точки – это метод измерения размера программного продукта с точки зрения пользователя системы. Метод предназначен для оценки трудоёмкости на основе логической модели объёма программного продукта измеренного количеством функционала, востребованного заказчиком и поставляемого разработчиком [9-10]. Важной особенностью метода является то, что измерения не зависят от технологической платформы, на которой разрабатывается продукт, и все проекты компании оцениваются одним подходом [11].

Теперь же определим, что такое «bang-метрика». «Bang-метрика» – это независимая от реализации индикация размера системы. Она, так же как и метод функциональных точек, даёт оценку трудоёмкости программного продукта. Согласно этому методу, инженер-программист должен сначала оценить набор примитивов – элементов модели анализа, которые далее не подразделяются на уровни анализа.

Примитивы «bang-метрики»:

• 1.    FP (Functional primitives) – количество функциональных примитивов, лежащих внутри границы человек-машина;

• 2.    FMP (Modified manual function primitives) – количество модифицированных ручных функциональных примитивов (функции, лежащие вне границы человек-машина, которые необходимо изменить для установки новой автоматизированной системы);

• 3.    DE (Data Elements) – количество всех элементов данных;

• 4.    DEI (Input data elements) – количество всех входных элементов данных;

• 5.    DEO (Output data elements) – количество всех выходных элементов данных;

• 6.    DER (Retained data elements) – количество элементов данных сохраненных (хранимых) в автоматизированной форме;

• 7.    OB (Objects) – количество объектов в модели данных;

• 8.    RE (Relationships) – количество соединений в модели данных;

• 9.    ST (States) – количество состояний в модели перехода состояния;

• 10.    TR (Transitions) – количество переходов в модели перехода;

• 11.    Tci (Data tokens) – количество токенов данных вокруг границы i-го функционального примитива (оценивается для каждого примитива), токен – это элемент данных, который не должен подразделяться на примитивы;

• 12.    REi (Relationship connections) – количество соединений, связанных с i-ым объектом модели сохраненных данных (оценивается для каждого объекта).

Затем, ДеМарко предполагает, что большинство программ может быть отнесено к одному из двух доменов: function-strong или data-strong. Домен определяется отношением RE к FP. Для function-strong RE/FP<0.7, для data-strong RE/FP>1.4, также существует смешанный тип приложений 0.7

Основным компонентом bang-метрики для приложений типа function-strong является FP. Однако некоторые функции стоят дороже, чем другие. Вариации существуют как по размеру, так и по сложности, которые должны быть скорректированы в модели. Выходные (скорректированные) токены генерируются из входных токенов в каждом преобразовании с помощью формулы:

CFPI = Tci × log2 (Tci) / 2

Где CFPI – скорректированное приращение FP; Tci – количество токенов данных вокруг границы i-го функционального примитива.

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

Большая часть усилий приложений типа data-strong распределяется по задачам, связанным с реализацией самой базы данных. Наиболее очевидным примитивным подсчетом для базового анализа измерений является OB. Для каждого объекта подсчитывается и корректируется значение REi. Корректировки требуются для учета различных затрат на реализацию различных объектов. Они приведены в таблице 3.

Таблица 1 Взвешивание данных для коррекции размера функциональных примитивов

Таблица 2

Классы функций и весовые коэффициенты

Таблица 3

Соотношение взвешенных объектов

После того как мы определили к какому типу относится приложение, подсчитываем цену. Для каждого типа приложения есть свой алгоритм.

Алгоритм 1: Вычисление стоимости для приложений типа Function-strong. Установить начальное значение FUNCTIONBANG = 0 затем для каждого FP:

• 1.    Вычислить количество TCi;

• 2.    Определить CFPI по таблице 1;

• 3.    Определить класс примитва;

• 4.    Умножить CFPI на соответствующий вес (класса);

• 5.    Прибавить получившееся произведение к FUNCTIONBANG.

Алгоритм 2: Вычисления стоимости для приложений типа Data-strong и для смешанных. Приравнять начальное значение DATABANG = 0, затем для каждого OB:

• 1.    Вычислить REi;

• 2.    Определить COBI из таблицы 3;

• 3.    Прибавить COBI к DATABANG [11, 12].

Приведём пример, в котором мы оценим стоимость проекта. Пусть в нашем проекте будет 2 соединения [RE] и 3 функциональных примитива [FP]. Определим, к какому типу относится приложение, вычислив отношение количества соединений к количеству функциональных примитивов. Как говорилось раннее если RE/FuP<0.7, это приложение типа function-strong. Тогда используем соответствующий алгоритм, в нашем случае – это первый алгоритм. Вычислим количество токенов (TCi) для каждого функционального примитива (пусть будет 5, 10 и 8). Определяем CFPI по таблице (5.8, 16.6 и 12.0). Определяем классы примитивов (пусть будет простое обновление, арифметические операции и проверка) и определяем вес каждого примит-ва (0.5, 0.7 и 1). Умножаем CFPI на соответствующие веса (5.8 × 0.5, 0.7 × 16.6 и 1 × 12.0) и получившиеся произведения (2.9, 11.62 и 12) складываем. Получившийся результат – это оценка стоимости проекта (2.9 + 11.62 + 12 = 26.52).

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