Завдання

Дата добавления: 2015-08-27; просмотров: 731

Підсумкова оцінка______________ Підпис студента______________

Підпис викладача______________

Питання на залік з інтелектуальної власності.

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 изначально спроектирован таким образом, чтобы поддерживать корпоративные стандарты управления проектами. Для этого в пакете предусмотрена возможность создания непосредственно в пакете библиотек типовых фрагментов проектов, а также всевозможных баз данных, включая производительности ресурсов на типовых назначениях, объемы и длительности типовых операций, расход материалов и расценки на единичных объемах типовых операций и назначений и т.д. Пользователи могут создать (или импортировать из стандартных SQL баз, таких как Oracle, Access и т.д.) и любые другие базы данных и использовать их во всех проектах компании.

Проекты могут создаваться путем включения типовых фрагментов (с автоматической корректировкой объемов и длительностей работ, потребности в материалах и стоимости). Это позволяет внедрять типовые подходы к созданию компьютерных моделей проектов, использовать в проектах корпоративные и государственные нормы и расценки.

2.8. Анализ рисков и технология управления Spider Project

Опыт и анализ проектов показал, что детерминированные расписания имеют низкую (обычно 20 - 35%) вероятность успешного исполнения. В данной статье из-за недостатка места мы не будем останавливаться на причинах этого, но отметим, что без анализа рисков качественного анализа и управления проектами обеспечить нельзя. Встроенный в Спайдер анализ рисков предназначен для определения реальных сроков и бюджетов проектов и позволяет определять и анализировать вероятность успешного исполнения директивных параметров проекта.

Пользователям предлагается для всей исходной информации проекта определять не только наиболее вероятные, но и оптимистические и пессимистические значения. Это позволяет, наряду с вероятной, создать оптимистическую и пессимистическую версии проекта. Следует подчеркнуть, что в этих версиях могут отличаться не только характеристики тех же самых операций и ресурсов, но и состав работ. Так, например, в пессимистической версии могут быть предусмотрены переделки, дополнительные циклы тестирования и т.д. Если пользователь задаст желательные вероятности соблюдения плановых сроков контрольных событий, соблюдения запланированного бюджета, расхода основных материалов, то пакет определит целевые сроки, целевой бюджет и целевые потребности в материалах, которые могут быть использованы в контрактных переговорах. Кроме того, пакет определит резервы времени, стоимости и расхода материалов, которые следует предусмотреть для исполнения операций проекта, чтобы обеспечить заданную вероятность соблюдения целевых параметров проекта.

Целевой график является основой для контрактных переговоров, однако их результаты могут привести к другим директивным параметрам и пакет позволяет вычислить вероятность успешного исполнения намеченных директивных дат, затрат, расхода материалов. Это служит необходимой информацией для принятия обоснованных управленческих решений.

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

Нацеленность на успех – отличительная черта методологии управления Spider Project.

2.9. Ведение архивов проекта, анализ отклонений

В пакете предусмотрена возможность создания неограниченного количества версий проекта, которые можно сравнивать между собой и определять отклонения по любым параметрам. Эта возможность не только используется при анализе «что если», но и позволяет вести архивы проекта и контролировать динамику изменений показателей проекта, что очень важно для принятия управленческих решений. Архивы проекта также используются для анализа хода реализации проекта и создания послепроектного отчета.

2.10. Система учета

В пакет Spider Project встроена полноценная система оперативного учета, которая позволяет собирать информацию по выполненным объемам, отработанной длительности, произведенным затратам и истраченным материалам по любой операции и любому ресурсу проекта, а также агрегировать эту информацию по любой из используемых иерархических структур работ и ресурсов.

В результате пользователи могут получить полную информацию о работах, произведенных за любой период любым ресурсом, любым подразделением, на любой операции, фазе или по проекту в целом.

Пакет также ведет архивы учета, что позволяет контролировать ту отчетность, которая послужила исходной учетной информацией.

2.11. Особенности групповой работы

В пакете используется необычная технология групповой работы с проектами, которая не имеет аналогов. Разработчики намеренно отказались от стандартной клиент-серверной технологии, плохо приспособленной для особенностей решения задач управления проектами.

В проектном управлении важно иметь срезы состояния проекта на различные моменты времени для анализа, подготовки отчетности и ведения архивов. При мультипроектном управлении, когда информация вводится в одну базу из разных мест, в разное время и по операциям, принадлежащим разным фазам, обеспечить такие срезы не просто. Кратко опишем технологию, принятую в Spider Project.

Составляется перечень менеджеров отдельных фаз и подпроектов с указанием их адресов в локальной или глобальной сети (для входящей и исходящей информации). Фазам проекта в структуре ответственности проекта сопоставляются менеджеры, которые этими фазами управляют, или имеют право вводить в модель учетные данные по исполнению проекта. По команде менеджера проекта фазы проекта копируются (репликация данных) и рассылаются ответственным (для этого достаточно в меню проекта выбрать пункт Разослать подпроекты). Те, кто отвечают за исполнение фаз, получают полноценные компьютерные модели своих фаз для ведения учета, внесения корректировок в исходную информацию, подготовки отчетов и т.д. В любой момент менеджер проекта может собрать информацию по текущему состоянию проектов от ответственных менеджеров своих подпроектов (пункт меню Собрать подпроекты) и обновить компьютерную модель проекта в соответствии с его текущим состоянием.

