Содержание к диссертации
Введение
1. Анализ концепций жизненного цикла программного продукта 7
1.1 Анализ моделей разработки программного продукта 7
1.2. Анализ изменения концепций управления разработкой программных продуктов 12
1.3. Анализ альтернативных описаний процессов разработки программных продуктов 22
1.4. Основные стандарты жизненного цикла пп 27
1.5. Анализ стандарта шее 1074 как процесса жизненного цикла разработки программного продукта 29
1.6. Анализ жизненного цикла разработки программного продукта 42
1.7. Резюме 47
2. Анализ моделей разработки программного продукта и оценка результата разработки 50
2.1. Задача определения параметров программного продукта 50
2.2. Оценка результата разработки программного продукта 53
2.3. Классификация моделей жизненного цикла разработки программного продукта 66
2.4. Анализ каскадной модели цикла разработки программного продукта -. 68
2.5. Анализ v-образной модели цикла разработки программного продукта 77
2.6. Анализ модели прототипирования цикла разработки программного продукта... 81
2.7. Анализ модели цикла быстрой разработки приложений программного продукта 92
2.8. Анализ инкрементной модели цикла разработки программного продукта 98
2.9. Анализ спиральной модели цикла разработки программного продукта 104
2.10. Анализ адаптированной модели цикла разработки программного продукта 111
2.11. Резюме 118
3. Стоимостная оценка и моделирование процессов замены программного продукта 121
3.1. Анализ особенностей программных продуктов как объектов интеллектуальной собственности 121
3.2. Применение методов определения стоимости программного продукта 128
3.3. Моделирование процессов замены программного продукта с учетом морального износа 135
3.4. Определение сроков начала разработки нового программного продукта 155
3.5. Резюме 163
Заключение 166
Использованная литература:
- Анализ изменения концепций управления разработкой программных продуктов
- Анализ стандарта шее 1074 как процесса жизненного цикла разработки программного продукта
- Анализ каскадной модели цикла разработки программного продукта
- Применение методов определения стоимости программного продукта
Введение к работе
Почти треть проектов информационных систем прекращают свое существование, оставшись незавершенными. По данным, публикуемым компанией Standish Group, в 1996 году 84% проектов информационных систем не были завершены в установленные сроки, в 1998 году сократилась до 74%, однако и в 2000-м общий объем "хронического" незавершенного производства не опустился ниже 50% [13].
Главной причиной такого положения является то, что уровень технологии анализа и синтеза систем, методов и средств управления проектами не соответствует сложности создаваемых систем, которая постоянно возрастает в связи с усложнением и быстрыми изменениями бизнеса. Следовательно, необходимо тщательно планировать жизненный цикл разработки программных продуктов, проводить анализ и осуществлять поиск наиболее эффективных решений и методов, позволяющих выпустить готовый продукт, при этом необходимо уложиться в заданные сроки, ограничения по стоимости разработки и при всем при том обеспечить соответствующий уровень качества.
Вследствие увеличения возможностей персональных компьютеров, на все программные продукты распространяется явление морального старения, которое ограничивает время их применения. Появляются новые продукты, которые могут выполнять более трудоемкие задачи. Продукты, упрощаясь технически, за счет использования новейших технологий разработки, усложняются в то же время в функциональном отношении за счет расширения решаемого круга задач.
В связи со спецификой схемы жизненного цикла разработки программных продуктов (разработка - использование - продолжение разработки), для фирмы - разработчика возникает проблема определения периода замены программного продукта на новый, улучшенной версии.
Перечисленные моменты указывают на актуальность темы диссертации, посвященной моделированию жизненного цикла программного продукта.
Объектом исследования является жизненный цикл программного продукта, который анализируется с точки зрения разработчика программного про-дукта, начиная с этапа зарождения идеи о создании продукта до момента его вывода из эксплуатации.
Предметом исследования являются модели и методы, возникающие при исследовании, управлении и планировании жизненного цикла программного продукта.
Цель исследования состоит в выявлении и формулировке системы задач, позволяющих управлять жизненным циклом программного продукта на этапе планирования, разработки и использования, а также выявлении периодов модернизации продукта и создания нового, идущего на замену предыдущему.
В диссертационном исследовании решаются следующие основные задачи:
анализ существующих моделей разработки программных продуктов, выявление сильных и слабых сторон каждой модели, обозначение сферы применения. Построение адаптированных моделей жизненного цикла разработки продукта, где в качестве "каркаса" используются базовые модели разработки;
формулирование задачи определения параметров программного продукта и предложение методов решения;
формализация подходов, используемых при формировании стоимости программного продукта на этапе планирования проекта, при индивидуальной разработке, рассмотрение методологии и подходов, используемых для построения прогнозных оценок;
моделирование процесса замены программного продукта с учетом морального износа;
определение сроков разработки нового программного продукта при замене продукта на новый.
Теоретической и методологической основой исследования послужили работы отечественных и зарубежных ученых и специалистов в области управ-
5 ления программными проектами. Фундаментальными трудами в области управления программными проектами являются работы Майкла Ньюэлла, Фредерика Брукса, Барри Боэма, У. Ройса, Р. Фатрелла, Джосефа Филлипса. Среди работ, в которых рассматривался процесс разработки программных продуктов,
можно выделить работы В. Кулямина, Р. Арчибальда, М. Грашиной, М. Разу, В.
Богданова, Э. Иордона, В. Липаева, А. Вендрова, Л. Боброва, Р. Томсетта, Г.
Ефимова, Д. Яна, Э. Брауде.
Научная новизна диссертационного исследования. На основе проведенного анализа жизненного цикла программного продукта, предложен и решен ряд задач имеющих научную новизну:
проведена классификация существующих моделей разработки программных продуктов, выявлены сильные и слабые стороны каждой модели, обозначены сферы применения;
сформулирована и решена задача определения параметров программного продукта;
смоделирован процесс замены программного продукта с учетом морального износа;
определены сроки разработки нового программного продукта при замене продукта на новый;
определена процедура обновления программного продукта, где обновление может выступать в форме новой версии продукта или в форме нового продукта;
формализованы подходы, используемые при формировании стоимости
программного продукта, при индивидуальной разработке на заказ.
Практическая значимость работы заключается в возможности исполь
зования полученных результатов фирмами, занимающимися разработкой про
граммных продуктов, главным образом, на этапах планирования проекта, раз
работки, а также на этапе сопровождения продукта.
Результаты диссертационного исследования, выносимые на защиту: задача определения параметров программного продукта;
модель замены программного продукта на новый, улучшенной версии,
использующая в качестве базы анализа поток амортизационных отчисле-t
ний и фактические затраты на обслуживание;
модель определения сроков разработки нового продукта, основанная на
анализе потока доходов фирмы-разработчика;
процедура обновления программного продукта, где обновление может
выступать в форме новой версии продукта или в форме нового продукта.
Апробация результатов диссертационного исследования.
Основные результаты исследования, выводы и заключения нашли отра
жение в публикациях автора, докладывались и обсуждались на научно-
» практической конференциях студентов и аспирантов: "Менеджмент и экономи-
ка в творчестве молодых исследователей ИНЖЭКОН-2005" и "Менеджмент и экономика в творчестве молодых исследователей ИНЖЭКОН-2007".
Анализ изменения концепций управления разработкой программных продуктов
Микроминитюаризация элементной базы привела к появлению персональных компьютеров, что позволило расширить сферу их применения. Следствием этого процесса явилась глобальная компьютеризация, как производственной деятельности, так и деятельности домашних хозяйств. Появилась потребность в разработке множества программных продуктов, что в свою очередь привело к их массовому производству, которое в настоящее время приблизилось по масштабам товарного производства. Несмотря на громадную вовлеченность в этот процесс больших сил и средств, производство программных продуктов является единичным. Несмотря на особенности процесса создания программных продуктов, очень многое роднит этот процессе с товарным производством. Особенно это касается процессов организации и технологии. Поэтому был неизбежен переход к использованию идеологии управления проектами. Первой задачей, которая встает на этом пути это привязка терминологии управления проектами к процессу создания программных продуктов. В первую очередь это такие термины как задача, действие, фаза, проект, программа, программный продукт. Соединение терминологии процесса создания программных продуктов и управления проектами позволило дать следующие определения.
Прежде всего, определим термин "работа", как действие во времени, имеющее начало, окончание и законченный результат, который можно зафиксировать.
В этом случае под задачей понимается работа, которая не включена в структуру пооперационного перечня работ, но потенциально может быть разбита на части лицами, ответственными за ее выполнение. Также этот термин обозначает минимальный уровень трудозатрат в рамках проекта.
Под действием понимается характеристика или параметр работы, выполненной в процессе реализации проекта. Действие обычно имеет ожидаемую продолжительность и стоимость, а также прогнозируемые требования к ресурсам, кроме того, оно может быть разделено на отдельные задачи.
Фаза содержит группу действий/задач, в ходе осуществления которых производится существенная часть рабочего продукта.
Проект рассматривается как уникальное, ориентированное на достижение цели, срочное и ограниченное условиями действие. Проект - это большое или важное действие (или последовательность действий), которое было запланировано заранее. С точки зрения приведенных определений термин "проект" не определяется однозначно. Под проектом понимается как процесс, так и результат [15]. С этих позиций термин "Проект" может рассматриваться как: 1. Определенный план или схема разработки проекта.
2. Запланированное действие, которое может представлять, например: (а) определенным образом сформулированная часть исследования; (б) большое, обычно поддержанное правительственными субсидиями действие; (в) задача или проблема, обычно поставленная перед группой студентов, которая затем выносится на аудиторные занятия. С точки зрения проекта программа - это совокупность взаимосвязанных проектов, а система: организованный элемент, выступающий как единое целое. По завершении проекта должен быть создан конечный продукт проекта (программного инжиниринга) - программный продукт. В дальнейшем для программного продукта будет использоваться терминология, предложенной Институтом программного инжиниринга (Software Engineering Institute, SEI) и Институтом инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers, IEEE).
Процесс разработки программного продукта нуждается в управлении. С этой точки зрения менеджмент рассматривается как практика управления, которое включает формулировку целей, определение средств и ресурсов, с последующим их планированием, организацией и контролем выполнения. С более общих позиций, менеджмент в управлении проектами по разработке программных продуктов может рассматриваться как [15]:
1. Акт или искусство проведения или наблюдения действий (например, с точки зрения бизнеса).
2. Эффективное использование средств для достижения заданного результата (получения программного продукта).
3. Коллективный орган управляющих предприятием, занятым разработкой и продвижением на рынок программных продуктов.
Простое на первый взгляд понятие менеджмент (управление) проектом программными продуктами предполагает наличие многих особенностей, существенно влияющих на процесс их разработки и продвижения на рынок. Поэтому приведенный анализ терминологии управления проектами, применительно к процессам разработки программных продуктов является недостаточным и нуждается в уточнении.
Согласно Барри Боэму (Barry Boehm), инжиниринг программного продукта - это практическое применение научных знаний при разработке и создании компьютерных программ и связанной с ними документации, необходимой для их разработки, использования и поддержки. Институт IEEE определяет этот термин как систематический подход к развитию, действию, поддержке и прекращению эксплуатации программного продукта. А Стефен Шах (Stephen Schach) описывает программный инжиниринг как дисциплину, целью которой является создание качественного программного продукта, которое завершается вовремя, не ведет к превышению выделенных бюджетных средств, а также удовлетворяет выдвигаемым требованиям.
Если провести синтез этих определений, то в результате получится: инжиниринг программного продукта - это регламентированный, системный подход к разработке, оперированию, обслуживанию и прекращению эксплуатации программного продукта с помощью практического применения идеологии управления проектами.
Анализ стандарта шее 1074 как процесса жизненного цикла разработки программного продукта
Стандарт ШЕЕ 1074 обеспечивает поддержку процесса жизненного цикла разработки программного продукта (Software life cycle process, SLCP). Процесс жизненного цикла программного продукта определен неоднозначно и основывается на:
Создаваемые человеком информационные сущности, документы в достаточно общем смысле, участвующие в качестве входных данных и получающиеся в качестве результата различных деятельностей. характерном для проекта описании процесса, который основывается на жизненном цикле программного продукта; интегральных процессах и процессах менеджмента, используемых организацией.
Интегральные процессы включают менеджмент конфигурации, метрические показатели, обеспечение качества, уменьшение степени риска, действия по оценке, планированию и обучению. Разработка процесса жизненного цикла программного продукта в рамках проекта входит в обязанности менеджера и архитектора проекта.
Реализация подобной методологии начинается с выбора соответствующего вида модели жизненного цикла разработки программного продукта (Software life cycle model, SLCM) с целью ее применения в рамках определенного проекта. Затем задается жизненный цикл программного продукта (SLC), используя отобранную модель SLCM и действия, описанные в таблице 1.2. Используемая в данном случае, методология заключается в адаптации выбранной модели SLC к иерархии управления в конкретной организации с целью проектирования процесса жизненного цикла разработки программного продукта. Действия, описанные в таблице отображения процесса согласно стандарту ШЕЕ 1074 (табл.1.2.), охватывают полный жизненный цикл проекта программного продукта от исследования концепции до возможного прекращения процесса эксплуатации программной системы.
Стандарт ШЕЕ 1074 целесообразно применять в любой организации, которая занимается разработкой и реализацией программных продуктов. Он может использоваться там, где программный продукт образует завершенную систему или является частью большей системы. Он пригоден для организаций, занимающихся только программными продуктами, отделов, в обязанности которых входит разработка внутренних информационных технологий, консультантов в области программных продуктов и организаций, занимающихся только менеджментом проектов, которые доставляют и реализовывают имеющиеся в наличии коммерческие (commercial-offhe-shelf, COTS) программные продукты. Стандарт IEEE 1074 - это цикл SLCP, который требуется для выполнения определенного программного проекта.
Хотя стандарт IEEE 1074 описывает разработку отдельного, полного процесса SLCP, который должен применяться для проекта, пользователь этого стандарта должен признать, что SLCP может сам включать низкоуровневые жизненные циклы разработки программного продукта. Здесь используется та же самая концепция, что и при менеджменте конфигурации, когда отдельный элемент конфигурации может включать зависимые элементы. Этот стандарт одинаково пригоден к разработке процесса SLCP на любом уровне.
Стандарт ШЕЕ 1074 включает шесть основных категорий процесса: 1. процесс модели жизненного цикла разработки программного продукта; 2. процессы менеджмента проектов; 3. процессы предварительной разработки; 4. процессы разработки; 5. процессы, выполняемые после разработки; 6. интегральные процессы.
Также существует 17 подпроцессов и 65 действий, входящих в состав подпроцессов. Все эти объекты приводятся в таблице, описывающей стандарт IEEE 1074.
Стандарт IEEE 1074 не отождествляется с определенным процессом модели SLCM. Он не может существовать без определенных циклов SLC организации. Стандарт IEEE 1074 не предполагает использования определенной методологии разработки и даже не рекомендует ее. Он не является самодостаточным, т.е. могут быть добавлены в случае необходимости более строгие требования. В табл. 1.2 приведена карта категорий IEEE 1074 для процессов и действий.
Стандарт IEEE 1074 представляет собой пошаговое руководство, в котором описывается реализация девяти шагов, которые определяют методы выполнения процессов SLCP. Учитывая природу настройки данного стандарта IEEE 1074, практики пришли к выводу, что определенные в стандарте инструкции могут быть в дальнейшем упрощены до следующих шести этапов.
Этап 1. Выбор модели SLCM. На данный момент времени можно выбирать модель жизненного цикла между той, с которой имеется больший опыт работы (предложена организацией), и моделью, требуемой клиентом, или новой моделью, которая, как показало исследование, может принести хорошие результаты в деле улучшения качества. В текущем описании будет выбрана для реализации простейшая модель - основная каскадная модель, показанная на рис. 1.7. Рис. 1.7. Этап 1 - рассмотрение основной каскадной модели процесса Сначала необходимо идентифицировать цикл модели SLCM, в соответствие которому будут поставлены действия. Этот этап включает расположение, оценку, отбор и получение цикла модели SLCM. Организация может иметь множество моделей жизненного цикла разработки программного продукта. Однако для проекта должна быть отобрана только одна модель. Смешение моделей в пределах проектов приводит к беспорядку и получению недетерминированного набора методов измерений проектов. Для оценки и выбора модели SLCM необходимо придерживаться следующих пяти этапов. 1. Идентифицировать все циклы модели SLCM, которые являются доступными при разработке проекта. 2. Идентифицировать признаки, которые применяются для желаемой окончательной системы и среды разработки. 3. Идентифицировать любые ограничения, которые могли бы быть наложены на выбор. 4. Оценить различные циклы модели SLCM на основе предыдущего опыта и организаторских способностях. 5. Выбрать цикл SLCM, который лучше всего удовлетворяет атрибутам и ограничениям проекта.
Анализ каскадной модели цикла разработки программного продукта
Классическая каскадная модель, несмотря на полученную в последнее время негативную оценку, исправно служила специалистам по программному инжинирингу многие годы. Понимание ее сильных сторон и недостатков улучшает оценочный анализ других, зачастую более эффективных моделей жизненного цикла, основанных на данной модели.
В первые годы практики программирования сначала записывался программный код, а затем происходила его отладка. Общепринятым считалось правило начинать работу не с разработки плана, а с общего ознакомления с продуктом. Без лишних формальностей можно было спроектировать, закодировать, отладить и протестировать программный продукт еще до того, как он будет готов к выпуску. Это напоминало процесс, изображенный на рис. 2.1. В структуре такого процесса есть несколько недостатков. Во-первых, поскольку изначально не существовало официального проекта или анализа, невозможно было узнать о моменте завершения процесса. Также отсутствовал способ определения соответствия требованиям относительно достижения качества.
В 1970 году каскадная модель была впервые определена как альтернативный вариант метода разработки программного продукта по принципу кодирование-устранение ошибок, который бьш широко распространен в то время. Это была первая модель, которая формализовала структуру этапов разработки программного продукта, придавая особое значение исходным требованиям и проектированию, а также созданию документации на ранних этапах процесса разработки.
Модель процесса по принципу "делать, пока не будет сделано" Начальный этап выполнения каскадной модели показан в левой верхней части рис. 2.2. Продолжающийся процесс выполнения реализуется с помощью упорядоченной последовательности шагов. В модели предусмотрено, что каждая последующая фаза начинается лищь тогда, когда полностью завершено выполнение предыдущей фазы. Каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные. В результате выполнения генерируются внутренние или внешние данные проекта, включая программный продукт и документацию к нему. Документы по анализу требований впоследствии передаются системным специалистам, которые в свою очередь передают их разработчикам программных систем более высокого уровня. Программисты разрабатывают детальные технические характеристики, которые уже представляют готовый код тестерам.
Переход от одной фазы к другой осуществляется посредством формального обзора. Таким образом, клиент получает общее представление о процессе разработки, кроме того, происходит проверка качества программного продукта.
Как правило, прохождение стадии обзора указывает на договоренность между командой разработчиков и клиентом о том, что текущая фаза завершена и можно перейти к выполнению следующей фазы. Окончание фазы удобно принимать за стадию в процессе выполнения проекта.
После формирования заключительной базовой линии производится обзор приемки.
Попытки оптимизации каскадной модели привели к возникновению других циклов разработки программного продукта. Прототипирование программ позволяет обеспечить полное понимание требований, в то время как инкре-ментные и спиральные модели позволяют повторно возвращаться к фазам, соотнесенным с классической каскадной моделью, прежде чем полученный продукт будет признан окончательным.
Отличительным свойством каскадной модели можно назвать то, что она представляет собой формальный метод, разновидность разработки "сверху вниз", она состоит из независимых фаз, выполняемых последовательно, и подвержена частому обзору.
Рассмотрим характеристики каждой фазы каскадной модели (включая фазы интеграции): исследование концепции - происходит исследование требований на системном уровне с целью определения возможности реализации концепции; процесс системного распределения - может быть пропущен для систем по разработке исключительно программных продуктов. Для систем, в которых необходима разработка как аппаратного, так и программного обеспечения, требуемые функции применяются к программным продуктам и оборудованию в соответствии с общей архитектурой системы;
процесс определения требований - определяются программные требования для информационной предметной области системы, предназначение, линии поведения, производительность и интерфейсы. (В случае необходимости в процесс также включено функциональное распределение системных требований к аппаратному и программному обеспечению.);
процесс разработки проекта - разрабатывается и формулируется логически последовательная техническая характеристика программной системы, включая структуры данных, архитектуру программного продукта, интерфейсные представления и процессуальную (алгоритмическую) детализацию;
процесс реализации - в результате которого выполненное эскизное описание превращается в полноценный программный продукт. При этом создается исходный код, база данных и документация, которые лежат в основе физического преобразования проекта. Если программный продукт представляет собой приобретенный пакет прикладных программ, основными действиями по его реализации будут являться установка и тестирование пакета программ. Если программный продукт разрабатывается на заказ, основными действиями являются программирование и тестирование кода;
процесс установки - включает установку программного продукта, его проверку и официальную приемку заказчиком для операционной среды;
процесс эксплуатации и поддержки - подразумевает запуск пользователем системы и текущее обеспечение, включая предоставление технической помощи, обсуждение возникших вопросов с пользователем, регистрацию запросов пользователя на модернизацию и внесение изменений, а также корректирование или устранение ошибок;
Применение методов определения стоимости программного продукта
Стоимость программного продукта предлагается рассматривать с нескольких точек зрения, включая стоимость его разработки, цену и оценку стоимости у пользователя. Последнее связано с дополнительными затратами, которые несет пользователь в процессе освоения и использования программного продукта. Основное внимание производителей программных продуктов уделяется, как это было показано во второй главе, сокращению периода разработки. Применение многочисленных технологий во многом подтверждает эту точку зрения. Это связано с уникальностью производства программных продуктов и высокими затратами труда на его создание. В отличие от других сфер деятельности в данном случае необходимо привлечение высококвалифицированных специалистов на всех стадиях создания программных продуктов. Затраты на программный продукт столь велики, что можно предполагать "неограниченность" бюджетов, выделяемых на эти цели. Конечно, есть ориентиры позволяющие дать верхнюю оценку цены программного продукта, затратам на его приобретение и эффекту от его применения по сравнению с существующими аналогами. На стоимость разработки оказывает влияние длительность этого периода и численность персонала, непосредственно участвующего в этом процессе. Экономия затрат на разработку возможна за счет сокращения его периода и уменьшения стоимости рабочей силы. Первое реализуется за счет внедрения различных технологий, рассмотренных выше, а второе за счет привлечения рабочей силы в других странах с более низким уровнем жизни.
Поэтому в зависимости от величины емкости рынка программного продукта возможно рассматривать ту или иную величину средств, инвестируемую на создание нового или совершенствование существующего программного продукта. Неопределенность, возникающая в процессе разработки и реализации программного продукта, заставляет производить многочисленные оценки его стоимости разными методами. Для этой цели предлагается использовать, такие методы определения стоимости программного продукта как: "затратный" метод"; метод сравнения с рыночными продажами аналогов для определения стоимости авторского права на программный продукт; метода дисконтированного денежного потока.
"Затратный метод" определения балансовой и рыночной цены ПП предполагает установление цены на уровне средних затрат на разработку плюс нормальная прибыль, а также дополнительная (экономическая) прибыль за высокий научно-технический уровень разработки или уменьшение сроков ее выполнения. Таким образом, устанавливается цена по научно-техническим подрядам - договорам па создание научно-технической продукции, в частности на разработку ПП.
В условиях рынка, когда договора заключаются на конкурсной основе, такой принцип ценообразования называется "Const plus Fee", т.е. затраты плюс вознаграждение. На переговорах по заключению договора стороны согласуют смету затрат на разработку (подряд, заказ), а также вознаграждение в процентах или доле от суммы договорной сметы (не ниже ставки банковского процента). На этот принцип накладывается его модификация "Target price" (целевая цена) и "Taget time" (целевой срок), предполагающая дополнительное вознаграждение за превышение показателей технического задания или желательное для заказчика сокращение срока заказа.
Обычная смета затрат на разработку научно-технической продукции включает в себя следующие статьи затрат: - заработную плату разработчиков; - отчисления на социальное страхование; - эксплуатационные расходы, включающие амортизацию лицензионного программного обеспечения (ПО); - накладные расходы.
В п. 7 ПБУ 14/2000 указано, что первоначальная стоимость нематериальных активов, созданных самой организацией, определяется как сумма всех фактических расходов на их создание, изготовление (израсходованные материаль ные ресурсы, оплата труда, услуги сторонних организаций по контрагентским (сойсполнительским) договорам, патентные пошлины, связанные с получением патентов, свидетельств, и т. п.), за исключением налога на добавленную стоимость и иных возмещаемых налогов (кроме случаев, предусмотренных законодательством Российской Федерации). В п. 57 Положения по ведению бухгалтерского учета и бухгалтерской отчетности в Российской Федерации, утвержденного приказом Минфина России от 29.07.98 г. N 34н (с изменениями от 30.12.99 г., 24.03.2000 г.), содержится норма, согласно которой нематериальные активы отражаются в бухгалтерском балансе по остаточной стоимости, т. е. по фактическим затратам на приобретение, изготовление и затратам по их доведению до состояния, в котором они пригодны к использованию в запланированных целях, за минусом начисленной амортизации [23].
Сумма вышеуказанных статей затрат представляет стоимость разработки, но без учета налогов и дополнительного вознаграждения за качество и сроки. Таким образом, договорная цена на разработку программного продукта носит "затратный характер" в отличие от "антизатратных цен" на рынке лицензий (договоров на передачу имущественных прав на ПП).
Основными факторами, определяющими стоимость объектов интеллектуальной собственности, являются: - затраты владельца исключительных прав на разработку объекта правовой охраны (по смете затрат по договору-подряду на НИОКР); - затраты владельца исключительных прав на патентование (регистрацию) объектов интеллектуальной собственности, включая пошлины и другие расходы на поддержание охранных документов в силе; - затраты на организацию использования программного продукта, включая и затраты на его маркетинг; - затраты на страхование разработки программного продукта; - срок действия охранного документа (патента, свидетельства) на момент оценки его стоимости;
