Требования к разработчикам проектной документации

Содержание

Разработка проектной документации на строительство

Требования к разработчикам проектной документации

01.12.2017

Разработка проектной документации на строительство — начальный этап работ по возведению того или иного объекта. Структура, состав и порядок составления проекта утверждается на законодательном уровне, а его содержание является основной для работы специалистов. В чем особенности такой документации? Как она правильно составляется? Кто занимается разработкой проекта, и какие требования к нему предъявляются? Этим и ряду других вопросов уделим внимание в статье.

Что такое проектная документация в строительстве?

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

Задача проекта состоит в том, чтобы регламентировать процесс воплощения строительной документации в жизнь. Кроме того, его оформление является одним из требований законодательства. Без наличия такого документа ввести готовый объект в эксплуатацию не получится. Кроме того, наличие проекта обязательно при перепланировании, реконструкции и строительстве объектов.

Получается, проектно-сметная документация необходима для решения двух задач:

  • Выполнения требований законодательства.
  • Использования в роли источника данных при возведении сооружений и зданий с соблюдением действующих критериев качества.

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

Процесс разработки документации

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

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

  • Рабочая документация и проекты для сооружений с 4 по 6 категории, а также для зданий 3 категории, возводимых по персональному проекту.
  • Рабочая и проектная документация для зданий с 1 по 3 категории, а также объектов, возводимых по типовым проектам.

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

  • Особая социальная значимость.
  • Расположение объекта на значимой территории.
  • Технически сложное сооружение.

При изучении вопроса разработки проекта стоит различать два типа документации:

  • На возведение зданий гражданского и жилищного назначения.
  • На строительство сооружений, зданий и других объектов производственного характера.

Алгоритм разработки проектной документации имеет следующий вид:

  • Выпускается приказ.
  • Формируется задание с последующей передачей главному проектировщику.
  • Составляется проектная документация с учетом полученных исходных параметров.
  • Готовый документ передается для согласования.

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

Порядок разработки проектной документации относится ко всем субъектам, которые имеют разрешение на подготовку проектов.

Кто разрабатывает?

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

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

Требования к документам

При составлении проектной документации главный упор делается на Градостроительный кодекс РФ. Именно в нем прописываются требования, которые должны соблюдаться при оформлении проекта и сметы на строительство. В ГрК РФ, в свою очередь, указано, что требования к проектно-сметной документации устанавливает Правительство РФ. Если исходить из практики, главные требования к проекту рассмотрены в Постановлении под номером 87 (принято еще в феврале 2008 года).

  Правила производства строительных работ ОКВЭД 2017

Нормы, которые содержатся в упомянутом Постановлении, используются при подготовке проекта для следующих сооружений:

  • Производственного назначения.
  • Непроизводственного назначения.
  • Сооружений линейного типа.

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

  • Данные о возводимом объекте.
  • Описание технических решений.
  • Пояснения и ссылки на действующие нормативные источники, применяемые в процессе подготовки документов.
  • Расчеты, которые подтверждают принятые решения.

В графической части содержатся планы, схемы, чертежи и прочие элементы, представленные в графическом виде.

Исходные данные

Чтобы избежать проблем в процессе строительства, заказчик передает проектировщику следующие исходные данные:

  • ГПЗУ или проект планирования территории, который будет использоваться для возведения объекта.
  • Бумаги, отражающие результаты инженерных изысканий. Если они не подготовлены, требуется задание на их выполнение.
  • Техусловие (если обеспечение работы строительного объекта требует технического подключения).

