Судьба требований ГОСТ 34-й серии в проектах по информационной безопасности

Что в 2020 году подразумевает требование «проектировать по ГОСТу», становится ли оно менее обязательным? Что делать, если государственный регулятор не предлагает замену для ГОСТов 34-й серии? И вообще, какими стандартами стоит руководствоваться при оформлении проектной документации? Отвечает Николай Зенин, специалист с 12-летним опытом формирования таких требований.

 

 

 

 

1. Введение
1. 1.1. Проблематика
2. 1.2. Терминология
3. 1.3. Состав работ по созданию систем
4. 1.4. Состав ГОСТов 34-й серии
5. 1.5. Рассматриваемые вопросы
2. Практика применения требований ГОСТ 34
1. 2.1. В чем суть требований ГОСТ 34 и какова их польза?
2. 2.2. Что устарело в ГОСТ 34 и почему он все еще действует?
3. 2.3. Чем заполнить пустоту в связи с отменой РД 50-34.698-90 и какими требованиями следует руководствоваться 2.4. при проектировании систем в 2020 году?
4. 2.4. Какие требования ГОСТ 34 обязательны?
5. 2.5. Как оптимизировать трудозатраты, проектируя по ГОСТ 34?
1. 2.5.1. Состав документации
2. 2.5.2. Содержание документации
3. 2.5.3. Оформление документации
3. Выводы

 

Введение

Проблематика

К 2020 году складывается впечатление, что требование «проектировать по ГОСТу» постепенно становится всё менее обязательным, а замены для ГОСТов 34-й серии государственным регулятором не предлагается. Поэтому при формировании требований к разработке технических документов, принятии решения о содержании и оформлении проектной документации возникает вопрос: «какими стандартами следует руководствоваться?».

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

 

Терминология

Для упрощения применяемой терминологии часть понятий в данной статье объединена (в случаях, где не требуется их разделение):

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

 

Состав работ по созданию систем

Основным стандартом, определяющим последовательность работ по созданию автоматизированных систем, является ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания», введённый в действие с 01.01.1992 взамен предыдущего принятого Госстандартом СССР ГОСТа 1986 года и с тех пор так и не подвергавшийся обновлению. Стандартом ГОСТ 34.601-90 определено 8 стадий создания автоматизированных систем, но по сложившейся практике выполнения проектов эти стадии объединяются, и работы выполняются в 3-6 этапов:

1. Предпроектный этап. На данном этапе заказчики самостоятельно определяют технические требования к системе и размещают заказы на закупку. Ему соответствует стадия 1 «Формирование требований к АС» (согласно ГОСТ 34.601-90).
2. Обследование. На этом этапе привлечённый исполнитель обследует инфраструктуру заказчика и нормативную документацию, определяет угрозы безопасности информации, подготавливает отчёт об обследовании, модель угроз и комплект организационно-распорядительной документации (согласование которой может продолжаться в течение последующих стадий проекта). Этапу соответствует стадия 2 «Разработка концепции АС» (согласно ГОСТ 34.601-90).
3. Техническое задание. На данном этапе выполняется разработка и утверждение технического задания на создание системы, что соответствует стадии 3 «Техническое задание» по ГОСТ 34.601-90. Часто этапы «Обследование» и «Техническое задание» объединяют.
4. Технорабочее проектирование. На этом этапе исполнитель разрабатывает комплект документации технического проекта, рабочей документации (включая эксплуатационную), программу и методику испытаний. Этапу соответствуют стадия 4 «Эскизный проект», стадия 5 «Технический проект» и стадия 6 «Рабочая документация» (согласно ГОСТ 34.601-90).
5. Ввод в действие. На данном этапе выполняются пусконаладочные работы, подготовка персонала, проводятся испытания системы и — при необходимости — аттестация системы по требованиям безопасности информации. Ему соответствует стадия 7 «Ввод в действие» (согласно ГОСТ 34.601-90).
6. Эксплуатация и сопровождение. На этом этапе выполняются работы в соответствии с гарантийными обязательствами, а также послегарантийное обслуживание. Этап продолжается до вывода системы из эксплуатации. Ему соответствует стадия 8 «Сопровождение АС» (согласно ГОСТ 34.601-90).

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

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

 

Состав ГОСТов 34-й серии

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

1. ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем»;
2. ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
3. ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;
4. РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов»;
5. ЕСКД (ГОСТ 2) «Единая система конструкторской документации»;
6. ЕСПД (ГОСТ 19) «Единая система программной документации».

