Паттерн (шаблон)
Паттерны (шаблоны) проектирования — это способы построения программ, которые считаются хорошим тоном для разработчиков. Их еще называют шаблонами или образцами: чаще всего паттерн — это типовое решение для часто встречающейся задачи на построение.
«IT-специалист с нуля» наш лучший курс для старта в IT
Паттерны используются именно для проектирования и структуризации, а не для бизнес-задач. Можно привести аналогию: если вы разрабатываете самолет, вам не нужно с нуля придумывать, какой формы он будет. Опыт предыдущих самолетостроителей подсказывает правила: формат и количество крыльев, особенности хвоста, нужные элементы. Это и есть паттерн — схема, по которой строится решение.
Понятие не стоит путать с паттерном в дизайне — там так называются узоры, построенные на повторяющихся элементах или орнаментах. В разработке же паттерн — это схема решения.
Кроме паттернов, существуют антипаттерны проектирования — это плохие решения, неэффективные. Применять их считается дурным тоном.
Профессия / 8 месяцев
IT-специалист с нуля
Попробуйте 9 профессий за 2 месяца и выберите подходящую вам
Кто пользуется паттернами проектирования
Паттерны используют программисты на разных языках, в первую очередь те, которые занимаются объектно-ориентированным программированием. Само понятие паттерна тесно связано с ООП: этот подход позволяет разбить структуру программы на формализованные классы и объекты. Решение строится из них, как из кирпичиков. Такой вид разработки хорошо сочетается с паттернами.
В широком смысле паттерны проектирования применяются во всех отраслях, где есть списки часто встречающихся формализованных проблем. В разработке это почти любое направление.
Для чего нужны паттерны
В программировании есть задачи, которые встречаются часто и с которыми сталкивается большинство разработчиков. Придумывать новое уникальное решение каждый раз было бы трудозатратно и неэффективно, поэтому существуют паттерны, на которые можно ориентироваться.
Паттерны проектирования помогают быстрее и эффективнее создавать код, а не «изобретать велосипеды». Как с созданием любого продукта: лучше воспользоваться знаниями, которые наработали другие, чем продумывать с нуля абсолютно все.
Если разработчик может грамотно формализовать проблему с помощью ООП и выбрать подходящий паттерн для ее решения, это может серьезно ускорить сроки разработки. А решение будет понятным и эффективным – это уже доказали люди, которые начали применять конкретный паттерн раньше.
Кроме того, использование паттернов еще и улучшает читаемость кода. Другой программист, знакомый с нужным паттерном, сможет увидеть его в коде и понять, как все реализовано. А ведь в разработке обычно задействовано несколько специалистов – коммуникация между ними упрощается.
Как устроены паттерны
Типичный паттерн — это формализованное решение какой-либо проблемы. Оно может быть представлено как алгоритм или как схема, блоки которой означают части программы.
У паттернов есть свои имена, есть описания, они четко предназначены для решения той или иной проблемы. Имеется и классификация – в первую очередь по тому, для чего нужен тот или иной шаблон.
Отличия паттернов проектирования от архитектурных
Кроме паттернов проектирования, еще есть архитектурные паттерны. Они работают по тому же принципу, но с важным различием. Архитектурные паттерны – высшего уровня, они описывают структуру всего продукта. А паттерны проектирования применяются уже на уровне конкретных объектов, алгоритмов и частей программы.
Если упростить, архитектурный паттерн отвечает на вопрос «как будет устроен продукт». Например, модель MVC — архитектурный паттерн.
А паттерн проектирования отвечает на вопрос «как лучше организовать составные части продукта»: как эффективнее создавать объекты, настраивать обмен данными между ними и их взаимодействие. Паттерны проектирования адаптированы под конкретную задачу, не зависят от языка программирования и не влияют на структуру продукта целиком. Они описывают детали, а не общую архитектуру.
Еще есть идиомы — это тоже формализованные способы решения проблем, но зависящие от языка программирования. Они реализуются на еще более мелком уровне для решения конкретных задач – например, утечки памяти.
Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить
Виды паттернов проектирования
Порождающие. Такие шаблоны нужны, чтобы оптимизировать создание того или иного объекта. Порождающие паттерны помогают создавать объекты так, чтобы они эффективно общались с другими, и управлять их работой. Вот несколько примеров:
- «Фабрика» (Factory) — для создания новых объектов придумывают отдельный класс. Он создает объекты как копии некоего эталона;
- «Прототип» (Prototype) — объект сам создает свои копии;
- «Строитель» (Builder) — похож на фабрику, но новые объекты можно модифицировать. Они создаются по сложной логике, а не копируют эталонный;
- «Одиночка» (Singleton) — подразумевает наличие одного большого объекта, который имеет глобальный доступ ко всему;
- «Ленивая инициализация» (Lazy Initialization) — метод, при котором объект инициализируется не сразу, а по мере необходимости.
Существуют и другие шаблоны разной сложности. Для каждой задачи оптимальнее тот или иной паттерн. Конкретное решение зависит от задачи, но в результате должна получиться эффективная и оптимизированная система.
Структурные. Если порождающие паттерны отвечают за создание и взаимодействие объектов, то структурные — за то, как эти объекты структурированы в коде. Они описывают, каким образом простые классы и объекты «собираются» в более сложные.
- «Декоратор» (Decorator) — шаблон для подключения дополнительного поведения к объекту;
- «Компоновщик» (Composite) — паттерн, который объединяет несколько объектов в древовидную структуру;
- «Мост» (Bridge) — принцип разделения сущности на абстракцию и реализацию, чтобы теоретическая структура и конкретный объект могли изменяться независимо;
- «Фасад» (Facade) — метод для сведения внешних вызовов к одному объекту;
- «Заместитель» (Proxy) — паттерн, похожий на «Фасад», но со специальным объектом-заместителем, который контролирует доступ к основному.
Это только некоторые примеры. Реальных паттернов намного больше.
Поведенческие. Это паттерны проектирования, которые описывают, как объекты себя ведут и взаимодействуют с другими. Их используют, например, для разделения обязанностей между разными сущностями или для реагирования на изменения без ошибок.
Примеры поведенческих паттернов:
- «Итератор» (Iterator) — один объект последовательно дает доступ к разным другим, при этом не использует их сложные описания;
- «Наблюдатель» (Observer) – шаблон, при котором объекты узнают об изменениях в других;
- «Хранитель» (Memento) — помогает сохранить объект в каком-то состоянии с возможностью вернуться к нему в будущем;
- «Цепочка ответственности» (Chain of Responsibility) — распределяет ответственность за те или иные задачи на разные объекты;
- «Посредник» (Mediator) — организует слабые связи между объектами, чтобы снизить их зависимость друг от друга.
Как понять, какой паттерн применить
У каждого паттерна своя область использования. Опытные разработчики понимают, где что использовать, по самой специфике задачи, но в начале пути это может быть сложно. Поэтому новичкам советуют разделять выбор паттерна на более мелкие шаги:
- выделить сущности, которые используются в процессе;
- продумать связи между ними;
- абстрагировать получившуюся систему от конкретной задачи;
- посмотреть, не подходит ли проблема по смыслу на что-то, для чего есть паттерн;
- выбрать несколько паттернов из нужной группы и посмотреть какой подходит лучше;
- продумать конкретную реализацию этого паттерна с учетом особенностей задачи.
Это выглядит сложно, но со временем придет привычка. Опытные разработчики уже «набили руку», поэтому проблемы с выбором паттерна у них возникают намного реже. Когда сформируется понимание и наберется практика, будет проще.
Преимущества паттернов проектирования
- Ускоряют и облегчают написание кода.
- Позволяют не «изобретать велосипед», а воспользоваться готовым проверенным принципом.
- При грамотном использовании делают код более читаемым и эффективным.
- Упрощают взаимопонимание между разработчиками.
- Помогают избавиться от типовых ошибок.
- Не зависят от языка программирования и его особенностей.
- Позволяют реализовывать сложные задачи быстрее и проще.
Недостатки паттернов проектирования
- Использование паттернов ради паттернов, наоборот, усложняет код и запутывает разработчиков.
- Неправильное применение того или иного шаблона способно сделать программу менее эффективной.
- Паттерны неуниверсальны: в одной задаче конкретный паттерн подойдет, в другой нет.
- На ранних этапах изучения бывает сложно выбрать подходящий для конкретной проблемы паттерн.
- Из-за сильной связи с объектно-ориентированным программированием использование паттернов в других парадигмах ограничено. Хотя, например, в функциональном программировании они могут применяться — просто реализуются иначе.
Стоит ли пользоваться паттернами
Наличие недостатков не делает саму идею паттернов плохой. Просто это инструмент, которым нужно пользоваться с умом. Не стоит применять шаблоны там, где можно без них обойтись, просто ради «красоты». Если же использовать их в местах, где они действительно нужны – они станут хорошей помощью в работе программиста.
Более того: на собеседованиях уровня Middle и выше почти всегда спрашивают, знаком ли соискатель с паттернами проектирования. То есть их знание и умение ими пользоваться — практически обязательное условие для программиста уровня выше начального. И неважно, на чем вы пишете: Python, Java, JavaScript или что-нибудь еще.
Как начать работать с паттернами
Паттерны проектирования для новичков — не задача первостепенной важности. К ним обычно переходят люди, у которых есть определенный опыт в программировании, успевшие изучить базовые принципы. Но для перехода на уровень Middle и выше они понадобятся.
Сначала нужно освоить особенности программирования на выбранном языке — некоторые вещи можно почерпнуть уже оттуда. Например, в JS активно используются декораторы. Затем стоит переходить к изучению самих паттернов: какие они бывают, как устроены, что собой представляют.
Освоив теоретическую часть, можно тренироваться. Ведь фактическая реализация порой может серьезно отличаться от теоретического описания, поэтому нужна практика.
IT-специалист с нуля
Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.
Статьи по теме:
Разбор профессии и подборка востребованных специальностей
Рассказ о профессии дата-инженера: автоматизация, организация хранилища данных и лайфхаки по борьбе с рутиной
Шаблон проекта. Создание и настройка
руководитель и исполнитель в объектах проекта уже были преднастроены ИЛИ руководителем и исполнителем вставал создатель проекта из шаблона.
Как создать шаблон проекта
Шаг 1. Создание нового шаблона
Чтобы создать шаблон проекта:
зайдите в раздел «Администрирование» → «Свойства объектов» → «Шаблоны»;
в портлете «Шаблоны проектов» нажмите «Создать шаблон»;
выберите тип родительского объекта в шаблоне (Рисунок 1).
Можно построить новый шаблон на основании уже существующих шаблонов в системе. Это может быть полезным, когда нужно создать несколько дополнительных шаблонов проектов, которые незначительно отличаются от уже созданных.
Рисунок 1 – Выбор типа объекта для создания шаблона
на открывшейся карточке создания шаблона укажите необходимые реквизиты и свойства;
сохраните изменения (Рисунок 2).
Рисунок 2 – Страница создания родительского объекта в шаблоне
Шаг 2. Иерархия шаблонов объектов
Важное преимущество шаблонов проектов – в том, что пользователь сможет в пару кликов развернуть целый преднастроенный проект. ⇒ Нужно в новом шаблоне проекта создать ту иерархию, которая развернётся у пользователя.
Мы рекомендуем опираться на уже существующие проекты, обкатанные на практике. Отталкивайтесь от того, как оно бывает в жизни + добавляйте щепотку той стройности, структурности, которую нужно привнести.
Не стоит рисовать идеальную картину в шаблоне, которую пользователи выдержать в рабочем процессе не смогут. Например, закладывать нереалистичные сроки или добавлять те задачи, ценность которых сомнительна или значение которых пользователи не поймут без дополнительных пояснений.
Чтобы в шаблоне добавить иерархическую структуру объектов, у вас есть 2 равноценных инструмента:
через раздел «Иерархическая структура» на карточке шаблона, процесс добавления объектов полностью аналогичен обычному добавлению новых объектов в Дереве проектов;
Здесь вы в том числе сможете воспользоваться импортом объектов, чтобы ускорить процесс, если нужно загрузить много однотипных объектов.
Рисунок 3 – Добавление нового объекта в шаблон из иерархии
через «Диаграмму Ганта» – создавая записи прямо в диаграмме.
Меню слева на карточке шаблона → Гант → клик на объект в списке → «Добавить элемент с типом».
Рисунок 4 – Добавление нового объекта в шаблон из диаграммы Ганта
Для сохранения любых изменений, сделанных на диаграмме, нужно нажать кнопку «Сохранить изменения» . В противном случае, при переходе на другую страницу без этого действия, все изменения будут утеряны!
Также при добавлении объектов в шаблон через диаграмму Ганта вы можете сразу же настроить временные связи между работами.
Шаг 3. Даты
По умолчанию даты при создании шаблона полностью копируются.
Определите, в зависимости от типа проекта, какие даты в нём должны быть:
фиксированные – когда бы вы ни создали проект, там будут «гвоздями прибитые» конкретные даты;
относительные – когда проект создан – от такой даты он и начинается.
Фиксированные даты
С помощью Ганта или через карточки объектов настройте время начала и окончания работ.
Относительные даты
Чтобы проект, развернутый из шаблона, начинался с текущей даты и имел корректную дату завершения, нужно:
поставить чек-бокс «Сбросить плановые даты» в настройках шаблона (Рисунок 5);
всю последовательность работ выстроить с помощью зависимостей (связей) между задачами проекта.
Рисунок 5 – Настройки шаблона проекта в портлете «Шаблоны проектов»
Шаг 4. Делегирование
Может быть 2 варианта настройки:
Назначается создателю
Чтобы проект и его содержимое назначался на того, кто этот проект из шаблона развернёт, надо чтобы в настройках шаблона проекта НЕ стояли чек-боксы:
«Назначить на работы исполнителей, указанных в шаблоне»
«Назначить на работы руководителей, указанных в шаблоне» (Рисунок 5).
В таком случае после разворачивания проекта тот, кто его создал, вручную может менять назначения руководителей и исполнителей, как в любых других объектах, если у него есть права на делегирование.
Назначается преднастроенным руководителям и/или исполнителям
Чтобы проект и его содержимое назначался на конкретных пользователей системы, надо:
Делегировать объекты проекта в шаблоне ответственным пользователям.
Процесс делегирования в шаблоне аналогичен обычному процессу делегирования объектов.
В настройках шаблона проекта (Рисунок 5) должен стоять чек-бокс:
«Назначить на работы исполнителей, указанных в шаблоне» – если нужно зафиксировать в шаблоне исполнителей;
«Назначить на работы руководителей, указанных в шаблоне» – если нужно зафиксировать в шаблоне руководителей.
Например, руководители проекта известны, и понятно, кто будет отвечать за определённые вехи. Однако у каждого руководителя свой штат, и он сам решит после начала проекта, кому именно дать эти поручения в работу. ⇒ Нужно зашить в настройки делегированного руководителя, а исполнителя оставить без настроек.
Если в шаблоне проекта есть преднастроенные в объектах руководители и исполнители, то развернуть такой шаблон сможет только тот, у кого есть системные права на делегирование объектов и лицензия «Руководитель» или «Директор».
Шаг 5. Дополнительные настройки
Имя шаблона
Адмнистрирование → Шаблоны → портлет «Шаблоны проектов» → столбец «Сохранять имя шаблона».
Если поставить чек-бокс, название шаблона будет автоматически подставляться в название разворачиваемого проекта.
Удобно сохранять название, когда из шаблонов формируются отдельные этапы работ.
Если чек-бокс снят, то название проекта по умолчанию будет пустым.
Доступность шаблона для разворачивания
«Администрирование» → «Шаблоны» → портлет «Шаблоны проектов» → чек-бокс «Добавить, если в родительском объекте установлен признак».
Можно ограничить доступность шаблона для разворачивания в родительском объекте – указать значение реквизита-классификатора, при котором шаблон станет доступен.
Условия проверки доступности работают по принципу логического «ИЛИ» – если любое значение в любом из указанных в настройках шаблона реквизитов совпадает со значением такого же реквизита, выбранном в родительском объекте, то шаблон будет доступен для создания.
Документы
Если есть какие-то типовые документы, которые должны быть в проекте на момент его старта, добавьте их в шаблон. Инструмент добавления документов в шаблон аналогичен обычному добавлению документов к объекту.
В шаблонах удобно сохранять контрольные документы на уровне отдельных задач или вех, без прикрепления которых завершить веху или задачу будет невозможно.
В последующем, при реализации проекта, при изменении пользователем статуса вехи или задачи на «Готов к проверке», система проверит наличие необходимых документов, и сигнализирует об ошибке, если они отсутствуют.
- product/templates/object.txt
- Последнее изменение: 09.11.2021 05:18
- — Сердцев Сергей
Если не указано иное, содержимое этой вики предоставляется на условиях следующей лицензии:
CC Attribution-Share Alike 4.0 International
Для чего нужны шаблоны проектирования
Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.
Немного воспоминаний из молодости
Когда я учился в университете, нам преподавали в рамках одного из курсов шаблоны проектирования. На тот момент они казались мне чем-то наподобие сферического коня в вакууме, потому что практического опыта их применения я не имел (это был третий или начало четвертого курса много лет назад). Запомнить кто из них кто тоже было достаточно сложно, не говоря уже о тонкостях и деталях. Тем не менее, вопросы по шаблонам проектирования задавали в обязательном порядке на каждом собеседовании на работу. Кандидатам приходилось раздувать щеки и доказывать как круты разные шаблоны (особенно Singleton), видя их в жизни максимум раз-другой на страницах книжек.
Но ведь совсем не глупые люди придумали шаблоны проектирования:
- В 70-ые годы архитектор Кристофер Александр начал дело и сформулировал набор шаблонов проектирования.
- Его дело в IT подхватили в далеком 1987 году небезызвестные Кент Бэк и Вард Каннингем, составив шаблоны проектирования для популярного языка программирования Smalltalk.
- Еще один легендарный в IT человек Эрих Гамма написал докторскую диссертацию на эту тему в 1988-1990.
- И наконец, в начале 90-ых известная «банда четырех» в составе все того же Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидсома опубликовала легендарную книгу «Design Patterns: Elements of Reusable Object-Oriented Software».
Дальше продолжать исторические хроники смысла нет. Это была первая книга, из которой наше поколение черпало свои знания по шаблонам проектирования и пыталось применять их в своей работе. Она считается классикой в этой тематике и обязательна к прочтению.
Через некоторое время работы я начал замечать, что даже теоретические знания шаблонов проектирования помогают мне понять чужой код гораздо быстрее. А это особенно важно на старте вашей карьеры, когда вам надо вникать в существующие проекты без опыта работы. Например, встречая класс с суффиксом Builder, я понимал, что его добавили с целью упрощения и изоляции логики построения сложных объектов. Я сразу легко находил как им пользоваться и применять в своем коде. Повсюду были разбросаны представители шаблона Singleton, совершить ошибку при инициализации которых так легко без знаний правил применения. В коде, с которым я работал, обильно встречались Facade, Visitor, Chain of Responsibility, Iterator, Adapter, Decorator, Proxy, Strategy, Template Method и прочие популярные шаблоны проектирования.
Я осознал, как много времени я экономлю, применяя свои скудные книжные знания шаблонов проектирования и даже в душе зауважал их авторов. Мне было легко не только понимать чужой код, но и расширять его своими решениями, а также добавлять новые.
А как без шаблонов?
Время шло… Я достаточно быстро привык к повсеместному применению шаблонов проектирования и мне стало сложно работать без них. Я начал понимать для чего на собеседовании у кандидатов спрашивают о них (конечно, если не просто «для галочки»). Тут речь даже не об обязательном применении шаблонов проектирования, а об упрощении общения между разработчиками. А это тот процесс, который занимает ключевое место в разработке — обсуждение архитектуры и дизайна конкретного решения задачи.
Первый важный параметр — это время, которое тратится на обсуждение и принятие решения (я надеюсь, что у вас решения принимает не один бородатый Senior Senior Global Product Software Architect). Представьте себе как сложно было бы быстро объяснить кому-то, что нужно реализовать Decorator: «нам нужно сделать класс, которому мы передадим в конструкторе экземпляр другой реализации того же интерфейса и который будет добавлять логику к вызову этих методов, не меняя их основного поведения. » А ведь еще за кадром остались куча мелочей и нюансов. И это для мелкой детали вашего дизайна, которых в большинстве решений десятки, а то и сотни. Мы даже не трогаем сложные и серьезные архитектурные шаблоны.
На примере с Decorator легко понять второй важный параметр — одинаковое понимание дизайна решения задачи в головах всех членов команды. При размытости формулировки каждый может понять решение по-разному, а это чревато проблемами. Ведь реализация может сильно отличаться от обсуждаемой задумки. А это приведет к дополнительному времени на ревью кода и переделки.
Третий важный параметр — понимание работы сторонних инструментов и библиотек. На данный момент практически в каждом проекте используется множество сторонних решений. Чтобы их использовать правильно и не наступать на грабли, архитектор и разработчик должны понимать как что устроено. А для этого используются общеизвестные шаблоны, которые призваны сильно упростить понимание и сравнить с альтернативными решениями.
В жизни мы активно используем примеры для описания ситуаций, предметов, поступков. Чтобы объяснить кому-то какую-то концепцию, мы базируемся на общеизвестных знаниях и выстраиваем примеры на их основе. «Такой же здоровый как Вася», «так же тяжело как после 5 км пробежки», «плохо как с бодуна», «кислый как лимон» и т.д. Подобные выражения мы используем в своей речи постоянно и даже не замечаем этого. Для нас их применение проще чем детальное описание и это позволяет вашему собеседнику лучше вас понять.
Следующий уровень
Если вы заметили, что вы не пытаетесь вспомнить детали реализации шаблона проектирования, а просто можете изложить детали его применения своими словами, то вы переросли уровень Shu в известной восточной философии Shuhari (я когда-то давно писал о ее применимости к Agile подходам и практикам). На уровне Shu вы просто следуете шаблонам и не можете осознать их полезность, тонкости и влияние. На уровне Ha вы уже все осознаете и можете сознательно отказываться от определенных шаблонов, критиковать решения на их базе, видоизменять некоторые шаблоны под конкретную ситуацию и контекст.
На уровне Ha я настоятельно рекомендую прочитать отличную книгу «Refactoring to Patterns» от Джошуа Кериевски. В ней рассказывается о том, как находить в коде неподходящие или плохо примененные шаблоны проектирования, а потом посредством рефакторинга приводить их к верным и подходящим решениям. Эту книгу стоит читать именно на уровне Ha, потому что до этого она будет для вас просто пустым звуком.
У как же уровень Ri? На этом уровне вы и вовсе перестаете задумываться о применении шаблонов. Решения рождаются натурально на базе ваших знаний и навыков, которые вы накопили с годами. Где-то вырисовываются одни шаблоны, где-то ваши собственные наработки, которые стали для вас шаблонами в данном контексте. В голове у вас перестает работать цепочка «от шаблона к решению» и остается только «от решения к шаблону». Тогда вместо вопросов о конкретных шаблонах проектирования на собеседовании вы переходите к открытым вопросам о применимости данного инструмента и примерах из реальной жизни…
Заключение
Шаблоны проектирования — это один из инструментов разработчика, который помогает ему сэкономить время и сделать более качественное решение. Как и любой другой инструмент, в одних руках он может принести много пользы, а в других — один только вред. Я попытался донести на примерах, что конкретно дадут вам шаблоны проектирования и как к ним стоит относиться. Надеюсь, мне это удалось…
P.S. На одном из моих тренингов хвалили книгу по шаблонам проектирования для начинающих «Head First Design Patterns». Лично сам не читал, потому как достаточно владел темой из других источников и недоверительно отношусь к такого формата книгам.
- шаблоны проектирования
- проектирование
- дизайн
- архитектура
- разработка
- команда
- Веб-разработка
- Анализ и проектирование систем
- Проектирование и рефакторинг
Шаблоны проектов
Dynamics 365 Project Service Automation стало Dynamics 365 Project Operations. Дополнительные сведения см. в статье Переход на Project Service Automation.
Относится к приложению Project Service версии 3.x
Шаблон проекта — это предварительно определенная структура, которая помогает быстро и легко начать проект. Можно использовать предварительно заданный шаблон для создания нового проекта одним щелчком. В отношении проектов необходимо определить обязательные условия для шаблонов проекта. Следует задать календарь по проекту для каждого шаблона проекта, и роли и прайс-листы необходимо предопределить в организации, чтобы эти компоненты шаблона содержали полезные данные.
Шаблон проекта состоит из трех компонентов: расписание, оценки проекта и участники проектной группы.
Расписание
Расписание в шаблоне проекта имеет тот же набор элементов, что и расписание в проекте. Можно создать иерархию задач, связать роли с задачами, определить атрибуты расписания и задать зависимости. Расписание в шаблоне проекта также поддерживает режимы задачи для каждой задачи. Следовательно, оно поддерживает подсистему планирования. Необходимо связать календарь проекта с проектом. При составлении рабочего расписания нет разницы между шаблоном проекта и проектом.
Оценки проекта
Оценки проекта в шаблоне проекта работают таким же образом, как и оценки проекта в проекте. Однако затраты и продажные цены извлекаются из прайс-листов стоимости и продаж по умолчанию, которые определены в параметрах.
Создание проекта из шаблона
Существует несколько способов создания проекта из шаблона проекта:
- При создании проекта из предложения с расценками можно выбрать шаблон проекта в диалоговом окне Быстрое создание: Проект.
- При создании нового проекта путем выбора пункта Создать проект, страница Проект отображается перед сохранением записи. В поле Выберите шаблон выберите один из предопределенных шаблонов проекта в организации.
- Используйте Создание проекта из шаблона на странице Сущность шаблона.
Копирование компонентов шаблона в проект
При копировании компонентов шаблона проекта в проект несколько переопределений выполняется, в зависимости от настроек в проекте.
Копирование расписания
При копировании расписания из шаблона проекта рабочие часы из календаря проекта применяются к расписанию задач, если календарь проекта отличается от календаря шаблона. Таким образом расписание корректируется в соответствии со связанным календарем проекта. Аналогично первая задача в расписании принимает дату начала проекта, и расписание остальной иерархии обновляется с учетом продолжительности и зависимостей, определенных в шаблоне.
Копирование оценок проекта
При копировании между строками оценки проекта прайс-листы обновляются. Для списка себестоимости эти обновления основаны на подразделении, отвечающем за проект. Для прайс-листа продаж они основаны на клиенте. Для проектов, которые связаны с сущностью продаж, стоимость единицы и цены продажи определяются на основе этих прейскурантов.
Копирование проектной группы
При копировании рабочей группы проекта из шаблона проекта в проект, универсальные ресурсы копируются вместе с навыками и компетенциями, определенными в шаблоне. Назначения универсальных ресурсов также обслуживаются как в шаблоне проекта. Именованные ресурсы не поддерживаются в шаблонах проектов.