Стандартизация при работе в САПР. Зачем это нужно и как ее контролировать?

[trir]

просто ещё одна точка отказа…

[dows]

Я не понял этот комментарий… отказа от чего?

[trir]

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

[Kutuzova]

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

[trir]

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

про AutoCAD тоже самое говорят… но мы то знаем

[Kutuzova]

Вопрос, конечно, философский. ЧП случаются. Но если страшно полагаться на код, то на алгоритмы, выполняемые вручную надеяться еще опаснее (человеческий фактор- дело такое). Остаётся только предпринимать всевозможные меры, для того чтобы минимализировать риск появления ошибок. К чему мы все, несомненно, стремимся. Все-таки норма- это стабильная работа, а не наоборот!

[trir]

вскрывать чёрный ящик ещё сложнее, а со свои кодом — ты понимаешь, что происходит и сразу можно понять, что пошло не так…

[Kutuzova]

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

[trir]

если падает САПР — она падает на одной машине, если сламается ваша приблуда — САПР сломается во всей организации… и всех собак спустят на САПР'вцев

Когда в AutoCAD появилось цетральное управление настройками, исправления которые делались за 5 пять минут — начали делатся за пол или целый день, потомучто пришлось писать заявки САПР'вцам в центральном офисе, в другом городе. А ещё выяснилось, что для Civil'а нужны другие настройки — это вообще затянулось на несколько дней…

[dows]

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

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

[zhabr]

руководителю всё равно, лишь бы получить положительное заключение экспертизы и деньги от заказчика

[dows]

ну не согласен… это пустая сторона стакана. Мы скорее видим полунаполненный стакан ))

[fedor0v]

Лично я готов расцеловать автора статьи и разработчиков нанокада. У нас компания не настолько большая, чтобы использовать взрослые игрушки, но уже не такая маленькая, когда каждый сам себе хозяин. Проблемы, затронутые автором статьи, вызывают у меня острую головную боль — всё прочувствовал на собственной шкуре: разный уровень подготовки пользователей, копирование наработок из предыдущих проектов, местами игнорирование здравого смысла и т.п. Обязательно попробую предложенное решение.
Ps. Еще бы ворд так обуздать…

[Surokkk]

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

[Kutuzova]

Если у Вас возникают вопросы и пожелания, то кроме форума можно обратиться к обсуживающему дилеру или по линии технической поддержки nanoCAD (адрес есть в личном кабинете)!

[fisuna]

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

1) а что мешает «сохранить как..» хоть шаблон, хоть полупустой файл с настроенными стилями/слоями/…?
2) что будет с чертежами полученными от субчиков? при открытии автоматом все шрифты и стили поменяются в соответствии с СТП?

[dows]

1. Ничто не мешает, конечно. Но DWT шаблон — это часть процесса; важная, но не единственная. Например, DWT шаблоны могут быть в разных отделах разные — а значит надо будет ходить по всем отделам (а это уже сговор :-) ). Также корпмодуль позволяет динамично обновлять DWT шаблоны…

2. Автоматом нет. Но DWS при каждом сохранении будет говорить, что в них нарушены такие-то такие-то пункты СТП на DWG. Субчиков имеет смысл строить с помощью договоров и требований к сдаваемым материалам.

[Kutuzova]

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

[fisuna]

т.е. вы предлагаете в договоре с субчиками прописывать использование слоёв/типов линий/шрифта/…?
У субчиков своё ПО(возможно отличное от заказчика), своё СТП…
В одной конторе все размеры/выноски вынесены на один слой, а в другой организации слоёв с размерами может быть множество (речь про ПГС)

[dows]

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

[fisuna]

т.е. вы сами все настройки субчикам отдадите, чтоб получить всё в красивой обёртке ;)

[dows]

почему? Проектировщик выставляет требования к субчику по выдаче DWG по требованиям своего СТП (которые контролирует вручную либо с помощью нашего Корпмодуля). Субчик в свою очередь также настраивает свой СТП под этого Проектировщика. Если у субчика несколько Заказчиков (Проектировщиков), то ему надо будет вести несколько СТП внутри себя (под каждого Проектировщика). Вручную либо с помощью нашего Корпмодуля… Между Субчиком и Заказчиком СТП описывается договором и требованиями.

[fisuna]

не в ту ветку (

[GlebGleb]

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