Таким образом, главные исходные данные — это:

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

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

  • Задание на реставрацию — документ, который выдается отдельно или вместе с основным проектом (в зависимости от действующих требований и норм). Дальнейшее оформление и реализация договора между сторонами по реализации проекта производится в порядке, предусмотренном в ГрК РФ и законодательстве РФ в целом. Если разработка проектной документации ведется за бюджетные деньги, выбор проектировщика производится с учетом действующих требований и законодательства. При этом цена и технология процесса оговаривается на раннем этапе.
  • Технические условия. Такие исходные данные могут дополнять проектную документацию. При этом исполнители должны знать специфику их применения. Этот аспект также регламентируется Постановлением правительства под номером 87. В документе указано, что разработка техусловий обязательно в ряде случаев. Во-первых, когда соответствующие требования не отражены в нормативных актах. Во-вторых, в ситуации, когда разработка проекта требует выполнения большего числа требований, касающихся безопасности и надежности конструкций. Создание технических условий производится с учетом норм, установленных законодательством. На практике его созданием занимается ЖКХ РФ, Минстрой РФ, а также другие государственные органы.
Читайте также  Помещение зарядной аккумуляторов требования

  Стимулирование развития жилищного строительства

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

Ответственность разработчика

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

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

При этом исполнитель несет ответственность не только за сам процесс, но и за полученный результат. Готовая документация должна соответствовать нормам и требованиям ГрК РФ и действующих законодательных актов

( 0,00 из 5)
Для того чтобы оценить запись, вы должны быть зарегистрированным пользователем сайта. Загрузка…

Источник: https://stroimprosto-msk.ru/stati/razrabotka-proektnoj-dokumentacii-na-stroitelstvo/

Управление документацией в проектах разработки ПО

Требования к разработчикам проектной документации

21.09.2006 Александр Самбук

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

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

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

Классификация и виды документации

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

Рисунок. Виды документации

Описание проекта

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

В различных организациях документы такого рода называются по-разному: техническое задание, задание на разработку, обоснование и т.д. Однако, несмотря на различия в названиях, их цель — описать ключевые положения контрактного характера. Это описание обычно служит приложением к контракту и основой для выделения средств, а поэтому должно быть разработано с максимальной тщательностью.

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

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

Планы

Необходимыми атрибутами планов являются: собственно описание требуемых действий; информация о событиях, «запускающих» эти действия; описание взаимной зависимости действий между собой; информация об исполнителях. Календарный план (schedule), кроме этого, содержит информацию о прогнозируемых датах начала и окончания действий. Наиболее распространенным видом планов является план-график проекта в нотации Ганта и Перта.

Исследовательские проекты, а также проекты, управляемые временем (time-driven project), могут обходиться без планов-графиков. В таких проектах планирование может иметь неглубокий горизонт, а планы на будущий период фиксироваться, например, в регулярных отчетах.

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

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

Задания исполнителям и отчеты о ходе работ

Задания (task), выдаваемые исполнителям, подлежат документированию в целях исключения их «забывания» и двоякого толкования. Документальные формы, используемые для накопления и отслеживания заданий, на практике используются редко и обычно в качестве источника информации о выданных заданиях применяются: планы-графики; специально выделенные разделы в регулярных отчетах; задачи, выставленные через Microsoft Outlook или через системы управления изменениями (такие, как IBM ClearQuest).

Отчеты о ходе работ (status report) применяются для информирования руководства и заказчика о статусе проекта. Отчеты могут исходить как от конечных исполнителей, так и от менеджера проекта.

Протоколы

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

Отчеты о результатах активностей

Ход мероприятий, которые завершаются принятием ключевых для проекта решений, отражается в отчетах, представляемых на рассмотрение лицу, принимающему решение. Основными мероприятиями такого рода являются: анализ осуществимости, анализ альтернатив реализации, обзор (review) проектной документации, тестирование и приемка. Протоколы этих активностей, как правило, содержат сведения о времени, объекте, рамках и характере активности, среде, в которой проводилась активность, достигнутых результатах и рекомендуемых решениях.

Читайте также  Двери лестничных клеток противопожарные требования

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

Журналы

Журнал (log) — накопительное перечисление тех или иных однотипных событий или фактов, возникающих в ходе проекта. Типичными объектами, накапливаемыми в журналах, являются риски, проблемы, запросы на изменения, дефекты (как документации, так и собственно продукта). План-график может заменяться или дополняться «журналом задач», в случае, если эти задачи носят локальный характер.

