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