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