Технические характеристики
Підсумкова оцінка______________ Підпис студента______________
Підпис викладача______________
Питання на залік з інтелектуальної власності.
1. Поняття права інтелектуальної власності. 2. Підходи до оцінки інтелектуальної власності. 3. Еволюція авторського права. 4. Характеристика життєвого циклу об’єктів інтелектуальної власності. 5. Становлення права на результати науково-технічної творчості (еволюція патентного права). 6. Методи оцінки прав на об’єкти інтелектуальної власності. 7. Загальна характеристика міжнародних документів, якими було започаткована міжнародна охорона інтелектуальної власності. 8. Управління правами інтелектуальної власності на різних етапах існування об’єкту інтелектуальної власності. 9. Міжнародні організації в сфері охорони інтелектуальної власності. 10. Поняття та визначення контрафактних порушень авторського права і суміжних прав. 11. Автор як первинний суб’єкт права інтелектуальної власності. 12. Поняття недобросовісної конкуренції. 13. Особисті немайнові і майнові права автора (винахідника). 14. Дії, що визнаються порушенням прав на винаходи (корисну модель). 15. Держава як володілець прав інтелектуальної власності. 16. Дії, що визнаються порушенням прав на промислові зразки. 17. «Вільне використання» об’єктів права інтелектуальної власності. 18. Дії, що визнаються порушенням прав на торговельну марку. 19. Дати визначення об’єктів авторського права і суміжних прав. 20. Дайте визначення формам захисту права інтелектуальної власності. 21. Поняття та види похідних творів. 22. Функції та завдання Всесвітньої організації інтелектуальної власності. 23. Джерела права інтелектуальної власності України. 24. Органи, які здійснюють загальний порядок захисту права інтелектуальної власності. 25. Поняття та об’єкти винаходу. 26. Цивільно-правовий захист права інтелектуальної власності. 27. Поняття промислового зразка. Вимоги до правової охорони промислового зразка. Відмінність промислового зразка від корисної моделі. 28. Адміністративно-правовий спосіб захисту права інтелектуальної власності. 29. Поняття корисної моделі. Вимоги до правової охорони корисної моделі. 30. Кримінальна відповідальність за порушення права інтелектуальної власності. 31. Поняття та вимоги до правової охорони топографії інтегральної мікросхеми. 32. Захист права інтелектуальної власності на кордоні. 33. Поняття та вимоги щодо правової охорони прав на сорти рослин та породи тварин. 34. Угода TRIPS (Угода з торгівельних аспектів прав інтелектуальної власності) як одна з найважливіших угод Світової організації торгівлі. 35. Поняття та правова охорона наукового відкриття. 36. Основні функції ДП «Українське агентство з авторських і суміжних прав». 37. Поняття та правова охорона раціоналізаторської пропозиції. 38. Основні функції ДП «Український інститут промислової власності». 39. Поняття та правова охорона комерційної таємниці. 40. Поняття та роль патентної документації. 41. Поняття та види торгівельних марок. 42. Поняття патенту. Вимоги патентоспроможності. 43. Вимоги щодо надання правової охорони торгівельної марки. 44. Процедура патентування винаходу (корисної моделі). 45. Поняття та види зазначення походження товару. 46. Поняття та істотні умови ліцензійного договору. 47. Поняття та правова охорона фірмового найменування. 48. Види ліцензійних платежів. 49. Права та обов’язки патентовласників. 50. Процедура реєстрації торгівельної марки. 51. Права та обов’язки власника свідоцтва на торгівельну марку. 52. Реєстрація прав на кваліфіковане зазначення походження товару. 53. Поняття та істотні умови авторського договору. 54. Види ліцензій. 55. Поняття та види співавторства. 56. Види авторських договорів. 57. Суб’єкти суміжних прав. 58. Охорона прав на добре відомий знак. 59. Поняття та види об’єктів суміжних прав. 60. Дострокове припинення дії свідоцтва на торговельну марку.
Spider Project (Спайдер Проджект) — пакет з управління проектами, спроектований та розроблений російським розробником компанією «Спайдер Проджект» Технічні характеристики Spider Project § Необмежена кількість операцій; § Необмежена кількість ресурсів; § Необмежена кількість календарів; § Будь-яка кількість ієрархічних структур робіт в кожному проекті; § Будь-яка кількість ієрархічних структур ресурсів в кожному проекті; § Будь-яка кількість ієрархічних рівнів в кожній з ієрархічних структур; § Будь-яка кількість статей прибутків і видатків; § Будь-яка кількість центрів витрат і матеріалів; § Будь-яка кількість версій проекту і можливість порівнювати поточну версію проекту з будь-якою іншою версією і проектом; § Оптимізація розкладу виконання робіт за обмежених ресурсів, за заданих графіках постачань і фінансування; § Мультіпроектне управління; § Вартісний аналіз за методикою NASA (Earned Value Analysis); § Можливість порівняння між собою будь-яких двох версій проекту; § Будь-яка кількість базових версій; § Діаграми Гантта для робіт і ресурсів; § Гістограми завантаження ресурсів; § Графіки витрат і потреби в матеріалах; § Побудова графіків і гістограм за будь-якими показниками звітів; § Моделювання як видатків, так і прибутків; § Моделювання постачань і витрат матеріалів; § Моделювання виробництва ресурсів; § Складання розкладу виходячи з обсягів робіт, кваліфікації та продуктивності ресурсів; § Три види мережевих діаграм; § Організаційні діаграми для представлення ієрархій робіт і ресурсів; § Плавне масштабування діаграм; § Табличні та графічні звіти; § Вбудована система обліку. 2. Primavera — программное обеспечение для управления проектом, которое используется для управления и контроля проектов, отслеживания ресурсов, материалов и оборудования, используемого на проект. Primavera в основном используется для обработки очень больших и сложных проектов, особенно в машиностроении и строительстве (например, строительство атомных электростанций). Сегодня (2010), Oracle предлагает решение, по управлению портфелем проектов. Primavera предоставляет своим пользователям следующие возможности: § Выбор нужного сочетания стратегических проектов. § Обеспечение корпоративного управления проекта. § Улучшение процессов и методов. § Улучшение совместной работы проекта. § Измерение прогресса в достижении целей. § Связь проектов со стратегией. Spider Project – нацеленность на успех
В.И.Либерзон, PMP
Система управления проектами Spider Project разрабатывалась на основании богатого опыта управления проектами в России и отличается от всего, что предлагается западными поставщиками. Система поддерживает традиционные подходы к управлению проектами, описанные в PMBOK Guideâ и реализованные в большинстве западных пакетов, но при этом предлагает и много такого, что не имеет аналогов ни в теории, ни в практике управления проектами на Западе. Поэтому голое описание технических характеристик не будет достаточным для понимания отличий этого пакета от конкурентов, и мы остановимся особо на тех особенностях пакета, которые имеют отношение к предлагаемой методологии управления проектами с использованием Spider Project. Отличительной чертой этой методологии является управление вероятностью успешной реализации проектов с учетом всех ограничений, рисков и неопределенностей, с которыми приходится сталкиваться менеджерам проектов. Особое внимание в пакете уделяется моделированию работы и управлению ресурсами проекта
Технические характеристики
Начнем с перечисления характеристик пакета Spider Project, в котором жирным шрифтом выделено то, что либо не имеет прямых аналогов в других пакетах, либо решено совершенно иначе, и во второй части этой статьи будет изложено подробнее: · Неограниченное количество операций, · Неограниченное количество ресурсов, · Неограниченное количество календарей, · Неограниченное количество иерархических структур работ в каждом проекте, · Неограниченное количество иерархических структур ресурсов в каждом проекте, · Неограниченное количество иерархических уровней в каждой из иерархических структур, · Неограниченное количество статей затрат, · Неограниченное количество центров затрат, ресурсов и материалов, · Моделирование как расходов, так и доходов, · Моделирование как расхода, так и производства ресурсов, · Корректное моделирование неполной загрузки ресурсов, · Моделирование независимых назначений ресурсов и сменной работы, · Моделирование переменной загрузки ресурсов на работах проекта, · Составление расписания исходя из объемов работ, квалификации и производительности ресурсов, · Оптимизация расписания исполнения работ при ограниченных ресурсах с учетом графиков производства, поставок и финансирования, · Средства для стабилизации расписания, · Определение ресурсного критического пути (Critical Chain), · Определение резервов времени на исполнение операций с учетом ограниченности ресурсов проекта, · Неограниченное количество проектных баз данных (справочников), · Использование библиотеки типовых фрагментов, · Встроенный анализ рисков, · Определение управленческих резервов по срокам, стоимости, материалам и т.д., необходимых для успешного исполнения проекта, · Подсчет текущей вероятности успешного исполнения директивных параметров проекта, · Стоимостной анализ по методике Earned Value Analysis, · Неограниченное количество версий проекта, · Ведение архивов проектов, · Возможность сравнения между собой любых двух версий проекта, · Встроенная система учета, · Мультипроектное управление и групповая работа с проектами, · Неограниченное количество пользовательских полей, · Пользовательские формулы, связывающие показатели проекта, · Произвольные фильтры, · Диаграммы Гантта для работ и ресурсов, · Гистограммы загрузки ресурсов, · Графики затрат, cash flow и движения материалов, · Три вида сетевых диаграмм, · Организационные диаграммы для представления иерархий работ и ресурсов, · Линейные диаграммы, · Плавное масштабирование диаграмм, · Табличные и графические отчеты как по плану, так и по исполнению проекта, · Экспорт и импорт информации в SQL базы (Oracle, Access и т.п.), Lotus Notes, программы MS Office, Html и текст, · Импорт проектов и информации из сметных строительных программ, · Групповая работа через Интернет. Как видите, жирным шрифтом выделено довольно много, поэтому обо всем придется упомянуть очень коротко.
2. Особенности пакета
2.1. Множественные иерархические структуры работ.
Существуют различные способы и рекомендации по построению иерархической структуры работ. Оптимальность здесь отсутствует, а удобство определяется конкретным проектом. В пакете Spider Project пользователям дается возможность ввода и параллельного использования неограниченного количества иерархических структур работ для операций одного проекта. Как правило, используется, по меньшей мере, три ИСР, позволяющие проанализировать проект с разных сторон. ИСР по объектам получается, если результат проекта на верхнем уровне иерархии разбивается на результаты по отдельным объектам проекта, а затем по процессам (например, проектирование, реализация, и т.д.). ИСР по процессам на верхнем уровне использует процессы, а на более низких – объекты проекта. Кроме того, мы рекомендуем использовать и структуру ответственности, группируя работы в соответствии с распределением между отдельными исполнителями проекта ответственности за реализацию его частей. В конкретных проектах могут быть полезны и другие структуры, определяемые отношениями отчетности и необходимостью агрегирования проектной информации. В частности, в строительных проектах одна из структур может соответствовать смете затрат. Это необходимо для анализа исполнения проекта и сопоставления фактических и сметных затрат. Иерархические структуры могут иметь двойное назначение. При составлении компьютерной модели проекта ИСР помогает ввести (и не пропустить) операции проекта, на которые разбивается нижний уровень ИСР и на исполнение которых впоследствии назначаются ресурсы. Для этого одна из структур используется в качестве основной, а использование других структур позволяет проконтролировать созданную структуру проекта и внести в нее необходимые дополнения. После создания компьютерной модели ИСР используются для агрегации проектной информации и подготовки требуемой отчетности. Поэтому возможно создание дополнительных структур, в том числе неполных (из которых исключены некоторые операции проекта), исходя из требований отчетности и анализа.
2.1. Множественные иерархические структуры ресурсов.
Аналогично можно создавать и использовать для целей анализа и агрегации информации множественные структуры ресурсов. Это особенно важно и полезно при мультипроектном управлении. При матричной структуре управления проектом мы рекомендуем использовать по меньшей мере две такие структуры – функциональную, в которой ресурсы группируются в соответствии с их положением в функциональной структуре управления предприятием и подводятся всевозможные итого (по загрузке ресурсов, затратам, доходам и т.д.) по функциональным отделам, и проектную, в которой ресурсы группируются в соответствии с их иерархией в проектах и итого подводятся в соответствии с зонами ответственности исполнителей проекта.
2.3. Статьи затрат и центры стоимостей, ресурсов и материалов
В серьезных проектах, как правило, необходим и достаточно серьезный финансовый анализ, который касается не только затрат по проекту в целом, но и по подпроектам и фазам, отдельным статьям расходов и доходов, по группам ресурсов и материалов, в разных валютах и т.п. Поэтому в пакете пользователям предоставляется возможность ввода и использования в проектах неограниченного количества статей затрат, причем в разных валютах, с возможностью создания любых центров затрат, и возможностью применения всех инструментов планирования (в том числе выравнивания) и анализа не только к общим затратам, но к любым центрам и компонентам стоимости. Кроме того, полезно иметь возможность группировки материалов и ресурсов и получения отчетности не только по отдельным ресурсам и материалам, но и по этим группам, которые в пакете называются центрами ресурсов и материалов.
2.3. Моделирование доходов и производства
В проектах наряду с расходом ресурсов и материалов может встретиться их производство или поставки, наряду с расходами финансовых средств полезно моделировать и доходы. Особенно это важно для служб заказчиков, которые непосредственно ресурсами проектов не управляют, но управляют поставками основных материалов и финансированием работ. Кроме того, это очень важно для проектов, в которых на одних работах производятся ресурсы или материалы, которые используются или расходуются на других. Spider Project позволяет моделировать производство и финансирование, и использовать эту информацию для составления расписания работ с учетом ограниченности ресурсов, материалов и финансирования проекта. Пользователи пакета могут рассчитать, как отразится на сроках реализации проекта та или иная схема поставок и финансирования, определить сроки окупаемости капиталовложений и получить соответствующие отчеты – cash flow по любым составляющим и центрам затрат, а также по любым материалам проекта.
2.4. Моделирование работы ресурсов
Возможности моделирования работы ресурсов, заложенные в пакете Spider Project, сильно отличают пакет от западных аналогов. Прежде всего, отметим, что в качестве исходной информации по операциям проекта наряду с длительностью операций можно задавать физические объемы работ, которые следует произвести, и производительности назначенных ресурсов. Кроме того, в пакете заложена возможность назначать на исполнение операции не конкретные ресурсы, а пулы назначений – группы ресурсов, которые способны исполнить рассматриваемую операцию, хотя и с разной производительностью. Задав либо суммарное количество, либо суммарную производительность ресурсов из пула, пользователь может предоставить программе самой выбрать оптимальный состав ресурсов для исполнения операции. Длительность операции вычисляется в процессе составления расписания работ, исходя из производительности и процентной загрузки назначенных (выбранных пакетом) ресурсов. К тому же следует учесть, что в пакете моделируется и переменная загрузка ресурсов, определяемая необходимостью их использования на параллельных работах. При моделировании неполной загрузки учитывается и количество назначенных ресурсов, и их загрузка. Это отличает подход Спайдера от подходов, используемых в других пакетах, в которых задается только суммарная загрузка ресурсов, но не их количество. При таком подходе моделирование неполной загрузки может быть некорректным, а информации о потребностях проекта в ресурсах - неверной. Еще одна особенность моделирования работы ресурсов в пакете – возможность назначения на исполнение работ независимых команд. Для этих команд можно задать выполняемые ими объемы или длительности назначений (после выполнения которых команда снимается с выполнения операции), но можно задать и их работу до тех пор, пока операция не будет выполнена. В этом случае объемы работ, выполняемые каждой из команд, неизвестны и зависят от ситуации, складывающейся при составлении расписания выполнения работ. Это позволяет моделировать сменную работу и не имеет аналогов в западных пакетах. В процессе исполнения работ проекта ресурсы могут сниматься с менее приоритетных работ и назначаться на более приоритетные. При параллельном исполнении нескольких работ ресурсы могут сниматься частично (на определенный процент своего рабочего времени). Кроме того, некоторые операции могут потреблять свободное время, остающееся у ресурсов после назначения на исполнение операций проекта (работы, выполняемые в "«фоновом» режиме). Возможность моделирования переменной загрузки ресурсов позволяет включить рутинную деятельность в компьютерную модель реализации проектов организации. Удобные инструменты для управления назначениями ресурсов открывают имеющиеся в пакете возможности назначения на операции мультиресурсов. Мультиресурс – это устойчивая группа вместе работающих ресурсов (например, бригада). Во-первых, назначая мультиресурс, пользователь назначает все входящие в него ресурсы, то есть облегчает свою работу. Но более интересно то, что в любой момент можно изменить состав мультиресурса и распространить эти изменения на все его назначения. Такая возможность облегчает анализ «что если», позволяя эффективно подбирать и изменять составы назначенных бригад.
2.5. Особенности расчета расписания исполнения проекта
Предметом особой гордости разработчиков является оптимизация расписания исполнения работ проекта при ограниченных ресурсах. Расписания, составляемые пакетом, как правило, короче тех, что составляют другие пакеты управления проектами. При этом учитываются ограничения на поставки и финансирование. Сокращение сроков исполнения проекта позволяет сэкономить значительные средства. Кроме того, в пакете имеется и средство стабилизации расписания. Дело в том, что после того, как расписание работ утверждено, подписаны контракты и сделаны заказы на поставки материалов и оборудования, изменение расписания даже на более оптимальное крайне нежелательно. Поэтому имеется возможность задать опцию составления расписания, при котором сохраняется принятый ранее порядок исполнения работ.
2.6. Ресурсный критический путь
Важной особенностью пакета является вычисление ресурсного критического пути, то есть тех операций проекта, задержка исполнения которых приводит к задержке завершения проекта с учетом имеющихся ограничений на ресурсы проекта. Ресурсный критический путь пакет вычисляет с самой первой своей версии, которая была выпущена еще в конце 1992 года. Теперь и мир пришел к тому, что это важно, но тем не менее Spider Project пока остается единственным пакетом, который умеет это делать. Нашумевшая Критическая цепь (Critical Chain), о которой написал Голдратт в одноименной книге и которая сейчас широко обсуждается мировым сообществом менеджеров проекта, есть не что иное, как ресурсный критический путь. Практически все, что предлагается в теории Критической цепи, давно реализовано в пакете Spider Project. Наряду с вычислением ресурсного критического пути пакет вычисляет резервы времени, имеющиеся у ресурсов на исполнение тех или иных операций с учетом всех ограничений, имеющихся в проекте, что очень важно для принятия управленческих решений. На рис. 1 проиллюстрировано понятие ресурсного критического пути и резервов времени на исполнение операций. В проекте РКП на операции 2 и 4 назначен ресурс А, который имеется в одном экземпляре, а потому они не могут исполняться параллельно. Исполнение операций 1 и 5 может быть отложено до моментов, показанных на диаграмме полыми полосками. Ресурсный критический путь – операции 3, 4 и 2.
2.7. Поддержка корпоративных стандартов
Spider Project изначально спроектирован таким образом, чтобы поддерживать корпоративные стандарты управления п
|