Ведение архива проектов (Страница 1 из 2)

Имеются системы инженерного документооборота и администрирования проектов и там есть такая функция.
На крупных предприятиях используется.
Посмотрите информацию на сайте csoft.ru

Это конечно так, но через незначительное время в "куче" версий разобраться будет невозможно. По опыту знаю - человек в отпуске - ищешь его чертежи, а там... неизвестно какой файл "конечный". Без контроля версий и доступа на изменение порядок маловероятен.

С сервером работать надо.Дерево проекта должно храниться там, архив тоже. Большой объем данных хранить на локальных машинах - позавчерашний день.
И грамотный системный администратор нужен, не мальчик-"машинист" , серьезный человек знающий специфику работы в САПР.

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

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

Систему документооборота можно купить. За большие деньги. Причем на пиратском диске ее не возьмешь, а стоить она будет подороже Автокада.

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

Делать надо примерно так (чтобы без больших затрат поэтапно получать результаты:

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

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

На первом этапе можно просто иметь комментированные файлы. Но далее надо создавать базу данных архива.

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

Реализуется не так уж сложно. Но работы много.

В дальнейшем поиск чертежей не только по реквизитам и ключевым словам, но и по изобржению. Это совсем сложно. Это и дает дороговизну. Можно обойтись.

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

Для начала можно просто попробовать навести порядок на соей машине, в своей группе. Не надо бояться изобретать велосипед. Если бы эти "велосипеды" были уже на потоке, то да, а если изобретаете второй или десятый велосипед в мире, то стесняться не надо

> Западаев
Андрей
>ВСЕ БУДУ РАСКЛАДЫВАТЬ ПО ПАПОЧКАМ И ЗАПОМИНАТЬ!!!!!!
Просто запоминать - не получится. "Запоминать" надо в базе данных (формат не важен) с возможностями поиска, предоставляемыми БД. Визуально БД должна имитировать древовидныю структуру документов. При этом физическое расположение файлов не имеет особого значения.

>> конструктор не должен думать что и куда положить. Он должен выполнять прямую свою работу

Типичное заблуждение. Не надо думать, куда положить можно только тогда, когда и не надо брать. То есть проще вообще не сохранять файлы. Конструировать ради процесса. Быть правым ("не мое дело"), но "иногда" находить файлы.

Теоретически, конечно, думать об этом должны другие люди. Может быть у НИХ это так и есть. Хотя многие из тех, кто уехал, подтверждают тезис М.Задорнова - "Ну, тупые!!". У них, может, и включает компьютер специальный негр.

В наших условиях конструктор не должен надеяться на неких программистов из "отделов САПР". Не будет от них толку. Для большинства из них пользователи - досадное недоразумение, отвлекающее от более приятных занятий и мыслей. Разумеется, бывают и исключения).

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

>найдя известную систему

Не так-то просто ее "найти".  Имеется ввиду, что не в прайсах CS. (Кстати, такие системы и пригодны для аренды и долгосрочного внедрения. Тут заказчик не продинамит).
А кроме "найти", надо еще и пощупать хорошенько. И если даже найдете ПОСЛЕ накопления своего опыта, то и это неплохо. Опыт-то останется у вас, а вот деньги надо отдавать дяде. Вернее "анклу".  А у него новая версия - "Теперь без сахара! Теперь ваши ноги будут гладкими!"

> Западаев
Андрей
Конечно, понедельник... Жара, одновременно наводнение и прочее. Побалагурим:

>1) БД не запоминается , а формируется

Потому я "запоминается" и пишу в кавычках. Я ведь не пишу технически точную постановку задачи

>2) С точки зрения построения реляционных БД ее структура имеет ...
Конечно имеет. "Крайне важное значение". Бесспорно. Я про это и не упоминаю. Пишу "формат не важен". То есть может быть и Interbase, и MSSQL, и (ужас!) текстовый формат.
А вот термин "СУБД" многие понимают по разному. Для некоторых СУБД - только что-то дорогое, не хуже Oracle. Для некоторых - и FoxPro или Access тоже СУБД. В нашем случае это должна быть специализированая система, ориентированная на работу с документами, причем содержащими графику.

>3) Древовидную структуру "имитирует " не БД, а интерфейс БД, хотя такой подход, как мне кажется наиболее правильный со всех точек зрения!

А вот чтобы "имитировать" дерево, должна быть и соответствующая структура таблиц. Обычно это два поля ID и Parent_ID. При наличии таких полей любую базу данных визуально можно представить в виде дерева. В "интерфейсных" элементах.

