О выборе линейки САПР

На вчерашнем заседании Русского отделения INCOSE в кулуарах произошло обсуждение того, какие критерии должны быть у хорошего САПР. Выяснилось, что любая линейка САПР должна рассматриваться по двум главным аспектам: -- поддержка всех дисциплин системной инженерии (инженерия требований, инженерия системной архитектуры и т.д.). -- поддержка всех инженерных специальностей (и хорошим примером тут являются сооружение из тяжелого бетона, нашпигованного металлом. САПР-поддержка для этого случая тем и интересна, что традиционно работа с тяжелым бетоном была весьма далека от дисциплин системной инженерии, и демонстрация одновременной поддержки дисциплин системной инженерии и работы с тяжелым бетоном служит тяжелым нагрузочным тестом для всех поставщиков САПР). В кулуарах к кулуарам мы с vvagr сформулировали следующий набор вопросов, которые нужно задавать поставщикам САПР. Ответы на эти вопросы крайне разные для разных поставщиков, а у поставщиков крайне разные для разных версий их систем: 1. Поддержка специальной инженерии: все САПР хорошо поддерживают 3D-картинки или принципиальные схемы (например, P&ID). Но каждый элемент для той или иной специальной инженерии (труба, швеллер, да и сам бетон) имеют какую-то модель данных, которой для вашей специальной инженерии просто может не быть. Вопрос: -- модели данных каких элементов наличествуют в САПР "из коробки"? -- модели данных каких элементов можно купить? -- модели данных какого вида можно "настроить"? -- есть ли какие-то доступные каталоги? Есть ли готовые "настройки" для рабочих мест специальной инженерии? (трубы, HVAC, бетон, электрика...). 2. Поддержка дисциплин системной инженерии: -- поддерживается ли в рамках одного рабочего места (без дополнительной настройки) трассировка "по клику мышкой" между требованиями (заинтересованных сторон, требований к системе), логической архитектурой, физической архитектурой, имитационными моделями, рабочим проектом, закупками (практика соглашений), проектом-project? -- есть ли поддержка "оценочного дела" (для требований, архитектуры, "обоснование безопасности" и т.д. -- claims, arguments, evidence). 3. Поддержка процесса системной инженерии: -- поддерживается ли ситуационная инженерия методов? Насколько удобно описываются процессы-workflow (процесс известен и доступен "из коробки"; процесс неизвестен, ибо повторяет процесс какого-то давнего заказчика; процесс гибко настраиваем -- но без настройки ничего не работает) -- есть ли поддержка проектной/менеджерской группы описаний (контрольные точки, пересмотры и т.д.). 4. Интеграция данных жизненного цикла: -- в каждом отдельном САПР своя модель данных ("схема") и база данных для этой модели, а "общий САПР" делается длительной "настройкой" каждого отдельного САПР по схеме "каждый с каждым" для отдельных случаев. -- то же, что выше, но есть общая модель данных (общая "схема") и общая база данных (репозиторий), куда помещается оговоренная часть информации из отдельных САПР при ее "публикации" -- модель данных ("схема") для всех рабочих мест одна и та же, база данных общая. Особых проблем по интеграции между разными рабочими местами поэтому нет. -- подключение дополнительного софта по ISO 15926 5. Какие чертежи выдаются в производство и на стройку? -- выдаются не чертежи, а что-то иное (тогда как это иное может быть использовано в наших краях?) -- выдается полный комплект чертежей по ГОСТ, никаких проблем с отечественными надзорами и подрядчиками -- выдается полный комплект чертежей по каким-то иностранным стандартам, и требуются уговоры контрагентов для их использования.