ГлавнаяРазноеОценка стоимости программного обеспечения

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


Глава 6. Оценка стоимости программного продукта

Рассматривается проблема оценки затрат и времени, необходимых для выполнения определенных этапов проекта.

Менеджерам необходимо получить ответы на следующие вопросы.

−Какие затраты необходимы для выполнения этапа?

−Сколько это займет времени?

−Какова стоимость выполнения данного этапа?

Этапы расчета оценки стоимости:

−Предварительные расчеты должны быть выполнены на ранней стадии для утверждения бюджета.

−Во время выполнения проекта все расчеты должны регулярно обновляться. Это помогает планировать работу и содействует эффективному использованию средств.

Цена продукта включает:

−издержки производства;

−предлагаемую прибыль Параметры, используемые для оценки проекта:

−Стоимость аппаратных средств и программного обеспечения, включая их обслуживание.

−Расходы на командировки и обучение.

−Расходы на персонал (в основном на привлечение со стороны специалистов по программному обеспечению), включающие:

−расходы на содержание, отопление и освещение офисов;

−на содержание вспомогательного персоналабухгалтеров, секретарей, уборщиц и технического персонала;

−на содержание компьютерной сети и средств связи;

−на централизованные услуги - библиотеки, места отдыха и развлечения и т.д.;

−на социальное обеспечение и выплаты служащим (например, пенсии и медицинская страховка).

Таблица 20 - Факторы, влияющие на стоимость программного продукта

Фактор

 

Описание

 

 

 

 

 

 

 

 

Возможности рынка ПО

Организация-разработчикможет выставить

 

 

низкие цены на программный продукт из-за

 

намерения переместиться в другой сегмент

 

рынка ПО, что в будущем может привести к

 

более высоким доходам.

 

 

 

 

 

 

 

 

 

Непредвиденные факторы

Если организация примет фиксированную

 

 

величину

стоимости,

издержки

 

производства

могут

возрасти

из-за

 

непредвиденных расходов

 

 

 

 

 

 

 

 

Условия контракта

Если, например, право на владение

 

 

программным

кодом

после

завершения

 

проекта передано заказчику, то проект

 

стоит дороже.

 

 

 

 

 

 

 

 

 

 

Изменение требований

После заключения контракта за изменение

 

 

требований

можно

назначить

 

дополнительную цену

 

 

 

 

 

 

 

 

 

Финансовая стабильность

Во избежание банкротства

фирмы,

 

 

 

 

 

 

 

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

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

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

−Функциональный показатель. Зависит от функциональных возможностей программного продукта в целом, например, количество функциональных и объектных точек.

Показатель размера

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

Функциональный показатель

Для определения можно воспользоваться методом функциональных точек. Критерием оценки производительности выступает количество функциональных точек, созданных за человеко-месяц.Функциональная точка — это комбинация свойств ПО:

−Интенсивности использования ввода и вывода внешних данных.

−Взаимодействия системы с пользователем.

−Внешних интерфейсов.

−Файлов, используемых системой.

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

UFC = 2 (количество элементов данного типа) х (весовая величина).

Для определения можно воспользоваться методом объектных точек.

Количество объектных точек в программе можно получить путем предварительного подсчета ряда элементов:

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

−Количество представленных отчетов. Для простых отчетов назначаются 2 точки, умеренно сложным отчетам назначаются 5 точек. Написание сложных отчетов оценивается в 8 точек.

−Каждый модуль на языке третьего поколения считается за 10 объектных точек.

Производительность программиста

Самым важным фактором являются индивидуальные способности.

Таблица 21 - Факторы, влияющие на производительность программиста

Фактор

Описание

 

 

Опыт разработки ПО для

Для эффективной разработки программного

 

 

предметной области

продукта необходимо знание той предметной

 

области, где будет эксплуатироваться области

 

разрабатываемое ПО.

 

 

Процесс управления

Применяемый метод программирования может

качеством

оказать существенное влияние на

 

производительность написания кода.

 

 

Размер проекта

Чем больше проект, тем больше времени уходит

 

на согласование различных вопросов внутри

 

группы разработчиков и ниже

 

производительность.

 

 

Поддержка технологии

Хорошая поддержка технологии разработки ПО,

разработки ПО

например CASE-средстваили системы

 

управления конфигурацией, может значительно

 

повысить производительность труда

 

программиста

 

 

Рабочая обстановка

