Типовая проектная документация | Минстрой России

1 июля 2021 года принят Федеральный закон № 275-ФЗ «О внесении изменений в Градостроительный кодекс Российской Федерации и отдельные законодательные акты Российской Федерации» (далее – Федеральный закон № 275-ФЗ), согласно которому застройщик, технический заказчик или лицо, обеспечившее выполнение инженерных изысканий и (или) подготовку проектной документации в случаях, предусмотренных частями 1.1 и 1.2 статьи 48 Градостроительного кодекса Российской Федерации (далее – ГрК РФ), обеспечивающие подготовку проектной документации с использованием экономически эффективной проектной документации повторного использования, до 1 октября 2021 года завершает такую подготовку в соответствии с порядком, установленным статьей 48.2 Кодекса (в редакции, действовавшей до 1 октября 2021 года). Экономически эффективная проектная документация повторного использования, сведения о которой по состоянию на 1 октября 2021 года включены в единый государственный реестр заключений экспертизы проектной документации объектов капитального строительства (далее – ГИС ЕГРЗ), признается типовой проектной документаций.

В соответствии с частью 1 статьи 48.2 ГрК РФ (в редакции Федерального закона № 275-ФЗ) проектная документация, получившая положительное заключение государственной экспертизы проектной документации и использованная при строительстве, реконструкции объекта капитального строительства, в отношении которого получено разрешение о его вводе в эксплуатацию, по решению уполномоченного Правительством Российской Федерации федерального органа исполнительной власти может быть признана типовой проектной документацией в порядке, установленном Правительством Российской Федерации.

Частью 2 статьи 48.2 Кодекса установлено, что сведения о типовой проектной документации включаются в единый государственный реестр заключений экспертизы проектной документации объектов капитального строительства уполномоченным Правительством Российской Федерации федеральным органом исполнительной власти.

В соответствии с пунктом 5 раздела II Правил использования типовой проектной документации Федеральные органы исполнительной власти, органы исполнительной власти субъекта Российской Федерации, органы местного самоуправления, юридические лица, созданные Российской Федерацией, субъектом Российской Федерации, муниципальным образованием, юридические лица, доля в уставных (складочных) капиталах которых Российской Федерации, субъектов Российской Федерации, муниципальных образований составляет более 50 процентов, со дня включения сведений о типовой проектной документации, исключительное право на которую принадлежит Российской Федерации, субъекту Российской Федерации или муниципальному образованию, в ГИС ЕГРЗ при подготовке проектной документации применительно к объекту капитального строительства, строительство которого они обеспечивают, обязаны использовать типовую проектную документацию, подготовленную применительно к объекту капитального строительства, аналогичному по назначению, проектной мощности, природным и иным условиям территории, на которой планируется осуществлять такое строительство (за исключением случаев подготовки проектной документации в целях строительства особо опасных, технически сложных, иных определенных главным распорядителем средств соответствующего бюджета объектов капитального строительства, случаев подготовки проектной документации на основании концессионных соглашений, соглашений о государственном частном партнерстве, а также в целях реконструкции, капитального ремонта объектов капитального строительства, проведения работ по сохранению объектов культурного наследия).

В соответствии с пунктами 2, 3 и 4 раздела I Правил использования типовой проектной документации (далее – Правила использования), утвержденных постановлением Правительства Российской Федерации от 1 марта 2022 г. № 278, при осуществлении архитектурно-строительного проектирования, строительства, реконструкции объекта капитального строительства застройщик, технический заказчик, лицо, обеспечившее выполнение инженерных изысканий и (или) подготовку проектной документации в случаях, предусмотренных частями 1.1 и 1.2 статьи 48 ГрК РФ, вправе использовать типовую проектную документацию, подготовленную применительно к объекту капитального строительства, аналогичному по назначению, проектной мощности, природным и иным условиям территории, на которой планируется осуществлять такие строительство, реконструкцию.

В соответствии с приказом Министерства строительства и жилищно-коммунального хозяйства Российской Федерации от 2 марта 2022 г. № 135/пр утверждены критерии, на основании которых устанавливается аналогичность проектируемого объекта капитального строительства и объекта капитального строительства, применительно к которому подготовлена проектная документация, в отношении которой принято решение о применении типовой проектной документации (далее – критерии аналогичности):

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

2. Мощность проектируемого объекта соответствует мощности объекта капитального строительства (допустимое отклонение значения составляет не более 10%).

