Поняття програмного продукту

ВСТУП.

Суттєвою особливістю постіндустріальної епохи стала поява ринку авторських прав на програмні продукти. Варто відразу ж зазначити різницю понять "програмний продукт" (ПП) і "програма для ЕОМ", яка повністю визначена.

Чи потрібен програмний продукту якийсь відмітний знак, що підтверджує його якість? Здавалося б, ринкова економіка дає негативну відповідь на це питання - високий попит підтвердить якість товару. Своєрідним знаком якості часто служить гучне ім'я постачальника, всім відомий 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 plus Fee", тобто витрати плюс винагорода. На переговорах з укладення договору сторони узгодять кошторис витрат на розробку (підряд, замовлення), а також винагороду у відсотках або частці від суми договірної кошторису (не нижче ставки банківського відсотка). На цей принцип накладається його модифікація "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.