Спокойное рабочее окружение с

 

индивидуальными рабочими местами

 

способствует повышению производительности

 

 

Основная проблема в оценке себестоимости проектов заключается в низкой точности применяемых методов оценивания.

Таблица 22 – Методы оценки стоимости ПО

Метод

Описание

 

 

Алгоритмическое

Метод основан на анализе статистических

моделирование

данных о ранее выполненных проектах, при этом

себестоимости

определяется зависимость себестоимости

 

проекта от какого-нибудьколичественного

 

показателя программного продукта (обычно это

 

 

размер программного кода).

Оценка эксперта

Проводится опрос нескольких экспертов по

 

технологии разработки ПО, знающих область

 

применения создаваемого программного

 

продукта.

 

 

Оценка по аналогии

Проект оценивается по уже реализованным

 

аналогичным проектам.

 

 

Закон Паркинсона

Усилия, затраченные на работу, распределяются

 

равномерно по выделенному на проект времени.

 

Здесь критерием для оценки затрат по проекту

 

являются человеческие ресурсы, а не целевая

 

оценка самого программного продукта.

 

 

Назначение цены с целью

Затраты на проект определяются наличием тех

выиграть контракт

средств, которые имеются у заказчика. Поэтому

 

себестоимость проекта зависит от бюджета

 

заказчика, а не от функциональных

 

характеристик создаваемого продукта.

 

 

Предварительная оценка может выполняться с применением нисходящего и восходящего подходов:

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

−Восходящий подход начинается на уровне системных компонентов. Система разбивается на компоненты и определяются затраты на разработку каждого из них. Затем эти

studfiles.net

Оценка стоимости прав на программное обеспечения | Info-Comp.ru

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

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

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

Чаще всего это "исключительное право" на программу. Исключительное право - это имущественное право, которое позволяет правообладателю производить с программой множество действий: использовать, распоряжаться, передавать "не исключительное право" иным лицам (например, право использования по пользовательской лицензии), вносить правки в код - словом относиться к программе, как своей собственности. Но не нужно путать "исключительное право" с "авторским правом". Авторское право - это право называться автором того или иного произведения или объекта интеллектуальной собственности. Автор и обладатель "исключительного права" могут быть разными лицами. Например, если Вы работаете в компании и создали программу в порядке исполнения своих рабочих обязанностей, то Вы - автор, а правообладатель - компания, если в Вашем трудовом договоре не предусмотрено иное. Авторское право нельзя оценить потому, что его нельзя никому передать, оно не отчуждаемо, автор - Вы, и это навсегда.

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

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

Тем, кто заинтересовался вопросами оценки стоимости интеллектуальной собственности мы советуем посетить указанную страницу в интернете.

info-comp.ru

Оценка стоимости программного продукта — МегаЛекции

 

Цели

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

q знать, как оценивается себестоимость и назначается цена программного продукта, и понимать сложные взаимосвязи между этими двумя процессами;

q знать три системы оценивания производства программного продукта;

q понимать, что для правильной оценки стоимости ПО и для создания графика работ необходимо применять широкий спектр различных методов оценки стоимости программного продукта;

q знать принципы работы модели СОСОМО 2 для алгоритмической оценки стоимости.

 

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

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

 

1. Какие затраты необходимы для выполнения этапа?

2. Сколько это займет времени?

3. Какова стоимость выполнения данного этапа?

 

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

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

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

 

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

• Расходы на командировки и обучение.

• Расходы на персонал, в основном на привлечение со стороны специалистов по программному обеспечению.

 

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

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

 

1. Расходы на содержание, отопление и освещение офисов.

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

3. Расходы на содержание компьютерной сети и средств связи.

4. Расходы на централизованные услуги – библиотеки, места отдыха и развлечения и т.д.

5. Расходы на социальное обеспечение и выплаты служащим (например, пенсии и медицинская страховка).

 

Обычно накладные расходы приравниваются к удвоенной зарплате программиста, в зависимости от размера компании и расходов на ее содержание. Например, если специалист по программному обеспечению получает 90 000 долларов в год, расходы организации на этот год составляют сумму 180 000 долларов, или 15 000 долларов в месяц.

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

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

Таблица 23.1. Факторы, влияющие на стоимость программного продукта

 

