Изготовление проектной документации: Виды рабочей строительно-проектной документации: ППР, ППРк, ПОр, ПОС

ГОСТ 2.120-2013 Единая система конструкторской документации (ЕСКД). Технический проект (с Поправкой)

ГОСТ 2.120-2013

МКС 01.110
ОКСТУ 0002

Дата введения 2015-07-01

Предисловие

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены в ГОСТ 1.0-2015 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2015 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1 РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ), Автономной некоммерческой организацией Научно-исследовательский центр CALS-технологий «Прикладная логистика» (АНО НИЦ CALS-технологий «Прикладная логистика»)

2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 14 ноября 2013 г. N 44, приложение N 24 доп.)

За принятие проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004-97	Код страны по МК (ИСО 3166) 004-97	Сокращенное наименование национального органа по стандартизации
Азербайджан	AZ	Азстандарт
Армения	AM	Минэкономики Республики Армения
Беларусь	BY	Госстандарт Республики Беларусь
Казахстан	KZ	Госстандарт Республики Казахстан
Киргизия	KG	Кыргызстандарт
Молдова

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

Компания ИРБИС предлагает услуги по разработке проектно-сметной документации и выпуска рабочей документации на строительство, капитальный ремонт и реконструкцию:

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

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

Когда необходима проектно-сметная документация

В соответствии со ст. 48 ГрК РФ изготовление проектно-сметной документации необходимо для возведения, реконструкции, капитального ремонта объектов капитального строительства. Исключение составляет ИЖС в случае, если сметная стоимость не подлежит проверке предмет достоверности. Подготовка ПСД для объектов этой категории выполняется по инициативе застройщика. Согласованная и утвержденная проектная документация передается организации, заключившей с заказчиком договор генерального строительного подряда. В соответствии со ст. 52 ГрК РФ отступление от проектных решений недопустимо. Любые отклонения параметров объекта возможны только после внесения изменений и нового утверждения.

Качественно разработанная проектная документация закладывает крепкий фундамент для успешной реализации проекта.

Артем Азаров

Директора Департамента Проектирования

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

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

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

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

Подготовка выполняется в соответствии со ст. 48 ГрК РФ. Порядок работ устанавливают методические рекомендации НОПРИЗ 3.1. Состав  и содержание разделов регламентирует постановление Правительства РФ №87.

Предпроектная стадия

Предпроектная стадия включает в себя:

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

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

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

Разделы проектной документации:

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

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

Выпуск рабочей документации

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

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

Заказать проектно-сметную документацию

Стоимость разработки проектно-сметной документации составляет от 2-5% до 10-15% от сметной стоимости строительства в зависимости от масштабов и функционального назначения объекта. Расходы на строительно-монтажные работы могут доходить до 90%.

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

Мы работаем в Санкт-Петербурге, Москве, Екатеринбурге и других регионах России.

Зарубежный опыт

Компания «ИРБИС» оказывает услуги по всему миру. Реализованы проекты в странах:

Опыт в РФ

Компания «ИРБИС» работает по всей территории России. Реализованы проекты в городах:

Владивосток

Волгоград

Воронеж

Екатеринбург

Казань

Калининград

Краснодар

Красноярск

Москва

Мурманск

Нижний Новгород

Новороссийск

Новосибирск

Омск

Пермь

Ростов-на-Дону

Самара

Санкт-Петербург

Саратов

Севастополь

Симферополь

Сочи

Сургут

Тюмень

Согласование рабочей документации | АБ МСР

Автор Кадастровый инженер На чтение 14 мин. Просмотров 1.6k. Опубликовано 22 сентября, 2020

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

---

Калькулятор стоимости и сроков наших услуг — здесь

---

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

Что такое рабочая документация и кто ее оформляет

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

Состав проектной и рабочей документации на строительство представлен на схеме.

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

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

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

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

Соловьев Петр

Эксперт в сфере сертификации, кадастра, недвижимости и проектирования. Высшее юридическое образование, опыт работы более 10 лет.

Задать вопрос

Здравствуйте! Может ли подрядчик сам менять положения рабочей документации, если это не повлияет на реализацию проекта?

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

