Этапы и стадии проектирования зданий в строительстве

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

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

В зависимости от технической сложности и масштабов объекта проектирование осуществляется в одну или две стадии.

Одностадийное проектирование

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

Преимущество одностадийной схемы – сокращение срока проектирования в полтора-два раза и снижение стоимости разработки проекта на 40-50%. Однако такой подход не дает никакой гарантии, что готовые чертежи не потребуют доработки. Поэтому одностадийное проектирование практикуется в исключительных случаях — для простых, типовых или повторно строящихся объектов. Также из одной стадии состоит разработка проекта капитального ремонта.

Двухстадийное проектирование

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

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

Состав проектной документации

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

Состав разделов проектной документации утвержден Постановлением Правительства Российской Федерации № 87. В документе выделено 12 разделов:

1. Пояснительная записка – текстовый документ, в котором приводится описание и обоснование принятых проектных решений.
2. Генеральный план – планировочная схема организации выделенного под застройку земельного участка.
3. Архитектурные решения – пространственная и планировочная организация здания, его визуальные и функциональные характеристики.
4. Конструктивные и объемно-планировочные решения – проработка несущих конструкций здания.
5. Сведения об инженерно-технических сетях и оборудовании для систем водоснабжения, водоотведения, газоснабжения, связи, вентиляции и кондиционирования, электроснабжения, тепловых сетей. Также в этот раздел входят «Технологические решения», разрабатываемые с целью согласования архитектурных и конструктивных решений с особенностями технологических процессов, реализуемых в здании.
6. Проект организации строительства – требования к составу и последовательности выполнения работ на строительной площадке.
7. Проект организации работ по демонтажу или сносу зданий, последовательность выполнения демонтажных работ.
8. Мероприятия по охране окружающей среды, комплекс мероприятий по обеспечению пожаробезопасности.
9. Обеспечение доступа для людей с ограниченными возможностями.
10. Мероприятия по повышению энергоэффективности здания.
11. Прочая документация, состав которой определяется в индивидуальном порядке в соответствии с требованиями федерального законодательства.

Предпроектное предложение

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

• определяется схема размещения здания на земельном участке;
• проводятся технико-экономические расчеты для обоснования инвестиционной привлекательности объекта;
• разрабатывается общая концепция архитектуры здания;
• прорабатываются общие вопросы стилистики, конструкции, функциональности здания.

Стадия «Проект»

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

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

Стадия «Рабочая документация»

На стадии «Р» проектные решения прорабатываются более детально, на основании чего разрабатывается:

• комплекты чертежей по маркам;
• сметая документация;
• спецификации оборудования;
• ведомости потребности в материалах;
• ведомости объемов строительно-монтажных работ;
• прочие прилагаемые документы.

Рабочая документация используется строительно-монтажными бригадами для выполнения работ на объекте. Чертежи и спецификации необходимы специалистам по авторскому и техническому надзору. Общий состав рабочей документации определяется в зависимости от специфики объекта и уточняется в договоре на проектирование. Состав рабочих чертежей соответствует требованиям специальной системы стандартов СПДС (Система проектной документации для строительства), в частности:

• ГОСТ 21.101-93 «СПДС. Основные требования к рабочей документации»;
• ГОСТ 21.110 «СПДС. Правила выполнения спецификации оборудования, изделий и материалов».

Марки комплектов рабочих чертежей

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

ГП – генеральный план. Разбивочный чертеж, планы земляных масс, организации рельефа, размещения инженерных сетей, благоустройства территории.

АР – архитектурные решения. Поэтажные планировки, разрезы, чертежи фасадов.

КР – конструкции решения. Чертежи фундаментов, стен, перекрытий, лестниц, металлических конструкций.

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

ВК – водопровод и канализация. Планы, схемы, спецификации оборудования систем водоснабжения и водоотведения.

ЭОМ – электрооборудование и освещение. Планы, спецификации, схемы размещения осветительных приборов и электрооборудования.

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

Выполнение всех этапов проектирования в соответствии с государственными стандартными и нормами – это главное условие качественного проектирования. Именно этим принципом руководствуется компания «PNProject» в ходе разработки проектов зданий и сооружений различного назначения.