Фактор Описание
Возможности рынка ПО Организация-разработчик может выставить низкие цены на программный продукт из-за намерения переместиться в другой сегмент рынка ПО. Даже если организация примет более низкую прибыль в первом проекте, это все равно может привести к более высоким доходам в будущем, поскольку полученный опыт позволит заниматься разработкой подобных программных продуктов и в дальнейшем  
Невозможно учесть все факторы, влияющие на стоимость   Если организация примет фиксированную величину стоимости, издержки производства могут возрасти из-за непредвиденных расходов
Условия контракта Заказчик может позволить разработчику сохранить за собой право владения программным кодом с последующим его использованием в других проектах. При этом назначенная цена может быть ниже, чем в том случае, если право на программный код передано заказчику  
Изменение требований При изменении требований к ПО организация может снизить цену с тем, чтобы выиграть контракт. Если контракт уже заключен, за изменение требований можно назначить дополнительную цену  
Финансовая стабильность Фирмы, испытывающие финансовые затруднения, для получения заказа могут снизить цены на свои разработки. Как правило, лучше сегодня получить более низкую прибыль или даже работать на уровне самоокупаемости, чем обанкротиться в будущем

Производительность

 

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

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

 

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

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

 

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

Данный подход впервые появился еще во время массового использования таких языков программирования, как FORTRAN, язык ассемблера и COBOL. Затем программы переводились на перфокарты, каждая из которых содержала по одному оператору. Таким образом, было легко подсчитывать количество строк кода. Оно соответствовало количеству перфокарт в колоде. Однако программы, написанные на языках типа Java или C++, состоят из описаний, выполняемых операторов и комментариев. Они также могут включать макрокоманды, которые состоят из нескольких строк кода. С другой стороны, в одной строке может находиться не один, а несколько операторов. Таким образом, соотношения между операторами и строками в листинге могут быть достаточно сложными.

Одни методы подсчета строк основываются только на выполняемых операторах; другие подсчитывают выполняемые операторы и объявления данных; третьи ведут подсчет всех строк программы, независимо от их содержимого. Были предложены определенные стандарты подсчета строк в различных языках программирования [269], однако они не приобрели широкой популярности. Поэтому практически невозможно сравнивать производительность различных компаний-разработчиков, если только все они не используют один и тот же метод подсчета строк кода.

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

Для примера возьмем систему, которая должна быть написана с помощью кода ассемблера (5000 строк) или с помощью языка высокого уровня (1500 строк). Время выполнения различных этапов создания ПО показано в табл. 23.2. Специалист, программирующий на языке ассемблера, будет иметь производительность 714 строк в месяц, а у программиста, работающего с языком высокого уровня, производительность будет в два раза ниже – 300 строк в месяц. И это несмотря на то, что программирование на языке высокого уровня стоит дешевле и занимает меньше времени.

Таблица 23.2. Время выполнения этапов разработки программной системы

 

  Анализ (недели) Проектирование (недели) Кодирование (недели) Тестирование (недели) Документирование (недели)
Язык ассемблера  
Язык высокого уровня  
  Размер (строки кода) Затраченное время (недели) Производительность (строк в месяц)
Язык ассемблера  
Язык высокого уровня
             

 

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

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

 

• Интенсивность использования ввода и вывода внешних данных.

• Взаимодействие системы с пользователем.

• Внешние интерфейсы.

• Файлы, используемые системой.

 

Сложность каждого из указанных критериев оценивается отдельно, в результате каждому критерию присваивается определенная весовая величина, которая может колебаться от 3 (для простого ввода данных) до 15 баллов за использование сложных внутренних файлов. Можно использовать весовые величины, предложенные в статье [7], или величины, основанные наличном опыте.

Нескорректированный подсчет функциональных точек (unadjusted function-point count – UFC) выполняется путем вычисления суммы произведений оценки каждого фактора (количество элементов, составляющих данный фактор) на выбранную весовую величину этого фактора:

 

UFC = ∑ (количество элементов данного типа) х (весовая величина).

 

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

Вместе с тем в [330] отмечено, что оценка сложности несет в себе также и субъективный фактор, так как подсчет функциональных точек зависит от лица, проводящего оценивание. Люди имеют разные понятия о сложности. Так как подсчет функциональных точек зависит от мнения оценивающего, существует множество вариаций подсчета функциональных точек. Это приводит к разным взглядам на значимость функциональных точек [122]. Однако многие заявляют, что, несмотря на все недостатки, на практике этот метод себя оправдывает [196].

