Как вам удалось сертифицировать ПО без внедрения БРПО?
Выдержка из Положения по сертификации ФСТЭК России № 55. п. 47. Сертификационные испытания включают: "...проверку организации производства средства защиты информации, предусматривающую оценку соответствия работ по изготовлению средства защиты информации.."
"При проверке организации производства программных и программно-технических средств защиты информации проверяется внедрение заявителем процедур безопасной разработки программного обеспечения в соответствии с требованиями по безопасности информации, на соответствие которым проводятся сертификационные испытания."
Подскажите, пожалуйста, пример модели такой камеры (которую можно купить) в уличном исполнении. Всё что продаётся в розницу -- это именно видеокамеры с возможностью сделать фото, но не наоборот.
Возможно для специалиста звучит наивно, но почему нельзя сканировать сам вирус SARS-CoV-2, на самом современном оборудовании, в оригинале так сказать ) и выложить скан для изучения? Заморозить его, и быстро под микроскоп, или как это делают с другими вирусами? А то, для не специалиста выглядит как "моделирование на основе предсказания". Возможно отсюда и всякие теории заговора, вроде "этот ваш вирус -- пока только модель, вот когда его выделят, тогда и поговорим" )
Формат файла pdb хранит информацию о каждом атоме.
А как получен этот pdb? Это реальный результат сканирования атомно-силовым микроскопом вируса SARS-CoV-2? Или это тоже результат чего-то моделирования?
Проблема в формата в том, что качество данных в этом формате зависит от человеческого фактора: будь то разработчик софта или специалист который импортирует или экспортирует файл. Т.е. данные зависят от воли, способностей людей, которые оперируют этим файлом.
Файлами оперирует программное обеспечение, а не разработчики стандартов. Таким образом содержимое файлов зависит от ПО и данных пользователей ПО. Бюрократическая защита как раз и нужна, чтобы в стандарт не просачивались идеи от тех, кто не желает изучать стандарт и делать на его основе реализации, но готовы впихивать в него абстрактные сущности, например, под соусом "национальной геометрии", не неся потом за это ответственность.
Должна быть строгая сертификация софтверных продуктов
Любая сертификация ПО — это дорого, особенно для небольших игроков или инди-разработчиков. Я не знаю намеренно ли у вас опущено слово "обязательная", но такая жесткая политика негативно скажется на конкуренции. Сертификация может быть добровольной. Отсутствие сертификата не говорит о плохом качестве реализации ПО, а наличие сертификата не означает, что хорошее качество.
Даже если формат будет идеальным - всё равно будет зависимость качества данных от воли, желания и способностей разработчкиков имплементировать все возможные особенности формата IFC свой продукт.
Т.е. проблема не в формате, и не в держателе стандарта, как представлено в статье, а всё зависит от воли разработчика? Да, это так, и это не зависит от применяемого формата. Если у разработчика нет воли создавать качественне чтение/запись какого-либо формата, то возможность "лоббирования" качества в его ПО не добавит. Надо работать.
Опять видится противоречие тексту статьи. Всегда есть возможность создавать IFC без параметрической геометрии (например IfcTessellatedItem). Если в этом была цель, то она уже достигнута, никакого "лоббирования" для этого не нужно, это максимально простое использование части стандарта IFC, доступное любому вендору, без какого либо членства в buildingSMART.
Прежде чем отстраивать "национальную геометрию" желательно освоить применение уже существующей геометрии. IFC описывает множество геометрических представлений, достаточных для решения подавляющего большинства задач любого региона. Кто-то развивает и создаёт, а кто-то рассуждает о гипотетической возможности, гипотетической страны добавлять гипотетическую национальную геометрию. Эдак точно ничего никуда не добавить.
Стандарт IFC он для разработчиков софта. Они разбираются в его устройстве (при желании) и делают софт. Наверняка, они тратят свои ресурсы на реализацию чтения/записи IFC как раз потому, что он используется. Поэтому и формат IFC развивается.
Т.е. редкие элементы или классы, используемые в менее богатой стране (неспособной продвигать своих производителей через buildingSMART) не войдут в официальную классификацию IFC и будут распознаваться всеми программами CAD только через дополнительный “костыль” - IfcBuildingElementProxy.
На то они и "редкие классы". И IfcBuildingElementProxy хорошо решает свою задачу.
Но если работа с данными ведётся между системами, за которыми стоят разные разработчики, то из-за проблемы объектно-ориентированного подхода и “небольших особенностей” формата IFC корректно экспортировать, отстроить данные по геометрии и передать их корректно через формат IFC без трудоемкого ручного маппинга (соответствия) всех свойств UserDefined и геометрии в IfcBuildingElementProxy не получится.
Применение IfcBuildingElementProxy никак не мешает использовать классы точного описания геометрии. Для IfcBuildingElementProxy доступны GeometricCurveSet, SurfaceModel, SweptSolid, Brep, BoundingBox, MappedRepresentation.
К сожалению, не все элементы или классы добавляемые европейскими и азиатскими специалистами в IFC используются при строительстве в других странах мира. Т.е. редкие элементы или классы, используемые в менее богатой стране (неспособной продвигать своих производителей через buildingSMART)
Участвуют и европейские специалисты, и азиатские, и они смогли консолидировать усилия. Было бы странно, если они вместо этого, за свои деньги, начали разрабатывать классы для "менее богатых стран", которые и не просят их об этом.
Главный факт, неупомянутый в статье, что крупнейшие строительные компании Германии IFC компании не используют, хотя в Германии лежат корни IFC.
"Главный факт" противоречит самой статье:
Активными разработчиками и основными бенефициарами идеи IFC сегодня являются европейские вендоры, стремящиеся переломить гегемонию Autodesk над данными, и азиатские компании
Т.е. люди активно разрабатывают и поддерживают открытый формат, и даже стремятся переломить гегемонию Autodesk.
Аналогичная проблема с FreeCAD, который полностью зависит от ядра OpenCASCADE.
«OpenCASCADE is the heart of the geometrical capabilities of FreeCAD», но OpenCASCADE в рейтинг решили не добавлять.
The Mono engine is updated to version 4.9.4, including parts of the
Windows Presentation Foundation (WPF) framework. https://www.winehq.org/announce/5.0
Так я привёл цитату в ред. Приказа ФСТЭК России N121 от 05.08.2021, а сегодня 2023 год.
Как вам удалось сертифицировать ПО без внедрения БРПО?
Выдержка из Положения по сертификации ФСТЭК России № 55.
п. 47. Сертификационные испытания включают: "...проверку организации производства средства защиты информации, предусматривающую оценку соответствия работ по изготовлению средства защиты информации.."
"При проверке организации производства программных и программно-технических средств защиты информации проверяется внедрение заявителем процедур безопасной разработки программного обеспечения в соответствии с требованиями по безопасности информации, на соответствие которым проводятся сертификационные испытания."
А как же внедрение методик Разработки Безопасного Програмного Обеспечения (РБПО)? Говорят, что внедрение РБПО, сильно упрощает процедуру сертификации.
Подскажите, пожалуйста, пример модели такой камеры (которую можно купить) в уличном исполнении. Всё что продаётся в розницу -- это именно видеокамеры с возможностью сделать фото, но не наоборот.
есть Renga:
https://rengabim.com/
Возможно для специалиста звучит наивно, но почему нельзя сканировать сам вирус SARS-CoV-2, на самом современном оборудовании, в оригинале так сказать ) и выложить скан для изучения? Заморозить его, и быстро под микроскоп, или как это делают с другими вирусами? А то, для не специалиста выглядит как "моделирование на основе предсказания". Возможно отсюда и всякие теории заговора, вроде "этот ваш вирус -- пока только модель, вот когда его выделят, тогда и поговорим" )
А как получен этот pdb? Это реальный результат сканирования атомно-силовым микроскопом вируса SARS-CoV-2? Или это тоже результат чего-то моделирования?
Файлами оперирует программное обеспечение, а не разработчики стандартов. Таким образом содержимое файлов зависит от ПО и данных пользователей ПО. Бюрократическая защита как раз и нужна, чтобы в стандарт не просачивались идеи от тех, кто не желает изучать стандарт и делать на его основе реализации, но готовы впихивать в него абстрактные сущности, например, под соусом "национальной геометрии", не неся потом за это ответственность.
Любая сертификация ПО — это дорого, особенно для небольших игроков или инди-разработчиков. Я не знаю намеренно ли у вас опущено слово "обязательная", но такая жесткая политика негативно скажется на конкуренции. Сертификация может быть добровольной. Отсутствие сертификата не говорит о плохом качестве реализации ПО, а наличие сертификата не означает, что хорошее качество.
Т.е. проблема не в формате, и не в держателе стандарта, как представлено в статье, а всё зависит от воли разработчика? Да, это так, и это не зависит от применяемого формата. Если у разработчика нет воли создавать качественне чтение/запись какого-либо формата, то возможность "лоббирования" качества в его ПО не добавит. Надо работать.
Опять видится противоречие тексту статьи. Всегда есть возможность создавать IFC без параметрической геометрии (например IfcTessellatedItem). Если в этом была цель, то она уже достигнута, никакого "лоббирования" для этого не нужно, это максимально простое использование части стандарта IFC, доступное любому вендору, без какого либо членства в buildingSMART.
Прежде чем отстраивать "национальную геометрию" желательно освоить применение уже существующей геометрии. IFC описывает множество геометрических представлений, достаточных для решения подавляющего большинства задач любого региона. Кто-то развивает и создаёт, а кто-то рассуждает о гипотетической возможности, гипотетической страны добавлять гипотетическую национальную геометрию. Эдак точно ничего никуда не добавить.
Стандарт IFC он для разработчиков софта. Они разбираются в его устройстве (при желании) и делают софт. Наверняка, они тратят свои ресурсы на реализацию чтения/записи IFC как раз потому, что он используется. Поэтому и формат IFC развивается.
На то они и "редкие классы". И IfcBuildingElementProxy хорошо решает свою задачу.
Применение IfcBuildingElementProxy никак не мешает использовать классы точного описания геометрии. Для IfcBuildingElementProxy доступны GeometricCurveSet, SurfaceModel, SweptSolid, Brep, BoundingBox, MappedRepresentation.
Участвуют и европейские специалисты, и азиатские, и они смогли консолидировать усилия. Было бы странно, если они вместо этого, за свои деньги, начали разрабатывать классы для "менее богатых стран", которые и не просят их об этом.
"Главный факт" противоречит самой статье:
Т.е. люди активно разрабатывают и поддерживают открытый формат, и даже стремятся переломить гегемонию Autodesk.
Робот сам логинится в систему? От какой учётки? Или за него подключается пользователь с рабочего места, а потом запускает робота?
О каких именно "много ограничений" SQLite вы пишите? Желательно в сравнении с аналогичными величинами другой СУБД
«OpenCASCADE is the heart of the geometrical capabilities of FreeCAD», но OpenCASCADE в рейтинг решили не добавлять.
И вот ещё приятно удивило:
Windows Presentation Foundation (WPF) framework.
https://www.winehq.org/announce/5.0