Первые три стандарта, руководящий документ (РД) и ранее рассмотренный ГОСТ 34.601-90 образуют «костяк» требований ГОСТов 34-й серии. Состав документов технического проекта определён стандартом ГОСТ 34.201-89 (действующий). Содержание отдельных документов (технического задания, программы и методики испытаний) определены ГОСТ 34.602-89 и ГОСТ 34.603-92 соответственно (действующие).

Содержание каждого разрабатываемого документа технорабочей документации ранее определялось руководящим документом РД 50-34.698-90, и наступил бы его 30-летний юбилей, но действие данного документа на территории Российской Федерации было отменено приказом Федерального агентства по техническому регулированию и метрологии (Росстандарта) от 12.02.2019 №216, а нового руководящего документа взамен РД (на момент его отмены) не предложено.

«Программой национальной стандартизации в 2019 году», утверждённой приказом Росстандарта от 01.11.2018 №2286, запланирована разработка в том числе документа «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов», заменяющего РД 50-34.698-90 (плановая дата утверждения — 30.03.2021). Но до наступления этого момента мы не имеем действующего на территории Российской Федерации руководящего (методического) документа, определяющего содержание каждой части комплекта технорабочей документации.

Согласно разъяснениям Росстандарта содержание каждого документа, разрабатываемого при проектировании автоматизированных систем согласно ГОСТ 34.201-89, теперь определяет сам разработчик.

 

Рассматриваемые вопросы

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

1. В чём суть требований ГОСТ 34 и какова их польза?
2. Что устарело в ГОСТ 34 и почему он всё ещё действует?
3. Чем заполнить пустоту в связи с отменой РД 50-34.698-90 и какими требованиями следует руководствоваться при проектировании систем в 2020 году?
4. Какие требования ГОСТ 34 обязательны?
5. Как оптимизировать трудозатраты, проектируя по ГОСТ 34?

 

Практика применения требований ГОСТ 34

В чём суть требований ГОСТ 34 и какова их польза?

ГОСТы 34-й серии и связанные с ними стандарты регламентируют следующие 5 основных областей требований к проектированию систем:

1. стадии проекта создания системы;
2. состав проектной документации;
3. содержание проектной документации;
4. оформление проектной документации;
5. последовательность приёмки системы.

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

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

 

Что устарело в ГОСТ 34 и почему он всё ещё действует?

Конечно, стандарты 30-летней давности морально устарели, в них заложены архаичные представления об архитектуре автоматизированной системы. Наиболее богатым артефактами такого рода был недавно отменённый РД 50-34.698-90 (который определял содержание проектной документации).

В структуре требований ГОСТ 34 к проектированию предусмотрено указание сведений о расположении технических средств, о физическом подключении компонентов, о наличии программных средств, баз данных, клиент-серверных взаимодействий; однако не предусмотрены ни элементы сетевой модели OSI (в каких таблицах ведётся учёт IP-адресов и VLAN), ни технологии виртуализации, ни облачные вычисления, не говоря уже о современных тенденциях развития информационных технологий.

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

За последние несколько лет были приняты изменения ГОСТов в части оформления (новые ГОСТ Р 2.105-2019, ГОСТ Р 2.106-2019 — по оформлению ЕСКД, ГОСТ 7.32-2017 — по оформлению отчёта о научно-исследовательской работе).

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

 

Чем заполнить пустоту в связи с отменой РД 50-34.698-90 и какими требованиями следует руководствоваться при проектировании систем в 2020 году?

Во-первых, требования ГОСТов 34-й серии (в частности — ГОСТ 34.201-89, определяющего виды документов, и ГОСТ 34.602-89, определяющего содержание технического задания на создание системы) остаются действующими. Таким образом, после отмены РД 50-34.698-90 не произошло отказа от всей системы стандартов ГОСТ 34-й серии. Изменилась только ситуация с наличием действующего регламента по содержанию документации. Действительно, РД 50-34.698-90 нуждался в серьёзной переработке, поскольку был рассчитан на применение устаревших методов обработки информации. Оставшиеся действующими документы определяют структуру всей системы документации и содержание основных проектных документов, в том числе — технического задания.

Во-вторых, на необходимость учёта требований ГОСТов 34-й серии при создании систем указывает действующая нормативная база, в частности:

• ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищённом исполнении. Общие положения»;
• приказ ФСТЭК России от 11.02.2013 №17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;
• постановление Правительства Российской Федерации от 06.07.2015 №676 (в редакции от 07.08.2019) «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