Альтернативой функциональным точкам являются объектные точки [19], особенно если при разработке ПО используется язык программирования четвертого поколения. Метод объектных точек применяется в модели оценивания СОСОМО 2, которая рассматривается далее в главе. (Объектные точки – это отнюдь не классы объектов, которые производятся в результате применения объектно-ориентированного подхода в работе над программой, что можно было бы предположить, исходя из названия.) Количество объектных точек в программе можно получить путем предварительного подсчета ряда элементов.

 

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

2. Количество представленных отчетов. Для простых отчетов назначаются 2 объектные точки, умеренно сложным отчетам назначаются 5 точек. Написание сложных отчетов оценивается в 8 точек.

3. Количество модулей, которые написаны на языках третьего поколения и разработаны в дополнение к коду, написанному на языке программирования четвертого поколения. Каждый модуль на языке третьего поколения считается за 10 объектных точек.

 

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

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

Подсчет функциональных точек можно проводить параллельно с методом подсчета количества строк кода. Количество функциональных точек при этом используется для оценивания окончательной величины кода. На основе анализа выполнения предыдущих программных проектов для определенных языков программирования можно оценить среднее количество строк кода (average number of lines of code – AVC), необходимых для реализации одной функциональной точки. В этом случае получим оценку размер кода нового проекта, рассчитанную следующим образом:

 

размер кода = AVC x количество функциональных точек.

 

Значение AVC варьируется от 200 до 300 строк кода на одну функциональную точку в языке ассемблера и от 2 до 40 строк кода для языков программирования четвертого поколения.

Производительность отдельных программистов, работающих в организации-разработчике, зависит от множества факторов, влияющих на их работу. Некоторые из наиболее значимых факторов представлены в табл. 23.3. Однако различия в индивидуальных способностях программистов намного важнее всех этих факторов. В исследовании ранних этапов программирования [305] отмечено, что производительность некоторых программистов в 10 раз выше, чем у других. Это наблюдение подтверждается и моим личным опытом. Большие команды, члены которых имеют необходимый набор личностных качеств и способностей, будут иметь "среднюю" производительность. Вместе с тем в командах небольшого размера общая производительность во многом зависит от индивидуальных умений и навыков каждого члена команды.

Таблица 23.3. Факторы, влияющие на производительность программиста

 

Фактор Описание
Опыт разработки ПО для данной предметной области Для эффективной разработки программного продукта необходимо знание той предметной области, где будет эксплуатироваться разрабатываемое ПО. Инженеры, имеющие понятие об этой предметной области, выявят наивысшую производительность  
Процесс управления качеством Применяемый метод программирования может оказать существенное влияние на производительность написания кода. Этот фактор рассматривается в главе 25  
Размер проекта Чем больше проект, тем больше времени уходит на согласование различных вопросов внутри группы разработчиков. Тем самым уменьшается время, расходуемое непосредственно на разработку ПО, и снижается производительность  
Поддержка технологии разработки ПО Хорошая поддержка технологии разработки ПО, например CASE-средства или системы управления конфигурацией, может значительно повысить производительность труда программиста  
Рабочая обстановка Как уже упоминалось в главе 22, спокойное рабочее окружение с индивидуальными рабочими местами способствует повышению производительности

 

Должен отметить, что не существует какой-либо величины, определяющей "среднюю" производительность программиста, которую можно было бы применять в разных организациях и при создании разных программных продуктов. Например, при разработке больших систем производительность может быть очень низкой и доходить до 30 строк за человеко-месяц. На простых программных системах производительность может подняться до 900 строк в месяц. В [44] высказано предположение, что производительность программиста может колебаться от 4 до 50 объектных точек в месяц, в зависимости от наличия средств поддержки и от способностей программиста.

Недостатком оценок, которые основываются на подсчете объема выполненной работы или определении количества затраченного времени, является то, что они не принимают во внимание такие важные нефункциональные свойства разрабатываемой системы, как надежность, удобство эксплуатации и т.п. Обычно здесь работает простое правило: больше – значит, лучше. Бек (Beck, [32]) приводит удачное замечание, что если вы работаете над постоянным усовершенствованием и упрощением системы, то подсчет строк ничего не даст.

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

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

Методы оценивания

 

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

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

Несмотря ни на что, организации-разработчики обязательно должны оценивать затраты на разработку и себестоимость программного продукта. Для этого можно применять методы, описанные в табл. 23.4 [46].

