Опубликовано: 30 Октября 2007

«Достала меня эта кривая софтина!» — не выдержал мой
коллега, устанавливавший программное обеспечение одного из известных российских
разработчиков на компьютер заказчика. Сотрудница ПКО, пожилая женщина, уже
долгое время наблюдавшая за процессом инсталляции, в испуге отшатнувшись от
него, спросила: «Работать сегодня опять не будем?» «Нет, не будем», —
ласково ответил он ей и пошел набирать телефон службы технической поддержки
разработчика. Не стану приводить весь дальнейший разговор между специалистами
службы технической поддержки — он был долгим и оживленным. На следующий
день программу общими усилиями запустили. «А где же наша карточка клиента и наши
формы документов? — спросила женщина из ПКО нашего специалиста. — Нам
на обучении преподаватель фирмы-разработчика сказал, что все легко
настраивается…» Проштудировав руководство пользователя и перекопав все настройки
программы, они позвонили в сервисную службу разработчика, где им объяснили, что
в этой версии такой возможности действительно нет, а вот через полгода выйдет
новая версия программы, где все будет. В итоге программа легла на полку, а
женщина, как и раньше, продолжила работать в AutoCAD. Внедрить вертикальную САПР
не получилось, роста производительности труда достигнуто не было.


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


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


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


Однако в настоящее время многие отечественные разработчики (про
иностранцев отдельный разговор) производят «эгоистические» программы. Что
понимается в данном случае под эгоизмом, очень хорошо поясняет следующее
высказывание: «Многие программы напоминают мне некоторых моих преподавателей из
университета, считавших, что их предмет — самая главная из дисциплин
учебной программы и именно она станет, ни много ни мало, делом всей жизни
каждого из их студентов» (Жарков С.В. Shareware: профессиональная разработка и
продвижение программ. С. 87). Таким образом, «эгоистической» мы будем называть
такую программу, в которой отсутствует возможность адаптации (настройки), чтобы
выпускаемая с ее помощью проектная документация соответствовала стандартам
конкретного предприятия. Помните: чем больше «эгоизма» в программе и вранья в
рекламе, тем хуже для вас — вместо обещанного «мерседеса» вы можете
получить тачку с одним колесом, которую проще отложить, чем использовать в
работе.


Важные критерии при выборе ПО


Итак, что же нужно для успешного внедрения приобретаемых
программных средств? Для этого необходимо принимать во внимание следующие
факторы:



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

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

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

Хочу обратить ваше внимание на важную деталь: совместимость
программ может обеспечиваться введением стандарта на проектную документацию,
выполняемую в электронном виде. Существует несколько общепринятых стандартов
(ANSI, DIN и пр.), а в некоторых случаях необходимы также стандарты предприятия.
Конечно же, стандарты не должны препятствовать дальнейшему развитию, поэтому в
определенный момент приходится отступать от текущих стандартов и формулировать
новые. По этой причине программы должны быть адаптируемыми. Помните пример,
приведенный в начале статьи? Не верьте рекламе и сладким речам менеджеров,
просите показать работу программы на вашем конкретном примере или ждите
следующего года и покупайте ПО только тогда, когда в нем появятся необходимые
функции. Конечно, к выбору программы нужно подходить разумно. Если 90% ваших
потребностей программа удовлетворяет, а 10% — нет, но это вас не напрягает
и не тормозит процесс проектирования в целом, то ее можно приобретать.


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


Масштаб и его настройка


Как известно, существует два подхода к выполнению графической документации,
основанной на планах. Первый заключается в том, что основные проектные решения
выполняются в масштабе 1:1 (одна графическая единица соответствует одной единице
проектируемого сооружения, например мм), после чего производится необходимое
проецирование. Второй подход заключается в выполнении чертежей в определенном
масштабе (1:100, 1:50, 1:200 и т.д.).


Не будем анализировать и обсуждать преимущества и недостатки этих подходов и
выяснять, какой из них лучше. В проектной практике применяются оба: одни
пользователи предпочитают один способ, другие — другой, кому как удобно и
кто как привык работать. Следовательно, в программе должна быть предусмотрена
возможность настройки масштаба (1:1, 1:50, 1:100 и т.д.), в котором будет
производиться работа.


Шрифты, и как их настраивать

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

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

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

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

Способ задания толщины линий
и использование атрибутов слоев

На мой взгляд, это один из самых сложных
вопросов. В AutoCAD реализовано несколько способов задания толщины линий. Одни
пользователи задают толщину линий посредством цвета, а другие — через
атрибут «вес». В меньшей степени используются полилинии и цветонезависимые
таблицы стилей печати. Однако если в двух программах толщина линии задается
через цвет, причем у одной желтый соответствует толщине линии 0,5 мм, у
другой — 0,25 мм, а третья использует «вес» линии, то можно
представить, какой разброс будет при применении десятка продуктов! Поэтому в
программе должна быть предусмотрена возможность настройки толщины линии как
через «вес» и цвет, так и через цветонезависимые таблицы стилей печати, чтобы
удовлетворять стандарту предприятия.

Наименование слоев и распределение
информации по слоям

Вопрос непростой и в плане упорядочения
проектной графической информации не менее важный, чем предыдущий. В программе
должна быть предусмотрена возможность изменять названия используемых слоев и
распределять объекты по слоям, что, по сути, одно и то же. Например, в
программе, выполняющей архитектурную подоснову, должна быть реализована
возможность настраивать название слоя, в котором выполняются стены (А-СТЕНЫ,
СТЕНЫ, СТЕНА-ВНУТР и пр.).

В качестве примера приложения, позволяющего
производить такую настройку, можно привести систему Autodesk Architectural
Desktop. В ней есть замечательное средство key mapping, которое на каждый тип
объектов определяет слой, где будут формироваться объекты, причем в соответствии
с определенным стандартом.

Помимо возможности изменения распределения
информации по слоям, названия слоев должны удовлетворять стандартам на
наименования слоев. В качестве примера можно привести систему Autodesk
Architectural Desktop, которая поддерживает следующие стандарты: DIN 276,
ISYBAU, STLB, AIA и BS1192. Стандарты на наименования слоев необходимы для
упрощения обмена документацией в электронном виде. В настоящее время происходит
активный обмен чертежами между организациями. При совпадении стандарта на
наименования слоев у взаимодействующих сторон процедура обмена документацией
значительно облегчается.

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

Профиль

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

Самое важное: рамки и штампы

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

Выводы

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



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


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


  • программы не должны содержать процедуры
    формирования рамок и штампов;


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

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

Автор: Александр Лоза. Ведущий инженер, ЗАО «Бюро САПР»
Источник: САПР и графика
Сайт: www.sapr.ru