Состав документации ¦ УРБАНТЭК

Рассмотрим все стадии проекта по порядку:

Стадия 1 — ПП. Предпроектные проработки (концепция, эскизный проект)

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

Разработка Стадии «ПП» не является обязательной, но помогает сэкономить время и средства при дальнейшем проектировании.

Стадия 2 — ПД. Проектная документация

В отличие от Эскизного проекта Стадия «Проект» («ПД» или просто «П») является обязательной и подлежит согласованию в государственных органах исполнительной власти. По результатам согласования Стадии «Проект» выдаётся разрешение на строительство объекта. Состав и содержание данного этапа регулируется Постановлением Правительства РФ №87 от 16.02.2008г. Безусловно, состав будет индивидуален для каждого проекта, но мы попробуем составить наиболее полный перечень всех возможных разделов и подразделов Стадии «ПД»:

Номер	Шифр раздела	Название раздела
Раздел 1		Пояснительная записка
Том 1	ОПЗ	Пояснительная записка
Том 2	ИРД	Исходно-разрешительная документация
Раздел 2	ПЗУ	Схема планировочной организации земельного участка
Раздел 3	АР	Архитектурные решения
Раздел 4		Конструктивные и объемно-планировочные решения
Том 1	КР1	Железобетонные конструкции
Том 2	КР2	Металлические конструкции
Том 3	КР3	Деревянные конструкции
Том 4	КР.Р	Статический расчет
Раздел 5		Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений.
Подраздел 1		Система электроснабжения
Том 1	ИОС1.1	Наружное электроснабжение
Том 2	ИОС1.2	Силовое электрооборудование
Том 3	ИОС1.3	Электроосвещение
Подраздел 2		Система водоснабжения
Том 1	ИОС2.1	Наружное водоснабжение
Том 2	ИОС2.2	Внутреннее водоснабжение
Подраздел 3		Система водоотведения
Том 1	ИОС3.1	Наружное водоотведение
Том 2	ИОС3.2	Внутреннее водоотведение
Подраздел 4		Отопление, вентиляция и кондиционирование воздуха, тепловые сети
Том 1	ИОС4.1	Отопление и вентиляция
Том 2	ИОС4.2	Теплоснабжение
Том 3	ИОС4.3	Индивидуальный тепловой пункт
Подраздел 5		Сети связи
Том 1	ИОС5.1	Телефония, Радиофикация, Телеприем
Том 2	ИОС5.2	Структурированные кабельные сети
Том 3	ИОС5.3	Автоматизация инженерных систем
Том 4	ИОС5.4	Видеонаблюдение
Том 5	ИОС5.5	Охранная сигнализация
Том 6	ИОС5.6	Система контроля и учета доступа
Том 7	ИОС5.7	Прочие слаботочные системы
Подраздел 6		Система газоснабжения
Том 1	ИОС6.1	Наружное газоснабжение
Том 2	ИОС6.2	Внутреннее газоснабжение
Подраздел 7		Технологические решения
Том 1	ИОС7.1	Технологические решения
Том 2	ИОС7.2	Автоматизация технологических процессов
Том 3	ИОС7.3	Воздухоснабжение
Том 4	ИОС7.4	Холодоснабжение
Том 5	ИОС7.5	Снабжение паром
Том 6	ИОС7.6	Пылеудаление
Том 7	ИОС7.7	Прочие технологические системы
Раздел 6	ПОС	Проект организации строительства
Раздел 7	ПОД	Проект организации работ по сносу или демонтажу объектов капитального строительства
Раздел 8		Перечень мероприятий по охране окружающей среды
Том 1	ООС	Перечень мероприятий по охране окружающей среды
Том 2	ООС.ТР	Проект технологического регламента обращения со строительными отходами на объекте
Том 3	ИЭИ	Инженерно-экологические изыскания
Раздел 9		Мероприятия по обеспечению пожарной безопасности
Том 1	ПБ1	Мероприятия по обеспечению пожарной безопасности
Том 2	ПБ2	Автоматическая установка пожарной сигнализации, Система оповещения и управления эвакуацией людей при пожаре
Том 3	ПБ3	Автоматика противопожарной защиты
Том 4	ПБ4	Спецпожаротушение (водяное, порошковое и т. д.)
Раздел 10	ОДИ	Мероприятия по обеспечению доступа инвалидов
Раздел 10(1)	МЭ	Мероприятия по обеспечению соблюдения требований энергетической эффективности и требований оснащенности зданий, строений и сооружений приборами учета используемых энергетических ресурсов
Раздел 11		Смета на строительство объектов капитального строительства
Том 1	СМ1	Смета на строительство объектов капитального строительства
Том 2	СМ2	Мониторинг цен на материалы
Раздел 12		Иная документация в случаях, предусмотренных Федеральными законами
Том 1	КЕО	Светотехнические расчеты инсоляции и естественной освещенности (КЕО)
Том 2	ЗШ	Мероприятия по защите от шума и вибраций. Оценка шумового воздействия на период эксплуатации объекта
Том 3	ИТМ ГОиЧС	Инженерно-технические мероприятия гражданской обороны. Мероприятия по предупреждению чрезвычайных ситуаций
Том 4	ЭД	Инструкция по эксплуатации здания
Том 5	ПТА	Мероприятия по противодействию террористическим актам
Том 6	ДПБ	Декларация промышленной безопасности опасных производственных объектов

