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

Понятие програмного продукта ВВЕДЕНИЕ.

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

.

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

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

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

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

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

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

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