Оценка программного обеспечения

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

• доходный (Income Approach);
• сравнительный (Market Approach);
• затратный (Asset Based Approach).

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

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

Классификация методов оценки ПО

Особенность разработки программного обеспечения заключается в большой доле трудозатрат. В связи с этим в процессе оценки важную роль играет показатель трудоемкости. По расчетам стоимости программ существует большое количество исследований. Большой вклад в развитие данного направления внес американский профессор Барри Боэм (Barry Boehm). Ученый классифицировал основные алгоритмы определения затрат, представив несколько методов:

• экспертных оценок;
• аналогий;
• исследовательские и эмпирические;
• алгоритмического моделирования;
• динамические;
• функциональных точек;
• имитационного моделирования;
• математическая модель SLIM (Software Life-cycle Model);
• нейронные сети;
• байесовские сети;
• COCOMO (COnstructive COst MOdel);
• оценка для получения контракта. 

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

Метод экспертных оценок

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

Метод аналогий

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

Исследовательские и эмпирические методы

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

Метод алгоритмического моделирования

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

Динамические методы

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

Метод функциональных точек

Метод фокусируется на так называемых «функциональных точках», представляющих собой единицы измерения объема функциональности, которую продукт предоставляет пользователю. Система расчета стоимости разработок с точки зрения пользователя была выдвинута Аланом Альбрехтом в 70-х годах прошлого столетия. В число параметров включены количественные показатели входов/выходов и запросов пользователя, файлов, внешних интерфейсов.

Метод имитационного моделирования

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

Математическая модель SLIM

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

Нейронные сети

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

Байесовские сети

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

COCOMO (COnstructive COst MOdel)

Конструктивная модель стоимости задает определенный алгоритм взаимосвязи между размером кода программы и трудозатратами. Создателем модели является Б. Боэм.

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

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

Основные методы оценки стоимости программного продукта

Для определения стоимости ПО во всем мире используют классические методики: функциональных точек и COCOMO II. 

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

Американский инженер Барри Боэм во второй половине прошлого века предложил систему оценки объемов трудозатрат при проектировании программного обеспечения. Алгоритм был назван COCOMO – конструктивная модель стоимости (COnstructive COst MOdel). Система получила широкое распространение, поскольку ее можно применять на любом этапе разработки ПО. Ученый проанализировал большое количество разработок, выполненных по заказу американских военных, и вывел закономерность, которая определяет взаимосвязь между размером продукта, его классом и трудозатратами.

В системе COCOMO разрабатываемые проекты делятся условно на три класса:

• Ограниченные. К ним относятся небольшие по размеру проекты, к которым предъявляются не очень жесткие требования. Продукт может быть произведен любым IT-инженером или малой компанией.
• Полуинтегрированные. Продукт имеет средний размер с четкими требованиями и может быть выполнен группой производителей ПО с различным опытом работы.
• «Встроенные системы». К подобным программам предъявляются жесткие требования по спецификации. Продукт производится со значительными ограничениями и отличается повышенной надежностью и безопасностью.

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

Количество поправочных факторов, которые учитываются при использовании COCOMO, охватывает 15 пунктов. Они группируются по четырем категориям, оцениваемым по шкале в 6 баллов:

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

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

В семидесятых годах прошлого века Аланом Альбрехтом была разработана система оценки по функциональным точкам. Методика позволяет оценить программный продукт без учета величины системы, то есть количества логических строк в коде. Ученый сосредоточился на проектировании механизма усилий, связанных с разработкой программного обеспечения.

Несмотря на то, что первые результаты после публикации были высоко оценены компаниями-разработчиками, Альбрехт продолжил деятельность по усовершенствованию методики. Ученый представил несколько ревизионных методик.

Многие страны и компании взяли на вооружение методику расчета по функциональным точкам. Например, этот метод используется в Великобритании как национальный стандарт. Автором системы, названной Mark II FPA, является Ч. Саймон. Исследователь внес значительные изменения и улучшения в исходную версию метода. Он ввел современную терминологию и применил понятие «транзакция», обладающую входом, обработкой и выходом.

Аналогичные, но более узкие системы предложили и другие разработчики:

• Feature Points, предложенная К. Джонсом, более точно оценивает размеры сложных систем;
• 3D Points, представленная авиационным гигантом «Боинг».

По прошествии времени появились новые требования к системам, и алгоритм COCOMO стал устаревать. В конце XX века в методику были внесены изменения, и появилась система COCOMO II. Основными новшествами, введенными в метод, являются:

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

Система функциональных точек в услуге по оценке стоимости программного продукта

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

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

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

Число входов учитывается за определенный период времени.

Алгоритм дает возможность определить издержки. Данные рассчитываются, исходя из размеров затрат на увеличение ФТ на единицу. Рост маргинальных издержек происходит в связи с возрастанием размера проекта, поскольку при этом происходит:

• увеличение сложности;
• рост числа задач, нуждающихся в завершении;
• затруднение управления в связи с большим количеством разработчиков.

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

где Ci – воздействие каждого параметра системы.

На сегодняшний день выделено 14 параметров:

1. количество связей, применяемых для транспортировки информации внутри системы;
2. способы обработки распределенных данных;
3. требования к продуктивности;
4. требования к аппаратным элементам;
5. частота осуществления транзакций;
6. количество данных, вводимых онлайн (в процентном сооотношении);
7. эффективность для пользователя;
8. количество ILF, обновляемых онлайн;
9. применение сложной математической обработки;
10. число пользователей программой;
11. сложность архитектуры;
12. эффективность старта, копирования, воспроизведения;
13. учет количества пользователей и организаций;
14. возможность внесения дальнейших изменений в приложение.

Каждый пункт оценивается по шкале в 5 баллов:

FP = UAF VAF

В уравнении применяются обозначения:

• FP – финальное число ФТ
• UAF – число ФТ без учета подстройки
• VAF – коэффициент подстройки

Другая используемая формула представлена следующим образом:

UAF = EI + EO + EQ + ILF + EIF

В ней учитываются внешние параметры:

• EI – входящие потоки;
• EO – исходящие потоки;
• EQ – запросы;
• EIF – файлы интерфейса,

а также один внутренний показатель:

• ILF – логические файлы.

Рассчитать оценку разработки с помощью предварительной обработки данных можно по формуле:

DFP = (UFP + CFP) VAF, где

• DFP – число ФТ разработки;
• UFP – число ФТ без учета подстройки;
• CFP – число ФТ, присоединенных для обработки других ФТ;
• VAF – коэффициент подстройки.

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

EFP = [(ADD + CHGA + CFP)-VAFA] + (DEL VAFB)

Показатели, используемые в формуле:

• EFP – число ФТ без подстройки, присоединенные по добавленным требованиям;
• ADD – число ФТ без учета подстройки;
• CHGA – число ФТ, измененных по добавочным требованиям и без подстройки; /p>
• CFP – число ФТ без подстройки, прибавленных после изменений (обычно этот показатель равен 0);
• VAFA – коэффициент подстройки после введения добавочных требований;
• DEL – число ФТ, удаленных после внесения изменений;
• VAFB – коэффициент подстройки, установленный до введения добавочных требований. 

Если вас заинтересовали услуги нашей компании, звоните. Наш специалист ответит на все интересующие вас вопросы и поможет оставить заявку.

Вопрос-ответ

Стоимость услуг

Прайс на выполнение проекта
Оценка программного обеспечения	30000 Р	заказать

Необходимые документы

Для чего нужна оценка интеллектуальной собственности (ОИС)

Наши партнеры

Наши клиенты

В нашей базе более 5000 довольных клиентов