- Надмірне застосування стандартів
- шрифти
- Фіксована висота рядка
- Рамки і штампи в тестовій документації
Олександр Лоза (Провідний інженер відділу технічної підтримки, ЗАТ «Бюро САПР».)
Надмірне застосування стандартів
шрифти
Фіксована висота рядка
Рамки і штампи в тестовій документації
Чи слід ваша організація стандартам по оформленню проектної документації? На це питання багато співробітників підприємств, не замислюючись, дадуть відповідь, що, безумовно, слід. Насправді ж тут все далеко не так просто.
Для початку необхідно зрозуміти, для чого потрібні стандарти. Головне завдання стандартів полягає в забезпеченні однаковості і взаємодії, щоб проектну документацію могли прочитати і замовники і виконавці. Тобто саме для того, щоб документація була виконана одноманітно. Для того щоб вона була зрозуміла іншим людям, і розробляються стандарти на оформлення ПКД (проектно-кошторисна документація). Фактично тут закладений принцип доцільності.
Таким чином, виходить, що вимоги стандартів є вторинними, а первинні - це доцільність, читабельність і однаковість.
Якщо розглянути роботу підприємств, то практично на кожному з них в проектній практиці має місце як надмірне застосування стандартів, так і їх відсутність.
Надмірне застосування стандартів
Вимоги більшості ГОСТів, що регламентують оформлення ПКД, розроблялися в той час, коли креслення переважно виконувалися на ватмані і ні про яке їх виконанні в системах САПР на сучасному рівні не було й мови. Тому ГОСТ добре вирішував завдання із забезпечення однаковості і доцільності (практичності) в межах ручного оформлення документації:
- для зручності читання і однаковості всієї ПКД був регламентований один шрифт;
- структура таблиць складалася таким чином, щоб можна було вручну легко вписувати інформацію;
- рамки були зручним засобом для орієнтації, де слід закінчити писати текст.
Застосування САПР докорінно змінило техніку виконання креслень. Якщо раніше ГОСТ на оформлення документації задовольняв первинним вимогам: доцільності та однаковості (практичності), то, своєчасно не скорегувавши вимоги, він, навпаки, став противником даних положень і відповідно гальмом до розвитку.
Тепер більш детально розглянемо перераховані критерії.
шрифти
Для того щоб шрифт повністю задовольняв ГОСТ 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
Коли документ заповнюється ручним способом, це цілком логічно. Але варто тільки при розробці документації почати використовувати ПО, справа приймає зовсім інший оборот:
- все ПО (Word, Excel, AutoCAD і т.п.) при роботі з таблицями, якщо інформація не вміщується на один рядок, переносить порцію інформації на інший рядок, але в межах одного осередку (рис. 2)! Причому, звертаю увагу читачів, відбувається це автоматично!
- якщо порція інформації відділена не порожній рядком, а підкресленням, це набагато зручніше для читання. Око краще розрізняє інформацію, що відноситься до одного елементу, якщо вона відокремлена від іншого рисою і вміщується в межах одного рядка. Крім того, в цьому випадку таблиця займає менше місця.
При розробці документації вручну варіант написання тексту в одній комірці (див. Рис. 2) не був технологічним, але на даний момент цей метод є значно більш доцільним.
Мал. 2
Що ж робить проектувальник? Він записує інформацію в осередку, відстежуючи, уміщається вона в межах одного рядка. Якщо вона не вміщується, переходить в іншу клітинку і продовжує описувати об'єкт. Якщо ж тепер потрібно відкоригувати запис, то в разі збільшення розміру проектувальник змушений додати порожній рядок і вручну здійснити перенесення тексту. Ще гірше, якщо проводиться розробка додаткових програм для автоматизації даного процесу.
Як бачите, виходить додатковий обсяг ручної роботи (якщо не розробляються додаткові програми) або ж додатковий обсяг непотрібної роботи (якщо здійснюється розробка спеціалізованого ПЗ, яка розміщує інформацію відповідно до Держстандарту), хоча базове ПО (Word, Excel, AutoCAD) вже давно здатне форматувати інформацію в межах одного осередку (див. рис. 2). Чому ж так і не чинити ?!
Даний аспект стосується не тільки проектувальників, але і розробників програм, які формують різні звіти.
Рамки і штампи в тестовій документації
Якщо раніше рамка була доцільна і служила головним чином для завдання кордонів тексту, то тепер при розробці документації засобами текстового процесора (в 90% випадків це Microsoft Word) межі тексту задаються без застосування рамки. Рамка ж служить тільки додатковим декоративним елементом, вона не обмежує область тексту! Зате її застосування призводить до обмеження використання можливостей програми, вимагає додаткових невиправданих витрат як по формуванню документа, так і щодо усунення виникаючих неточностей (наприклад, часто зустрічається ситуація, що з'їхала рамка або необхідно вирівняти кордон таблиці відповідно до рамкою і т.п.) .
Виникає природне запитання: а навіщо потрібна рамка? Може бути, доцільно залишити її тільки на першому аркуші? Інформація про номери аркушів і марці креслення потрібна, але її можна прописати в колонтитулах (нехай не в звичному вигляді, але вона буде присутня). Що ж стосується штампа зміни, то документи в електронному вигляді зазвичай замінюються цілком і необхідність в такій інформації відпадає. Так, це незвичний спосіб, але, погодьтеся, відразу відпадає багато зайвих проблем!
Саме через уявної необхідності існування рамки і штампів (їх можна було б замінити інформацією в колонтитулі) рідко використовується ПО Microsoft Excel, хоча саме його, а не текстовий процесор варто було б застосовувати для формування специфікацій та інших табличних звітів.
Чому для формування специфікацій не використовувати СУБД, наприклад Access? Справа в тому, що якщо специфікація сформована засобами Access, то підкоригувати її відповідно до умов проектування (змінився штамп, потрібно дописати відсутню слово, вбити додаткову інформацію і т.п.) практично неможливо. Точніше, це можливо, але в такому випадку доведеться утримувати програмістів, які б постійно допомагали проектувальникам.
Якщо бути більш точним, в Excel є такі способи формування рамок:
- осередки групуються і обводятся таким чином, що кордони осередків і становитимуть штамп і рамку креслення;
- мені зустрічалися програми (під Excel), які з одного аркуша (інформація знаходиться в табличному вигляді) і іншого листа (містить рамку зі штампом) формують необхідний вид специфікації. Але це знову ж таки розробка додаткових програм.
Однак перший варіант не витримує ніякої критики: при додаванні рядка інформація починає «плисти», а другий вимагає розробки (наявності) додаткової програми, хоча сенс в цьому відсутня.
Можна навести ще багато подібних проблем, однак їх розгляд не входить в завдання даної статті.
При оформленні проектної документації проектувальники зазвичай орієнтуються на службу нормоконтролю, яка працює за принципом «так ми завжди робили» або «... відповідно до Держстандарту». Але якщо слідувати цій логіці, то як ми жили без телефонів, так і будемо продовжувати жити без них. Але ж ситуація змінюється, кошти проектування вдосконалюються, тому в завдання служби нормоконтролю повинно входити зміна стандартів підприємства таким чином, щоб здійснювати більш ефективну роботу.
Для того щоб документ повністю відповідав ГОСТу, потрібно витратити якийсь час на «дооформлення» документа. Тільки ось вільного часу у проектувальників не буває. А яка користь буде від такої роботи? Практично ніякого! Тобто проектувальник виконує цю роботу тільки тому, що «так треба». А підприємство оплачує виконання цієї порожній роботи. То чи не краще ці сили направити на більш корисні заняття: підвищення кваліфікації, роботу з документацією або більш глибоке вивчення програм?
Звичайно, документація не повинна бути оформлена абияк, але навіщо виконувати роботу даремно?
Продовження статті читайте в наступному номері журналу
САПР і графіка 9`2008
А що якщо доведеться працювати на складному кресленні?Що ж робить проектувальник?
Чому ж так і не чинити ?
Виникає природне запитання: а навіщо потрібна рамка?
Може бути, доцільно залишити її тільки на першому аркуші?
Чому для формування специфікацій не використовувати СУБД, наприклад Access?
А яка користь буде від такої роботи?
То чи не краще ці сили направити на більш корисні заняття: підвищення кваліфікації, роботу з документацією або більш глибоке вивчення програм?
Звичайно, документація не повинна бути оформлена абияк, але навіщо виконувати роботу даремно?