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

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

Чи потрібен програмний продукту якийсь відмітний знак, що підтверджує його якість? Здається, ринкової економіки даетотрицательный у відповідь це запитання — високого попиту підтвердить якість товару. Своєрідним знаком якості нерідко слугує гучне ім'я постачальника, всемизвестный 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}, де і - число аналогів (і =1, n).

Оцінюваний об'єкт і аналоги характеризуються безліччю показників {Nija}, (j = 1, n), де Nija є бальної оценкойкачества виконання j-ой функції i-го аналога.

Що стосується неможливості визначення натуральних значень параметрів — функцій необхідно провести оцінку. Работаэкспертов будується але наступному алгоритму:

— формулювання задачи;

— виявлення думки кожного эксперта;

— виявлення крайніх суждений;

— дослідження причин розбіжності в мнениях;

— доведення до всіх експертів, що у оцінці, зазначених вище результатів обробки мнений;

— аналіз кожним експертом зазначених вище результатів і переоцінка свого початкового думки чи збереження їх у силе;

— виявлення переважаючого, найбільш обгрунтованого мнения.

ЗАКЛЮЧЕНИЕ

.

Відтак можна дійти невтішного висновку:

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

У ринковій економіці авторські права на ПП виступають на вигляді принципово нового інформаційного ресурсу і продукту, вовлечениекоторого до господарського обороту проходить у процесі комерціалізації (купівлі-продажу, переуступки прав власності) і капіталізації (постановки набаланс, інвестування на статутний капитал).

Найбільш складної, але цікавою в теоретичному і практичному плані така обов’язкова процедура запровадження вхозяйственный оборот як непідвладна інфляції вартісна оцінка майнові права на ПП. Ще далеко ще не дозволені всі проблеми, пов’язані з вартісної оцінкою объектовпромышленной власності, а оцінка вартості авторських прав на ПП тим паче утруднена, т.к. ПП є синтетичним і найчастіше складовим объектоминтеллектуальной власності (ОИС) .

1. Єфімов О. Н. Програма для ЕОМ як об'єкт громадянського обороту. Московський оцінювач °1,1999.

2. Федотова М. А. Скільки коштує бізнес? методи оцінки, М. Перспектива 1996.

3. Валдайцев С. В. Оцінка бізнесу і інновацій, М — 1997.