Таблица 23.4. Методы оценки себестоимости

 

Метод Описание
Алгоритмическое моделирование себестоимости Метод основан на анализе статистических данных о ранее выполненных проектах, при этом определяется зависимость себестоимости проекта от какого-нибудь количественного показателя програ.ммного продукта (обычно это размер программного кода). Проводится оценка этого показателя для данного проекта, после чего с помощью модели прогнозируются будущие затраты  
Оценка эксперта Проводится опрос нескольких экспертов по технологии разработки ПО, знающих область применения создаваемого программного продукта. Каждый из них дает свою оценку себестоимости проекта. Потом все оценки сравниваются и обсуждаются. Этот процесс повторяется до тех пор, пока не будет достигнуто согласие по окончательному варианту предварительной сметы проекта  
Оценка по аналогии Этот метод используется в том случае, если в данной области применения создаваемого ПО уже реализованы аналогичные проекты. В таком случае при оценке затрат для сравнения берутся предыдущие проекты. В книге [251] дано достаточно ясное описание этого метода  
Закон Паркинсона Согласно этому закону усилия, затраченные на работу, распределяются равномерно по выделенному на проект времени. Здесь критерием для оценки затрат по проекту являются человеческие ресурсы, а не целевая оценка самого программного продукта. Если проект, над которым работает пять человек, должен быть закончен в течение 12 месяцев, то затраты на его выполнение исчисляются в 60 человеко-месяцев  
Назначение цены с целью выиграть контракт Затраты на проект определяются наличием тех средств, которые имеются у заказчика. Поэтому себестоимость проекта зависит от бюджета заказчика, а не от функциональных характеристик создаваемого продукта

 

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

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

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

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

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

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

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

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

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

 

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

• Применение систем типа клиент/сервер вместо систем, основанных на мэйнфреймах.

• Применение готовых коммерческих пакетов программного обеспечения вместо собственной разработки компонентов системы.

• Повторное использование компонентов системы вместо новых разработок.

• Использование CASE-средств и генераторов программ вместо разработки ПО без применения средств поддержки.

 

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

Рекомендуемые страницы:

Читайте также:

Воспользуйтесь поиском по сайту:

megalektsii.ru

7. Технико-экономические аспекты создания программного обеспечения вс. Оценка стоимости программной разработки.

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

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

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

1. Человеческий фактор, связан с опытом и знаниями компании которая занимается разработкой ПО;

2. Ресурсные факторы, характеризующие наличие ресурсов для разработки программных продуктов;

3. Проблемный фактор, определяемый сложностью проблемы которая должна быть решена;

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

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

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

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

■ откладывайте оценку на более поздний срок:

■ используйте для оценки простые методы декомпозиции:

■ разрабатывайте и используйте эмпирические модели для оценки стоимости и усилий:

■ приобретайте и используйте одно или несколько автоматизированных средств для получения оценок.

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

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

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

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

Методы функциональной декомпозиции

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

На практике широко используются оценки, основанные на размере программного продукта числе строк кода. (LOC lines of code.) Данные о числе строк кода при оценке проекта программного изделия используются:

■ как оценочные переменные для разрабатываемого проекта;

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

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

После получения LOC-оценок по каждому функциональному блоку проекта необходимо обратиться к базовым оценкам производительности труда и удельной стоимости проектирования и разработки одной строки кода полученным для предыдущих разработок.

Можно применить два различных подхода:

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

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

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

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

■ неадекватного понимания сферы применения проекта или неправильной ин-терпретации границ его использования;

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

В этом случае необходимо выявить причину расхождения оценок и провести повторные расчеты.

studfiles.net

Управление качеством программного обеспечения

«Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию»

Второй закон Вейлера

 

Общую проблему обеспечения качества ПС можно подразделить на следующую группу задач:

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

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

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

- создание совокупности методов и средств правового и организационно-экономического обеспечения гарантий необходимого качества программ на всех этапах ЖЦ.

Чтобы выполнить эти задачи необходимо создавать отчеты об ошибках, трассировка и процессы корректирующих действий. Для этой цели используется специальное программное обеспечение класса BTS (Bug Tracking System). BTS — это программные продукты, основанные на использовании базы данных и контролирующие все этапы жизненного цикла ошибок в ПО: от инициализации до момента исправления. Конечная цель BTS – улучшение менеджмента разработки программных продуктов.

