Пользователь
sspchram
Комментарии в проектах
Для ГОСТа, нацеленного – согласно п.1.1 – на информационное моделирование объектов строительства, более чем желательно было бы понять, как он соотносится с международными стандартами ИСО серии ISO 19650 (5 частей уже опубликовано. 6-я готовится) по вопросам информационного моделирования зданий (Building Information Modeling, BIM).
17 января 2023 в 14:05
В Содержании в заголовке главы 8 имеется опечатка. Замените "смеещенности" на "смещенности".
22 сентября 2022 в 09:55
В тексте и в оглавлении пропущен заголовок 5-го раздела "5. Требования к соответствию" (в оригинале Requirements for conformance)
21 сентября 2022 в 12:14
Неужели нельзя было название стандарта корректно перевести на русский язык?
С английского «Sustainability in buildings and civil engineering works» следовало бы перевести, например, как «Социально-экономическая и экологическая жизнеспособность зданий и сооружений» - вместо совершенно непонятного «устойчивого развития» зданий (они сами себя, что ли, развивают?!).
12 сентября 2022 в 13:14
ГОСТ Р (проект, первая редакция). Менеджмент риска. Риск-аппетит и ключевые индикаторы риска
В документе нет определения «риск-аппетита», поэтому его трудно использовать автономно. Хотя имеется нормативная ссылка на ГОСТ Р 51897-2021 / ISO Guide 73:2009 «Менеджмент риска. Термины и определения», где такое определение дано в п. 4.7.1.2 - этот буквально точный перевод международного определения требует пояснений, поскольку по-русски он звучит двусмысленно.
В связи с этим предлагается включить в документ определение:
Риск-аппетит (risk appetite) - Величина и тип соответствующего риска, который организация готова поддерживать или достичь. [ГОСТ Р 51897-2021, 4.7.1.2]
Также предлагается пояснить, что когда говорится «поддерживать или достичь», то речь идёт о предельной величине риска, которую организация готова терпеть, не предпринимая действий по его смягчению, или до которой она намерена этот риск понижать.
21 июня 2022 в 11:16
ГОСТ Р ИСО 22095 (проект, первая редакция). Цепочки поставок. Общая терминология и модели
Разработчики стандарта не справились с переводом англоязычной терминологии, переведя два очень разных ключевых термина «цепочка ответственного хранения» (chain of custody) и цепочка поставок «supply chain» - одинаково как «цепочка поставок». В результате искажено даже название документа, а в терминологической части появилась следующая чехарда (при этом определение 3.1.1 стало циклическим):
3.1.1 Цепочки поставок (chain of custody): Процесс, с помощью которого входящий поток и выходящий поток и связанная с ними информация передаются, отслеживаются и контролируются по мере их прохождения через каждый этап соответствующей цепочки поставок (!!).
3.2.1 Цепочка поставок (supply chain): Серия процессов или видов деятельности, связанных с производством и распределением материала или продукта, которые он проходит от своего источника
С моей точки зрения, одного этого более чем достаточно для того, чтобы отправить документ на переделку без детального обсуждения.
Для справки: Правильный перевод первого из определений следующий:
3.1.1 Цепочка ответственного хранения (сhain of сustody) – процесс, посредством которого исходные материалы (inputs), продукция (outputs) и ассоциированная с ними информация передаются, мониторятся и контролируются по мере их движения через каждый этап соответствующей цепочки поставок.
16 февраля 2022 в 14:53
Уважаемый Администратор,
Посылаю отзыв "по форме"
С уважением,
Н.А.Храмцовская
8 февраля 2022 в 10:56
Уважаемый Администратор,
Посылаю файл с замечаниями
26 января 2022 в 11:05
К сожалению, уважаемые авторы проекта, судя по всему, знакомы лишь с экономическими концепциями социалистического периода :)
В описании раздела «Обоснование выбора технического решения для реализации» авторы документа, как мне кажется, необоснованно исходят из предположения, что решение о выборе принимается исключительно на основании совокупной стоимости владения (даже не возврата на инвестиции!).
Такой несовременный подход не соответствует реальной практике, поскольку не учитывает не только ожидаемой экономической отдачи, но и целого ряда других ключевых аспектов – например, заведомо более дорогое решение вполне может быть выбрано как ввиду того, что именно оно открывает принципиально новые перспективные возможности для деловой деятельности, не поддерживаемые более дешёвыми вариантами, так и из социальных соображений (скажем, это может быть выбор в пользу экологически-дружественного варианта, иди же варианта, обеспечивающего бóльщие инвестиции и большее количество рабочих мест для местного населения).
23 января 2022 в 12:16
Раздел «Требования к электронным документам» Приложения 2 свидетельствует о некомпетентности разработчиков стандарта, не имеющих абсолютно никакого представления о том, в каких системах и форматах создается и поддерживается реальная исполнительная документация, каков объём этих объектов и т.д.
Разработчики просто переписали хорошо известные, давно уже морально устаревшие требования Росархива, сформулированные в конце прошлого века для организационно-распорядительной документации того времени…
Данного раздела вполне достаточно, чтобы рекомендовать Техническому комитету начать разработку проекта стандарта заново, с заменой коллектива разработчиков.
22 сентября 2021 в 11:35
Переводчики во Введении (предпоследний абзац) и в Области применения (1-й абзац) - возможно, и далее по тексту – давно уже ставшее привычным в российской литературе слово«политики» (policies) переводят как «стратегия» или «стратегии», что вовсе не одно и то же. Политика – это внутренний нормативный документ, определяющий принципы и правила ведения определенной деятельности, который охватывает не только стратегические вопросы, но и вопросы организационные, правовые, образовательные, оперативные и т.д. Стратегии, в сравнении с политиками, это более высокоуровневые документы, адресованные руководству высшего звена.
Самое неприятное, что переводчики при этом непоследовательны: например, в 5.1, абзац 1 (и во многих других местах), policies переведены как «политики». В результате возникает путаница.
28 июня 2021 в 14:48
В стандарте ISO/IEC 19941:2017 «Информационные технологии – Облачные вычисления – Интероперабельность и перемещаемость» (Information technology — Cloud computing — Interoperability and portability), см. https://www.iso.org/standard/66639.html и https://www.iso.org/obp/ui/#!iso:std:66639:en , рассматриваются 5 аспектов интероперабельности.
Эта же модель используется в стандарте ISO/IEC 21823-1:2019 «Интернет вещей – Интероперабельность систем интернета вещей – Часть 1: Концепция» (Internet of things (IoT) — Interoperability for IoT systems — Part 1: Framework), см. https://www.iso.org/standard/71885.html и https://www.iso.org/obp/ui/#!iso:std:71885:en
В проекте ГОСТ Р из них фактически упомянут лишь один. В связи с этим рекомендуется подумать о включении терминов, эквивалентных следующим:
- Transport interoperability
- Syntactic interoperability
- Semantic data interoperability
- Behavioural interoperability
- Policy interoperability
23 ноября 2020 в 14:35
Традиционно для переводчиков стандартов систем менеджмента, использован некорректный перевод термина records, который нужно переводить как «документы, документация». Попробуйте сравнить, как читаются соответствующие разделы (6.2.5, 6.4.13, 6.6.2, 7.1.8, 7.2.1.5, 7.2.2.4, 7.3.3, 7.4.2, 7.5, 7.8.1.2, 7.10.2 и др. ) при различном переводе, и Вы увидите, что несколько странный/заумный текст сразу превращается, в общем-то, в констатацию прописных истин :)
И, - хотя этот аргумент никогда не впечатлял коллег из СМК, - всё же напомню, что в законодательстве и судебной практике РФ «записей» (в используемом в тексте значении) нет, а есть одни лишь «документы».
23 ноября 2018 в 18:15
П.5.1.4, предложение 2. Лишнее слово в тексте «Предпочтение отдается предпочтение новым результатам». Следует писать «Предпочтение отдается новым результатам»
П.5.1.7, предложение 1. Грамматическая ошибка – «не существенные», правильно – «несущественные».
П.5.1.8, предложение 1. Судя по всему, опечатка – написано «в печатном аналоге», следует писать «о печатном аналоге»
П.5.3.7. Повтор уже сказанного в п.5.2.12, данный пункт следует убрать.
24 октября 2017 в 16:40
К разработчикам стандарта есть следующие вопросы:
- Зачем разрабатывать российский ГОСТ при наличии аналогичного международного стандарта ISO 37001:2016 «Системы менеджмента борьбы со взятками – Требования и руководство по применению» (Anti-bribery management systems - Requirements with guidance for use) – что вроде бы противоречит установленным в РФ принципам стандартизации, да и здравому смыслу тоже? Россия адаптирует стандарты всех прочих систем менеджмента, почему именно в данном случае появилось желание проявить самодеятельность?
- Почему, списывая из ISO 37001:2016, авторы не считают нужным сослаться на него хотя бы в Библиографии?
- Почему авторы не считают нужным определить ключевой термин «коррупция»?
26 января 2017 в 12:55
В проекте всерьёз не затронут один из ключевых вопросов о том, чем является информационная модель в правовом плане - это просто рабочие материалы, или же юридически-значимый документ? Если это юридически-значимый документ, то следовало бы поговорить об ответственности за полноту и точность модели, о мерах по подтверждению, поддержанию и доказыванию её целости и аутентичности.
Лишь в п.6.7.5 (в котором, кстати говоря, неверна структура предложения- «Порядок подготовки ... листов проектных документов ... электронными подписями (!)») упомянута возможность использования электронных подписей в формулировке, допускающей, например, использование простых электронных подписей (возможно, так и задумано, но это может оказаться и ляпом).
29 августа 2016 в 15:45
С моей точки зрения, проект «Порядок и условия применения международных стандартов, региональных стандартов, межгосударственных стандартов и стандартов иностранных государств» очень ярко показывает, что руководство Росстандарта плохо понимает, в каком мире живёт. Напомню – речь идёт о стандартах, т.е. документах, которые в принципе, по закону, применяются на добровольной основе. Если говорить попросту, это методические документы, которые каждый волен использовать по собственному усмотрению, вне зависимости от того, стоит на них «штампик» Росстандарта или нет, действующие они или отмененные. Их применение ограничено исключительно рамками закона, и ничем больше. Более того, организация вполне может воспользоваться стандартами, не ссылаясь при этом на первоисточники – ну и что ей за это будет? :) Даже интересно, много ли найдётся желающих пройти описанную в проекте «Порядка» дремучую и непонятно кому нужную бюрократическую процедуру...
К слову сказать, качество многих «проштампованных» Росстандартом переводов зарубежных стандартов низкое, так что ведомству сначала бы стоило подумать о том, как это качество контролировать.
13 апреля 2016 в 12:19
Например, "оптически считываемые носители данных"
4 марта 2016 в 17:32
В целом качество русского языка оставляет желать лучшего. Складывается впечатление, что выложен сырой «технический» перевод с английского, не прошедший редакторской правки.
П.3.1.1 Термин «сбор» представляется неудачным, лучше использовать термины «набор», «коллекция» и т.п.
П.3.1.2, 1-й параграф: Не удалена лишняя строка текста на английском языке.
П.3.1.2, Примечание 1: Английский текст «A knowledge model consists of a number of expressions of facts about a concept, each of which expressions expresses something that can be the case. Those expressions should comply with the guidelines in this standard.» переведен не слишком удачно как «Модель знаний состоит из определенного количества выражений факта концепции (?), каждое из которых выражает что-то, что может являться случаем (?!). Эти выражения должны соответствовать стандарту.».
Предлагается вариант: «Модель знаний состоит из ряда представлений фактов о понятии, каждое из которых отражает определенный аспект данного понятия и должно соответствовать приведенным в настоящем стандарте рекомендациям».
Переводчику следует обратить внимание на типовое выражение «to be the case», означающее «иметь место», а не «являться случаем».
П.3.1.2, Примечание 2. Опечатка «понятиеов». В целом перевод данного абзаца неудачен – непонятен его смысл, потеряно имеющееся в оригинале слово “typically” …
П.3.1.3. Пункт сложный, и его перевод надо переработать таким образом, чтобы получившийся текст на русском языке не был непонятным набором слов, как сейчас.
П.3.1.4 Предлагается вариант «Определение – представление понятия в виде описания, позволяющего дифференцировать его от других взаимосвязанных понятий» (вместо «Определение (definition) – представление понятия в виде описательных утверждений, служащее для отличия этого понятия от других, с ним связанных»).
П.3.1.6. Избыточно буквальный перевод на корявый русский язык, как мне кажется, в итоге приводит к потере смысла.
П.3.1.12. Вместо «Уникальный идентификатор - роль символьной строки при использовании однозначной ссылки на концепт или индивидуальный объект» (я не понимаю этого набора слов!), предлагается вариант «Уникальный идентификатор – символьная строка, используемая в качестве однозначной ссылки на понятие, взаимосвязь или отдельную сущность»
П.3.1.20 «Цель (objective) – роль состояния, которая должна быть достигнута, или которую следует предотвратить» - кто-нибудь и правда понимает, что здесь сказано?!
13 января 2016 в 16:29
Первое же слово в разделе 2: Термин record в правовом и документоведческом контексте переводится как "документ" (как вариант, "документированная информация"), а не как "запись" (замечу для справки, что законодательство РФ никаких "записей" не знает). Познакомиться с таким толкованием данного термина можно в ГОСТ Р ИСО 15489-1-2007 "Управление документами".
Термин "запись" вполне уместен, пока речь идёт о формате фиксации информации в базах данных. Если, однако, затрагиваются вопросы соответствия законодательно-нормативным и иным требованиями, желательно подчеркнуть документированность информации.
27 декабря 2015 в 15:27
На стр.44 подпись под рис.18 желательно дать в редакции "Порядок нумерации углов" (взамен режущей глаз "конвенции").
27 декабря 2015 в 14:47
NORMACS писал(а): Заполнять форму просят разработчики, чтобы они могли обработать замечания корректно. Все поданные по форме замечания они действительно рассматривают и обрабатывают.
Как мне кажется, у Вас несколько романтическое видение этого процесса :) Как человек, воюющий «по обе стороны баррикад» и, в роли разработчика стандартов, отвечающий на замечания, могу сказать: когда есть желание исправить свои ошибки или найти консенсус с представителями иных точек зрения, особой нужны в форме нет, если замечание сформулировано ясно (да ещё даны предложения по устранению). К сожалению, на практике «рассмотрение и обработка» большинства поданных по форме содержательных замечаний сводятся к проставлению в последней колонке слова «Отклонить». Исключения бывают, но на то они и исключения :)
Но всё-таки: зачем держать веб-форму на сайте, если разработчикам удобнее получать отзывы «по стандартной форме»? :) [это вопрос "на подумать", на который можно не отвечать; я ведь понимаю, что у Вас есть порядок работы сайта, который Вы обязаны соблюдать]
23 января 2023 в 10:40