Стадия 3 — РД. Рабочая документация

Стадия «РД» нужна в первую очередь строителям, так как в ней наиболее полно и детально разрабатываются проектные решения, которые в Стадии  «ПД» лишь обозначались. В отличие от «П», «Рабочка» включает в себя чертежи узлов, аксонометрические схемы и профили инженерных сетей, спецификации и т. п. С другой стороны, на рабочей стадии документация лишается некоторых разделов, полнота которых была исчерпана на стадии проектной (например, ПОС, ООС, КЕО, ИТМ ГОиЧС и т. п.). Как и на Стадии «П», состав «РД» будет индивидуален для каждого проекта, но мы попробуем составить наиболее полный перечень всех возможных разделов Стадии «Рабочая документация»:

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

ГОСТ Р 21.1101-2013 Система проектной документации:

4.2. Рабочая документация
4.2.1. В состав рабочей документации, передаваемой заказчику, включают:
— рабочие чертежи, предназначенные для производства строительных и монтажных работ;
— прилагаемые документы, разработанные в дополнение к рабочим чертежам основного комплекта.
4.2.2. В состав основных комплектов рабочих чертежей включают общие данные по рабочим чертежам, чертежи и схемы, предусмотренные соответствующими стандартами Системы проектной документации для строительства (далее — СПДС).
…
4.2.6. К прилагаемым документам относят:
— рабочую документацию на строительные изделия;
— эскизные чертежи общих видов нетиповых изделий, выполняемые в соответствии с ГОСТ 21.114;
— спецификацию оборудования, изделий и материалов, выполняемую в соответствии с ГОСТ 21.110;
— опросные листы и габаритные чертежи, выполняемые в соответствии с данными заводов — изготовителей оборудования;
— локальную смету по формам;
— другие документы, предусмотренные соответствующими стандартами СПДС.
Конкретный состав прилагаемых документов и необходимость их выполнения устанавливаются соответствующими стандартами СПДС и заданием на проектирование.
…
4.2.8. В рабочих чертежах допускается применять типовые строительные конструкции, изделия и узлы путем ссылок на документы, содержащие рабочие чертежи этих конструкций и изделий. К ссылочным документам относят:
— чертежи типовых конструкций, изделий и узлов;
— стандарты, в состав которых включены чертежи, предназначенные для изготовления изделий.
Ссылочные документы в состав рабочей документации, передаваемой заказчику, не входят. Проектная организация, при необходимости, передает их заказчику по отдельному договору.

СНиП 11-01-95 Состав рабочей документации:

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

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

Разделы проектной документации, расшифровка и состав по постановлению 87

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

В чем принципиальное отличие проекта (стадия П) от рабочей документации (стадия РД) ведь и там, и там пояснительная записка, схемы, планы, спецификация?

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

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

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