Последний из названных нормативных актов содержит не прямое указание на ГОСТ 34.601-90, а цитату из него, дополненную требованиями по защите информации: «Этап разработки документации на систему и её части включает разработку, согласование и утверждение документации в объёме, необходимом для описания полной совокупности проектных решений (в том числе по защите информации) и достаточном для дальнейшего выполнения работ по созданию системы».

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

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

Хорошо, если имеется отраслевой стандарт или внутри организации заказчика системы утверждён стандарт корпоративный, определяющий правила изложения и оформления документации технического проекта. В качестве основы для подготовки такого стандарта хорошо подходят требования РД 50-34.698-90 вместе с ГОСТ 34.201-89 (в качестве мастер-таблицы), если убрать из них ненужные документы и разделы.

Заказчику, приступающему к созданию системы по ГОСТ 34 в отсутствие корпоративного стандарта организации, следует в технических требованиях на проектирование системы вместо привычной ссылки на РД 50-34.698-90 указывать (цитатами из руководящего документа) конкретные требования к содержанию разрабатываемых документов. Например: «Пояснительная записка к техническому проекту (П2), содержащая разделы: “Общие положения”, “Описание процесса деятельности”, “Основные технические решения”, “Мероприятия по подготовке объекта автоматизации к вводу системы в действие”». Разработчик, увидев требования (в данном случае процитированные не из ГОСТ 2.120-2013 ЕСКД / ГОСТ 19.404-79 ЕСПД, а именно из ранее действующего РД 50-34.698-90), должен из соображений здравого смысла и своего опыта разработки подготовить документацию по ГОСТ 34.

 

Какие требования ГОСТ 34 обязательны?

В соответствии с Федеральным законом от 29.06.2015 №162-ФЗ «О стандартизации в Российской Федерации» добровольность применения документов по стандартизации является одним из её принципов (статья 4). ГОСТ становится обязательным только если это установлено Федеральным законом (не случай с ГОСТ 34) либо если изготовитель / исполнитель заявляет о применении национального стандарта (статья 26 вышеуказанного 162-ФЗ).

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

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

В данных случаях необходимо руководствоваться требованиями ГОСТ 34, даже если в современных трактовках вышеуказанных нормативных требований к разработке документации не употребляется прямая отсылка к ним, а, например, указываются цитаты из ГОСТа 34-й серии:

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

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

В таблице 1 обзорно показано, какие из пяти рассмотренных основных областей требований к проектированию систем по ГОСТ 34 становятся обязательными.

 

Таблица 1. Обязательность отдельных областей требований к документации

Область требований	Обязательность	Комментарии
стадии проекта создания системы	Рекомендательный характер	Последовательность стадий работ по ГОСТ 34.601-90 объединяет «лучшие практики» создания систем (правда, слегка устаревшие)
состав проектной документации	Рекомендательный характер	ГОСТ 34.201-89 содержит исчерпывающий перечень документов, из которого можно выбрать нужные по необходимости
содержание проектной документации	Обязательно	РД 50-34.698-90 не действует, однако содержание документации регламентировано прочими нормативными актами. Разработчик должен подготовить «достаточный» набор сведений в документации
оформление проектной документации	Рекомендательный характер	Требования к оформлению документации (ЕСКД) носят рекомендательный характер
последовательность приёмки системы	Обязательно	Созданная система должна быть оформлена надлежащим образом

 

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

 

Как оптимизировать трудозатраты, проектируя по ГОСТ 34?

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

 

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

Состав документации, определённый в ГОСТ 34.201-90, избыточен (содержит исчерпывающий набор на все возможные случаи и был сформирован для устаревшей архитектуры систем). Среди предложенных документов исходя из специфики задачи могут быть выбраны наиболее подходящие. Если требования заказчика не вполне определены, автор статьи рекомендует присмотреться к одному из предложенных в таблице 2 наборов (1…5) документации, описываемой ГОСТами 34-й серии, в качестве рекомендации, от которой можно далее отталкиваться.

 

Таблица 2. Рекомендуемые наборы документации

