Реферати

Реферат: Поняття програмного продукту

Стратегія і мети рекламної кампанії. Планування підготовки презентації. Робота після закінчення презентації. Стратегія для стимулювання попиту на товар з боку кінцевих споживачів. Цільова аудиторія. Креативний план. Креативная кампанія. Розробка фірмового упакування продукції.

На чому коштує математика. Математика як одна із самих древніх і консервативних наук. Поняття числа, побудова їхніх безлічей, особливості натуральних чисел, представлення ірраціональних чисел. Зміст категорії "простір", наслідку застосування некоректних методів пізнання.

Політичний і державний устрій земель давньоруської держави. Віче і князь у давньоруській державі. Російська правда. Походження. Судовий процес по Російській Правді.

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

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

ВВЕДЕННЯ.

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

Чи Потрібен програмний продукту деякий відмітний знак, підтверджуючий його якість? Здавалося б, ринкова економіка дає негативну відповідь на це питання - високий попит підтвердить якість товару. Своєрідним знаком якості часто служить гучне ім'я постачальника, весь відомий 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.