В соответствии с Постановлением Правительства Российской Федерации от 16 февраля 2008 г. № 87 «О составе разделов проектной документации и требованиях к их содержанию» проектная документация на объекты капитального строительства производственного и непроизводственного назначения состоит из 13 разделов:

Раздел 1 «Пояснительная записка».

Раздел 2 «Схема планировочной организации земельного участка».

Раздел 3 «Архитектурные решения».

Раздел 4 «Конструктивные и объемно-планировочные решения».

Раздел 5 «Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений»:

а) подраздел «Система электроснабжения»;

б) подраздел «Система водоснабжения»;

в) подраздел «Система водоотведения»;

г) подраздел «Отопление, вентиляция и кондиционирование воздуха, тепловые сети»;

д) подраздел «Сети связи»;

е) подраздел «Система газоснабжения»;

ж) подраздел «Технологические решения»;

Раздел 6 «Проект организации строительства».

Раздел 7 «Проект организации работ по сносу или демонтажу объектов капитального строительства».

Раздел 8 «Перечень мероприятий по охране окружающей среды».

Раздел 9 «Мероприятия по обеспечению пожарной безопасности».

Раздел 10 «Мероприятия по обеспечению доступа инвалидов».

Раздел 11 «Мероприятия по обеспечению соблюдения требований энергетической эффективности и требований оснащенности зданий, строений и сооружений приборами учета используемых энергетических ресурсов».

Раздел 12 «Смета на строительство объектов капитального строительства».

Раздел 13 «Иная документация в случаях, предусмотренных федеральными законами».

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

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

(«ГОСТ Р 21.1101-2009. Система проектной документации для строительства. Основные требования к проектной и рабочей документации» (утв. Приказом Ростехрегулирования от 30.11.2009 N 525-ст))

4.5. Расчеты металлических конструкций, выполняемые на всех стадиях проектирования, заказчику не выдаются (если иное не предусмотрено договором).

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

(«ГОСТ 21.502-2007. Система проектной документации для строительства. Правила выполнения проектной и рабочей документации металлических конструкций» (введен в действие Приказом Ростехрегулирования от 25.03.2008 N 58-ст))

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

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

Объем ПД должен быть таким, чтобы сметная стоимость соответствовала действительности (по крайней мере для Государственных объектов, где смета обязательна), иначе можно наехать на проектную организацию, если строительная организация не влезет в непредвиденные 2%.

Кроме того: Минрегион России рекомендует при определении стоимости проектных работ принимать «распределение базовой цены проектирования… в зависимости от стадии проектирования… проектная документация — 40%,   рабочая документация — 60%»

Техническая документация по разработке программного обеспечения: типы и инструменты

Время чтения: 18 минут

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

Проектная документация по этапам и назначению

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

Гибкий и водопадный подход

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

Водопад — это линейный метод с отдельными целями для каждой фазы разработки. Команды, использующие водопад, тратят разумное количество времени на планирование продукта на ранних этапах проекта.Они создают обширный обзор основных целей и задач и планируют, как будет выглядеть рабочий процесс. Команды Waterfall стремятся создать подробную документацию до начала любого из этапов проектирования. Тщательное планирование хорошо работает для проектов с небольшими изменениями или без них, поскольку оно позволяет точно составлять бюджет и оценивать время. Однако планирование водопада оказалось неэффективным для долгосрочного развития, так как оно не учитывает возможные изменения и непредвиденные обстоятельства на ходу.По данным 9-го глобального опроса PMI по управлению проектами, Agile-подход используется 71% организаций в своих проектах.

Схема цикла Agile-разработки

Гибкий подход основан на совместной работе, тесном сотрудничестве с клиентами и заинтересованными сторонами, гибкости и способности быстро реагировать на изменения. Основные строительные блоки гибкой разработки — это итерации; каждый из них включает планирование, анализ, проектирование, разработку и тестирование.Вначале гибкий метод не требует исчерпывающей документации. Менеджерам не нужно много планировать заранее, потому что все может меняться по мере развития проекта. Это позволяет осуществлять планирование точно в срок. Согласно одной из ценностей Agile Manifesto, поставив «работающее программное обеспечение над исчерпывающей документацией», идея состоит в том, чтобы создавать документацию с информацией, которая необходима для продвижения вперед, когда это имеет наибольший смысл.

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

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

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

