О методическом пособии по созданию цифровых требований (часть 1/2)
"НИЦ ЦПС" по заказу ФАУ "ФЦС" разработал методическое пособие по созданию цифровых требований для проверки ЦИМ. Мы не можем пройти мимо этого документа, так как направляли в ФАУ "ФЦС" наши комментарии по нему, но они остались без ответа. Проанализируем документ и обозначим некоторые вопросы.
Сразу обозначим, что создавать формат для требований без привязки к формализованной схеме данных - это как писать правила дорожного движения, не зная, какие бывают машины, дороги и знаки. Здесь предполагается ввести свой «язык» описания проверок, игнорируя тот факт, что модели уже давно представляются по стандарту IFC (ГОСТ Р 10.0.02-2019).
К чему это приведёт на практике?
🔴 Семантический разрыв. Требования будут описывать одни сущности и связи, а данные в IFC-модели будут содержать другие. Глухой телефон.
🔴 Эпоха коннекторов. Вместо следования единому стандарту каждой системе автоматизированной проверки придется писать собственный "переводчик" с языка методики. Это приведет к двойным трудозатратам для всех: и для составителей требований, и для разработчиков ПО.
🔴 Методика делает ставку исключительно на КСИ. Но строительная отрасль им не ограничивается: используются МССК, отраслевые классификаторы РЖД и т.д. Привязка только к КСИ не только игнорирует это, но и делает всю систему заложником его частых обновлений (4+ раза в год!): все созданные ранее правила проверок придется постоянно актуализировать из-за возможной смены кодов.
🔴 Игнорирование IFC. Самое тревожное - подход заточен только под проверку атрибутов ("параметров"). Он игнорирует мощь объектно-ориентированной модели IFC как онтологии: типизированные связи, наследование свойств - не слышали?
Скатываясь к примитивному способу проверок, их ценность просто потеряется. И тогда зачем это всё?
Создавать изолированный язык для проверок - это методологический тупик. Мы рискуем получить стройный, но, к сожалению, бесполезный реестр требований. Проверка моделей на эти требования не будет иметь большой значимости и смысла.
Далее напишем - как попытаться всё поправить.
@IFC_ru
@IFC_club
"НИЦ ЦПС" по заказу ФАУ "ФЦС" разработал методическое пособие по созданию цифровых требований для проверки ЦИМ. Мы не можем пройти мимо этого документа, так как направляли в ФАУ "ФЦС" наши комментарии по нему, но они остались без ответа. Проанализируем документ и обозначим некоторые вопросы.
Сразу обозначим, что создавать формат для требований без привязки к формализованной схеме данных - это как писать правила дорожного движения, не зная, какие бывают машины, дороги и знаки. Здесь предполагается ввести свой «язык» описания проверок, игнорируя тот факт, что модели уже давно представляются по стандарту IFC (ГОСТ Р 10.0.02-2019).
К чему это приведёт на практике?
🔴 Семантический разрыв. Требования будут описывать одни сущности и связи, а данные в IFC-модели будут содержать другие. Глухой телефон.
🔴 Эпоха коннекторов. Вместо следования единому стандарту каждой системе автоматизированной проверки придется писать собственный "переводчик" с языка методики. Это приведет к двойным трудозатратам для всех: и для составителей требований, и для разработчиков ПО.
🔴 Методика делает ставку исключительно на КСИ. Но строительная отрасль им не ограничивается: используются МССК, отраслевые классификаторы РЖД и т.д. Привязка только к КСИ не только игнорирует это, но и делает всю систему заложником его частых обновлений (4+ раза в год!): все созданные ранее правила проверок придется постоянно актуализировать из-за возможной смены кодов.
🔴 Игнорирование IFC. Самое тревожное - подход заточен только под проверку атрибутов ("параметров"). Он игнорирует мощь объектно-ориентированной модели IFC как онтологии: типизированные связи, наследование свойств - не слышали?
Скатываясь к примитивному способу проверок, их ценность просто потеряется. И тогда зачем это всё?
Создавать изолированный язык для проверок - это методологический тупик. Мы рискуем получить стройный, но, к сожалению, бесполезный реестр требований. Проверка моделей на эти требования не будет иметь большой значимости и смысла.
Далее напишем - как попытаться всё поправить.
@IFC_ru
@IFC_club