Формализация показателей качества выполняется на основе базовой номенклатуры характеристик, субхарактеристик и атрибутов стандартизованных в международном стандарте ISO 9126:1991 (ГОСТ Р ИСO/МЭК 9126-91) «Информационная технология. Оценка программного продукта».

Рекомендуется 6 основных характеристик качества ПС, каждая из которых детализуется несколькими (21) субхарактеристиками:

- функциональная пригодность;

- надежность;

- применимость;

- эффективность;

- сопровождаемость;

- переносимость.

 

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

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

Алгоритмические модели

Экспертные оценки

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

Закон Паркинсона

Метод конкурентных цен

Оценивание методом сверху вниз

Оценивание методом снизу вверх

Алгоритмические модели

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

- линейные модели;

- мультипликативные модели;

- аналитические модели;

- табличные модели;

- комбинированные модели.

Линейные модели

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

Затраты= a0+a1x1+a2x2+…+anxn, где

 

x1, x2, xn – переменные стоимостных факторов,

a0, a1, a2,..., an – последовательность коэффициентов, полученных при оценке завершенных проектов

Мультипликативные модели

Оценка стоимости программного обеспечения по мультипликативным моделями представляется в виде:

Затраты= a0*a1x1*a2x2*…*anxn, где

 

x1, x2, xn – переменные стоимостных факторов,

a0, a1, a2,..., an – последовательность коэффициентов, полученных при оценке завершенных проектов

 

Мультипликативные модели работают недостаточно точно, если факторы слабо зависимы, иначе возникает двойной учет одного и того же фактора.

Экспертные оценки

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

Выделяют коллективные экспертные оценки и индивидуальные экспертные оценки.

Различают также опрос экспертов в их взаимодействии и без их взаимодействия.

К опросам экспертов во взаимодействии относятся:

- мозговая атака (brainstorming, brainstorm method) ;

- метод сценариев;

- метод комиссий;

- метод докладных записок.

К опросам экспертов без взаимодействия относятся:

- метод анонимной аргументации;

- метод итерации;

- метод Делфи;

- паттерн;

- прогнозный граф;

- процедура «Жан».

Метод Делфи

Метод Делфи (Delphi method (technique, procedure) Computer Based Delphi Process) разработан в 50-х годах двадцатого века. Разработчиком данного метода является Олаф Хелмер (Olaf Helmer) Норман Делки (Norman Dalkey).

Особенности метода Делфи:

- анонимность процедуры;

- возможность пополнения информации о предмете экспертизы;

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

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

В первом туре объясняется цель экспертизы и формулируются вопросы, ответы на которые составляют основное содержание экспертизы.

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

Информация от экспертов поступает в аналитическую группу.

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

После этого эксперты корректируют свое мнение.

Третий и четвертый туры подобны второму.

Характерная особенность данного метода ‑ возрастающая согласованность экспертной оценки.

Аналитические модели

Оценки стоимости затрат в таких моделях имеет вид:

Затраты: f(x1, x2, …, xn), где

x1, x2, …, xn – переменные стоимостных факторов

f – некоторая математическая функция отличная от линейной или мультипликативной.

 

Пример 1.

Затраты=μ1*N2*N logμ/2Sμ2

μ1 – число различных операторов программы;

μ2 – число различных операндов

μ= μ1+ μ2

N – общее число операторов и операндов

N2 – общее число всех операндов в программе

S =18

Пример 2.

Конструктивная модель оценки стоимости программного обеспечения.

Constructive Cost Model (COCOMO). COCOMO81, COCOMOII.

 

Табличные модели

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

Комбинированные модели

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

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

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

Закон Паркинсона

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

Метод конкурентных цен

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

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:

zdamsam.ru

Оценка программного обеспечения заказать в компании «Атлант Оценка»

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

Основные причины для оценки программного обеспечения:

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

Оценочная процедура: что нужно знать

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

Факторы, определяющие стоимость программного обеспечения:

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

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

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

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

Компания «Атлант Оценка» — специалист в сфере оценки

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

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

Наши преимущества:

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

Компания «Атлант Оценка» ориентирована на плодотворное сотрудничество и решает самые сложные задачи.

Заказать консультацию

atlant-mos.com

Дэн Гэлорат и SEER-SEM / Хабрахабр

Дэниэль Д. Гэлорат — президент и исполнительный директор Galorath Incorporated и главный разработчик SEER-SEM, программного продукта по алгоритмическому управлению проектами.

