Рабочая документация архитектурных решений – «МАПРО»

Суть рабочего раздели проектных бумаг

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

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

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

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

Основные понятия РД

Предъявляемые условия к документации регламентируются ГОСТ Р 21.1101-2013 «Системой основных требований к РД». Согласно стандарту, утвержденному действующим законодательством:

1. Под «основным комплектом» понимается собрание рабочих чертежей (РЧ) в единый комплект. Добавлением выступают ссылочные документы, поправки.
2. Главный комплект РЧ состоит из документальных файлов в графическом представлении со сведениями, достаточными для начала строительных работ. Комплектация представлена разновидными чертежными эскизами, схематическими изображениями для строительства, монтажа. Подобные виды деятельности принято шифровать под «марку» – аббревиатурное представление с использованием первых букв словосочетания, кода обозначения определенных строительных, установочных операций.

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

Как правильно оформлять РД

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

Основные требования, предъявляемые к РЧ:

1. Чертеж должен содержать полноценную информацию о намеченном строительстве, монтаже.
2. Не допускаются повторения, избыточная детализация.
3. Не указывается излишняя для строительных работ информация.
4. Объем данных минимальный, достаточный для полноты проектируемой картины.
5. Каждый отдельный документ пронумеровывается.
6. Используемые ссылки должны опираться на целый нормативный акт, раздел. Ссылки на пункты неприемлемы.
7. Оформление чертежных изображений строго по регламентированным стандартам.
8. Условные обозначения устанавливаются с учетом действующих законодательных норм.
9. Графические объекты изображаются черным цветом.
10. Шрифт для написания текста: Arial, Times New Roman.
11. Масштаб РЧ регламентируется ГОСТ-2.302. На графическом полотне не указывается, исключая случаи, предусмотренные нормативными актами СПДС.

Составлением пакета РД занимается разработчик по согласованию с заказным лицом.

Текстовые части рабочей документации оформляются по установленным правилам:

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

Текст со сплошным набором слов, состоящий из разделов, подразделов, оформляется по единой структуре:

1. Первый лист предназначен для перечисления исполнителей с указанием должностей, ФИО, инициалов создателей проектаархитектуры. Важно учесть разработчиков, контролирующих особ, лиц, отвечающих за согласование плана конструкции. Предусматривается место для указания даты, подписи.
2. На втором листе оформляется оглавление с номерами, названиями структурных частей, приложений.
3. При одностороннем оформлении обозначение документа располагается в верхнем левом углу, при двусторонней печати: четные страницы – справа, нечетные – вверху слева.
4. Слева или справа листа — в зависимости от вида печати —  размещается наименование, логотип организации, разрабатывающей проектные эскизы.

Текст в РД оформляется с учетом ряда требований для простоты понимания заинтересованных особ:

1. В содержании неприемлемы толкования. Научно-технические термины описываются в основной части.
2. Запрещено использовать синонимы, иностранные близкие по смыслу слова.
3. Одно и то же понятие не может обозначаться разными терминами.
4. Нельзя использовать сокращенные формы слов, кроме установленных правилами орфографии, двоякие символы.

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

Составные части РД

В состав рабочей документации архитектурных решений обязательно входят:

1. Рабочие чертежи. Комплектация происходит по видам строительных, монтажных работ.
2. Оригиналы, дополняющие главный комплект РЧ.

ОКРЧ состоит из:

• общих данных;
• чертежных, схематических представлений, таблиц.

Прилагаемые документы подразумевают собрание:

1. Повторно используемых РД (чертежей, схем, таблиц).
2. РД на электромонтажные системы, требующие изготовления в специализированных мастерских.
3. Общих видов чертежных эскизов.
4. Локальной сметы.
5. Стройматериальной ведомости.
6. Спецификации оборудования.
7. Опросных листов на электрическое оборудование (если требует порядок разработки РД).
8. Дополнительных бумаг, прописанных в договоре.

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

Архитектурные решения интерьера (АИ)

Архитектурные решения интерьера (АИ)

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

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

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

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

План монтажа перегородок. На данном чертеже показаны возводимые стены и перегородки, со всеми размерами, высотами и материалами стен. Это основной чертеж в проекте.

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

План отопления. Здесь показаны трассы отопления и расположение радиаторов.

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

Схема укладки ЭППС. Показано расположение слоёв утеплителя и количественные характеристики (если необходимо дополнительная звукоизоляция или утепление пола под стяжку).

Устройство стяжки. Здесь видим какая стяжка и в каком объеме необходима для квартиры, также привязки профилей для маячков (при условии отсутствия стяжки от застройщика).

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

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

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

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

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

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

План потолка с привязками светильников. План освещения со всеми осветительными приборами и привязками.

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

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

Это основные чертежи. Также альбом дополнен листами со схемами, узлами, развертками (помещений, мебели) и ведомостями.

Мы располагаем листы в проекте в согласовании с планом работ.