Такая организация работ требует достаточно жесткой регламентации (своевременной рассылки и сборки проекта), однако снижает опасность возникновения проблем с компьютерной моделью проекта (всегда сохраняется предыдущая версия, информация распределена по разным компьютерам, что позволяет восстановить модель при аппаратных сбоях). Кроме того, такая организация работ нацелена именно на создание срезов проектов на определенные моменты и их последующего хранения. Для этого достаточно потребовать от менеджеров фаз периодически вводить информацию о состоянии проекта на определенное время (например на 18 часов во вторник). Даже если информация была введена в разное время, она будет отражать состояние проекта именно на согласованные моменты.

2.12. Отчетность

Spider Project поддерживает стандартные формы отчетности, имеющиеся в аналогичных программах – таблицы, сетевые и организационные диаграммы, диаграмма Гантта. Однако можно получить и дополнительные графические формы отчетности. В частности, диаграмму Гантта для ресурсов проекта и Линейную диаграмму.

Диаграмма Гантта для ресурсов аналогична диаграмме Гантта для операций, но отображаются на ней периоды занятости ресурсов и назначения этих ресурсов на исполнение операций проекта.

В линейной диаграмме показывается продвижение проекта по метрике, которую определяет пользователь. Для линейно протяженных проектов (строительство трубопроводов, дорог и т.п.) в качестве метрики могут быть приняты километры трассы, для строительства зданий – этажи, метрика может быть качественной (1-й этап, 2-й этап и т.д.).

В линейной диаграмме по горизонтали откладывается метрика проекта, по вертикали – время. На диаграмме разными цветами и видами линий отображаются работы различных видов в виде графиков, отображающих плановое состояние данного вида работ в различное время (например – в какое время на каком километре должны проводиться рассматриваемые работы). Получается очень компактное и наглядное отображение проекта – на странице А4 можно отобразить ту же информацию, которая на диаграмме Гантта займет много листов формата А0.

Рис.2. Линейная диаграмма для некоторых работ строительства Каспийского трубопровода.

Пример линейной диаграммы (4-й поток строительства Каспийского трубопровода) представлен на рис.2.

Имеются и другие отличия пакета от других программ, предназначенных для управления проектами, но в такой короткой статье всего не перечислишь.

3. Историческая справка

Первая версия пакета Spider Project была выпущена в конце 1992 года. Поскольку в тот момент в нашей стране мало кто знал о том, что такое Управление проектами, версия была англоязычной. В 1993 году она демонстрировалась на выставках в Лейпциге и Мюнхене и заслужила весьма лестные отзывы благодаря алгоритмам оптимизации расписаний при ограниченных ресурсах проекта. Первыми пользователями пакета были немцы, финны и англичане.

С тех пор пакет непрерывно развивается, расширяются его функциональные возможности, а наличие большого числа российских пользователей из самых разных отраслей промышленности позволяет определять направления разработки в соответствие с потребностями и особенностями российского рынка.

Большую роль в распространении информации о пакете и росте его популярности сыграло его успешное использование для управления строительством Олимпийской деревни для Всемирных Юношеских Игр 1998 года. Стройка была очень крупной, была провозглашена важнейшей стройкой года Московским Правительством, и соблюдение сроков строительства и координация работы многочисленных подрядчиков было очень важной задачей. На стройке преимущества использования пакета были столь наглядно продемонстрированы, что Spider Project стал быстро распространяться по строительным организациям и даже заслужил репутацию пакета для управления строительством, несмотря на свою универсальность. До сих пор разработчики пакета получают заявки на «пакет управления монолитным домостроением», хотя пакет с успехом применяется не только в строительстве, но и в оборонных, информационных, телекоммуникационных, нефтегазовых, судостроительных, консалтинговых и иных проектах. На ряде предприятий Spider Project используется в качестве корпоративной системы управления проектами.

Для удовлетворения спроса на систему со стороны различных групп пользователей кроме профессиональной системы предлагаются более дешевые версии Desktop и Lite. Версия Desktop – однопользовательский вариант профессиональной системы, а в версии Lite функциональные возможности пакета ограничены, и пакет более напоминает западные системы управления проектами. Подробнее об особенностях различных версий пакета и их стоимости вы можете узнать на сайте www.spiderproject.ru. Там же можно скачать рабочие Демо версии Spider Project Professional и Spider Project Lite, Руководство по работе с пакетом, а также различные статьи и презентации на тему управления проектами.

ВАСИЛЬКОВ

8. Суть прямого проходу при плануванні проекту.

Прямий прохід

а рекурсивно розраховується наступним чином:

Початкова умова: якщо на кожному кроці не проводилася

нормалізація, буде розраховуватися Втім, ця спільна

ймовірність стрімко зменшується із ростом і. Одним із рішень може стати
логарифмування. Іншим - нормалізація, тобто розрахунок

сума яких завжди дорівнює одиниці. Це не лише

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

9. Суть зворотного проходу при плануванні проекту.

 обчислюються рекурсивно наступним чином. Початкова умова

Рекурсивний крок має вигляд

– це умовна імовірність, а не фільтроване наближення, і сума цих значень не обов’язково становить 1. З метою запобігання малих значень необхідно на кожному кроці виконувати нормалізацію.

10. Ролі в колективі розробників.

Для цілеспрямованого виконання проекту працівниками має бути виконаний ряд робіт, різних як по своєму призначенню, так і по кваліфікаційних вимогах, що

пред'являються до розробників. Іншими словами, в ході розвитку проекту командою розробників виконуються ті або інші функції. Розподіл функцій між виконавцями є нічим іншим як розподілом ролей в команді, що виконує проект. Зрозуміло, що значущість ролей розробників і тих, хто з ними пов'язаний,

розрізняється залежно від того, який проект виконує команда програміста. Проте, можна вказати на ряд найбільш типових ролей, ігнорування яких приводить кращому випадку до втрат продуктивності праці команди в цілому, а в найгіршому - до краху проекту. Як досить повний перелік ролей можна вказати на наступний список, запропонований в рамках підходу Центру об'єктно-орієнтованої технології фірми IBM

11. Функціональна роль Замовника (Customer) в колективі розробників.

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

результати (як поточні, так і остаточні) розробки, виконаної роботи;

12. Функціональна роль Планувальника ресурсів (Planner) в колективі розробників.

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

13. Функціональна роль Менеджера проекту (Project Manager) в колективі розробників.

Менеджер проекту (Project Manager) - відповідає за розвиток проекту загалом, гарантує, що розподіл завдань і ресурсів дозволяє виконати проект, що роботи і

пред’явлення результатів йдуть за графіком, що результати відповідають вимогам. В рамках цих функцій менеджер проекту взаємодіє із замовником і планувальником

ресурсів;

14. Функціональна роль керівника команди (Team Leader) в колективі розробників.

Керівник команди (Team Leader) – виконує технічне керівництво командою в процесі виконання проекту. Для великих проектів можливе залучення декількох керівників підкоманд, що відповідають за рішення окремих задач;

ГОС

15. Функціональна роль архітектора (Architect) в колективі розробників.

. Архітектор (Architect) - відповідає за проектування архітектури системи, погоджує розвиток робіт, пов'язаних з проектом;

16. Функціональна роль проектувальника підсистеми (Designer) в колективі розробникі

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

17. Функціональна роль експерта предметної області (Domain Expert) в колективі розробників.

Експерт предметної області (Domain Expert) - вивчає сферу програмного продукту, що розробляється, (розроблювального ПЗ), підтримує спрямованість проекту на рішення задач цієї області;

18. Функціональна роль розробника (Developer) в колективі розробників.

Розробник (Developer) - реалізує проектовані компоненти, розробляє специфічні класи і методи, здійснює кодування і автономне тестування, створює програмний продукт. Це широкий термін, який може підрозділятися на вужчі ролі (наприклад, розробник класів). Залежно від складності проекту команда може включати різну кількість розробників;

19. Функціональна роль розробника інформаційної підтримки (Information Developer) в колективі розробників.

Розробник інформаційної підтримки (Information Developer) - створює документацію, супроводжуючу продукт, коли випускається його версія. Інсталяційні матеріали, що включаються в неї, як зсилки так навчальну літературу, а також матеріали допомоги, які надаються на паперових і електронних носіях. Для складних проектів можливий розподіл цих завдань між декількома розробниками інформаційної підтримки;

20. Функціональна роль спеціаліста по користувацькому інтерфейсу (Human Factors Engineer) в колективі розробників.

. Фахівець з призначеного для користувача інтерфейсу (Human Factors Engineer) - відповідає за зручність застосування системи. Працює із замовником, щоб упевнитися, що призначений для користувача інтерфейс задовольняє вимогам;

21. Функціональна роль тестувальника (Tester) в колективі розробників.

Тестувальник (Tester) - перевіряє функціональність, якість і ефективність продукту. Будує і виконує тести для кожної фази розвитку проекту;

Я

22. Функціональна роль біблотекаря (Librarian) в колективі розробників.

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

23. Життєвий цикл програмного продукту.

Функції, що виконуються розробниками проекту, в ході його розвитку зазнають зміни, як, в іншому, і сам проект. Спочатку він існує у вигляді заявки на розробку, потім - як функціональні і технічні вимоги, далі - як специфікації виробу, що розробляється, набір програмних модулів, скомпонованная з модулів система і так далі. Цей перелік можна розглядати як один з прикладів моделі життєвого циклу програмного виробу, тобто

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