ВВЕДЕНИЕ.
Существенной особенностью постиндустриальной эпохи стало появление рынка авторских прав на программные продукты. Стоит сразу жеотметить разницу понятий " программный продукт " (ПП) и "программа для ЭВМ",которая полностью определена.
Нужен ли программный продукту некий отличительный знак, подтверждающий его качество? Казалось бы, рыночная экономика даетотрицательный ответ на этот вопрос - высокий спрос подтвердит качество товара. Своеобразным знаком качества часто служит громкое имя поставщика, всемизвестный brand. И тем не менее, серьезные компании стремятся не только обеспечить качество, но и подтвердить его официально, получив сертификат,демонстрирующий, что все внутренние процессы компании направлены на создание качественного продукта. Иначе говоря, работает система управления и обеспечениякачеством. Наличие такого сертификата - гарантия доверия его обладателю со стороны клиентов и партнеров.
В данной работе мы определим понятие «программного продукта», его сертификацию, а такжевопросы авторских прав.
1. Понятие программного продукта и его стандартизация.
Система качества представляет собой организационный стержень для компании, которая вынуждена тщательно продумывать и документальнооформлять, а затем контролировать каждый этап проектирования программного продукта и его результаты.Для этого нужен специально обученный персонал и особые методы управления качеством. Эти методы варьируются от компании к компании, но основные их положения едины для всех и определяютсястандартом. В конечном итоге система качества позволяет создать оптимальные условия для продуктивного труда специалистов, поскольку берет на себя всеформальные и рутинные, но абсолютно необходимые операции. Она позволяет перейти от кустарного уровня сотворения замечательных программ "на коленке" кнаучно организованному массовому производству программного продукта .
ISO 9000-3 - система качества для ПО Стандарт ISO 9000-3 включает в себя все положения общего стандарта ISO 9001, а такженеобходимые дополнения к ним, относящиеся к разработке, поставке и обслуживанию ПО. ISO 9001 устанавливает требования к системе качества поставщика и позволяетоценивать его возможности по проектированию и поставке продукции, соответствующей этим требованиям.
Требования стандарта направлены в первую очередь на то, чтобы удовлетворить запросы пользователя, предупредив появление каких-либонесоответствий продукции на всех стадиях ее жизненного цикла – от проектирования до обслуживания. Стандарт определяет ряд важных понятий , которые затем используются в положениях стандарта, в том числе:
продукт - результат действий или процессов; программный продукт - набор компьютерных программ, процедур и,возможно, связанных с ними документов и данных;
элемент программного обеспечения (software item) – любая идентифицируемая часть программного продукта ; основание (baseline) - формально утвержденная версия элемента
конфигурации, зафиксированная в определенный момент времени в процессе жизненного цикла элемента конфигурации; разработка(development) - процесс жизненного цикла программного продукта , охватывающий анализ требований, проектирование, кодирование,
интеграцию, тестирование, установку и поддержку; модель жизненного цикла (life cycle model) - базовая модель, включающаяпроцессы, действия и задачи, вовлеченные в разработку, функционирование и сопровождение программного продукта и хватывающие весь жизненный цикл системы от определениятребований до завершения
использования; этап (phase) - определенный сегмент работы; регрессионное тестирование (regression testing) - тестирование,позволяющее убедиться в том, что изменения, внесенные с целью исправления обнаруженных ошибок, не породили новых; репликация (replication) -копирование программного продукта с одного носителя на другой. Важно отметить, что в большинствепунктов стандарта поставщик обязывается не только определять соответствующие действия, но и оформлять их документально, регистрировать результаты ипериодически анализировать, для того чтобы внести необходимые усовершенствования или полностью заменить.
Управление проектированием
Это самый обширный раздел стандарта, поскольку он затрагивает базовую составляющую общегопроцесса создания продукта , программного продукта в частности, решающим образом влияющую наего качество. Поставщик устанавливает и документирует методики управления и верификации проекта с целью обеспечения выполнения установленных требований.Этот раздел стандарта ISO 9000-3 дает руководящие указания по основным действиям в процессе разработки, таким как анализ требований к проекту,проектирование архитектуры системы, детальное проектирование и кодирование, а также планирование разработки.
Проект разработки программного продукта организуется в соответствии с определенноймоделью жизненного цикла. ISO 9000-3 не определяет, какой должна быть модель жизненного цикла, это зависит от специфики решаемой задачи. Стандарт дает лишьобщее определение модели жизненного цикла как множества процессов. Модель показывает, когда и как эти процессы подключаются к реализации проекта.
Разработка системы - это процесс преобразования исходных требований в конечный программный продукт . Стандарт оговаривает, что этот процесс должен проводиться в строго определенном порядке. Это позволит предотвратитьпоявление ошибок и снизит зависимость от процессов проверки и утверждения как единственных методов определения проблемных ситуаций. Требование строгойдисциплины процесса разработки подразумевает наличие и поддержку в рабочем состоянии документированных процедур, которые послужат
гарантией того, что программный продукт создается в соответствии с заданнымитребованиями и планами разработки и обеспечения качества.
Управление проектом должно учитывать такие аспекты, как используемый метод проектирования и его соответствие конкретной задаче,опыт предыдущих проектов, требования последующих процессов: тестирования, установки, сопровождения и использования, наконец, соображения защиты ибезопасности. В тех случаях, когда сбои системы могут нанести ущерб людям, собственности или окружающей среде, при проектировании должно бытьсформулированы специальные требования, гарантирующие устойчивость системы или ее ответные действия на потенциальные аварийные ситуации. Для процессовкодирования должны задаваться правила использования языков программирования, принципы кодирования и правила составления адекватных комментариев.
Инструментальные средства и методы, используемые в разработке программного продукта , такие, например, как системы анализа и проектирования и компиляторы, должны заранее утверждаться иконтролироваться системой конфигурационного управления. Область применения инструментария должна быть задокументирована, а его использование периодическианализироваться, дабы выявить необходимость усовершенствования инструментальных систем или замены на новые продукты.
Проектирование и разработка должны тщательно планироваться. План разработки программного продукта формулирует строго документированные действия по анализутребований к системе, проектированию, кодированию, интеграции, тестированию, установке и поддержке системы. План разработки должен быть проанализирован иутвержден.
План разработки включает также связанные с основным процессом планы обеспечения качества, управления рисками и конфигурацией, планыинтеграции, тестирования, установки, обучения сотрудников и др.
Должны быть определены и задокументированы принципы организационно-технического взаимодействия между различными группами,участвующими в разработке. Здесь четко определяются границы ответственности каждого участника разработки и то, каким образом
техническая информация будет передаваться между участниками. Здесь же оговаривается ответственность заказчика проекта, если онпринимает участие в разработке: необходимость участвовать в проекте, обязательства по своевременному предоставлению нужной информации. В случаеобоюдной договоренности между поставщиком и заказчиком может быть запланирован совместный анализ ведения проект а, регулярно или на определенных его
этапах. Этот анализ затрагивает такие факторы, как ход разработки состороны поставщика, участие в разработке со стороны заказчика,соответствие системы требованиям заказчика, результаты проверок, результаты тестирования.
Входные проектные требования к продукции. Требования формулирует заказчик, а поставщик анализирует, насколько они адекватны.Неполные, двусмысленные или противоречивые требования являются предметом урегулирования с лицами, ответственными за их предъявление. В определенныхситуациях, по обоюдному согласию, спецификацию требований может проводить поставщик.
Выходные проектные данные также оформляются документально, причем таким образом, чтобыих можно было проверить и подтвердить относительно входных проектных требований. Выходные данные проекта программной системы могут включать:спецификацию архитектуры проекта, детальную спецификацию проекта, исходные коды, руководство пользователя. Поставщик программного продукта должен планировать и проводить официальный, документально оформленный анализ результатов проектирования.
Степень формальности и строгости процессов анализа соответствуют сложности разрабатываемойсистемы и степени риска, связанного с ее использованием. Анализ проектирования затрагивает такие аспекты, как выполнимость проекта, удовлетворение требованиямзащиты и безопасности системы, выполнение правил программирования и возможность тестирования. На определенных стадиях проектирования проводится проверкасоответствия выходных данных входным требованиям. Такая верификация проекта может
включать анализ выходных данных, демонстрации, в том числе с помощью прототипов и моделирования, или тестирование. Толькопроверенные выходные проектные данные утверждаются для окончательного приема и последующего использования. Все обнаруженные в процессе проверки проблемныеситуации должны адекватно разрешаться.
Прежде чем система будет передана заказчику, поставщик должен утвердить систему на соответствие заданному назначению. Заказчику можетбыть передан только утвержденный программный продукт .
Все изменения и модификации проекта должны быть идентифицированы, документально оформлены, проанализированы и утверждены до ихреализации. Поставщик устанавливает и поддерживает в рабочем состоянии процедуры управления изменениями в проекте, которые могут возникнуть на любойстадии жизненного цикла системы. Управление документацией и данными
Обслуживание
Поддержка заказчиков обсуждается в стандарте ISO 9000-2. Сопровождение системы, как правило, включает в себя обнаружение ианализ несоответствий в программной системе, вызывающих сбои в ее работе; коррекцию программных ошибок; модификацию интерфейсов, что необходимо в случаевнесения добавлений или изменений в аппаратуру; функциональное расширение или улучшение производительности Все действия по сопровождению должны проводиться иконтролироваться в соответствии с планом сопровождения, который заранее определяется и согласовывается поставщиком и заказчиком. В заключение намостается лишь добавить, что технология разработки программного обеспечения - это целая наука, которой в России, увы, почти не учат. Отсюда явный дефицитхороших менеджеров и специалистов по комплексным проектам. Общие положения стандарта по обеспечению качества - лишь верхушка айсберга. За пределами нашейстатьи остались детали тех процессов, которые реально обеспечивают качество конечного продукта. Но это, как правило, "ноу хау" компании.
2. АВТОРСКОЕ ПРАВО НА ПРОГРАММНЫЙ ПРОДУКТ
КАК ОБЪЕКТ СТОИМОСТНОЙ ОЦЕНКИ
Существенной особенностью постиндустриальной эпохи стало появление рынка авторских прав на программные продукты. Стоит сразу жеотметить разницу понятий " программный продукт " (ПП) и "программа для ЭВМ",которая полностью определена.
В рыночной экономике авторские права на ПП выступают в виде принципиально нового информационного ресурса и продукта, вовлечениекоторого в хозяйственный оборот происходит в процессе коммерциализации (купли-продажи, переуступки прав собственности) и капитализации (постановки набаланс, инвестирования в уставный капитал).
Наиболее сложной, но интересной в теоретическом и практическом плане является такая обязательная процедура введения вхозяйственный оборот как стоимостная оценка имущественных прав на ПП. Еще далеко не разрешены все проблемы, связанные со стоимостной оценкой объектовпромышленной собственности, а оценка стоимости авторских прав на ПП тем более затруднена, т.к. ПП является сложным синтетическим и часто составным объектоминтеллектуальной собственности (ОИС) .
Необходимость оценить в денежном выражении программный продукт (ПП) возникает на различных стадиях его жизненного цикла. Фирма,создавшая ПП, может быть заинтересована в его стоимостной оценке в качестве новой продукции, подлежащей реализации, а также в качестве своего имущества привключении ПП в баланс предприятия путем постановки на учет в составе нематериальных активов (НМА).
Стоимостная оценка ПП с целью включения в НМА (капитализации) называется балансовой стоимостью и носит явно выраженныйзатратный характер.
После включения в НМА ПП вводятся в состав основного капитала фирмы, погашают свою стоимость путем амортизации, но и как всякоедругое имущество, ПП подвергаются налогообложению.
Необходимость в стоимостной оценке ПП и их капитализации явно выражена в следующих ситуациях, требующих различного подхода:
- приватизация или превращение фирмы в акционерное общество;
- оценка имущества фирмы в случае ее разделения;
- организация на основе фирмы обособленного нового производства;
- оценка имущества фирмы в случае ее продажи;
- оценка имущества фирмы при страховании;
- оценка имущества фирмы при банкротстве.
Типичным случаем корпоративных трансакций также является внесение вкладов в уставной фонд вновь создающихся фирм, тогда имущественныеправа на ПП являются инвестициями в развитие другого производства.
Выход на рынок ПП также может рассматриваться как выход продукции (продажа копий), а также как выход на рынок имущественных правна ПП, который предусматривает различные случаи стоимостной оценки:
- оценка исключительных имущественных прав на ПП;
- оценка неисключительных имущественных прав на ПП;
- оценка имущественных прав на "ноу-хау", заключенных в прикладной компьютерной программе.
Уступка вышеуказанных имущественных прав на ПП оформляется в виде авторских или иных договоров, а также беспатентной лицензии, в которых вподавляющем большинстве случаев указывается стоимость прав в денежном выражении.
В процессе создания программы для ЭВМ алгоритм может быть защищён как "ноу-хау" в качестве информации научного илитехнического характера, составляющей коммерческую тайну фирмы-разработчика.
Имущественные же права на объекты интеллектуальной собственности, к которым относятся ПП, предполагают действие триады правомочий(владение, распоряжение, пользование). Такими правомочиями могут обладать авторы ПП или коллектив авторов, фирма-разработчик, а также физические илиюридические лица, купившие эти имущественные права на ПП. Только при наличии имущественных прав возможна их уступка, обмен правами, копирование и продажакопий, а также возбуждение судебных исков при незаконном пользовании ПП.
Стоимостная оценка прав на интеллектуальную собственность имеет много общего со стоимостной оценкой материальногоимущества, предприятий, бизнеса.
Федеральный закон об акционерных обществах (ст. 77) дает следующее определение рыночной стоимости:
"Рыночная стоимость имущества, включая стоимость акций или других ценных бумаг, является ценой, по которой продавец, имеющийполную информацию о стоимости имущества и не обязанный его продавать, согласен был бы продать, а покупатель, имеющий полную информацию о стоимости имущества ине обязанный его приобрести, согласен был бы приобрести".
Акты "покупки-продажи" имущественных прав на ПП как исключительных, так и неисключительных, выступают на рынке в виделицензионных, авторских или иных предусмотренных законодательством договоров. Этот рынок так же, как и рынок копий программ является преимущественно рынкоммонопольной конкуренции. Его существенное отличие от рынка копий ПП заключается в сравнительно небольшом количестве покупателей и продавцов, а значит и внебольшом количестве актов "покупки-продажи". Исходя из теоретических положений макроэкономики это означает, что при рыночном ценообразовании несрабатывает закон больших чисел и устанавливается не чистая рыночная цена имущественных прав, а, скорее, рыночная договорная. А это, собственно, и естьцена, по которой продавец согласен продать, а покупатель - купить товар на рынке.
Затратный метод определения балансовой и рыночной цены ПП предполагает установление цены на уровне средних затрат на разработку ОИСплюс нормальная прибыль, а также дополнительная (экономическая) прибыль за высокий научно-технический уровень разработки или уменьшение сроков еевыполнения. Таким образом устанавливается цена по научно-техническим подрядам - договорам па создание научно-технической продукции, в частности на разработкуПП.
В условиях рынка, когда договора заключаются на конкурсной основе, такой принцип ценообразования называется "Const plusFee", т.е. затраты плюс вознаграждение. На переговорах по заключению договора стороны согласуют смету затрат на разработку (подряд, заказ), а такжевознаграждение в процентах или доле от суммы договорной сметы (не ниже ставки банковского процента). На этот принцип накладывается его модификация"Target price" (целевая цена) и "Taget time" (целевой срок), предполагающая дополнительное вознаграждение за превышение показателейтехнического задания или желательное для заказчика сокращение срока заказа.
Обычная смета затрат на разработку научно-технической продукции включает в себя следующие статьи затрат:
- заработная плата разработчиков;
- отчисления на соцстрах;
- эксплуатационные расходы, включающие расходы на персональный компьютер (ПК) и амортизацию лицензионного программногообеспечения (ПО);
- накладные расходы;
- прибыль;
- налог на прибыль;
- НДС.
Сумма вышеуказанных статей затрат представляет собой стоимость разработки с налогами, но без дополнительного вознаграждения закачество и сроки. Таким образом, договорная цена на разработку ОИС носит "затратный характер" в отличие от "антизатратных цен" нарынке лицензий (договоров на передачу имущественных нрав на ОИС). К основным проблемам выявления затрат относятся трудности с определением трудоемкостиразработок, так как при ценообразовании должны учитываться только усредненные, обоснованные затраты. Такими, например, могут быть среднеотраслевые нормытрудовых затрат при разработке объектов промышленной собственности. Особенно острой является эта проблема при разработке ПП. В принятых в 1988 годуукрупненных нормах времени на разработку ПП к числу основных факторов, влияющих на трудоемкость разработки, отнесены:
- объем ПП в тысячах условных машинных команд;
- сложность ПП;
- степень новизны;
- степень использования при разработке стандартных модулей, типовых программ и ПС.
Однако с переходом на ПК вышеуказанные укрупненные нормы времени устарели, и трудоемкость определяется на основе методов аналогийи экспертных оценок, а чаще всего "уторговывается" при заключении договоров.
Основными факторами, определяющими стоимость объектов интеллектуальной собственности, являются:
- затраты владельца исключительных прав на создание, разработку объекта правовой охраны (по смете затрат по договору-подряду наНИОКР);
- затраты владельца исключительных прав на патентование (регистрацию) объектов интеллектуальной собственности, включаяпошлины и другие расходы на поддержание охранных документов в силе;
- затраты на организацию использования ОИС, включая и затраты на его маркетинг;
- затраты на страхование ОИС;
- срок действия охранного документа (патента, свидетельства) на момент оценки его стоимости;
- издержки владельца исключительных прав на разрешение патентно-правовых конфликтов, в том числе в судебном порядке, по оцениваемомуОИС;
- ожидаемые поступления лицензионных платежей по данному объекту интеллектуальной собственности при условии фиксации объемовплатежей лицензионными договорами, зарегистрированными в установленном действующим законодательством порядке;
- ожидаемые денежные поступления от продажи копий ПП;
- ожидаемая экономия текущих затрат при использовании ОИС в производстве.
Проблемы возникают в том случае, когда одна организация является разработчиком алгоритмов, а другая - исходного текста ПП.Если эти организации независимы друг от друга, то в балансе каждой из них отражаются только затраты, произведенные в каждой конкретной организации.
При расчёте рыночной цены прав на ПП затратным методом должны учитываться все совокупные затраты на синтетический ОИС, в том числе изатраты дилера, создающего для конечногопользователя исполняемый модуль, а также вознаграждение, распределение которого между авторами ПП должно найтиотражение в договоре о передаче прав на ПП.
При определении рыночной, а также инвестиционной стоимости авторского права на ПП может быть применён метод сравнения срыночными продажами аналогов.
Вышеуказанный метод основан на известном в теории оценивания принципе замещения. Он равно применим при расчете рыночной стоимостипо практике продаж аналогичных объектов и по практике продаж аналогичных имущественных прав. Например, метод сравнения рыночных продаж может бытьприменим как при установлении цены на копию ПП, так и при установлении цены переуступки имущественных прав на ПП.
Сущность метода заключается в сравнении по цене и потребительных свойствах сопоставимых объектов оценки (аналогов), и на этойоснове установления стоимостной оценки нового ОИС.
При применении метода сравнения рыночных продаж выявляется цена покупателя, которого не интересуют затраты разработчика инастоящего владельца ОИС, а только потребительные свойства (качество, конкурентоспособность) покупаемого ими товара. Как правило, эта цена вышерассчитанной затратным методом и может быть принята как верхняя граница оценки.
Трудность установления цены по вышеуказанному методу прежде всего заключается в выявлении конкретного набора потребительных свойств(технико-экономических характеристик, параметров, функций) оцениваемого объекта и их влияния на цену ОИС.
При расчете цены сервисной программы для ЭВМ может приниматься следующий набор потребительских характеристик (функций):
- набор возможностей;
- удобство использования;
- общая оценка скорости;
- качество документации.
Каждому конкретному случаю оценки отвечает определенный набор характеристик, параметров, функций (в дальнейшем текстефункций).
Алгоритм стоимостной оценки по методу аналогичных продаж состоит из следующей последовательности процедур:
1. Выявление основных функций ОИС;
2. Оценка в баллах качества выполнения отдельных функций для аналогов и оцениваемого ОИС;
3. Выявление экспертного мнения о коэффициентах веса (важности, полезности) функций;
4. Определение интегрального показателя качества выполнения функций для оцениваемого ОИС и его аналогов;
5. Определение "стоимости" балла качества;
6. Определение диапазона рыночной стоимостной оценки ОИС;
7. Формирование экспертного мнения о наиболее обоснованной рыночной стоимости оцениваемого ОИС.
Формализовано можно представить, что оцениваемый объект сравнивается с аналогами на множестве {Ni}, где i - число аналогов ( i =1, n).
Оцениваемый объект и аналоги характеризуются множеством показателей {Nija}, ( j = 1, n), где Nija является балльной оценкойкачества выполнения j-ой функции i-го аналога.
В случае невозможности определения натуральных значений параметров - функций необходимо провести экспертную оценку. Работаэкспертов строится но следующему алгоритму:
- формулирование задачи;
- выявление мнения каждого эксперта;
- выявление крайних суждений;
- исследование причин расхождения во мнениях;
- доведение до всех экспертов, участвующих в оценке, указанных выше результатов обработки мнений;
- анализ каждым экспертом указанных выше результатов и переоценка своего первоначального мнения или сохранение его в силе;
- выявление преобладающего, наиболее обоснованного мнения.
ЗАКЛЮЧЕНИЕ.
Таким образом можно сделать вывод:
Существенной особенностью постиндустриальной эпохи стало появление рынка авторских прав на программные продукты. Стоит сразу жеотметить разницу понятий " программный продукт " (ПП) и "программа для ЭВМ",которая полностью определена.
В рыночной экономике авторские права на ПП выступают в виде принципиально нового информационного ресурса и продукта, вовлечениекоторого в хозяйственный оборот происходит в процессе коммерциализации (купли-продажи, переуступки прав собственности) и капитализации (постановки набаланс, инвестирования в уставный капитал).
Наиболее сложной, но интересной в теоретическом и практическом плане является такая обязательная процедура введения вхозяйственный оборот как стоимостная оценка имущественных прав на ПП. Еще далеко не разрешены все проблемы, связанные со стоимостной оценкой объектовпромышленной собственности, а оценка стоимости авторских прав на ПП тем более затруднена, т.к. ПП является сложным синтетическим и часто составным объектоминтеллектуальной собственности (ОИС) .
ЛИТЕРАТУРА:
1. Ефимов А.Н. Программа для ЭВМ как объект гражданского оборота. Московский оценщик °1,1999
2. Федотова М.А. Сколько стоит бизнес? методы оценки, М. Перспектива 1996
3. Валдайцев С.В. Оценка бизнеса и инноваций, М - 1997.
|
