ВСТУП.
Суттєвою рисою постіндустріальної епохи стала поява ринку авторських прав на програмні продукти. Варто відразу жеотметіть різницю понять "програмний продукт" (ПП) і "програма для ЕОМ", яка повністю визначена.
Чи потрібен програмний продукту якийсь відмітний знак, що підтверджує його якість? Здавалося б, ринкова економіка даетотріцательний відповідь на це питання - високий попит підтвердить якість товару. Своєрідним знаком якості часто служить гучне ім'я постачальника, всемізвестний 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 годуукрупненних нормах часу на розробку ПП до числа основних факторів, що впливають на трудомісткість розробки, віднесені:
- Обсяг ПП у тисячах умовних машинних команд;
- Складність ПП;
- Ступінь новизни;
- Ступінь використання при розробці стандартних модулів, типових програм і ПС.
Проте з переходом на ПК вищевказані укрупнені норми часу застаріли, і трудомісткість визначається на основі методів аналогійі експертних оцінок, а найчастіше "уторговивается" при укладанні договорів.
Основними факторами, що визначають вартість об'єктів інтелектуальної власності, є:
- Витрати власника виключних прав на створення, розробку об'єкта правової охорони (за кошторисом витрат за договором-підряду наНІОКР);
- Витрати власника виключних прав на патентування (реєстрацію) об'єктів інтелектуальної власності, включаяпошліни та інші витрати на підтримання охоронних документів у силі;
- Витрати на організацію використання ОІВ, включаючи і витрати на його маркетинг;
- Витрати на страхування ОІВ;
- Термін дії охоронного документа (патенту, свідоцтва) на момент оцінки його вартості;
- Витрати власника виключних прав на дозвіл патентно-правових конфліктів, в тому числі в судовому порядку, за оценіваемомуОІС;
- Очікувані надходження ліцензійних платежів по даному об'єкту інтелектуальної власності за умови фіксації об'емовплатежей ліцензійними договорами, зареєстрованими у встановленому чинним законодавством порядку;
- Очікувані грошові надходження від продажу копій ПП;
- Очікувана економія поточних витрат при використанні ОІВ у виробництві.
Проблеми виникають у тому випадку, коли одна організація є розробником алгоритмів, а інша - вихідного тексту ПП.Еслі ці організації незалежні один від одного, то в балансі кожної з них відображаються тільки витрати, вироблені в кожній конкретній організації.
При розрахунку ринкової ціни прав на ПП витратним методом повинні враховуватися всі сукупні витрати на синтетичний ОІВ, у тому числі ізатрати дилера, що створює для конечногопользователя виконуваний модуль, а також винагороду, розподіл якого між авторами ПП має найтіотраженіе в договорі про передачу прав на ПП. < br /> При визначенні ринкової, а також інвестиційної вартості авторського права на ПП може бути застосований метод порівняння сриночнимі продажами аналогів.
Вищевказаний метод заснований на відомому в теорії оцінювання принципі заміщення. Він так само застосуємо при розрахунку ринкової стоімостіпо практиці продажів аналогічних об'єктів і з практики продажу аналогічних майнових прав. Наприклад, метод порівняння ринкових продажів може битьпріменім як при встановленні ціни на копію ПП, так і при встановленні ціни переуступки майнових прав на ПП.
Суть методу полягає в порівнянні за ціною і споживчих властивостях порівнянних об'єктів оцінки (аналогів), і на етойоснове встановлення вартісної оцінки нового ОІВ.
При застосуванні методу порівняння ринкових продажів виявляється ціна покупця, якого не цікавлять витрати розробника інастоящего власника ОІВ, а тільки споживчі властивості (якість, конкурентоспроможність) купується ними товару. Як правило, ця ціна вишерассчітанной витратним методом і може бути прийнята як верхня межа оцінки.
Труднощі встановлення ціни за вищевказаною методу насамперед полягає у виявленні конкретного набору споживчих властивостей (техніко-економічних характеристик, параметрів, функцій) оцінюваного об'єкта та їх впливу на ціну ОІВ.
При розрахунку ціни сервісної програми для ЕОМ може прийматися такий набір споживчих характеристик (функцій):
- Набір можливостей;
- Зручність використання;
- Загальна оцінка швидкості;
- Якість документації.
Кожному конкретному випадку оцінки відповідає певний набір характеристик, параметрів, функцій (надалі текстефункцій).
Алгоритм вартісної оцінки за методом аналогічних продажів складається з наступної послідовності процедур:
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.