Журналы редко оформляются в виде отдельного документа. Журналы рисков и проблем обычно являются разделом в отчете о состоянии проекта; ведение журналов изменений и дефектов организуется с помощью систем управления изменениями.

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

Технические требования

Технические требования, или требования к системе (system requirements specification), описывают функциональность, которую должен содержать продукт, а также ожидания заказчика относительно производительности, отказоустойчивости, надежности системы, среды, в которой она должна работать и т.д. Часто требования являются частью контрактной документации.

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

Технические спецификации

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

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

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

Сведения о выпуске

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

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

Руководства

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

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

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

Документация, методологии и стандарты качества

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

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

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

Александр Самбук (ASambuk@mail.ru) — генеральный директор Центра программных решений «Тауэр» (Москва).

Управление документацией в проектах разработки ПО

Поделитесь материалом с коллегами и друзьями

Источник: https://www.osp.ru/os/2006/07/3290814/

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

Требования к разработчикам проектной документации

ВЕДОМСТВЕННЫЕ СТРОИТЕЛЬНЫЕ НОРМЫ

ИНСТРУКЦИЯ  ПО РАЗРАБОТКЕ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ ДЛЯ СТРОИТЕЛЬСТВА ОБЪЕКТОВ МЕДИЦИНСКОЙ И МИКРОБИОЛОГИЧЕСКОЙ ПРОМЫШЛЕННОСТИ С ПРИМЕНЕНИЕМ БЛОКОВ.

ТЕХНОЛОГИЯ ПРОИЗВОДСТВА

ВСН 64-0-54-88

МИНМЕДБИОПРОМ СССР

ВСН 512-88

МИНМОНТАЖСПЕЦСТРОЙ СССР

МИНИСТЕРСТВО МОНТАЖНЫХ И СПЕЦИАЛЬНЫХ
СТРОИТЕЛЬНЫХ РАБОТ СССР

МИНИСТЕРСТВО МЕДИЦИНСКОЙ И
МИКРОБИОЛОГИЧЕСКОЙ ПРОМЫШЛЕННОСТИ СССР

РАЗРАБОТАНЫ ВНИИмонтажспецстроем Минмонтажспецстроя СССР (В.Я. Эйдельман, А.Г. Коновалова, А.Л. Прудовская), Южгипробиосинтезом Минмедбиопрома СССР (И.Г. Носач, И.Г. Шихер, М.Н. Солдатенков)

ВНЕСЕНЫ И ПОДГОТОВЛЕНЫ К УТВЕРЖДЕНИЮ Главным техническим управлением Минмонтажспецстроя СССР, Главным управлением проектирования и капитального строительства Минмедбиопрома СССР

Минмонтажспецстрой СССР

Минмедбиопром СССР

Ведомственные строительные нормы

ВСН 512-88

Минмонтажспецстрой СССР

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

ВСН 64-0-54-88

Минмедбиопром СССР

Вводится впервые

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

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

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

1. ОБЩИЕ ПОЛОЖЕНИЯ

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

Генеральные проектные организации Минмедбиопрома СССР (далее генпроектировщик) на основании схемы развития отрасли в установленном порядке должны представлять заказы Минхиммашу СССР на технологические комплексы для включения в «Перечень оборудования, подлежащего комплектной поставке», утвержденный Госснабом СССР и Госпланом СССР (далее перечень). В заказ должны быть включены технологические комплексы для всех объектов нового строительства, расширения и реконструкцию, в том числе указанные в приложении к приказу Минмедбиопрома СССР, Минхиммаша СССР и Минмонтажспецстроя СССР от 28.07.87 № 601/332/269 (далее приказ).

Читайте также  Требования пожарной безопасности к ресторанам кафе

Внесены Главным управлением проектирования и капитального строительства Минмедбиопрома СССР

Главным техническим управлением Минмонтажспецстроя СССР

Утверждены Минмедбиопромом СССР
20 января 1988 г.