Он считается экспертом в области оценки программного обеспечения и автор книги «Программное обеспечение, оценка и риск-менеджмент» («Software Sizing, Estimation, and Risk Management»).

«Книга помогает определить лучший способ инвестировать в улучшение производительности программного обеспечения.» — Берри Боэм, автор спиральной модели и COCOMO

Биография

Дэн Гэлорат учился в Университете штата Калифорния, который он закончил в 1980 г. по специальности «управление». После университета Гэлорат работал в области разработки программного обеспечения. Его первой пробой пера в области разработки программ по оценке программного обеспечения была совместная работа с Доном Райфером (Don Reifer) над программой Softcost для Лаборатории реактивного движения NASA. Эта программа использовалась на протяжении 1980-х годов и считается одним из прародителей современных систем оценки программного обеспечения.

В 1984 г. Дэн Гэлорат стал консультантом компании Computer Economics, Inc. (CEI), где он познакомился с модификациями Ренделла Дженсена (Dr. Randall Jensen) модели Putnam. Хотя модификации однозначно улучшали модель, они не годились для коммерческого использования. Для CEI Гэлорат разработал более удобную для пользователя программу оценки софта, так называемую CEI System-3.

В 1998 г. компания Дэна Galorath Inc. сформировала Технологический департамент SEER, в котором Гэлорат стал ведущим разработчиком платформы, впоследствии названной SEER-SEM.

Получившийся программный продукт использовал наработки CEI System-3, базу прецедентов и графический интерфейс. Эти улучшения позволили проектным менеджерам использовать SEER-SEM для улучшения оценки требований их программ.

С того времени Гэлорат и его компания внесли множество улучшений в первоначальную версию SEER-SEM, добавив библиотеку, содержащую примеры реализации тысячи различных проектов. Благодаря этому программу стали использовать компании из различных отраслей, например, производители авиатехники Lockheed Martin и Northrup Grumman, электроники Siemens и даже Министерство обороны США.

В 2009 г. Гэлорат получил награду от Общества оценки и анализа стоимости за его заслуги в области параметрического моделирования цены, графика, риска, надежности и обслуживания программного обеспечения.

Проекты

JPL Softcost Метод Softcost был изначально разработан для Лаборатории реактивного движения NASA и считается одной из первых моделей по оценке программного обеспечения. В соответствии с названием метода, он давал точные прогнозы по времени и цене, но был позже заменен на JPL из-за отсутствия опции оценки риска.

CEI System-3 Будучи консультантом Гэлорат разработал System-3. В основном модель базировалась на работе Ренделла Дженсона по модификации модели Putnam. Некоторые черты у обеих моделей были схожи, например, неопределённые возможности по оценке минимального количества времени. CEI's System-3 значительно увеличила возможности использования модели Дженсона, открыв ей доступ к рыкну платных услуг по оценке реализации проектов.

SEER-SEM Начальная версия SEER-SEM состояла из 22 тыс. строчек кода и работала только на Windows 2.0. Текущая версия выросла до 200 тыс. строчек кода, позволяет работать с Microsoft Project и IBM Rational. Текущие модификации SEER широко применяются в различных сферах деятельности: банковской, автомобилестроения, авиастроительной, производства электроники, а также используется Минобороны США. Программа имеет дело со всеми аспектами разработки программного обеспечения: оценкой сроков, трудоемкости, затрат, рисков.

SEER-SEM

System for event evaluation and review — метод, система (экспертных) оценок и обзора событий.

SEER для программного обеспечения — SEER SЕM — является алгоритмическим приложением по управлению проектами, разработанным специально для оценки, планирования и мониторинга усилий и ресурсов, требуемых для разработки и/или поддержания программного обеспечения.

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

История
Предшественники
  • 1966 г. — системная модель корпорационного развития.
  • 1980 г. — исследование Дона Райфера (Don Reifer) и Дэна Гэлората (Dan Galorath), которое привело к созданию модели JPL Softcost. Эта модель, являясь ранним примером оценки программного обеспечения, позволяла анализировать риски в автоматическом режиме. Softcost стал в последствие коммерческим продуктом компании Reifer Consultants.
  • 1984 г. Гэлоратом разработана Система-3 на основе модели Jensen-2 (Computer Economics JS-2).