Наименование документа	Код	1	2	3	4	5
1. Отчёт об обследовании	—		+	+	+	+
2. Модель угроз безопасности информации	—		+	+	+	+
3. Концепция автоматизированной системы	—				+	+
4. Техническое задание	ТЗ	+	+	+	+	+
5. Ведомость технического проекта	ТП			+	+	+
6. Схема структурная комплекса технических средств	С1			+	+	+
7. Схема функциональной структуры	С2			+	+	+
8. Пояснительная записка к техническому проекту	П2		+	+	+	+
9. Схема автоматизации	С3				+	+
10. Описание автоматизируемых функций	П3				+	+
11. Описание информационного обеспечения системы	П5					+
12. Описание комплекса технических средств	П9				+	+
13. Описание программного обеспечения	ПА					+
14. Схема организационной структуры	СО					+
15. Описание организационной структуры	ПВ				+	+
16. План расположения	С8				+	+
17. Схема соединений внешних проводок	С4					+
18. Таблица соединений и подключений	С6					+
19. Чертёж установки технических средств	СА				+	+
20. Программа и методика испытаний	ПМ	+	+	+	+	+
21. Ведомость эксплуатационных документов	ЭД			+	+	+
22. Руководство администратора (технологическая инструкция)	И2			+	+	+
23. Руководство пользователя	И3		+	+	+	+
24. Инструкция по эксплуатации КТС	ИЭ			+	+	+
25. Формуляр	ФО					+
26. Паспорт	ПС				+

 

Коды документов в таблице 2 приведены в соответствии с ГОСТ 34.201-90. Акты, протоколы, приказы, эскизный проект и редко разрабатываемые документы (из списка 58 документов ГОСТ 34.201-90) не учитывались в ней.

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

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

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

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

Набор 5 редко требуется в таком широком составе, даже для аттестации систем.

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

 

Содержание документации

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

Указывая на необходимость разработки модели угроз (определения угроз безопасности информации), можно сослаться либо на базу данных угроз ФСТЭК России, либо на ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем».

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

• Справочник требований. Должен быть чётко описан переход от конкретных требований к результатам. Предпроектные технические требования после запуска проекта должны превратиться в техническое задание (путём внесения уточнений по результатам обследования и определения угроз), а решения технического проекта должны стать подтверждением перехода от требований «должен» к «решено»:

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

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

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

 

Оформление документации

Стандартом оформления технических документов принято считать ЕСКД (ГОСТ 2) «Единая система конструкторской документации».

Согласно РД 50-34.698-90, на настоящий момент отменённому, документацию технического проекта (строки 5-26 в таблице 2) выполняют по ГОСТ 2.105 и ГОСТ 2.106, которыми установлены требования к оформлению текстовых документов и чертежей на листах формата по ГОСТ 2.301, включая рамку по границам листа, с надписью внизу рамки по ГОСТ 2.104 и с кодом документа по ГОСТ 34.201-89.

Оформление документов в рамке по границам листа в своё время было замечательным решением для обеспечения бумажного документооборота: всегда можно было определить принадлежность листа документа к конструкторской документации и место любого из листов по уникальной комбинации его номера и кода документа. Однако с переходом к электронному документообороту требования к наличию рамок стали менее актуальными. Если заказчик разработки документации считает, что рамки по границе листа затрудняют восприятие, то от них можно отказаться, не нарушая требований ГОСТа. Для этого в заказе на разработку документации необходимо указать «без рамки» — например, в такой формулировке: «Документация оформляется в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа». В таком случае технорабочая документация будет выполнена так же, как подготавливается техническое задание, что удобно для электронного документооборота.

ГОСТ 2.105, новая редакция которого вышла в 2019 году (вступление в силу отложено до 01.07.2020 приказом Росстандарта от 30.01.2020 №19-ст), содержит общие требования к текстовым документам. Для производства профессионально составленной документации разработчикам (техническим писателям) рекомендуется применять соответствующие ГОСТу советы специализированных руководств, одним из наиболее заслуженных среди которых считается «Справочник издателя и автора» (Мильчин А.Э, Чельцова Л.К.) — пятое издание 2018 года.

 

Выводы

По результатам рассмотрения требований ГОСТов 34-й серии мы приходим к заключению, что они имеют рекомендательный характер, но их очень желательно применять как минимум в качестве чек-листа. Кажущиеся жёсткими формулировки, ориентированные на архаические представления систем, не требуют обязательного исполнения. Среди требований ГОСТов содержатся важные структурообразующие элементы, умелое применение которых позволит сэкономить много сил. Как говорится в древнем высказывании, «если притупится топор, и если лезвие его не будет отточено, то надобно будет напрягать силы; мудрость умеет это исправить».

Применяйте ГОСТ со здравым смыслом!