Можно ли заказать рабочую документацию отдельно от проекта?

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

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

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

Нужно ли отдельно подтверждать соответствие рабочей документации после завершения строительства?

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

Кто может заниматься разработкой проектной и рабочей документации

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

---

Калькулятор стоимости и сроков наших услуг — здесь

---

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

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

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

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

№ п/п	Обязательные процедуры при проектировании и согласованиях строительства	Описание
1	Изыскания	Проводятся в отношении участка, существующих объектов и коммуникаций перед проектированием строительства, реконструкции
2	Экспертиза	Проводится за проектов строительства и реконструкции, если это предусмотрено Градостроительным кодексом РФ.
3	Получение разрешения на строительство	Проходит через Госстройнадзор для проектов строительства и реконструкции.
4	Ввод в эксплуатацию	Осуществляется через Госстройнадзор для нового или реконструируемого здания
5	Кадастровый учет	Проводится в Росреестре для вновь построенного или реконструируемого здания на основании технического плана.

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

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

• Градостроительный кодекс РФ (скачать) – описывает требования к согласованиям, документам заказчика;
• Постановление № 87 (скачать) – содержит описание по всем разделам проектной и рабочей документации;
• ГОСТ Р 21.1101-2013 (скачать) – содержит порядок заполнения документов, чертежей.

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

Для строительства МКД

0%

Для строительства нежилого здания

11.11%

Для строительства ОПО

11.11%

Для реконструкции или капитального ремонта здания

77.78%

Что представляет собой проектно-сметная документация :: BusinessMan.ru

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

Что называют проектно-сметной документацией?

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

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

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

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

Подготовительные работы к составлению проектно-сметной документации

От правильности, чёткости и согласованности проекта зависит то, какого качества будет итог проделанной работы. Будут ли соблюдены сроки его выполнения, реально ли войти в пределы отпущенного финансирования.

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

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

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

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

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

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

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

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

В состав проектно-сметной документации также входит набор необходимых смет.

Разрешение на строительство

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

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

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

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

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

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

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

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

Проведение экспертизы проектно-сметной документации

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

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

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

Главная / Инжиниринг / Детальный инжиниринг /Версия для печати

Конструкторская документация (КД) — документация, разрабатываемая на конкретное изделие/оборудование перед началом его производства и эксплуатации на объекте. Поэтому она является основополагающей для заводов-производителей, так как именно по ней изготавливается то или иное оборудование, которое было подобрано для конкретного объекта на стадии базового инжиниринга.

Инженерно-конструкторский отдел Саратовского резервуарного завода разрабатывает конструкторскую документацию в соответствии с ГОСТ 2.103-2013 «Единая система конструкторской документации (ЕСКД). Стадии разработки»*. Выполнение конструкторской документации КД на заказ осуществляется как в составе комплексных работ по проектированию и строительству объектов нефтегазовой отрасли, так и отдельно при заказе оборудования производства САРРЗ.

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

Стадии и этапы разработки конструкторской документации

ГОСТ 2.103-2013 регламентирует разработку основных видов конструкторской документации: проектной и рабочей.

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

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

Каждый проект (техническое предложение, эскизный и технический проект) принимается и утверждается конструкторским отделом и заводом-производителем.

Этапами создания рабочей конструкторской документации является разработка КД:

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

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

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

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

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

Пример выполненного сборочного чертежа горизонтального отстойника нефти ОГЖФ

Правила оформления конструкторской документации регламентируются следующими нормативными стандартами:

• ГОСТ 2.001-2013 «Единая система конструкторской документации (ЕСКД). Общие положения»;
• ГОСТ 2.102-2013 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»;
• ГОСТ Р 2. 002-2019 «Единая система конструкторской документации. Требования к моделям, макетам и темплетам, применяемым при проектировании»;
• ГОСТ 2.052-2015 «Единая система конструкторской документации. Электронная модель изделия. Общие положения»;
• ГОСТ 2.118-2013 «Единая система конструкторской документации. Техническое предложение»;
• ГОСТ 2.119-2013 «Единая система конструкторской документации. Эскизный проект»;
• ГОСТ 2.120-2013 «Единая система конструкторской документации. Технический проект»;
• ГОСТ Р 2.601-2019 «Единая система конструкторской документации (ЕСКД). Эксплуатационные документы»;
• ГОСТ 2.602-2013 «Единая система конструкторской документации. Ремонтные документы»;
• ГОСТ 2.109-73 «Единая система конструкторской документации (ЕСКД). Основные требования к чертежам»;
• ГОСТ 2.701-2008 «Единая система конструкторской документации (ЕСКД). Схемы. Виды и типы. Общие требования к выполнению»;
• ГОСТ 2.410-68 (СТ СЭВ 209-75, СТ СЭВ 366-76) «Единая система конструкторской документации (ЕСКД). Правила выполнения чертежей металлических конструкций (с Изменением №1)» и др.*;

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

Как заказать разработку конструкторской документации?

Чтобы узнать цену разработки конструкторской документации, Вы можете:

• прислать техническое задание на электронную почту
• воспользоваться формой «Заказать услугу», указать контактную информацию для связи с Вами
• позвонить по телефону 8-800-555-9480

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

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

Время чтения: 22 минуты

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

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

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

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

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

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

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

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

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

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

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

В соответствии со следующими классификациями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документация для конечного пользователя

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

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

Краткое руководство по началу работы с OneNote, источник: slideshare

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

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

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

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

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

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

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

Документация системного администратора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Atlassian Confluence — самый популярный инструмент для совместной работы над проектами, в котором есть вся экосистема для управления требованиями к продукту и написания документации. Confluence известен стабильной вики-системой и эффективным интерфейсом управления пользовательскими историями.
• Document 360 — это база знаний самообслуживания / платформа документации по программному обеспечению, разработанная для продуктов «Программное обеспечение как услуга».
• bit.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.

Инструменты для технических писателей

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

• MadCapFlare — мощное облачное программное обеспечение с функцией многоканальной публикации, многоязычной поддержкой, обширными обучающими ресурсами и многим другим.
• Adobe RoboHelp — полнофункциональная CMS, которая позволяет создавать мультимедийный контент, удобное управление микроконтентом, совместную работу для контроля версий и т. Д.
• ClickHelp — отмеченная наградами платформа, предлагающая простой переход с других программ, гибкие варианты разрешений и ряд возможностей отчетности.

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

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

Шаблоны общей проектной документации

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

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

Шаблоны дорожных карт продуктов

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

Шаблоны документации по обеспечению качества

Если вы все еще ищете шаблоны, связанные с контролем качества, вы можете проверить здесь:

• StrongQA.com имеет различные шаблоны документации для QA-специалистов. К ним относятся контрольные списки тестирования, шаблоны дымового тестирования, планы тестирования и многое другое.
• Template.net имеет раздел с шаблонами планов обеспечения качества.
• EasyQA предлагает SDK для тестирования программного обеспечения и шаблоны с подробным руководством по созданию качественного плана тестирования.
• Тестирование программного обеспечения — это большая платформа, включающая блог, форум и всевозможные информационные материалы для специалистов по тестированию.

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

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

Примеры специализированных архитектур: AWS, Microsoft Azure и Google Cloud

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

• Amazon — Центр архитектуры AWS предоставляет рекомендации по архитектуре AWS, инфраструктуры, инструменты и передовые методы выполнения архитектурных рабочих нагрузок в облаке.
• Microsoft — этот ресурс предлагает множество полезных материалов по архитектуре Azure, включая примеры сценариев, архитектурные схемы и многое другое.
• Google — посетите официальную библиотеку иконок с образцами для построения архитектурных схем Google Cloud.

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

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

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

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

Учитывайте свою аудиторию

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

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

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

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

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

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

Поддерживайте актуальность документации по программному обеспечению

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

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

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

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

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

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

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

Дополнительные советы по созданию и поддержке документации

Вот еще несколько предложений, которые помогут вам оптимизировать и ускорить процесс написания документов и дальнейшего управления:

• считают наиболее эффективным средством передачи информации. Например, создание аудио- или видеозаписей может быть отличным вариантом для сбора требований, руководств пользователя и т. Д .;
• вставлять ссылки на соответствующие онлайн-статьи или информационные страницы вместо того, чтобы воспроизводить их в своей документации;
• генерирует диаграммы из кода или баз данных, когда это возможно, а не создает их с нуля;
• используйте скриншоты и другие изображения — это поможет вам быстро найти то, что нужно обновить, и вам не придется читать весь текст;
• рассмотрите возможность хранения вашей технической документации вместе с исходным кодом, просто храните их отдельно.Это поможет поддерживать его в актуальном состоянии и позволит всем узнать, где его найти;
• настроить доступ, чтобы избежать лишних изменений. Предоставьте разрешения на редактирование потенциальным авторам, в то время как те, у кого есть доступ только для просмотра, все еще могут видеть информацию, но не могут ее изменять;
• убедитесь, что авторы могут иметь быстрый и легкий доступ к документации для просмотра и обновления. Устранение таких препятствий, как ненужные процедуры авторизации и / или утверждения;
• сохранять предыдущие версии и архивировать электронные письма по проекту, так как вам может потребоваться вернуться к ним в будущем;
• не забудьте сделать резервную копию;
• используйте теги для облегчения поиска;
• , если документация — это способ поделиться знаниями, подумайте о других способах общения или выясните, почему члены команды просто не говорят об этом.Это может быть полезно для совместной работы и сокращает объем необходимой документации.

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

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

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

УПРАВЛЕНИЕ ИНЖЕНЕРНЫМИ ДАННЫМИ ПРИ АВТОМАТИЧЕСКОЙ ПОДГОТОВКЕ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ

Статья на Русский

Для цитирования: Гурьянов А.В., Шукалов А.В., Жаринов И.О., Леоновец С.А., Диденко Э.Ю. Управление инженерными данными проекта при автоматизированном оформлении конструкторской документации. Научно-технический журнал информационных технологий, механики и оптики , 2017, т. 17, нет. 1. С. 182–186. DOI: 10.17586 / 2226-1494-2017-17-1-182-186

Аннотация

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

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

Список литературы

1. Авдеева М., Чиркин А. Преобразование бумажных документов в электронный вид. САПР и Графика , 2004, вып. 1. С. 70–72. (На русском).

2. Садовников Д., Ноздрин А., Ширяев Н. Система управления технической и конструкторской документацией. САПР и Г рафика , 2002, вып. 5. С. 74–77.

3. Кукаренко Е., Молочко Д. Управление потоками знаний в технической документации предприятия. САПР и Г рафика , 2001, №10. С. 35–37. (На русском).

4. Бычков И., Вашук Ю. Техническое задание — основа управленческой информации предприятия. САПР и Графика , 2001, вып. 9. С. 90–95.

5. Брахутин А.Г. CALS выходит на федеральный уровень. Вестник авиации и космонавтики , 2001, вып. 5. С. 26–27. (На русском).

6. Гатчин Ю.А., Жаринов И.О., Жаринов О.О. Программная архитектура АРМ разработчика бортовой авиационной техники. Научно-технический вестник информационных технологий, механики и оптики , 2012, №1. 2. С. 140–141. (На русском).

7. Гатчин И.Ю., Жаринов И.О., Жаринов О.О., Косенков П.А. Реализация жизненного цикла «проектирование-изготовление-эксплуатация» бортового оборудования предприятий авиационной промышленности. Научно-технический вестник информационных технологий, механики и оптики , 2012, №1. 2. С. 141–143. (На русском).

8.Парамонов П.П., Гатчин Ю.А., Жаринов И.О., Жаринов О.О., Дейко М.С. Принципы построения отраслевых систем автоматизированного проектирования в авиационном приборостроении. Научно-технический вестник информационных технологий, механики и оптики , 2012, №1. 6. С. 111–117. (На русском).