Соответствует следующей классификации.

Документация по программному обеспечению, наиболее часто используемая в Agile проектах

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

• Документация по продукту
• Технологическая документация

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

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

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

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

Продукт: Системная документация

Документация по системе

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

Документ о требованиях к продукции

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

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

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

Вот основные рекомендации, которые следует включить в документ с требованиями к продукту:

1. Роли и обязанности .Начните свой документ с информации об участниках проекта, включая владельца продукта, членов команды и заинтересованных лиц. Эти детали прояснят обязанности и сообщат цели целевого выпуска для каждого из членов команды.
2. Цели команды и бизнес-задача . Кратко опишите самые важные цели.
3. Предпосылки и стратегическое соответствие . Кратко объясните стратегическую цель ваших действий. Почему вы создаете продукт? Как ваши действия влияют на разработку продукта и соответствуют целям компании?
4. Предположения. Создайте список технических или бизнес-предположений, которые могла бы иметь группа.
5. Пользовательские истории. Перечислить или связать пользовательские истории, необходимые для проекта. Пользовательская история — это документ, написанный с точки зрения человека, использующего ваш программный продукт. История пользователя — это краткое описание действий клиентов и результатов, которых они хотят достичь.
6. Критерии приемки. Это условия, которые указывают на завершение пользовательской истории. Основная цель критериев приемлемости — определить удовлетворительный результат для сценария использования с точки зрения конечного пользователя.Прочтите нашу специальную статью о критериях приема, чтобы узнать больше.
7. Взаимодействие с пользователем и дизайн . Свяжите со страницей исследования дизайна и каркасы.
8. Вопросы. По мере того, как команда решает проблемы по ходу проекта, у них неизбежно возникает много вопросов. Хорошая практика — записывать все эти вопросы и отслеживать их.
9. Не работает. Составьте список того, что вы не делаете сейчас, но планируете сделать в ближайшее время. Такой список поможет вам организовать командную работу и расставить приоритеты.

Сделайте всю эту информацию более полной, используя следующие методы:

• Используйте ссылки и якоря . Они помогут вам упростить чтение и поиск документа, поскольку читатели смогут постепенно понимать информацию. Например, вы можете предоставить ссылки на интервью с клиентами и привязки к предыдущим обсуждениям или другую внешнюю информацию, связанную с проектом.
• Используйте инструменты построения диаграмм , чтобы лучше сообщить о проблемах вашей команде.Люди более склонны воспринимать информацию, глядя на изображения, чем читая обширный документ. Различные визуальные модели помогут вам выполнить эту задачу и более эффективно обозначить требования. Вы можете включить диаграммы в процесс создания требований, используя следующие программные инструменты построения диаграмм: Visio, Gliffy, Balsamiq, Axure или SmartArt в Microsoft Office.

Пользовательский интерфейс Проектная документация

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

Документацию UX можно разделить на этапы. Этап исследования включает:

• Персоны пользователей
• Пользовательский сценарий
• Карта сценария
• Карта истории пользователя
• Руководство по стилю UX

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

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

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

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

Пример карты пользовательской истории с разбивкой на выпуски

Источник: realtimeboard.com

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

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

• Карты сайта
• Каркасы
• Мокапы
• Прототипы
• Схемы потоков пользователя или путь пользователя
• Отчеты юзабилити-тестирования

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

Пример структуры карты сайта

Источник: uxforthemasses.com

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

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

Источник: medium.com

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

Пример каркаса для мобильного приложения Peekaboo

Источник: gallery.wacom.com

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

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

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

Документ архитектуры программного обеспечения

Проектная документация архитектуры программного обеспечения

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

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

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

Описание User Story. Свяжите истории пользователей со связанными бизнес-процессами и связанными сценариями. Вам следует избегать технических подробностей в этом разделе.

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

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

Схема архитектуры веб-приложения Azure