Минмонтажспецстроем СССР
25 января 1988 г.

Срок введения в действие
1 сентября 1988 г.

Технологические комплексы (ТК), включенные в перечень, в том числе указанные в приказе, должны разрабатываться в соответствии с «Положением о проектировании, производстве, поставке, вводе в эксплуатацию, наладке и доводке комплексов машин, оборудования и приборов, поставляемых комплектно потребителям» (постановление ГКНТ СССР, Госплана СССР, Госстандарта СССР, Госснаба СССР и Госстроя СССР от 12.12.86 г. № 517/233/9/184/53 – далее положение).

Проектная документация для строительства объектов, поставка оборудования для которых не вошла в перечень, должна разрабатываться с применением блоков, собираемых на производственных базах Минмонтажспецстроя СССР. В этом случае разработка ведется в соответствии с техническими условиями на проектирование с применением блоков, которые являются неотъемлемой частью задания на проектирование.

1.2. Технологическая часть объекта строительства должна разрабатываться из технологических блоков и блоков коммуникаций с соблюдением инструкции «Технические требования (монтажные) к проектированию объектов медицинской и микробиологической промышленности с применением блоков. Технология производства», ВСН 485-86/Минмонтажспецстрой СССР — ВСН 131-86 / Минмедбиопром СССР (далее ВСН 131-86).

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

1.3. Конструкторскую документацию разрабатывают в соответствии со стандартами «Единой системы конструкторской документации» (ЕСКД), проектную документацию для строительства – в соответствии с ГОСТ 21.401-88 «Система проектной документации для строительства. Технология производства. Основные требования к рабочим чертежам», и пособиям к настоящей инструкции. Заявку и техническое задание (ТЗ) на разработку технологических комплексов и блоков составляют в соответствии с настоящей инструкцией.

1.4. Разработку технологической части объекта строительства с применением ТК осуществляют:

генпроектировщик с привлечением организаций Минмедбиопрома СССР;

головные специализированные организации по разработке АСУ ТП, электроснабжения, промвентиляции и других систем обеспечения технологического комплекса (далее разработчики СО) с привлечением организаций – разработчиков комплектующих изделий систем обеспечения;

головная организация Минмонтажспецстроя СССР по комплектно-блочному методу производства монтажных работ (далее головная организация Минмонтажспецстроя ССР) и других организаций министерства.

Разработку технологического комплекса (блоков) для технологической части объекта строительства осуществляет институт Минхиммаша СССР (далее головной разработчик ТК) с привлечением организаций Минхиммаша СССР специализирующихся на разработке блоков и комплектующих в составе ТК, а также организаций других министерств и ведомств для разработки документации на блоки, не являющиеся специализацией Минхиммаша СССР.

1.5. Разработку технологического комплекса головной разработчик ТК осуществляет, как правило, по договору с головным поставщиком.

Допускается осуществлять разработку ТК по договору с генпроектировщиком или заказчиком ТК.

Разработку комплекса блоков осуществляют по договорам с головным разработчиком.

При заключении договора на разработку ТК с головным поставщиком или заказчиком разработку чертежей расположения блоков и трубопроводов, а также схем соединений блоков осуществляет проектный институт Минмедбиопрома СССР по договору с головным разработчиком.

Неотъемлемой частью договоров на разработку конструкторской документации на ТК, блоки, комплектующие изделия и проектной документации на объект строительства должен являться график.

При заключении договоров необходимо руководствоваться «Положением о договорах на создание (передачу) научно-технической продукции», утвержденным постановлением ГКНТ СССР от 19.11.87 № 435.

Стоимость разработок определяется договорной ценой.

1.6. Документацию для строительства с применением ТК следует разрабатывать в последовательности, приведенной в таблице, с соблюдением «Порядка разработки, согласования, экспертизы и утверждения технических проектов на создание технологического оборудования с длительным циклом конструирования и изготовления и передачи этой документации для разработки проектов на строительство». Постановление ГКНТ СССР и Госстандарта СССР от 4.07.85 № 355/76 (далее порядок разработки оборудования).

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