Перечень всех чертежей в проекте:
0. Титульный лист
1. Общие данные
2. Обмерочный план
3. Подготовка к ремонту
4. Итоговые обмеры
5. План демонтажа
6. План монтажа перегородок
7. План отопления
8. Схема прокладки трасс кондиционирования
9. Схема подключения кондиционеров
10. Монтаж вентиляции
11. План потолка с привязками светильников
12. Управление освещением
13. Привязка электрооборудования
14. Итоговые обмеры инженерных сетей
15. Схема заделки штроб
16. Схема укладки ЭППС
17. Устройство стяжки
18. План каркасного потолка
19. Схема монтажа остекления
20. Схема монтажа входной двери
21. Схема утепления балкона. Отделка балкона.
22. План привязки подоконников к окну. Схема оштукатуривания оконных откосов
23. Монтаж гидроизоляции
24. План монтажа ГКЛ конструкций
25. Схема обшивки потолка
26. Схема подключения радиаторов
27. Малярный план
28. План раскладки теплого пола
29. План наливного пола. Схема укладки
30. Развертка СУ, укладка плитки
31. Развертка ванной, укладка плитки
32. Схема укладки фартука. Развертки
33. План напольного покрытия
34. План отделки стен
35. Функциональное зонирование
36. План монтажа дверей. Схема монтажа дверной коробки
37. Схема монтажа доборных элементов
38. Нумерация видов
39 — 52. Развертки стен

Нужны качественные чертежи?

Максимально полная рабочая документация для качественного ремонта

Статьи из блога

Щит ЭОМ в сборе

Разберем из чего состоит распределительный щит

Водоснабжение и канализация (ВК)

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

Коллекторный узел в сборе

Из каких деталей компонуется коллекторный узел водоснабжения

Преимущество 3D тура

Наглядное сравнение 3D тура и статического изображения

История DIY брендов

DIY расшифровывается как Do It Yourself, что означает “сделай сам”. Это не просто лозунг, а девиз и возникшая в Штатах субкультура, объединяющая музыку.

Ошибки в визуализации

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

ДНК скандинавского стиля

Характерные особенности стиля

Согласование перепланировки: что нужно знать

Какие популярные проблемы и подводные камни перепланировки

История визуализации

От отмывки от руки в древние времена до современных технологий

Подход к построению архитектуры решения Документ

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

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

Что такое архитектура решения?

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

Сейчас, в наше время, это практика, которую Solutions Architect готовит с помощью консультантов, менеджеров проектов и разработчиков. Архитектор решения определяет взаимосвязь процесса внутри и с окружающей средой, рассматривая принципы проектирования и помня о масштабах эволюции. Он предназначен для поддержки, автоматизации и адаптации к бизнес-идеям и целям.

Подход к архитектуре решения

Введение

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

Убедитесь, что вы четко указываете объем документа там, где он должен убедить клиента в том, что документ включает все требования решения.

Цели архитектуры

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

См. также: Вниманию разработчиков чат-ботов! 5 вещей, которые нужно знать о разработке чат-ботов

Требования к качеству обслуживания

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

Case View

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

Логическое представление

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

Представление процесса

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

 Представление развертывания

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

Представление реализации

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

Итерация важна

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

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

Документирование архитектуры решения: введение , Спонсор проекта, Команды разработки и контроля качества и другие.

Потребности в таком общении следующие:

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

Отсутствие любой этой информации может легко привести к задержке проекта, перегрузке или отмене.

Фото ThisisEngineering RAEng / Unsplash

Начнем с примера

Каждая программная система достаточно сложна. Первая попытка задокументировать это — попытаться нарисовать какую-то диаграмму, включающую все, что очень быстро терпит неудачу. Представьте, что мы хотим задокументировать что-то относительно простое, скажем, этот конкретный блог, о котором вы читаете статью. Он работает на CMS Ghost, хранящей данные в базе данных MySQL; Apache используется для веб-сервера. Запросы обрабатываются веб-сервером, перенаправляя все запросы с http на https и направляя запросы в CMS. CMS проверяет токены и запрашивает у базы данных контент, включая страницы, сообщения в блогах и плагины. Все три компонента работают на виртуальной машине в GCP в сети по умолчанию в отдельной организации. Доступ к системе имеют читатели и контент-менеджеры, последние могут добавлять новый контент и редактировать текущий. Система также может быть изменена системными администраторами через облачную консоль. Я постараюсь включить всю эту информацию в одну диаграмму:

‌

Можно сказать, что это неплохая диаграмма, однако у нее есть следующие проблемы:

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

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

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

Существует несколько подходов к этому (модули-компоненты и соединители-распределение, подход C4 и т. д.), неважно, что вы выберете. Главное, чтобы вы хотели, чтобы 1 человек одновременно мог получить максимум информации за минимальное время.

Разделите опасения

Для нашей системы у нас есть следующие заинтересованные лица (стейкхолдеры):

1. Спонсор проекта
2. Автор блога
3. Системный администратор
4. Контент-менеджер
5. Читатель

Их соответствующие опасения следующие:

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

С кем взаимодействует система?

Контекстная диаграмма

Эта диаграмма называется Контекстная диаграмма (по нотации C4), которая показывает именно это: с какими агентами взаимодействует система. Смотрите, здесь есть блок «Аналитика». Я буквально забыл об этом, когда рисовал первый, но взгляд на определенном уровне позволяет сосредоточиться на определенных аспектах и ​​ничего не упустить.

Как и где развертывается система?

Диаграмма развертывания

На этой диаграмме показано, что решение развернуто на Google Cloud Platform, на одной виртуальной машине в одной сети в одном регионе, доступ защищен Cloud IAM. По сути, он отвечает, сколько денег примерно стоит решение (20-30 долларов в месяц в зависимости от региона и размера ВМ), и что оно плохо масштабируется и потребует редизайна в случае резкого увеличения нагрузки.