Источник: docs.microsoft.com

Исходный код документа

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

Документы с исходным кодом могут включать, но не ограничиваются следующими деталями:

• Фреймворк генерации HTML и другие применяемые фреймворки
• Тип привязки данных
• Шаблон проектирования с примерами (например, модель-представление-контроллер)
• Меры безопасности
• Прочие модели и принципы

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

Документация по обеспечению качества

В Agile есть разные типы тестовых документов. Мы выделили самые распространенные:

• План управления качеством
• Стратегия тестирования
• План испытаний
• Технические характеристики тестового корпуса
• Контрольные листы испытаний

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

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

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

• Список функций для тестирования
• Методы испытаний
• Таймфреймы
• Роли и обязанности (например, модульные тесты могут выполняться командой QA или инженерами)

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

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

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

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

Документация по API

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

Документация по API

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

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

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

• конечных пользователей
• системные администраторы

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

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

• Часто задаваемые вопросы
• Видеоуроки
• Встроенная поддержка
• Порталы поддержки

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

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

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

Технологическая документация

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

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

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

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

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

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

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

Дорожные карты Agile-продуктов

Дорожные карты продукта

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

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

• Стратегическая дорожная карта
• Дорожная карта технологий или ИТ
• План выпуска

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

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

Пример дорожной карты стратегического программного обеспечения

Источник: productplan.com

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

Пример технологической дорожной карты

Источник: hutwork.com

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

Пример плана выпуска

Источник: productplan.com

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

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

Инструмент общего назначения

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

• Atlassian Confluence — самый популярный инструмент для совместных проектов, в котором есть вся экосистема для управления требованиями к продукту и написания документации.Confluence известен стабильной вики-системой и эффективным интерфейсом управления пользовательскими историями.
• Document 360 — это база знаний самообслуживания / платформа документации по программному обеспечению, разработанная для продуктов «Программное обеспечение как услуга».
• ai — это инструмент для совместного создания, хранения документации, обмена данными и использования вики-системы. Документация интерактивна, что означает, что разработчики могут встраивать блоки или фрагменты кода прямо в документ и делиться им одним щелчком мыши. Закончив редактирование документации, вы можете сохранить ее в формате PDF или markdown и опубликовать на любой другой платформе.
• Github не нуждается в представлении, за исключением тех, кто хочет использовать его для документации по программному обеспечению. Он предоставляет вам собственную вики-систему и позволяет конвертировать вашу документацию в привлекательные витрины веб-сайта.

Редакторы Markdown

Поскольку документацию по программному обеспечению легче использовать в сети, ее необходимо создавать в надлежащем формате. Вот почему используются текстовые языки разметки. Самый популярный из них — Markup, который легко конвертируется в HTML, не требует специальных знаний для его использования.Разметка используется на GitHub и Reddit и практически везде для веб-документации. Итак, вот несколько редакторов Markdown, которые могут быть полезны для создания документов для вашего проекта:

Специальные инструменты для дорожной карты

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

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

Инструменты для документации UX

Самыми популярными инструментами для разработки пользовательского интерфейса являются инструменты для создания прототипов, которые помогают создавать эскизы, макеты, каркасы и интерактивные прототипы:

• Sketch — это простой, но мощный инструмент векторного дизайна с веб-приложением и настольным клиентом Mac. Sketch популярен и довольно прост, предлагая достаточно возможностей для проектирования интерфейсов.
• InVision — один из самых популярных инструментов для создания прототипов. InVision славится своими функциями совместной работы и кроссплатформенными возможностями, что делает его отличным инструментом для разработки будущих интерфейсов.
• UXPin — это инструмент для проектирования Mac и Windows, который позволяет создавать чертежи любого типа. Вы также можете загрузить свои эскизы или каркасы из других продуктов и сделать из них интерактивный прототип.
• Adobe XD — где XD означает опыт дизайна.Продукт ориентирован на UX-специалистов. Это позволяет дизайнерам создавать прототипы с высокой точностью и делиться ими через приложение.

Инструменты для документации API

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

