Про загадочность

Если начальник КБ загадочным путём придёт и прочтёт этот комментарий, то пусть не обижается, но намотает на ус следующее:

1. Мутации изделий часто имеют место и без всяких CAD-систем. Тут бывает достаточно обветшавшей кальки, формального выполнения своих обязанностей подчинёнными, а особенно забывчивости руководства в части соответствия вознагражений сложности и качеству работ.

2. Пространство для творчества разработчиков составных частей задаёт разработчик целого. По-русски это называется выдать ТЗ с габаритным чертежом и техническими требованиями. В параметрических CAD-системах для этих целей есть целые модули, только чтобы понять их смысл и принципы создания базы знаний нужно быть именно конструктором.

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

4. Практика сковывания свободы творчества в угоду необъективным факторам (интересам) именуется вредительством. В общем, проблема синхронизации и оповещений на самом деле достаточно просто решена средствами обычного БТД и можно только догадываться почему этот приём упорно не хотят воспроизвести разработчики PDM. Кстати, это и к вопросу о заблокированных библиотеках API.

С пунктами 1,2,3,4 спорить невозможно, ибо истина это. В каноническом смысле. В виде догмы, я бы сказал. Так должно быть, но не бывает практически.

Переписчик действует по алгоритму, а значит его работу легко можно перепоручить электроному болвану с той или иной переферией.

Только если работу болвана будет принимать переписчик, думается что болван будет посрамлён.

Так вот, для того чтобы технолога, производственника и рабочего не смывало потоком конструкторской мысли прежде всего необходимо максимально повысить качество проектирования. Это значит что под заказ в производство должно идти уже очень хорошо продуманное и просчитанное изделие, а это достигается только максимальной эффективностью связки (CAD-CAE)/PDM.

Трёхбуквий маловато будет. PDM без эксплуатационных и производственных данных вряд ли потянет озвученные задачи. А с ними - это уже совсем другое дело. Совсем не PDM. Хотя я давно на буквы особо не смотрю - на то что делается как-то больше внимания обращаю.

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

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

Спрашиваю: чего тут запредельного для программирования? Ужели нельзя проводить синхронизацию локальных копий с серверными подлинниками без всяких сообщений в почтовом ящике?

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

ИМХО, тут была бы очень кстати индикация изменённых файлов посредством цвета, курсива или стрелочки какой ни будь. Кстати, что-то мне так подспудно кажется, что ныне на такое не способен даже NX верхом на TCE.

Может и не способен. Я не знаю. А это мы делали для изобретателя лет 7 назад. Тоже было и для SE, SW, NX. Хотя почему было ? Оно и есть - только не надо никому.

#pdm #plm #проектирование #кооперация #cad #обсуждение #архив