> 4) Физическое расположение файлов имеет крайне важное значение...
Имею ввиду, что в БД могут быть просто ссылки на файлы, в том числе на "ленту", CD и прочее. И вести эту БД должен весьма ответственный человек.

А последний абзац был про то, что к рекламе надо осторожно относиться. Особенно от "системных интеграторов". У нас на входе их просто охрана не пускает. Про прайсы CS я представления не имею. Имел ввиду, что в этих прайсах, возможно, имеются и системы документоборота. Очень может быть. Но если всем ясно, что такое водка (или Автокад), то с документооборотом сложнее. Желающих привязать лопоухого заказчика именно к своей технологии много.

Но это все треп, мы же понимаем, о чем речь.

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

ввсе таки насколько разные люди бывают в разных форумах и насколько по разному они "балагурят" .
Вот к вопросу о системе качества (искал в яндексе обсуждения на эту тему).
Вот как это понимают в моем родном городе:)
(последние посты не читать! :))
http://www.nn.ru/forum/free/read.php3?thread=14584

> Западаев
Андрей 
Спасибо, а стандарт?

Не хотелось бы о Нижнем Новгороде судить по приведенной ссылке на форум. Она пахнет зоной.

> Западаев
Андрей
Я имел ввиду  "...и нового стандарта", упомянутого ShaggyDoc.

> ShaggyDoc
Благодарю.

По поводу самой примитивной организации хранения КД. Подходит для относительно небольшого объема данных. Я работаю один, для меня это идеально подходит и не требует ни малейших затрат времени, сил и денег. Но легко поддается интерполяции на небольшую группу проектировщиков и чертежников.
Слава богу, сразу, как только начал работать на компьютере, поставил себе целью создать и поддерживать строгую и прозрачную систему хранения данных. Сейчас, когда на винчестере десятки проектов, меня это спасает.
Итак, в Моих документах существует папка Работа. В Работе содержатся папки проектов, объединенные по имени заказчика (скажем, 13Г(Стройгазконсалтинг) содержит все проекты, выполненные для Стройгазконсалтинга). Соответственно, все проекты в этой папке имеют номера, начинающиеся с "13Г..." Проекты для мелких, разовых, заказчиков объединяются по принципу сходства (например, 13Д(Длинномеры), 13К(Колесная техника) и т.д.), дабы не загромождать Работу десятками папок.
Папка каждого проекта имеет именем полный номер проекта, иногда с добавлением краткого описания (скажем, 13Г3.00.00.000СБ(диафрагмы жесткости)).
Каждый файл проименован таким же образом (например, 13Г3.00.00.000СБ.dwg, 13Г3.00.00.000.doc, 13Г3.00.00.000РР.doc и т.д.). Каждая сборка - папка, содержащая все файлы документов, входящих в сборку и подпапки подсборок. Строго по ЕСКД.

Не знаю специфику деятельности Олега, думаю, что у него связано с машиностротельными чертежами, но мне такая структура не очень подходит. Да и для обработки программой его структура не очень подходит. Гораздо лучше, на мой взгляд, было-бы избавиться от директорий "заказчик". Здесь мне кажеться и выдумывать ни чего не надо, каждый проект имеет свой номер (шифр), каждый раздел проета имеет так-же свой идентификатор, каждому чертежу присваивается свой шифр... вот такой пример для строительной проектной организации:
имя файла 025461-04-AS-01.dwg
025461 - номер проекта; 04 - номер подъобъекта (очередь строительства); AS - раздел проекта (АС - архитектурно-строительный); 01 - номер листа (чертежа). Кстати имя файла чертежа должно совпадать с шифром чертежа, который общепринят для чертежей в проектной организации. То есть если чертеж 051224-ГП лист 1, то и имя файла соответственно будет 051224-GP-01.dwg.
Далее дерево каталогов: 1 уровень - c:\work, 2 уровень - \025461, 3 уровень \025461-04 (дальше можно продолжать по необходимости, я лично остановился на 3 уровне, мне больше не надо) Данная система полностью исключает совпадение имен фалов разных проектов.
Согласен, что информативность, которую несут имена файлов,  в такой системе неполноценная. Вот тут и надо писать базу данных, будь она в экселе или на языке программирования баз данных.
А если есть перспектива работать с забугорными фирмами, то лучше было-бы если все имена файлов имели только цифры.
:) Каждый день встречаюсь с файлами типа plan.dwg. Разве можно так работать... :)