Статьи / Легенда раскрыта. Автоматическое получение спецификаций в Renga.
Подсчет количества строительных материалов и работ — весьма трудоемкая, но крайне важная часть документации по проекту. В связи с этим в любой BIM-системе, и российская Renga Architecture не исключение, разработаны инструменты для их автоматического создания. Разработчики Renga смогли минимизировать временные затраты на работу со спецификациями, создав новый инструмент «Легенда». Теперь получение спецификаций в соответствии с ГОСТ больше не кажется «тайной, покрытой мраком».
После двух лет кропотливого труда над чертежами, выполняемыми вручную, я с великим удовольствием узнал, что существует ряд специализированных программ в помощь инженеру-проектировщику. К сожалению, все программы, в которых я работал в течение года, были зарубежными. Это приводило к ряду проблем, связанных, например, с несоответствием получаемых чертежей принятым в нашей стране стандартам. В поисках их решения я столкнулся с неожиданным открытием: оказывается, в России существует отечественная BIM-система. И это Renga Architecture!
Программа в освоении оказалась достаточно простой, особенно в сравнении с Autodesk Revit. Я не могу сказать, что в совершенстве владею всеми инструментами российской BIM-системы, но за достаточно короткий срок создавать типовые проекты зданий точно научился. Я часто сталкиваюсь с созданием документации к чертежам, для меня было немаловажно, насколько легко реализована эта возможность в той или иной BIM-системе. И надо сказать, что Renga Architecture меня приятно удивила!
Вам, конечно, известно, что ни один новый проект здания или сооружения, к какому бы этапу проектирования он не относился, не может обойтись без подсчета количества используемых строительных материалов, данных о площадях и объёмах помещений, применяемых нормативных документах и т.п.
В Renga Architecture для создания таких отчетов существует инструмент «Спецификации», с помощью которого можно в автоматическом режиме сформировать необходимый перечень материалов или иных требуемых компонентов (рис.1).
Рисунок 1. Спецификации элементов со всей 3D-модели здания, полученные с помощью инструмента «Спецификации».
Данный инструмент хорошо справляется со своей задачей и предназначен для получения отчетов со всей BIM-модели. Однако, когда мы переходим к оформлению чертежей и созданию по ним спецификаций, возникают трудности. Например, для получения поэтажной экспликации помещений, необходимо создать несколько фильтров, исключающих возможность отображения помещений с других этажей, и применить к общей спецификации. Очевидно, что на выполнение данной задачи требуется достаточное количество времени. Но не стоит переживать, так как в Renga появился еще один инструмент, который значительно сокращает трудоемкость получения спецификаций по конкретному виду или чертежу.
Инструмент получил название «Легенда», и сейчас я расскажу о его возможностях.
«Легенды», как и любой другой объект в Renga, имеют свой стиль (рис.2). Именно он позволяет управлять и настраивать вид легенды, который мы хотим применить, будь это гостовские таблицы, например, экспликация помещений, ведомость отверстий или спецификация заполнения оконных и дверных проемов, либо произвольная пользовательская таблица, на вкус архитектора.
Рисунок 2. Окно «Стили легенды».
Доступ к этим стилям можно получить через меню «Управление стилями — Стили легенд».
«Легенда» формируется на основе выбранных типов объектов, в соответствии с которыми происходит сбор данных с модели. На данном этапе инструмент обеспечивает возможность более удобного и быстрого выбора граф, из которых будет состоять спецификация, по сравнению с инструментом «Спецификация». Также уже после создания и настройки легенды при желании ее можно легко изменить, чтобы собирать в ту же таблицу данные по другим типам объектов. Для этого нужно просто поставить галочки напротив требуемых объектов (рис. 3).
Рисунок 3. Применение легенды «Спецификация объектов» из шаблона к виду.
Итак, начнем с создания экспликации помещений для первого этажа некоторого здания. Для этого необходимо в стилях легенд создать новый стиль, задать все необходимые параметры таблицы, то есть настроить будущую «Легенду», а затем применить ее к текущему виду на чертеже. После нехитрых манипуляций получаем следующее (рис. 4):
Рисунок 4. Применение созданной легенды к текущему виду на чертеже.
Как видите, в «Легенде» отображены все помещения, видимые на плане первого этажа.
Теперь откроем чертеж второго этажа и применим уже созданную легенду к нему (рис. 5).
Рисунок 5. Применение созданной легенды к плану второго этажа здания.
Нетрудно заметить, что в этом случае спецификация отображает все помещения уже не первого, а второго этажа, используя тот же стиль легенды.
Данный пример наглядно демонстрирует одну из возможностей нового инструмента: мы можем применять созданную и настроенную один раз «Легенду» к неограниченному числу видов и отображать на чертеже собранную с них информацию, что уже является признаком упрощения и эффективности работы по созданию спецификаций.
Не менее удобна и возможность переноса легенд из одного проекта в другой. Работает это так: если в одном проекте мы создаем стиль легенды, его можно скопировать в буфер обмена с помощью обычных средств, а затем вставить в другом проекте, находясь в пространстве чертежа. Все, что потребуется при этом, — выбрать вид, к которому будет применена скопированная легенда. Форматирование «Легенды», ее графы и выбранные типы объектов для сбора данных будут сохранены, а легенда добавлена в список в стилях легенды (Рис. 6). Такая возможность недоступна для инструмента «Спецификации», что выгодно отличает «Легенды» от последнего.
Рисунок 6. Копирование стиля легенды из одного проекта в другой
Кроме того, необходимо отметить, что при работе со сборками инструмент «Легенды» позволяет составлять спецификации для каждого входящего в сборку элемента (Рис. 7).
Рисунок 7. Применение легенды к сборке.
Итак, что мы имеем в итоге? Очевидно, что «Легенды» – это новый, достаточно мощный инструмент для создания такой трудоемкой части любого проекта здания или сооружения, как спецификации, который позволяет:- исключить создание «лишних», дополнительных фильтров для отображения нужной информации на конкретном виде;- быстро отформатировать таблицы спецификаций;- легко изменять спецификацию, лишь меняя вид, к которому она относится.Предполагаю, что у вас еще остались сомнения по поводу различия между двумя инструментами, поэтому хочу подчеркнуть, что инструмент «Спецификации» собирает данные со всей 3D-модели и отображает их независимо от выбранного чертежа. В то же время «Легенды» показывают данные только по объектам, видимым на чертежном виде, к которому они применены.Я думаю, вы уже поняли, что продукт Renga Architecture меня сильно заинтересовал, я собираюсь изучать его и дальше и с удовольствием поделюсь с вами своими открытиями на этом поприще.До новых встреч!
Автор: Максименко Артем, архитектор
Статьи / BIM для проектов повторного применения
В последние годы строительная отрасль форсированно переходит на BIM. Технология информационного моделирования применяется при проектировании новых объектов и реконструкции существующих, но до недавнего времени редко использовалась при работе с проектами повторного применения. Компания Renga Software решила изменить ситуацию и выступила проводником BIM-технологии в сферу типового проектирования.
Проекты повторного применения: кому и зачем?
По данным Минстроя уже несколько лет более трети всех социальных объектов строятся в России по проектам повторного применения. Строительство объектов по проектам повторного применения поддерживается на уровне Правительства Российской Федерации. Еще в 2016 году был принят закон № 368-ФЗ об обязательном применении экономически эффективной проектной документации повторного использования при строительстве объектов с привлечением бюджетных средств. Государственные заказчики обязаны использовать проекты повторного применения, а частные проектные компании отдают им предпочтение потому, что на их проработку требуется меньше ресурсов, чем на создание индивидуальных проектов.
История типового проектирования
Типовое проектирование применялось еще в Древней Руси по большей части для строительства оборонительных сооружений и крепостей. Наибольшую популярность оно приобрело в советское время, когда для массового применения типовых проектов открыли огромное количество домостроительных комбинатов (ДСК), производивших серийные строительные изделия. На территории бывшего СССР более 85% жилых и общественных и более 70% производственных сооружений построены по типовым проектам. Свою задачу с экономической точки зрения типовые проекты выполнили: обеспечили массовое строительство социального жилья, которое, в том числе бесплатно, было предоставлено гражданам Советского Союза.
В наши дни типовое проектирование является одним из элементов государственного регулирования при реализации государственной политики в области массового строительства зданий и сооружений. Создан и регулярно пополняется реестр типовой проектной документации. Это полезный для экономики механизм, но содержащиеся в реестре проекты представлены в нередактируемом формате PDF, что вносит определённые сложности в случае, когда требуется адаптировать проект под новые географические (климатические и грунтовые) условия.
Перспектива развития типового проектирования
С целью сделать работу с проектами повторного применения более удобной за счет предоставления информационной модели и документации в редактируемом формате, наша компания, российский BIM-разработчик Renga Software, уже не первый год ведет работу по созданию BIM-моделей проектов повторного применения для системы «Техэксперт». Но все они были представлены только разделом АР. Но совсем недавно совместными усилиями проектировщиков и специалистов Renga Software была разработана комплексная модель проекта повторного применения, содержащая в себе основные разделы проектирования.
Комплексная BIM-модель проекта повторного применения
В качестве проекта для разработки комплексной BIM-модели, включающей в себя разделы АР, КР, ИОС, был выбран проект повторного применения Дворца бракосочетаний в городе Боброве Воронежской области. Этот проект хорошо проработан его авторами, специалистами ЗАО «Воронеж-Автоматика», а кроме того, сам объект проекта несет в себе социальную значимость, поэтому был выбран для информационного моделирования.
Моделирование велось в российской BIM-системе Renga. Для ускорения процесса работы три специалиста вели одновременную работу над моделью. Исполнители работали в разных городах и синхронизировали свою совместную работу в единой модели. В качестве сервера выступал персональный компьютер одного из проектировщиков.
Информационная модель Дворца бракосочетаний создавалась по исходной проектной документации, в которой было указано, что проект соответствует стадии проектирования «П». Но в ходе работы над проектом выяснилось, что некоторые конструктивные решения были проработаны с более высокой детализацией, соответствующей рабочей документации.
Дворец бракосочетаний расположен на одной из центральных улиц Боброва с застройкой конца XIX века, поэтому было важно архитектурными элементами создать преемственность эпохи. Тем самым, проект будет полезен при повторном применении и для городов, стремящихся сохранить историческую застройку.
С архитектурной точки зрения проект Дворца примечателен входной группой, выполненной в виде двух полуколец, которые создавались с помощью колонн в системе Renga. Колоннада делает акцент на функциональное назначение здания, придает ему торжественность и значимость. Архитектурная выразительность здания Дворца бракосочетаний достигается принятой в проекте симметричностью фасадов, запроектированных разновысотными объемами.
Принимая во внимание заявленную стадийность исходного проекта, разуклонка плоской кровли в модели выполнена линиями модели; при этом существует возможность её выполнения в Renga специализированным инструментом «Крыша» с настраиваемыми параметрами и учетом правил подрезки.
Информационная модель Дворца бракосочетаний
Привлекает внимание и зал бракосочетаний с зенитным фонарем в центре, который обеспечил большое количество естественного освещения в главном помещении объекта.
На первом этаже здания располагаются помещения, предназначенные для проведения торжественной государственной регистрации рождения и заключения брака. Помещения второго этажа служат для жизнеобеспечения сотрудников ЗАГСа. В подвале расположены: венткамера, помещение ИТП, электрощитовая, водомерный узел.
Вид сверху на техподполье
Конструктивная часть здания представляет собой бескаркасную конструкцию с продольными и поперечными несущими стенами, колоннами и монолитными перекрытиями. Фундамент здания — монолитная железобетонная плита.
При работе над конструктивным разделом производилось армирование. Так, например, фоновое армирование монолитных железобетонных плит было выполнено автоматическим способом, а уже для усиления участков под сталебетонными колоннами использовался инструмент «Арматурный стержень» в «Сборке». Наряду с армированием также применялись и другие инструменты системы, которые позволили в полной мере воссоздать конструктивные решения в данном проекте.
Фрагмент армированных конструкций в модели
Проект интересен большим количеством детально проработанных инженерных сетей. С помощью автоматической трассировки в Renga были проложены сети водоснабжения и водоотведения, вентиляции, отопления, электроснабжения и электроосвещения. Благодаря удобному алгоритму работы в Renga c проектированием сетей не возникло сложностей. После расстановки оборудования и точек трассировки в модели объекты соединялись в «Конструкторе систем». Завершалось построение сетей расстановкой запорной арматуры на проложенных трассах.
В случае необходимости корректировки инженерных систем при повторном применении проектировщикам не придется прилагать много усилий, так как все сети ассоциативно связаны.
В процессе работы над моделью возникла потребность в построении различных коробов, в которые «прячутся» сети. Например, в «Сборке» было разработано крепление для электрических кабелей, которое монтируется в перекрытии под подвесным потолком.
Большая часть оборудования для создания сетей в модели создавалась стандартными инструментами Renga. Но специализированное, например посудомоечная машина, было импортировано с помощью инструмента «Элемент» и подключено к сетям с помощью точки трассировки. Найти нужные модели на просторах Интернета не составило труда, так как Renga поддерживает множество форматов для импорта.
Инженерные системы в проекте
На основании информационной модели специалисты оформили чертежи и спецификации. Некоторые чертежи для полного соответствия исходным документам потребовалось оформить графическими инструментами встроенного редактора чертежей. Учитывая намеченное развитие инструментов Renga, например, появление возможности разреза вида «Объекта» и управления границами вида разреза или фасада – эти чертежи смогут быть получены целиком из модели.
В процессе создания спецификаций на основе данных модели выяснилось, что в спецификациях исходного проекта были допущены неточности. Поэтому для сохранения исходных данных при оформлении спецификаций в Renga был применен инструмент «Таблицы», в которые были вписаны данные, посчитанные авторами проекта и прошедшие экспертизу.
Проектировщики, которые будут в дальнейшем использовать эту модель, смогут сформировать автоматические спецификации и применять более точные данные в сметах.
Пример оформленного чертежа
Для улучшения восприятия технических и архитектурных решений проекта в программе Twinmotion подготовлена визуализация BIM-модели.
В модели устранены коллизии, которые были обнаружены в процессе работы в исходной документации: исправлены пересечения и наложения решений разных проектных разделов, допустимые к исправлению без нарушения целостности проекта. Остальные коллизии воссозданы без исправлений. Проектировщики, которые в будущем будут работать с моделью, смогут увидеть принятые за основу решения и при обоснованной необходимости изменить их в модели. Наглядность модели поможет им быстрее погрузиться в работу над адаптацией проекта повторного применения и завершить ее в кратчайшие сроки.
Масштаб проделанной Renga Software работы оценили и разработчики проекта в лице руководителя ЗАО «Воронеж-Автоматика» Дмитрия Тышнюка и главного инженера Михаила Боброва: «В реестре проектов повторного применения наш проект был представлен в виде чертежей нередактируемого формата PDF. Наличие модели и чертежей в редактируемом формате, которые подготовили специалисты Renga Software, позволят проектировщикам адаптировать решения, принятые в проекте повторного применения, под специфику и условия конкретной местности. Отдельно хотим отметить высокий уровень проработки информационной модели объекта. Наша организация создала в Renga архитектурные решения проектов нескольких объектов, которые уже возводятся. И даже учитывая этот факт, мы собрали коллег и, продемонстрировав им модель, показали к чему нам надо стремиться при разработке BIM-моделей».
Модель дворца бракосочетаний в г. Боброве размещена в профессиональных справочных системах «Техэксперт» и доступна для скачивания вместе с проектной документацией, а на портале Youtube.com размещен видеообзор созданной модели.
Цифры вместо заключения
По данным Минстроя России, многократное применение проектов с доказанной экономической эффективностью уменьшает время, выделяемое на проектирование, примерно на 40%. Создание BIM-моделей проектов повторного применения за счет наглядности и возможности редактирования информационной модели, позволит еще больше увеличить этот показатель, а значит оптимизировать расходы бюджетной системы Российской Федерации на проектирование и строительство объектов по экономически эффективной проектной документации повторного использования.
Уже несколько лет уровень проникновения BIM в России по данным консалтингового агентства «Конкуратор» держится на уровне 22%. Применение технологии информационного моделирования в проектах повторного применения будет способствовать популяризации BIM в России.
Авторы: Дарья Романюк и Яна Колмогорова, Renga Software.
Настройка рабочих дней и рабочего времени для проекта
Классический клиент Project Online Project профессиональный 2021 Project Server по подписке Project стандартный 2021 Project профессиональный 2019 Project Server 2019 Project стандартный 2019 Project профессиональный 2016 Project Server 2016 Project стандартный 2016 Project профессиональный 2013 Project Server 2013 Project стандартный 2013 Еще. Меньше
При создании проекта для планирования работы используется стандартный базовый календарь. Это может быть обычная рабочая неделя с понедельника по пятницу с 8:00 до 17:00 или что-то другое, что лучше соответствует работе вашей организации.
Если рабочее время проекта выходит за рамки стандартных часов, вы можете:
- Изменить рабочее время в календаре проекта в соответствии со своими потребностями. ИЛИ
- Выбрать другой базовый календарь (например, «24 часа» или «Ночная смена»).
Настройка рабочего времени для проекта
Если для обычного графика работы проекта не подходит ни один из доступных базовых календарей, вы можете изменить рабочие дни и рабочее время, чтобы запланировать работу соответствующим образом.
Совет: Это расписание используется для других проектов? Экономьте время коллег, создав расписание проекта в виде нового базового календаря.
- Выберите Свойства > проекта >изменить рабочее время.
В списке Для календаря выберите (календарь проекта), который вы хотите изменить. Перейдите на вкладку Рабочие недели , а затем выберите Сведения.
Примечание: Используйте вкладку Исключения , чтобы добавить праздники в расписание.
Выберите дни, для которого нужно изменить рабочее время, а затем выберите, будет ли это рабочее или нерабочее время.
Если вы выбрали Задать дни для использования этих рабочих часов, с помощью столбцов С и По задайте рабочее время для выбранных дней.
Совет: Изменить рабочие дни или время в середине проекта? Перед нажатием кнопки Сведения присвойте каждому временному интервалу имя на вкладке Рабочие недели и добавьте даты начала и окончания . Выберите первый интервал времени, нажмите кнопку Сведения, а затем повторите процесс для следующего интервала.
Изменение базового календаря для планирования проекта
Project содержит несколько базовых календарей, и ваша организация может иметь дополнительные базовые календари, добавленные администратором. Если базовый календарь уже существует, соответствующий расписанию проекта, можно легко изменить базовый календарь проекта в диалоговом окне Сведения о проекте .
-
Выберите Свойства проекта > >сведения о проекте.
В списке Календарь выберите календарь, который вы хотите использовать для планирования работы, а затем нажмите кнопку ОК.
Как еще можно использовать календари?
Project позволяет точно настроить планирование с помощью нескольких календарей. Если вы понимаете, как календари работают вместе, проще спланировать влияние на даты проекта. Вот еще несколько статей, которые могут оказаться полезными для создания более точной картины рабочих и нерабочих дней в вашей организации.
Если календарь больше не нужен, его можно удалить.
При работе с календарями в Project профессиональный есть разные действия, которые можно сделать, чтобы учитывать рабочее и нерабочее время в вашей организации. В следующих разделах приведены примеры и шаги по внесению каждого изменения.
Примечание: В этой статье предполагается, что вы уже создаете или редактируют календарь. Дополнительные сведения о создании календаря см. в разделах Создание календаря предприятия или Копирование существующего календаря.
В этой статье
- Изменение рабочего дня на нерабочий день
- Преобразование нерабочего дня в рабочий день
- Изменение рабочего времени для рабочего дня
- Изменение рабочего времени для каждого дня рабочей недели
Изменение рабочего дня на нерабочий день
Иногда может потребоваться превратить рабочий день в нерабочий день. Например, если ваша организация отмечает определенные дни как праздники, вы можете превратить эти праздники в нерабочие дни. Project Server не будет планировать работу в нерабочие дни.
Чтобы изменить рабочий день на нерабочий:
- Выберите в календаре дату, которую вы хотите преобразовать в нерабочий день.
- На вкладке Исключения введите имя нерабочего дня в столбце Имя . Столбцы Пуск и Окончание автоматически заполняются датой, выбранной на шаге 1.
Примечание: Хотя можно создать несколько исключений, содержащих определенный день, в этот день будет применяться только исключение самого низкого уровня. Например, может быть одно исключение, изменяющее стандартное рабочее время на месяц, и другое исключение, которое называет определенный день в этом месяце нерабочим днем. Так как однодневное исключение находится на более низком уровне, чем исключение длиной в месяц, в этот день применяется одно исключение нерабочего дня. Нельзя создать несколько однодневных исключений в один день.
Преобразование нерабочего дня в рабочий день
Иногда вашей организации приходится работать над тем, что в противном случае было бы нерабочим днем. Например, предположим, что ваша организация участвует в ежегодном соглашении, которое происходит в выходные дни. Выходные дни соглашения можно преобразовать в рабочие дни, чтобы Project Server знал, как планировать работу в эти дни.
Чтобы изменить нерабочий день на рабочий, выполните приведенные далее действия.
- Выберите в календаре дату, которую вы хотите превратить в нерабочий день.
- На вкладке Исключения введите имя рабочего дня в столбце Имя и нажмите клавишу ВВОД.
Примечание: Хотя можно создать несколько исключений, содержащих определенный день, в этот день применяется только исключение самого низкого уровня. Например, может быть одно исключение, изменяющее стандартное рабочее время на месяц, и другое исключение, которое называет определенный день в этом месяце нерабочим днем. Так как однодневное исключение находится на более низком уровне, чем исключение длиной в месяц, в этот день применяется одно исключение нерабочего дня. Нельзя создать несколько однодневных исключений в один день.
- Выберите строку, которую вы добавили за рабочий день, а затем выберите Сведения.
- В разделе Установка рабочего времени для этих исключений выберите Рабочее время, а затем задайте рабочее время для этого дня, изменив время в столбцах От и До .
- Если ваша организация регулярно наблюдает эти рабочие периоды (например, один раз в месяц или раз в год), в разделе Шаблон повторения выберите, следует ли повторять эти периоды : Ежедневно, Еженедельно, Ежемесячно или Ежегодно, а затем задайте следующие параметры:
- Ежедневно Задайте частоту для этого рабочего времени. Например, каждые 10 дней.
Совет: Если вы обнаружите, что исключение рабочего дня происходит очень часто, вам может быть проще изменить параметры календаря по умолчанию в разделе Расписание в диалоговом окне Параметры проекта в Project профессиональный. Все календари начинаются с этих дней и времени по умолчанию. Изменить параметры календаря по умолчанию проще, чем настроить исключения, которые часто повторяются.
- Начать Выберите дату начала шаблона повторения.
- Окончание после Если вы хотите, чтобы повторение повторялось только заданное количество раз, нажмите кнопку Завершить после и введите количество экземпляров, в которых должно произойти рабочее время.
- Конец Если вы хотите, чтобы повторение происходило только в течение определенного периода времени, нажмите кнопку Завершить до, а затем выберите, когда повторение должно остановиться.
Изменение рабочего времени для рабочего дня
Хотя конкретные дни в календаре могут быть точно учтены как рабочие и нерабочие, могут быть рабочие дни, которые используют расписание, отличное от стандартного 8-часового рабочего дня. Вы можете настроить рабочее время для определенного рабочего дня, чтобы точно запланировать работу на этот день.
Чтобы изменить рабочее время рабочего дня, выполните следующие действия:
- Выберите в календаре дату рабочего дня, который нужно изменить.
- На вкладке Исключения в столбце Имя введите имя измененного рабочего дня и нажмите клавишу ВВОД.
Примечание: Хотя можно создать несколько исключений, содержащих определенный день, в этот день применяется только исключение самого низкого уровня. Например, может быть одно исключение, изменяющее стандартное рабочее время на месяц, и другое исключение, которое называет определенный день в этом месяце нерабочим днем. Так как однодневное исключение находится на более низком уровне, чем исключение длиной в месяц, в этот день применяется одно исключение нерабочего дня. Нельзя создать несколько однодневных исключений в один день.
- Выберите строку, добавленную для измененного рабочего дня, а затем выберите Сведения.
- В разделе Задать рабочее время для этих исключений выберите Рабочее время, а затем задайте рабочее время для этого дня, изменив время в столбцах От и До .
- Если ваша организация регулярно наблюдает эти рабочие периоды (например, один раз в месяц или раз в год), в разделе Шаблон повторения выберите, следует ли повторять эти периоды : Ежедневно, Еженедельно, Ежемесячно или Ежегодно, а затем задайте следующие параметры:
- Ежедневно Задайте частоту для этого рабочего времени. Например, каждые 10 дней.
- Еженедельно Укажите частоту повторения рабочего времени и в какой день недели они должны повторяться. Например, каждые две недели в субботу.
- Ежемесячно Выберите день месяца и с какой периодичностью вы хотите, чтобы рабочее время повторялось. Например, день 15 каждого третьего месяца или третья суббота каждого шестого месяца.
- Ежегодно Выберите, в какой день года будет повторяться рабочее время. Например, 21 августа или третья суббота июля.
- В разделе Диапазон повторений укажите период, в течение которого необходимо выполнить повторение, если это необходимо.
- Начать Выберите дату начала шаблона повторения.
- Окончание после Если вы хотите, чтобы повторение повторялось только заданное количество раз, нажмите кнопку Завершить после и введите количество экземпляров, в которых должно произойти рабочее время.
- Конец Если вы хотите, чтобы повторение происходило только в течение определенного периода времени, нажмите кнопку Завершить до, а затем выберите, когда повторение должно остановиться.
- Нажмите кнопку ОК.
Изменение рабочего времени для каждого дня рабочей недели
Если в вашей организации есть определенная рабочая неделя (или набор рабочих недель), если рабочее время отличается от времени по умолчанию, вы можете внести эти изменения в рабочее время для каждого дня в рабочей неделе в течение заданного периода времени. Например, если ваша организация не использует расписание по умолчанию с понедельника по пятницу с 08:00 до 17:00, вы можете изменить рабочее время для каждого дня в рабочей неделе в соответствии с точным графиком вашей организации.
Чтобы изменить рабочее время для каждого дня рабочей недели, выполните следующие действия:
- Выберите дату в календаре, с которой нужно начать измененное рабочее время.
- На вкладке Рабочие недели в столбце Имя введите имя измененной рабочей недели или недель, а затем нажмите клавишу ВВОД.
- Измените дату в столбце Готово для только что добавленной строки, чтобы отразить последний день, который вы хотите включить в измененную рабочую неделю или недели.
- Выберите Сведения.
- В разделе Выбор дней выберите день недели, в который вы хотите использовать скорректированное рабочее время. Нажмите клавиши CTRL или shift и щелкните, чтобы выбрать несколько дней.
- Если вы хотите превратить выбранный день или дни в нерабочее время, выберите Задать дни для нерабочего времени.
- Если вы хотите изменить рабочее время для выбранного дня или дней, выберите Задать дни для этого рабочего времени, а затем задайте рабочее время, введя в столбцах От и До .
- Нажмите кнопку ОК.
Методы сбора требований или «Как понять, что хочет заказчик?»
Данная статья будет полезна как аналитикам, так и менеджерам, занимающимся сбором и анализом требований. В ней описаны основные методики сбора требований, а также их плюсы и минусы. Возможно, что-то вы уже применяли на практике, а о чем-то, возможно, не знали. В общем, эта статья для всех тех, кто уже занимается бизнес — анализом или только планирует пополнить ряды аналитиков.
Сбор требований — это один из самых важных этапов процесса создания любой информационной системы, будь то десктопное, веб или мобильное приложение или же просто доработка уже существующего решения. Прежде, чем начать собирать требования, необходимо выявить всех заинтересованных лиц (стейкхолдеров), которые будут пользоваться системой. Чем точнее будет этот список, тем полнее будут требования. Итак, для начала, рассмотрим кто же такие стейкхолдеры.
Стейкхолдерами могут быть любые физические лица и/или организации, которые активно участвуют в нашем проекте, и чьи интересы могут быть затронуты не только в процессе создания системы, но и непосредственно по завершению самого проекта. Ими могут быть менеджеры, начальники отделов, директора, любые сотрудники организации, которые будут хоть как-то взаимодействовать с готовым решением, и чьи требования (пожелания, идеи, потребности, проблемы) будем собирать.
Существует множество различных техник сбора требований, которые помогут лучше понять, что же хочет заказчик.
Рассмотрим основные из них чуть подробнее:
Анкетирование
Данный способ подразумевает под собой составление листа-опросника (анкеты, брифа), который может содержать открытые (требуют от опрашиваемого сформулировать его ответ) и закрытые (требуют от опрашиваемого выбрать ответ из предложенных вариантов) вопросы.
Анкетирование используется для того, чтобы подтвердить или детализировать ранее известные требования, выбрать параметры для решений.
Самым известным примером анкетирования может быть “Бриф на разработку сайта” — анкета содержащая список основных требований и информацию о будущем сайте.
Преимущества:
- Высокая скорость получения результатов.
- Сравнительно небольшие материальные затраты.
- Данный метод не подходит для выявления неявных требований.
- При составлении опросника физически невозможно учесть все необходимые вопросы.
Интервью
Этот метод известен многим, своего рода беседа “по душам” с заинтересованным лицом, тет-а-тет.
Необходимо задавать открытые вопросы для получения информации и закрытые для того, чтобы подтвердить или опровергнуть конкретные варианты требований.
Данный способ применяется, в основном, для получения информации по какой-либо конкретной теме и/или для уточнения требований.
Многим может показаться этот способ достаточно легким, но это не так. Провести хорошее интервью достаточно сложно. Вы должны гибко реагировать на реакцию интервьюируемого и в случае необходимости изменять порядок заготовленных вопросов или их формулировку. Не забудьте включить диктофон во время интервью или вести заметки.
- Возможность задавать вопросы в произвольной последовательности.
- Возможность использовать вспомогательный материал.
- Анализ невербальной реакции опрашиваемого человека, позволит сделать дополнительный вывод о достоверности его ответов.
- Интервью отнимает достаточно много времени и сил.
- Дополнительной сложностью является получение одинаковых ответов от интервьюируемых.
Автозапись
Данный метод подразумевает под собой работу с записями, письмами (электронными письмами), а также с любым другим документом, автором которого является Заказчик или конечный пользователь (т.е. стейкхолдер).
В действительности это может быть и документ и наговоренная на диктофон последовательность действий или самая обычная салфетка, на которой заказчик набросал свои идеи / проблемы /хотелки, которые необходимо превратить в полноценные требования, согласовать и передать в разработку.
Примером такого метода может быть работа с концепцией или видением проекта (сам Заказчик любит называть это — «ТЗ»), которую он прислал вам на момент начала работ по аналитике.
Преимущество:
- Помогает лучше понять сложные процедуры или процессы.
- Данный метод сильно зависит от опыта Заказчика, а также от его умения формулировать и выражать свои мысли.
Изучение существующей документации
Данная методика может быть использована при наличии в организации документации, которая может помочь в определении потребностей Заказчика. Примеры документации включают в себя: регламенты,
описания процессов, структура организации, спецификации продукта, различные процедуры, стандарты и инструкции, шаблоны документов и т.д.
Выявленные требования являются основой для дальнейшего анализа и должны быть детализированы.
Данная методика применима, например, при автоматизации устоявшихся в организации регламентированных бизнес процессов.
- Быстрое получение информации.
- Данный способ не применим при наличии в компании только базовых документов (или при их полном отсутствии) или, если в компании Заказчика не поддерживается актуальность документации.
Повторное использование спецификации
Повторно использовать спецификации можно в том случае, если есть уже завершенные один или несколько подобных проектов.
Техническое задание, подготовленное на предыдущем проекте может быть использовано для другого проекта с целью сократить продолжительность сбора, анализа и разработки требований, что позволит быстрее начать разработку.
Например, ТЗ для интернет магазинов похожи друг на друга и содержат одинаковые требования.
В большинстве случаев только часть документации актуальна для нового проекта, поэтому потребуется тщательная проверка требований на соответствие текущим целям и задачам Заказчика.
Преимущество:
- Сокращение времени на разработку документации.
- Высокая стоимость первого проекта.
- Излишняя детализация требований, может привести к их дорогостоящим изменениям в будущем.
Представитель заказчика в компании разработчика
Один из наиболее эффективных методов сбора требований, поскольку позволяет получать от представителя Заказчика своевременную оценку прогресса, корректности реализации, в короткие сроки получать обратную связь (фидбек) и дополнительную информацию для корректировки и разработки требований.
Метод часто применяется для сбора и управления требованиями при итерационной разработке, позволяет оперативно собирать, согласовывать и дорабатывать требования.
В дополнение можно сказать, что наличие представителя заказчика в компании разработчика является одним из главных правил Agile.
Преимущество:
- Быстрое получение обратной связи и информации от Заказчика.
- Достаточно высокая цена для Заказчика.
- Затраты по времени на адаптацию сотрудника.
Работа «в поле»
Работа «в поле» состоит из наблюдения за деятельностью и процессами будущих пользователей системы, и в определении требований, основанных на этом наблюдении. Если говорить проще, то это наблюдение за тем, как работают пользователи, и документирование процесса, задач и результатов их деятельности.
Метод позволяет избежать проблем, связанных с трудностями стейкхолдеров в описании и выражении своих потребностей. В некоторых случаях процесс наблюдения может сопровождаться «интервьюированием» пользователей для уточнения особенностей и деталей их работы и задач. В процессе наблюдения можно так же выявить пути оптимизации бизнес процессов Заказчика.
Преимущества:
- Позволяет наглядно увидеть проблему и разработать наиболее оптимальный вариант ее решения.
- Помогает наиболее точно собрать требования, наблюдая за работой сотрудников.
- В процессе наблюдения могут быть упущены некоторые альтернативные сценарии бизнес процесса.
- Трудно применим на секретных предприятиях или опасных (вредных) производствах.
Обучение
Обучение — это процесс, в котором Заказчик или любой другой человек из организации Заказчика, знающий процесс, обучает аналитика по принципу учитель — ученик.
Метод полезен, когда процессы и деятельность сотрудников Заказчика трудно описать с помощью других методов или Заказчик не может предоставить адекватное описание требований.
Обучение позволяет лучше понять сложные бизнес-процессы, а также преодолеть трудности, связанные с нехваткой абстрактного мышления и самовыражения у будущих пользователей системы.
Преимущество:
- Позволяет понять сложный бизнес процесс, что позволяет предложить наилучшее решение.
- Высокая стоимость и длительность.
- Метод неприменим на опасных (вредных) производствах.
Мозговой штурм
Мозговой штурм — наиболее часто используемый метод получения требований, которые связанны с новыми или плохо изученными направлениями деятельности организации Заказчика или функциями системы.
Он позволяет собрать множество идей от различных заинтересованных лиц (стейкхолдеров) в кратчайшие сроки и практически бесплатно.
Во время мозгового штурма участники «накидывают» любые идеи, касающиеся решения данной проблемы.
С помощью этой методики можно проработать несколько различных вариантов решения заданной проблемы, а также разрешить конфликты требований.
- Позволяет генерировать множество (в том числе и нестандартных) вариантов решений, а также позволяет участникам развивать идеи друг друга.
- Участники мозгового штурма должны быть мотивированы на идеи.
- Трудно применим в распределенных командах.
Совещание
Совещание — встреча, ориентированная на обсуждение конкретных вопросов, которые были определены и озвучены участникам заранее.
На такие встречи привлекаются люди, которые придерживаются различных точек зрения по текущей проблеме и могут помочь описать требования, основываясь на взглядах с разных сторон. В процессе совещания уточняется общий список требований, выявляются скрытые требования и решаются конфликты требований.
Совещания являются одной из ключевых практик в Agile, т.к. в них участвуют все стороны, заинтересованные в развитии проекта и решении проблемы.
- Позволяет развить и детализировать требования, определить приоритеты.
- Сложности в организации встречи, если команда географически разделена, могут возникнуть трудности с присутствием всех необходимых людей на совещании.
- Консенсус необязательно будет достигнут.
Use case
Use cases или варианты использования позволяют собрать и сформировать функциональные требования от лица участников Диаграммы вариантов использования определяют границы решения и показывают связи с внешними системами и участниками.
Метод позволяет детализировать требования с точки зрения пользователей, а также помогает уточнить и систематизировать функционал, который требуется реализовать.
- Позволяет проработать все варианты развития сценария (основной и альтернативные сценарии)
- Метод не применим для сбора нефункциональных требований.
Эпилог
Комбинирование методик позволяет повысить эффективность сбора требований, а так же избежать их «потери».
При сборе требований необходимо помнить, что важны не только функциональные требования (ЧТО делает система), но и нефункциональные (КАК система это делает).
Тщательно собранные требования минимизируют риски проекта, т.к. позволяют сформировать четкий и понятный базис для разработки системы.
Информация для статьи взята из учебного пособия по подготовке к сертификации REQB Certified Professional for Requirements Engineering (Базовый уровень).
Спасибо за внимание!
Авторские материалы о разработке и управлении мы также публикуем в наших соцсетях – ВКонтакте и Telegram.
- ит-консалтинг
- управление требованиями
- аналитика проекта
- сбор требований
- Блог компании SimbirSoft
- Анализ и проектирование систем