3. Площадь и (или) протяженность проектируемого объекта соответствует площади и (или) протяженности объекта капитального строительства (допустимое отклонение значения составляет не более 10%).

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

ВИТРИНА ПРОЕКТОВ

Посмотреть Скачать

Проекты повторного использования себя не оправдали, Минстрой заменит их типовыми

Проекты повторного применения существенно сокращают сроки проектирования и стоимость строительства. О том, что их надо применять активнее, как-то сказал президент РФ. Какое-то время тема была модной. Впрочем, помимо рассуждений особых прорывов не случилось. В Петербурге первые типовые проекты определили ещё в 2015 году, а потом сформировали из них общий реестр. Чтобы упростить повторное использование, появился и Единый реестр заключений экспертизы проектной документации. В 2016-м использование не только типовых, но и экономически эффективных проектов стало обязательным на ряде бюджетных строек.

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

Теперь в Минстрое признали, что динамика развития строительной отрасли и постоянное изменение технических регламентов и сводов правил зачастую не позволяют в неизменном виде повторно применять уже согласованные проекты. Ведомство внесло в Госдуму законопроект, который предлагает заменить их типовым проектированием. Типовая проектная документация будет предназначена для многократного применения при создании аналогичных (по назначению, проектной мощности, природным и иным условиям территории) объектов и также станет частью единого госреестра заключений экспертизы. А вот конкретики в законопроекте очень мало – большинство решений отдаётся исполнительной власти. Например, критерии «аналогичности» проектируемого объекта должен установить Минстрой, а требования к типовой проектной документации, срокам её применения, порядку признания документации типовой и пр. – Правительство РФ или Минстрой.

Если права на документацию принадлежат Федерации, субъектам РФ или муниципалам, другие органы власти могут её использовать бесплатно, а частным компаниям эти проекты будут продавать. Размер платы установит Правительство РФ. Если права на документацию остались в частной собственности, государство будет продавать интересантам сведения о лице, у которого исключительные права на проект.

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

В Минстрое говорят, что законопроект разработан для исполнения поручения президента РФ и нужен, чтобы обеспечить ускорение темпов строительства и повышение прозрачности при создании объектов за бюджетный счёт. В ведомстве планируют использовать для формирования типовых проектов «лучшие практики, которые предусматривают актуальные технические решения, наиболее выигрышные по функциональным, техническим и экономическим показателям, которые отвечают критериям экономической эффективности проектной документации». Хотя в пояснительной записке к законопроекту честно указано, что новшества  «не окажут социально-экономических, финансовых и иных последствий, в том числе для субъектов предпринимательской и иной экономической деятельности, предлагаемые решения не повлияют на достижение целей государственных программ РФ».

Тогда зачем заново городить весь этот огород?

Справка для разработчиков | REUSE

Неофициальные переводы доступны на:

• Česky
• Украинская

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

Содержание: Вспомогательный инструмент, примеры репозиториев, REUSE API, рабочие процессы CI/CD

Вспомогательный инструмент

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

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

Примеры репозиториев

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

• reuse-example — репозиторий, совместимый с REUSE, демонстрирующий несколько способов добавления информации об авторских правах и лицензировании. Включает несоответствующую ветку для тестирования. Этот проект является основой для нашего урока.
• reuse-tool — сам вспомогательный инструмент соответствует требованиям, как и все другие репозитории REUSE.

Попробуйте зарегистрировать свой проект в REUSE API, чтобы добавить значок динамического соответствия.

API

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

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

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

Как и все остальное в ПОВТОРНОМ ИСПОЛЬЗОВАНИИ, API общедоступен по лицензиям на свободное программное обеспечение.

Перехватчик перед фиксацией

Вы можете автоматически запускать повторно используйте lint при каждом коммите в качестве хука перед фиксацией для Git. Это использует предварительную фиксацию. После его установки добавьте его в репозиторий .pre-commit-config.yaml в своем репозитории:

:
- репозиторий: https://github.com/fsfe/reuse-tool
    версия: v1.0.0
    крючки:
    - идентификатор: повторное использование
 

Затем запустите pre-commit install . Теперь каждый раз, когда вы совершаете коммит, reuse lint запускается в фоновом режиме и предотвращает выполнение коммита в случае ошибки.

Включение в рабочие процессы CI/CD

REUSE можно легко интегрировать в существующие процессы CI/CD, чтобы постоянно тестировать репозиторий и его изменения на соответствие REUSE.

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

