Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель: ООО НТЦ «АПМ»

ИНН 5018019971 ОГРН 1035003357366

Рекламодатель:
ООО «С3Д Лабс»

ИНН 7715938849 ОГРН 1127747049209

9 - 2008

Стандарты… А что же это такое?

Александр Лоза (Ведущий инженер отдела технической поддержки, ЗАО «Бюро САПР».)

Избыточное применение стандартов

Шрифты

Фиксированная высота строки

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

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

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

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

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

Избыточное применение стандартов

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

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

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

Теперь более подробно рассмотрим перечисленные критерии.

В начало В начало

Шрифты

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

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

Такой подход чреват следующими последствиями:

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

Разработка новых шрифтов обычно происходит из-за того, что начертание некоторых букв в шрифтах, поставляемых с системой, отличается от приведенных в ГОСТ 2.304-81.

Выше уже было замечено, что любые требования ГОСТа являются вторичными и служат для удовлетворения первичных требований: удобочитаемости, единообразия и целесообразности. На данный момент в системах Windows и AutoCAD заложены шрифты, которые стали стандартом де-факто. Они поставляются вместе с приложением и гарантируют корректное прочтение документации на любом компьютере, где установлено данное ПО. Такими шрифтами являются системные шрифты Times New Roman, Arial и др., шрифты AutoCAD — txt, romans и т.п. Первичным требованиям данные шрифты прекрасно удовлетворяют: гарантируют единообразие, удобочитаемость текстового материала в электронных чертежах и целесообразность использования: не надо копировать никакие шрифты, а чертеж, выполненный с использованием стандартных шрифтов, однозначно прочитается на другом компьютере.

Дополнительно создаваемые шрифты (spds. shx, eskd и т.п.), полностью соответствуя ГОСТу, не удовлетворяют первичным требованиям.

В результате складывается такая ситуация: слепо следуя требованиям ГОСТа (при разработке или использовании шрифтов), мы приходим к тому, что нарушаются первичные требования: целесообразность и единообразие, ради чего ГОСТ и разрабатывался.

Следует заметить, что в некоторых организациях вместо векторных шрифтов AutoCAD при выполнении графической документации используются контурные шрифты — стандартные шрифты Windows . Обоснование выбора такого шрифта приводится не очень убедительное: так смотрится красивее, да и буквы получаются более толстыми. Подобный подход в корне ошибочен: применение контурных шрифтов сильно замедляет работу в программе — даже при незначительном по насыщенности чертеже компьютер будет долго обрабатывать информацию, ведь ему требуется просчитать очертание каждой буквы и залить соответствующие области. А что если придется работать на сложном чертеже? Толщиной букв прекрасно можно управлять, используя векторные шрифты (только этим надо уметь пользоваться).

Следующие проблемы возникают при формировании заказных спецификаций.

В начало В начало

Фиксированная высота строки

В ГОСТ 21.110-95 приводится форма заказной спецификации и указывается, что высота строки должна быть «8 min». Хотя напрямую в тексте нигде не сказано, что строки должны иметь одинаковую высоту, таблица разлинована через одинаковый промежуток. Поэтому в подавляющем большинстве организаций принята следующая запись: если информация не умещается в пределах одной строки, она переносится в следующую ячейку (рис. 1).

Рис. 1

Рис. 1

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

  • всё ПО (Word, Excel, AutoCAD и т.п.) при работе с таблицами, если информация не умещается на одну строку, переносит порцию информации на другую строку, но в пределах одной ячейки (рис. 2)! Причем, обращаю внимание читателей, происходит это автоматически!
  • если порция информации отделена не пустой строкой, а подчеркиванием, это гораздо удобнее для чтения. Глаз лучше различает информацию, относящуюся к одному элементу, если она отделена от другого чертой и умещается в пределах одной строки. Кроме того, в этом случае таблица занимает меньше места.

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

Рис. 2

Рис. 2

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

Как видите, получается дополнительный объем ручной работы (если не разрабатываются дополнительные программы) или же дополнительный объем ненужной работы (если осуществляется разработка специализированного ПО, размещающего информацию согласно ГОСТу), хотя базовое ПО (Word, Excel, AutoCAD) уже давно способно форматировать информацию в пределах одной ячейки (см. рис. 2). Почему же так и не поступать?!

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

В начало В начало

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

Если раньше рамка была целесообразна и служила главным образом для задания границ текста, то теперь при разработке документации средствами текстового процессора (в 90% случаев это Microsoft Word) границы текста задаются без применения рамки. Рамка же служит только дополнительным декоративным элементом, она не ограничивает область текста! Зато ее применение приводит к ограничению использования возможностей программы, требует дополнительных неоправданных затрат как по формированию документа, так и по устранению возникающих некорректностей (например, часто встречается ситуация, что съехала рамка или необходимо выровнять границу таблицы в соответствии с рамкой и т.п.).

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

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

Почему для формирования спецификаций не использовать СУБД, например Access? Дело в том, что если спецификация сформирована средствами Access, то подкорректировать ее в соответствии с условиями проектирования (изменился штамп, нужно дописать недостающее слово, вбить дополнительную информацию и т.п.) практически невозможно. Точнее, это возможно, но в таком случае придется содержать программистов, которые бы постоянно помогали проектировщикам.

Если быть более точным, в Excel имеются следующие способы формирования рамок:

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

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

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

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

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

Конечно, документация не должна быть оформлена кое-как, но зачем выполнять работу впустую?

 

Продолжение статьи читайте в следующем номере журнала

В начало В начало

САПР и графика 9`2008

Регистрация | Войти

Мы в телеграм:

Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557