9. Уткин С.Б., Батова С.В., Благонравов С.А., Коновалов П.В., Жаринов И.О. Автоматизированное построение таблиц конфигурации программного обеспечения для систем реального времени в авионике. Программирование и софт , 2015, т.41, нет. 4. С. 219–223. DOI: 10.1134 / S0361768815040076 10. Костишин М.О. , Шукалов А. В., Жаринов И.О., Жаринов О.О., Ершов А.Н. Колориметрические особенности проектирования и производства авиационных систем отображения в жизненном цикле изделия. Индийский журнал науки и технологий , 2016, т. 9, вып. 29, арт. 99451. DOI: 10.17485 / ijst / 2016 / v9i29 / 99451 11. Коробейников А.Г., Федосовский М.Е., Мальцева Н.К., Баранова О.В., Жаринов И.О., Гурджанов А.В., Жаринов О.О. Использование информационных технологий в проектной и производственной деятельности приборостроительных заводов. Индийский журнал науки и технологий , 2016, т. 9, вып. 44, арт. 104708. DOI: 10.17485 / ijst / 2016 / v9i44 / 104708

12. Богатырев В.А. Обеспечение надежности и эффективности компьютерных сетей. Информационные технологии , 2006, вып. 9. С. 25–30. (На русском).

13. Батова С.В. Программа производства готовой продукции .Свидетельство о государственной регистрации программы для ЭВМ № 2016614244, подача 19.04.2016. (На русском).

14. Жаринов И.О., Жаринов О.О., Шек-Иовсепянц Р.А., Суслов В.Д. Оценка падения надежности подготовки конструкторской документации CALS-технологиями в приборостроении. Научно-технический вестник информационных технологий, механики и оптики , 2012, №1. 4. С. 151–153. (На русском).

Design — Поддержка | WSDOT

Помощник государственного инженера-проектировщика
Помощник государственного инженера-конструктора (ASDE) и представители проектного отдела, расположенные в отделе разработки в штаб-квартире, обеспечивают безопасное, надежное, стратегически сбалансированное руководство, направление и утверждение проектной документации WSDOT, стандартов и политики.

Дизайн Политика / Руководство

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

Анализ проекта

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

Контрольные списки

Использование проприетарного изделия

Работа государственных сил (материалы, предоставляемые государством)
Работа государственных сил / материалы — это совокупность всех сумм, подлежащих оплате за рабочую силу, материалы и оборудование в рамках одного непрерывного или взаимосвязанного проекта, в котором работа должна выполняться одновременно по RCW 47 . 28.030 и RCW 47.28.035.

FHWA

Обучение

Ресурсы

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

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

Помощники государственных проектировщиков и представители по связям
Найдите свои задания по региону ASDE (pdf 89kb)

Заместитель государственного конструктора
Майк Флеминг, PE
360-705-7233

Помощник государственных проектировщиков
Скотт Целлер, ПЭ
360-705-7253

Дин Мун, ЧП
360-705-7237

Джим Махью, ЧП
360-705-7245

Кевин Миллер, ЧП
360-705-7236

Тодд Дейли, ЧП
360-705-7272

Представитель по дизайну
Самих Шилбайех, ЧП
360-705-7589

Типы технической документации

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

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

Общая классификация

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

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

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

Наша классификация

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

Мы придумали такую ​​схему:

Что ты думаешь об этом? Мы что-то упустили?

Расширенные примеры технической документации

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

User Guide (Manual) — это технический документ (как и остальная часть этого списка), предназначенный для помощи пользователям конкретной системы.В основном фокусируется на задачах, которые можно выполнить через графический интерфейс. Используемый язык подбирается для целевой аудитории с минимальным количеством жаргона или подробным объяснением.

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

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

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

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

User Requirements Document (URD) ​​(User Requirements Specification) — это технический документ, определяющий, что пользователи ожидают от программного обеспечения. Информация, задокументированная в URD, предназначена для того, чтобы точно указать, что программное обеспечение должно делать, и становится частью контрактного соглашения. Заказчик не может требовать функций, которых нет в URD, в то время как разработчик не может заявлять, что продукт готов, если он пропустил элемент URD.

Другие примеры расширенной технической документации могут включать в себя документы по архитектуре и проектированию (A&E Docs), файлы справки, руководства по стандартной процедуре эксплуатации (SOP), руководства по установке, руководства по устранению неполадок, руководства по конфигурации системы, документацию по коду, инструкции, справочные листы, официальные документы, Часто задаваемые вопросы, вопросы и ответы, справочные листы и т. Д.