Система-3 и другие моделирующие системы, такие как COCOMO Барри Боэма и ранние работы Doty Associates, напрямую и косвенно способствовали разработке Гэлоратом своего программного обеспечения в конце 1980-х годов.

Версия 1.0

В 1998 г. в Galorath Incorporated началась работа над начальной версией SEER-SEM, которая по завершению представляла собой около 22 тыс. строчек кода. SEER-SEM версия 1.0 была выпущена на тринадцати 5-ти дюймовых дискетах и была одной из первых программ, работающих на Windows 2. Разработка SEER-SEM под Windows считалась рискованным решением, т.к. этой операционной системе еще предстояло показать себя жизнеспособным конкурентом лидирующей в то время Microsoft's MS-DOS. Время показало, что это было правильным решением, т.к. SEER-SEM могла похвастаться интуитивно понятным пользовательским интерфейсом. Гэлорат выбрал Windows потому, что она позволяла наглядно демонстрировать основные стадии и динамику развития проектов.

Следующие версии

После выхода первой версии в 1988 г. SEER-SEM неоднократно обновлялась, чтобы соответствовать новым технологиям, улучшались ее потребительские качества и точность прогнозов. Например, выпущенная в 1994 г. версия 4.0 включала улучшенную математическую модель, которая работала с проектами в реальном времени, а не просто с рэлеевской кривой приближенных значений, а также много других наработок, в том числе последние достижения в области программного обеспечения и показателей сложности программ.

В 2003 г. были добавлены такие важные функции, как целеполагание и регулирование риска. Версия 6.0 уже позволяла импортировать и экспортировать данные из SEER в различные программные продукты Microsoft, например, в Excel.

Версия 7.0 позволяла лучше управляться с проектами, увеличивая их потенциал.

Настоящее время

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

У SEER появились спецификации:

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

Пользователи SEER для программного обеспечения используется тысячами лицензированных пользователей, в том числе крупными компаниями в области авиации, банковской, финансовой, страховой и производственной сферах. Например, среди клиентов компании числятся Bank of America, Boeing, Ford Motor Company, Lockheed Martin, National Oceanic and Atmospheric Administration, Northrop Grumman, Siemens, Raytheon и Минобороны США.

Технические детали SEER для программного обеспечения (SEER-SEM) разработана для работы в среде Windows, а с версии 6.0 полностью адаптирована для взаимодействия с Microsoft Office. Программный интерфейс приложения полагается на Microsoft Automation. Сама программа написана на C и C++.

Группы моделей SEER-SEM состоит групп моделей, согласованная работа которых позволяет оценить объём работ, длительность, кадровое обеспечение и недостатки проекта. Эти модели можно кратко описать вопросами, на которые они отвечают:

  • Размер: какой предполагаемый объем проекта (количество строчек кода, балльная функциональная оценка, прецеденты)?
  • Технология: какова производительность труда разработчиков (возможности, инструменты, опыт и пр.)?
  • Расчет объема и сроков: какой объем работ? Сколько времени требуется на завершение проекта? Что произойдет с проектом при ограничении или сокращении сроков и/или штата сотрудников?
  • Распределение обязанностей: как будут распределяться трудовые обязанности?
  • Оценка стоимости: учитывая заданный объем работ, длительность проекта и распределение обязанностей, сколько будет стоить его реализация?
  • Оценка недостатков: учитывая тип продукта, длительность проекта и другую информацию, какое ожидается качество итоговой продукции?
  • Оценка стоимости обслуживания: сколько усилий потребуется на адекватное техническое обслуживание и обновление данной компьютерной системы?
  • Прогресс: как оцениваются текущие результаты реализации проекта, учитывая сроки?
  • Обоснованность: возможно ли реализовать проект, используя доступные технологии?

Определение размера программного обеспечения

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

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

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

Модель SEER-SEM не просто вносит поправки в соответствии с особенностями языка программирования, но также учитывает такие факторы, как фазу оценки, операционное окружение, тип приложения и его сложность. Показатель энтропии колеблется от 1.04 до 1.2 в зависимости от типа разрабатываемого ПО.

Расчет трудоемкости и сроков

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

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

— степень интеграции сотрудников — показатель сложности проекта с точки зрения количества вовлеченных человек. — энтропия

Когда получен показатель трудоемкости, определяются сроки:

Видно, что с увеличением трудоемкости проекта, возрастают сроки его реализации, но не пропорционально (^0.4).
Источники

habr.com