График составляет генпроектировщик по исходным данным участников разработки, указанных в п. 1.4. настоящей инструкции.

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

1.7. Разработку технологической части проектной документации для строительства объектов, поставка оборудования для которых не вошла в перечень, осуществляет генпроектировщик с привлечением Гипрохиммонтажа в соответствии с ВСН 131-86 и приказом.

Этап

Исполнитель

ГП

ГР

ГРСО

ГМ

ПИ

КБ

КБЗ

1. Подготовка к разработке конструкторской и проектной документации

1.1. Подготовка и выдача генпроектировщику исходных данных к заявке на ТК и к техническим условиям на проектирование строительства

+

+

+

1.2. Разработка, согласование и передача головному разработчику заявки на ТК, передача проектным институтам  утвержденных заказчиком технических условий на проектирование

+

С

С

С

1.3. Составление и выдача генпроектировщику заключения по заявке на ТК, подготовка и утверждение заявки

+

+

+

1.4. Выдача головному разработчику исходных данных для ТЗ на ТК

+

+

+

+

1.5. Разработка и утверждение ТЗ на ТК

+

+

+

+

1.6. Заключение договоров на разработку

+

+

+

+

+

+

2. Разработка конструкторской документации на ТК и технического проекта объекта строительства

2.1. Разработка и согласование аванпроекта ТК

С

+

+

С

С

+

С

2.1.1. Разработка аванпроектов блоков и передача их генпроектировщику для разработки компоновки объекта

+

+

+

2.1.2. Разработка блок-схемы и компоновки объекта из блоков и передача головному разработчику для формирования аванпроекта ТК

+

+

+

2.2. Разработка технологической части проекта объекта строительства

+

+

+

2.3. Уточнение ТЗ на ТК

+

+

+

+

2.4. Разработка, согласование, экспертиза технического проекта ТК, передача его разработку рабочей документации на строительство (чертежи марки ТХ) и рабочей документации для изготовления и поставки

С,Э

+

+

С,Э

С,Э

+

С,Э

2.4.1. Разработка технических проектов блоков

+

+

2.4.2. Разработка чертежей расположения блоков, схемы соединений

+

+

2.4.3. Составление комплекта технического проекта и представление на утверждение

+

+

3. Разработка рабочей документации для изготовления ТК и чертежей марки ТХ

3.1. Разработка и передача застройщику чертежей марки ТХ

+

+

3.2. Разработка рабочих чертежей блоков для изготовления

+

4. Заказ оборудования, изделий и материалов для строительства

4.1. Составление заказных спецификаций и ведомостей объемов работ, передача на заявку:

а) при разработке ТК по договору с генподрядчиком;

+

+

б) при разработке ТК по договору с головным поставщиком или заказчиком

+

Примечания:

1.

Этап 1.5 и 2.1 могут быть совмещены.

2.

Этап 2.4.3 выполняет головной разработчик при заключении договора на разработку ТК с головным поставщиком.

3.

Принятые обозначения:

ГП — генпроектировщик;

ГР — головной разработчик;

ГРСО — головные разработчики систем обеспечения;

ГМ — головная организация Минмонтажспецстроя СССР;

ПИ — проектные институты Минмедбиопрома СССР;

КБ — разработчики блоков и комплектующих в составе ТК;

КБЗ — конструкторское бюро завода-изготовителя;

С — согласование;

Э — экспертиза.

2. ЗАЯВКА НА ТЕХНОЛОГИЧЕСКИЙ КОМПЛЕКС

2.1. Генпроектировщик представляет заявку на ТК одновременно с передачей ТЭО (ТЭР) на экспертизу.

Заявку представляют головному разработчику или головному поставщику в зависимости от решения, принятого по п. 1.5 настоящей инструкции.

Для составления заявки генпроектировщик привлекает исполнителей, указанных в таблице.

Источник: https://files.stroyinf.ru/Data2/1/4294847/4294847792.htm