• Swagger — это бесплатный программный сервис самодокументирования, предназначенный для создания и обновления веб-сервисов и API RESTful.
• RAML 2 HTML — это простой генератор документации, использующий спецификации RAML.

Образцы и шаблоны программной документации

Если ваша команда изо всех сил пытается найти качественный шаблон для некоторого типа документации по программному обеспечению, вот источники шаблонов документации:

• umkc.edu — список различных документов и планов по тестированию, архитектуре, требованиям.
• шаблонов Atlassian Confluence. Atlassian предоставляет готовые шаблоны проектной документации общего назначения со своим продуктом.
• strongqa.com — шаблоны документации для специалистов по контролю качества. К ним относятся контрольные списки тестирования, шаблоны дымового тестирования, планы тестирования и многое другое.
• ReadySET — это большая библиотека шаблонов документации по программному обеспечению в HTML, которая включает документы по планированию, архитектуре, дизайну, требованиям, тестированию и многому другому.
• ReadTheDocs — это универсальный шаблон, созданный на платформе ReadTheDocs, содержащий инструкции по написанию каждого типа документа, который может вам понадобиться, от архитектуры и диаграмм UML до руководств пользователя.

Как писать документацию по программному обеспечению: общие советы

Существует несколько общих практик, которые следует применять ко всем основным типам документации, которые мы обсуждали выше:

Напишите достаточно документации

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

Документирование — непрерывный процесс

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

Документация — совместная работа всех членов команды

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

Нанять технического писателя

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

Использовать перекрестные ссылки

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

Не игнорируйте глоссарии

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

Заключительное слово

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

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

.

Понимание подразделений ARE 5.0: планирование и дизайн проекта по сравнению с разработкой проекта и документацией | NCARB

В предыдущем посте в блоге мы провели подробное сравнение двух новых подразделений ARE 5.0: управления практикой и управления проектами. Теперь давайте посмотрим на Project Planning & Design и Project Development & Documentation — два подразделения, которые кажутся похожими друг на друга, и не только по названию. Это самые большие подразделения в ARE 5.0, каждый по 120 вопросов и пятичасовое время встречи. И тем кандидатам, которые используют рекомендованный нами подход к стратегическому тестированию, это единственные два подразделения ARE 5.0, которые вам нужно принять.

Так о чем они все? А в чем между ними разница?

Project Planning & Design занимается предварительным проектированием участков и зданий. Ожидайте увидеть контент о:

• Условия окружающей среды и контекст
• Нормы и правила
• Строительные системы, материалы и агрегаты
• Проект интеграции программы и систем
• Стоимость проекта и составление бюджета

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

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

• Интеграция строительных материалов и систем
• Строительная документация
• Руководство по проекту и спецификации
• Нормы и правила
• Смета строительства

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

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

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

Другой способ подумать о различиях между этими двумя делениями — это масштабы рисования.Планирование и дизайн проекта будут в масштабе 1/8 дюйма, 1/4 дюйма или даже 1/2 дюйма, в то время как разработка проекта и документация будут представлять собой подробные чертежи в меньшем масштабе 3/4 дюйма или 1 1/2 дюйма. Любые виды диаграмм или расписаний (дверная фурнитура, окна и т. Д.) Также будут в PDD. Помните об этих различиях во время учебы, чтобы лучше подготовиться к каждому разделу.

Просмотреть ветку обсуждения.

.

Почему важна проектная документация

Введение:

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

Документация по проекту:

Что такое документация?

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

Оксфордский словарь говорит: « Документация — это материал, который предоставляет официальную информацию или доказательства или служит в качестве записи, процесс классификации и аннотирования текста »

Merriam Webster определяет: «Документация — это акт или пример предоставления или подтверждения документов »

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

Следовательно, документация — это набор из

Назначение документации

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

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

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

Получается

• проектных ожиданий и целей без изменений;

• Отслеживание

  задач проекта; и

• помогает решать любые проблемы проекта, среди прочего.

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

Проектная документация помогает отслеживать прогресс и производительность проекта и принимать решения.

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

Значение документации в управлении проектами:

Источник изображения: https://pxhere.com/en/photo/764428

Почему документация имеет первостепенное значение в управлении проектами?