Как вы думаете?

Вы когда-нибудь имели дело с какой-либо технической документацией? Какие категории технических документов вы бы выбрали? Что вы думаете о нашей классификации? Расскажите нам больше в комментариях ниже!

Удачи с технической документацией!
Команда ClickHelp
Создание, размещение и доставка документации на разных платформах и устройствах

Текущие и перспективные этапы реализации проекта

2017–2019

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

• 2017-2018 гг. — в соответствии с действующим контрактом ООО «НТЦ — Геотехнология» в рамках подготовки проектной документации для Удоканского горно-металлургического комбината готовится технический проект на разработку Удоканского месторождения меди.

• 2018 — «Развитие Удоканского медного проекта. Технический проект Удоканского ГОКа »согласован Центральным комитетом по разработке месторождений твердых полезных ископаемых Роснедра.

2017–2018

Разработка проектной документации горно-металлургического комбината.

• 2017-2018 гг. — в соответствии с действующим контрактом ООО «НТЦ — Геотехнология» разрабатывает проектную документацию горно-металлургического комбината «Удокан», относящуюся к горнорудному комплексу и горно-транспортной сфере.

• 2017-2018 гг. — в соответствии с действующим контрактом ООО «Механобр Инжиниринг» разрабатывает проектную документацию на объекты Удоканского горно-металлургического комбината, относящиеся к технологической установке.

• 2017-2018 гг. — Группа «ШАНЕКО» выполняет комплексную оценку воздействия Удоканского горно-металлургического комбината на окружающую среду в соответствии с действующим контрактом.
  

• 2018 — Компания «ТОМС Инжиниринг» разрабатывает проектную документацию на объекты инфраструктуры Удоканского горно-металлургического комбината в соответствии с действующим контрактом.

• 2018 — ООО «ТОМС Инжиниринг» выступает генеральным проектировщиком и руководит разработкой проектной документации Удоканского горно-металлургического комбината.

2019

Рассмотрение проектной документации государственными экспертами и выдача разрешения на строительство

• 2018 — Управление Росприроднадзора по Забайкальскому краю утвердило положительные заключения государственной экологической экспертизы федерального уровня по проектной документации «Удоканский горно-металлургический комбинат.I очередь строительства мощностью 12 млн т руды в год »

• 2018 г. — Разрешение на строительство подъездной дороги от станции Новая Чара к площадке Удоканского ГМЗ, объектов энергоинфраструктуры, городка и водозабора.

• 2018 — Положительная государственная экспертиза проектной документации и результатов инженерных изысканий по I очереди Удоканского ГМЗ присуждена ФАУ «Главгосэкспертиза России».

  
  

2018–2022

Строительство горно-металлургического комбината и объектов инфраструктуры

2022-2065

2 этап строительства

Диплом в области экспериментального дизайна продуктов и интерьера

|

Переключить навигацию

• О NYP

  • Обзор NYP

    • Кто мы
    • О NYP
    • Наша миссия, видение и ценности
    • Стратегические цели
    • Образовательный фонд NYP
    • Политика EHS
    • Наше руководство
    • Совет управляющих Нью-Йорка
    • Сенат Нью-Йорка
    • Старшее руководство NYP
    • Организационная структура
    • Медиа-зал
    • Информационные сообщения
    • Освещение в СМИ
    • Пресс-релизы
    • Новости кампуса
    • Публикации
    • Специализированные центры — центры передового опыта
    • Китайский перевод

    Центр поддержки и услуг NYP

    • Академия студенческой жизни
    • i0 Преинкубатор
    • i @ Central
    • Компьютерный и сетевой центр
    • Поддержка студентов
    • Образование и профориентация

    Nanyang Polytechnic International

    Организационные награды

    • Достижения
    • Фонд совершенствования организации
    • История инноваций
    • Достижения и награды Очерки
    • Отзывы
  • Прием
    • Диплом на полный рабочий день
    • Обучение на протяжении всей жизни
  • Школы и курсы

    • Школа управления бизнесом

      • Очные курсы
      • Обучение на протяжении всей жизни
      • Отраслевые проекты
      • События
      • Достижения и награды
  .