Дрон

Включите следующий фрагмент в файл .drone.yml :

 шагов:
- название: повторное использование
  изображение: fsfe/повторное использование: последнее
 

Больше информации о Drone на сайте drone.io.

GitHub

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

Дополнительные сведения о действиях GitHub см. на сайте help. github.com.

GitLab

Включите следующий фрагмент в файл .gitlab-ci.yml :

 повторное использование:
  изображение:
    имя: fsfe/повторное использование: последний
    входная точка: [""]
  сценарий:
    - повторное использование ворса
 

Дополнительная информация о CI GitLab на docs.gitlab.com.

Travis CI

Включите следующий фрагмент в файл .travis.yml :

 язык: минимальный
услуги:
  - докер
до_установки:
- docker pull fsfe/повторное использование: последний
- docker run -v ${TRAVIS_BUILD_DIR}:/data fsfe/reuse:последняя проверка
 

Больше информации о Travis CI на travis-ci.com.

Как легко повторно использовать компоненты в проектах и ​​репозиториях | Джонатан Саринг

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

Опубликовано в

·

Чтение: 7 мин.

·

17 сентября 2019 г.

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

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

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

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

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

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

Специализированные инструменты, такие как Bit (GitHub), позволяют разрабатывать, создавать и тестировать отдельные компоненты в библиотеке в полной изоляции. Используя Bit, каждый компонент в любом репозитории (и библиотеке) можно отслеживать как отдельную единицу и автоматически упаковывать его со всеми его зависимостями. Затем компоненты могут быть независимо связаны с компилятором (не требуется никаких конфигураций), чтобы их можно было собирать, тестировать и отображать изолированно. Затем несколько компонентов могут иметь версии и публиковаться из репозитория. Когда вы обновляете один компонент, Bit «знает», какие другие компоненты зависят от него, и помогает вам обновить все компоненты, на которые влияет обновление.

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

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

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

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

Настройка портала общих компонентов; Сделать красиво! Создайте свой концентратор компонентов в bit.dev

Чтобы собрать всех вместе на общих компонентах и ​​консолидировать обнаружение и потребление компонентов, вы можете создать свой собственный портал компонентов или просто использовать облачный портал, такой как bit.dev.

Ключевыми компонентами такого портала являются:

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

Если вы построите его самостоятельно, это может занять некоторое время, но это возможно. Если вы выберете bit.dev, вы получите все вышеперечисленное «из коробки», а также функции для управления разрешениями, управления рабочими процессами и т. д. Он будет размещать ваши компоненты, запускать их CI, позволит вам сохранять и играть с отрендеренными примерами кода, извлекать документацию по API для компонентов и устанавливать их с помощью npm/yarn.

bit.dev- найти, изучить, попробовать и установить компоненты

Включить обновление одиночных или массовых компонентов; не вся библиотека

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

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

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

Разрешить модификации и обновления компонентов из любого потребляющего репозитория; управление и контроль изменений в проектах

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

Эта «клонированная» версия компонента поставляется со всеми соответствующими файлами и зависимостями, связанным компилятором, версиями и управлением которой занимается Bit. В результате вы можете просто редактировать код и запускать сборку+тесты изолированно.

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

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

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

Система визуального дизайна с фактическими компонентами кода

С помощью bit. dev реальные компоненты кода (React, Vue, Angular) визуализируются и визуализируются, чтобы разработчики и дизайнеры могли точно узнать, как их компоненты выглядят, ведут себя и ощущаются пользователям. Они даже могут играть с компонентами в любой момент на редактируемой игровой площадке.

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

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

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

Рабочий процесс системы проектирования библиотеки компонентов

Используя Bit, вы можете создавать, упаковывать и публиковать компоненты изолированно в библиотеке. Затем вы можете экспортировать их в bit.dev, откуда они становятся системой визуального дизайна, состоящей из реальных компонентов исходного кода.

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

• Разработка модульных компонентов : Автоматически инкапсулируйте компоненты в репозиторий со всеми их зависимостями, свяжите компилятор с нулевыми конфигурациями сборки, и вы сможете легко начать сборку, тестирование и обновление компонентов в репозитории и только их зависимостей. Затем вы можете массово опубликовать свои компоненты, каждый в виде отдельного пакета.
• Упрощенное обнаружение и использование компонентов : Объедините свои компоненты в один портал, из которого они будут обнаружены и использованы. Легко обновляйте и контролируйте изменения в проектах.