Неопытным руководителям проектов часто сложно понять, почему важна документация? Документация добавляет беспокойства начинающему менеджеру проекта.Поскольку она должна выполнять несколько проектов в рамках ограничений. Но позвольте мне убедить вас не пропускать часть документации любой ценой, чтобы компенсировать ваши временные трудности. Хороший тайм-менеджмент — очень необходимый навык для руководителя проекта. Аналогичным образом, документация также не менее важна, если вы хотите отточить навыки управления проектами. Хороший набор документов по управлению проектом обязательно окупится. Если вы хорошо управляете проектной документацией, вы увидите успешную карьеру в качестве специалиста по управлению проектами.

Рассмотрим следующие случаи, чтобы лучше понять важность проектной документации:

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

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

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

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

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

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

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

8. Большинству руководителей проектов сложно оценить ресурсы, необходимые для проекта. Даже некоторые из сбоев проекта наблюдаются из-за плохого управления ресурсами. План управления ресурсами помогает определить ресурсы, необходимые для проекта. Он направляет процесс приобретения ресурсов и определяет роли / обязанности человеческих ресурсов.Он также закладывает основу для обеспечения достаточности ресурсов. Еще один важный аспект — оценка и контроль выполнения работ. Отчеты помогают понять потребности в ресурсах на протяжении всего проекта.

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

10. Менеджер проекта не может игнорировать важность управления заинтересованными сторонами. Успех проекта зависит как от всех заинтересованных сторон, так и от руководителя проекта. Заинтересованные стороны имеют разные уровни интереса и влияния в проекте. Им нужно хорошо управлять, чтобы вытащить из них максимальную поддержку. Следовательно, план управления заинтересованными сторонами должен быть подготовлен для обеспечения того же.

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

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

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

Области действия проектной документации

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

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

Преимущества проектной документации

Ниже приводится перечень преимуществ проектной документации:

#	Преимущества
1	Позволяет ставить цели проекта
2	Помогает в планировании проекта
3	Позволяет лучше контролировать статус проекта
4	Облегчает хорошее общение
5	Введение управления
6	Подготавливает вас к любым скрытым рискам
7	Помогает улучшить планирование и распределение ресурсов
8	Обеспечивает отслеживаемость проекта
9	Сохраняет фокусировку
10	Помогает получать поддержку от спонсоров
11	Помогает легко вносить изменения

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

Как это помогает менеджеру проекта?

Поскольку мы теперь поняли важность документации, она действительно помогает руководителю проекта во время проектов.Хорошая документация повысит ваш авторитет среди профессионалов по управлению проектами. Если вы хотите стать многообещающим менеджером проекта, переходите к документации. Документация по проекту поможет вам с легкостью справиться с предстоящими ситуациями. Он устанавливает платформу для всестороннего общения и понимания. В новой редакции руководства PMBOK, PMBOK 6th, подчеркивается важность документации. Особенно это способствует сохранению знаний о проекте посредством надлежащей документации.Прежде чем настраивать действия для вашего текущего проекта, вы можете обратиться к репозиторию ресурсов организационного процесса и управления знаниями. Подумайте, если вы не ведете надлежащую документацию во время своих проектов, поможет ли это другим в том, что вы сделали? Можете ли вы повысить ценность своего хранилища организационных знаний? Даже если вы получите аналогичную концепцию проекта, вы не сможете ссылаться на свои предыдущие работы. Документация помогает менеджеру проекта принимать обоснованные и обоснованные решения. Таким образом, он действительно открывает путь к успеху вашего проекта.

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

Заключение

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

Повысьте уровень успешности ваших проектов — пройдите сертификацию прямо сейчас!

.

Разработка проекта и документация | NCARB

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

Подробная информация о разработке проекта и документации
Шт.	Продолжительность теста	Время приема
120	4 часа 15 минут	5 часов

Подготовка к разработке проекта и документации? Вы можете найти более подробную информацию, примеры вопросов и рекомендуемые ссылки в нашем ARE 5.0 Справочник и видео подготовительной серии.

PDD включает разделы по следующим областям содержания:

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

.