Идентификатор программного обеспечения что это

Идентификатор программного обеспечения что это

Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу выдаются удостоверения установленного образца.

Программа разработана совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Обзор документа

Приказ Федерального агентства по техническому регулированию и метрологии от 20 октября 2015 г. N 1217 «О внесении изменений в описание типа на системы измерений длительности соединений СИДС CSC3300»

Во исполнение приказа Министерства промышленности и торговли Российской Федерации от 25 июня 2013 г. N 970 «Об утверждении Административного регламента по предоставлению Федеральным агентством по техническому регулированию и метрологии государственной услуги по утверждению типа стандартных образцов или типа средств измерений», зарегистрированного в Министерстве юстиции Российской Федерации 12 сентября 2013 г. N 29940, в связи с обращением ООО «КИА» (входящий от 12 октября 2015 г. N 17052), г. Москва приказываю:

1. Внести в описание типа на системы измерений длительности соединений СИДС CSC3300, зарегистрированные в Федеральном информационном фонде по обеспечению единства измерений, с сохранением регистрационного номера 46366-11 следующие изменения:

1.1. В абзаце первом раздела «Описание средства измерений» после слов «междугородная телефонная станция» дополнить словами: «оконечно-транзитный узел связи подвижной радиотелефонной связи стандартов UMTS, GSM900/1800, LTE. Система измерений длительности соединений СИДС CSC3300 применяется при учете объема оказанных услуг электросвязи операторами связи»;

1.2. После раздела «Описание средства измерений» добавить раздел «Программное обеспечение» следующего содержания:

Метрологически значимая часть ПО системы измерений длительности соединений СИДС CSC3300 и измеренные данные достаточно защищены с помощью специальных средств защиты от непреднамеренных и преднамеренных изменений. Защита ПО от непреднамеренных и преднамеренных изменений соответствует уровню «средний» по Р 50.2.077-2014″;

1.3. Из раздела «Метрологические и технические характеристики» исключить слова:

«Идентификационные данные программного обеспечения приведены в таблице 1

Программное обеспечение обеспечивает необходимую точность средства измерений, исполнительная характеристика составляет 14.

Уровень защиты программного обеспечения от непреднамеренных и преднамеренных изменений соответствует уровню «С» в соответствии с МИ 3286-2010″;

1.4. Раздел «Нормативные документы, устанавливающие требования к системе измерений длительности соединений СИДС CSC3300» изложить в следующей редакции:

«ГОСТ 8.129-2013 «Государственная система обеспечения единства измерений. Государственная поверочная схема для средств измерений времени и частоты»;

1.5. Раздел «Рекомендации по областям применения в сфере государственного регулирования обеспечения единства измерений» исключить.

2. Управлению метрологии (Р.А. Родин) оформить новое описание типа средства измерений.

3. Контроль за исполнением настоящего приказа оставляю за собой.

Обзор документа

Вносятся изменения в описание типа на системы измерений длительности соединений СИДС CSC3300.

Скорректированы разделы «Описание средства измерений», «Метрологические и технические характеристики», «Нормативные документы, устанавливающие требования к системе измерений длительности соединений СИДС CSC3300». Раздел «Рекомендации по областям применения в сфере государственного регулирования обеспечения единства измерений» исключен из описания.

Источник

Категории статей

Дыхание картошки

Овощи продолжают жизненный цикл даже после сбора урожая. Какие процессы идут в картошке? Далее

Грибы против пластика

Ученые проводят исследования по разложению пластика с помощью микроорганизмов и грибов. Далее

Ученые ставят диагноз планете

Cтолько углекислого газа, как сейчас, в атмосфере не было последние 2 млн лет, метана и закиси азота — 800 тыс. лет. Далее

Природный регулятор температуры колибри

Учитывая огромную скорость и частоту крыльев, птицы должны нагреваться до температур, несовместимых с жизнью. Далее

Биоразлагаемые пакеты – вред или польза?

Интересно разобраться, действительно ли такие пакеты не наносят вреда окружающей природе. Далее

Популярные статьи

Польза и вред инфракрасного обогревателя (323801)

Среди электрических обогревателей, которые мы используем в быту, наиболее популярными сейчас становятся инфракрасные нагреватели. Они очень широко рекламируются в Интернете и в газетах. Говорят, что они намного эффективнее масляных радиаторов и тепловентиляторов. Меньше потребляют энергии, не сжигают кислород и т.д. Главное – они совершенно не вредные, никакого отрицательного воздействия на организм человека не оказывают. Далее

Почему горячая вода замерзает быстрее, чем холодная? (209945)

Это действительно так, хотя звучит невероятно, т.к в процессе замерзания предварительно нагретая вода должна пройти температуру холодной воды. Парадокс известен в мире, как «Эффект Мпембы». Далее

Вредно ли разогревать пищу в микроволновке? (199261)

Контролируйте температуру приготовления мяса! (181467)

При приготовлении сырого мяса, особенно, домашней птицы, рыбы и яиц необходимо помнить, что только нагревание до надлежащей температуры убивают вредные бактерии. Далее

451 градус по Фаренгейту, температура возгорания бумаги? (166900)

451 градус по Фаренгейту. Это название знаменитой книги Рэя Брэдбери. На языке оригинала звучит так: ‘Fahrenheit 451: The Temperature at which Book Paper Catches Fire, and Burns’. Действительно ли при этой температуре начинают гореть книги? Далее

Основные разделы

Идентификация программного обеспечения при испытаниях средств измерений в целях утверждения их типа

Сокращения, используемые в тексте: ПО – программное обеспечение; СИ – средство измерений; МХ – метрологические характеристики; БД – база данных; СУБД – система управления базами данных; ГЦИ – государственный центр испытаний.

Единообразный подход к любому ПО любого СИ, принятый в МИ 3286 и МИ 3290, стал камнем преткновения, серьёзно затрудняющим проведение ГЦИ СИ испытаний СИ, в конструкции которых тем или иным образом используется ПО. Критика (особенно действующих нормативных документов) – вещь нерациональная, если не предлагать альтернативу. Исходя из этого убеждения в приведённом ниже тексте я буду стараться воздерживаться от критических замечаний и излагать свою точку зрения на один из аспектов испытаний ПО при утверждении типа СИ – его идентификацию.

Затруднения при испытаниях ПО СИ начинаются с отсутствия в МИ терминов и определений, связанных с классификацией ПО и его окружения. Ниже приведены термины и определения для отсутствующих в МИ понятий, которые кажутся важными для испытаний ПО СИ.

Встроенное ПО СИ – исполняемое ПО, размещённое в запоминающих устройствах, расположенных внутри корпуса СИ.

Интегрированное ПО СИ – встроенное ПО СИ, недоступное для изменений через имеющиеся у СИ интерфейсы.

Загружаемое ПО СИ – встроенное ПО СИ, для которого в процессе эксплуатации СИ предусмотрена возможность записи через имеющиеся у СИ интерфейсы в запоминающие устройства, расположенные внутри корпуса СИ.

Автономное ПО – исполняемое ПО, размещённое вне корпуса СИ.
Примечание:
Определения встроенное ПО СИ, интегрированное ПО СИ, загружаемое ПО СИ, автономное ПО СИ могут использоваться также и в отношении части ПО, например: интегрированная часть ПО СИ, автономная часть ПО СИ.

Аппаратное окружение ПО СИ – комплекс аппаратных средств, с использованием ресурсов которого исполняется ПО СИ.

Программное окружение ПО СИ – комплекс программных средств, с использованием ресурсов которого исполняется ПО СИ.
Примечания:
1. Определения аппаратное окружение ПО СИ и программное окружение ПО СИ могут использоваться также и в отношении части ПО, например: аппаратное окружение интегрированной части ПО СИ, программное окружение автономной части ПО СИ.
2. Термин программное окружение ПО СИ не имеет смысла в случае интегрированного ПО СИ.

Входные данные – информация на входе процесса, в т.ч. исполняемого ПО, алгоритма и т.п.

Конфигурационные данные – изменяемая в процессе эксплуатации СИ информация, влияющая на функционирование исполняемого ПО СИ.

Выходные данные – информация на выходе процесса, в т.ч. исполняемого ПО, алгоритма и т.п.

Поток данных – абстракция, служащая для описания поступающих последовательно во времени входных данных или генерируемых последовательно во времени выходных данных.

Допускаемая нагрузка ПО СИ – объём потока входных данных, не приводящий к изменению функциональных характеристик исполняемого ПО СИ.

Идентификация интегрированного ПО

В качестве одной из причин необходимости идентификации ПО СИ, включая интегрированное ПО, авторы МИ называют потенциальную недобросовестность изготовителя, в силу которой он может попытаться изменить ПО с корыстной целью (видимо, это связано с предыдущей сферой деятельности авторов МИ – игровыми автоматами). Непонятно, почему такое внимание уделено именно ПО СИ – ведь изготовитель ровно с тем же эффектом может изменить схемотехнику СИ и это никак специально не контролируется. Более того, существует практика того, что изготовитель имеет право вносить в конструкцию СИ изменения после подтверждения в рамках «внутренних» типовых испытаний факта того, что вносимые изменения не влекут за собой ухудшения потребительских свойств изделия, в т.ч. МХ СИ. Функционально ПО – это такая же часть конструкции СИ, как, например инструментальный усилитель или АЦП, а лишать производителя права улучшать конструкцию СИ не кажется вполне законным.

Вдобавок, исполняемый код интегрированного ПО СИ часто размещён в заблокированной для чтения памяти программ микроконтроллера, что делает процедуру идентификации ПО бессмысленной с точки зрения контроля за добросовестностью изготовителя. Необходимой и достаточной гарантией того, что интегрированное ПО конкретного СИ аутентично экземпляру ПО СИ, представленного на испытания в целях утверждения типа, является целостность пломбы, ограничивающей доступ к размещённому внутри корпуса СИ аппаратному окружению интегрированного ПО, вкупе с подтверждённым при поверке соответствием МХ СИ установленным требованиям. С этой точки зрения для интегрированного ПО в описании типа средства измерений таблица с идентификационными признаками ПО не должна быть обязательной.

Исключение обязательных требований идентификации интегрированного ПО СИ избавит и изготовителей, и испытателей от бессмысленных «проверок ради проверок», от ненужных затрат средств и времени на реализацию механизмов, которые заведомо бесполезны.

Идентификация загружаемого ПО

Отдельный комплекс проблем связан с идентификацией загружаемого ПО СИ, к которому, в частности, могут быть отнесены компоненты многих систем SCADA. В случае такого ПО на передний план выходят дополнительные вопросы, связанные не столько с самим загружаемым ПО, сколько с его программным окружением, включающем как минимум загрузчик и среду исполнения.

Загружаемое ПО может вовсе не иметь исполняемого кода в привычном понимании, представляя собой набор конфигурационных данных – «проект», который воспроизводит необходимую мнемосхему вместе с параметрами её функционирования. В этом случае в одном массиве или базе данных могут храниться как неизменные данные, для которых может быть каким-либо образом получен цифровой идентификатор типа значения контрольной хэш-функции, так и изменяющиеся во времени данные – результаты измерений и параметры технологического процесса. Для осуществления контроля соответствия такого ПО экземпляру ПО, представленному на испытания в целях утверждения типа СИ, как один из вариантов, может быть проведено тщательное программное разделение, затем созданы специальные программные сценарии для выделения метрологически значимых неизменных данных, преобразования их в непрерывные последовательности и последующего вычисления для этих последовательностей значений контрольной хэш-функции. Одновременно должны быть применены средства идентификации текущей среды исполнения и загрузчика, так как только вместе эти компоненты точно воспроизводят необходимую функциональность ПО СИ. Очевидно, что этот путь требует значительных затрат средств и времени.

Каждый конкретный случай загружаемого ПО СИ должен рассматриваться индивидуально с точки зрения поиска наиболее экономически целесообразного решения задачи подтверждения его целостности и подлинности. Не факт, что идентификационные признаки загружаемого ПО удастся свести в таблицу подобную приведённой в МИ 3290.

Идентификация автономного ПО

При рассмотрении сопровождающего СИ автономного ПО сперва следует изучить вопрос о том, какую задачу это ПО решает. ПО СИ – это часть его конструкции. Независимо от реализованного «внутри» СИ метода измерений, СИ по определению (5.10, 6.2, 8.1 РМГ 29) решает измерительную задачу так, что результат измерений на его выходе – это результат прямых измерений, даже если в дальнейшем проверка этих результатов измерений осуществляется косвенным методом.

Для автономного ПО СИ и программ обработки результатов измерений различаются существенные требования к окружению. В первом случае, как правило, существенны требования как к программному, так и к аппаратному окружению, во втором – только к программному окружению. Во многих случаях, например, когда автономное ПО СИ формирует временные диаграммы управления процессом измерений, аппаратное и программное окружение могут оказывать влияние на функционирование автономного ПО СИ и, как следствие, на МХ СИ. В связи с этим следует отметить, что реализация описанного в ГОСТ Р 8.654 механизма программного разделения автономного ПО СИ на метрологически значимую и незначимую части будет успешной только тогда, когда установлено влияние ПО СИ на МХ СИ при любых разрешённых условиях применения в смысле аппаратного и программного окружения, включая проверку допускаемой нагрузки ПО СИ.

Вариант таблицы с идентификационными признаками ПО СИ, предлагаемый МИ 3286 представляется неудобным, поскольку не связан со структурой автономного ПО СИ и структурой его информационного взаимодействия с окружением.

Идентификация автономного ПО СИ при проведении испытаний в целях утверждения типа СИ должна включать идентификацию аппаратного и программного окружения, например, в виде, изложенном ниже.

Должны быть однозначно установлены требования к ОС, использование которых необходимо для правильного функционирования автономного ПО СИ. Сведения об ОС можно указать в таблице по форме таблицы 1.

Таблица 1 – Сведения об ОС

Должен быть однозначно установлен перечень программ – драйверов устройств, использование которых необходимо для правильного функционирования автономного ПО СИ. Для каждого драйвера устройства желательно указать характеристики, перечисленные в таблице 2.

Таблица 2 – Перечень драйверов устройств

Должен быть однозначно установлен перечень прикладных программ, использование которых необходимо для правильного функционирования автономного ПО СИ. Для каждой прикладной программы необходимо установить (указать) характеристики, перечисленные в таблице 3.

Таблица 3 – Перечень прикладных программ

Примечание:
В большинстве случаев СУБД относятся к прикладным программам, тогда как некоторые хранимые процедуры и таблицы БД могут быть классифицированы как часть автономного ПО СИ и конфигурационные данные, влияющие на результаты измерений. В таком случае возникает необходимость провести разделение метрологически значимой и не значимой частей БД.

После идентификации окружения, необходимо однозначно установить состав автономного ПО СИ с логическим разделением его на модули по функциональному назначению. Для каждого модуля желательно указать характеристики, перечисленные в таблице 4, а также состав в виде перечня физических объектов файловой системы (файлов) со своими собственными характеристиками, как показано в таблице 5.

Таблица 4 – Перечень программных модулей автономного ПО СИ

Таблица 5 – Характеристики программного модуля «Х»

В сопроводительной документации автономного ПО СИ, кроме прочего, должен быть описан способ его конфигурирования. Конфигурационные данные, очевидно, также являются объектом, в каком-то виде (с учётом «изменчивой» природы) подлежащим идентификации и защите от несанкционированного изменения.

Вместо заключения хотел бы предложить заинтересованным специалистам публично высказать здесь своё мнение по вопросам идентификации ПО СИ при испытаниях в целях утверждения типа, а также вопросам проверки защиты ПО СИ и вопросам оценки влияния ПО на МХ СИ.

Источник

Идентификация программного обеспечения

Источник:

«ОБЩИЕ ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ СРЕДСТВ ИЗМЕРЕНИЙ. РЕКОМЕНДАЦИЯ. МИ 2891-2004»

(утв. ФГУП ВНИИМС Ростехрегулирования 07.12.2004)

Смотреть что такое «Идентификация программного обеспечения» в других словарях:

идентификация программного обеспечения — 3.5 идентификация программного обеспечения: Проверка и подтверждение подлинности и целостности программного обеспечения, выраженное в символах (буквах, цифрах), однозначно связанных с программным обеспечением (например, контрольная сумма) [1],… … Словарь-справочник терминов нормативно-технической документации

идентификация — 4.15 идентификация (identification): Процесс последовательного сопоставления полученного изображения лица со множеством изображений лиц для обнаружения похожего изображения; сопоставление 1:N («один ко многим»). Источник … Словарь-справочник терминов нормативно-технической документации

Идентификация слов текста — 7.5. Идентификация слов текста 7.5.1. Процесс идентификации слов текста должен включать: отождествление словоформ одного слова и определение информативных слов текста. При этом может быть необходимо использование интеллектуальных процедур для… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 8.654-2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения — Терминология ГОСТ Р 8.654 2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения оригинал документа: 3.18 алгоритм хэширования: Алгоритм, который сжимает… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р ИСО/МЭК 19785-1-2008: Автоматическая идентификация. Идентификация биометрическая. Единая структура форматов обмена биометрическими данными. Часть 1. Спецификация элементов данных — Терминология ГОСТ Р ИСО/МЭК 19785 1 2008: Автоматическая идентификация. Идентификация биометрическая. Единая структура форматов обмена биометрическими данными. Часть 1. Спецификация элементов данных оригинал документа: 4.4. биометрический… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р ИСО/МЭК 19762-3-2011: Информационные технологии. Технологии автоматической идентификации и сбора данных (АИСД). Гармонизированный словарь. Часть 3. Радиочастотная идентификация (РЧИ) — Терминология ГОСТ Р ИСО/МЭК 19762 3 2011: Информационные технологии. Технологии автоматической идентификации и сбора данных (АИСД). Гармонизированный словарь. Часть 3. Радиочастотная идентификация (РЧИ) оригинал документа: 05.02.21 абстрактный… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р ИСО/МЭК 15419-2005: Автоматическая идентификация. Кодирование штриховое. Цифровые системы создания изображений и печати символов штрихового кода. Общие требования и требования к испытаниям — Терминология ГОСТ Р ИСО/МЭК 15419 2005: Автоматическая идентификация. Кодирование штриховое. Цифровые системы создания изображений и печати символов штрихового кода. Общие требования и требования к испытаниям оригинал документа: 3.11 дисторсия… … Словарь-справочник терминов нормативно-технической документации

МИ 2891-2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений — Терминология МИ 2891 2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений: Данные измерительная информация, представленная в виде, пригодном для передачи, интерпретации или обработки. Определения термина из… … Словарь-справочник терминов нормативно-технической документации

Политики ограниченного использования программ — Содержание 1 Общие сведения 2 Дополнительные правила и уровни безопасности … Википедия

система — 4.48 система (system): Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей. Примечание 1 Система может рассматриваться как продукт или предоставляемые им услуги. Примечание 2 На практике… … Словарь-справочник терминов нормативно-технической документации

Источник

Идентификатор программного обеспечения что это

ГОСТ Р ИСО/МЭК 19770-2-2014

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

МЕНЕДЖМЕНТ ПРОГРАММНЫХ АКТИВОВ

Тег идентификации программного обеспечения

Information technologies. Software asset management. Part 2. Software identification tag

Дата введения 2016-01-01

1 ПОДГОТОВЛЕН Закрытым акционерным обществом «Консистент Софтвеа Дистрибьюшн» на основе аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 076 «Системы менеджмента»

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

Введение

Данная часть настоящего стандарта представляет собой Международный стандарт, описывающий теги идентификации программного обеспечения. Тег идентификации программного обеспечения представляет собой XML-файл, содержащий достоверную идентификационную и управляющую информацию о программном продукте. Тег идентификации программного обеспечения устанавливается на вычислительное устройство вместе с программным продуктом. Тег может создаваться в процессе установки или добавляться позднее для уже установленного программного обеспечения без тегов. Однако чаще происходит так, что тег создается при исходной разработке программного продукта, а затем распространяется и устанавливается вместе с программным продуктом. Наличие тега, начиная с самого начала разработки программного продукта, позволяет обеспечить более эффективное управление процессами распространения и переупаковки, выполняемых лицами, внешними по отношению к потребителю программного обеспечения, и последующими процессами управления релизами в организации потребителя программного обеспечения.

Данная часть настоящего стандарта поддерживает процессы управления программными активами, определенные в ИСО/МЭК 19770-1. Данный стандарт также предназначен для совместного использования с будущим ИСО/МЭК 19770-3, который будет представлять собой Международный стандарт, описывающий теги прав на использование программного обеспечения.

a) возможность единообразной и достоверной идентификации программных продуктов для управления ими в любых целях, например в целях лицензирования, обновления, упаковки или для составления ведомости взаимозависимостей. Теги идентификации программного обеспечения содержат метаданные, необходимые для обеспечения более точной идентификации. Данный подход коренным образом отличается традиционных способов идентификации, ориентированных на файлы;

b) способность идентифицировать группы или наборы программных продуктов аналогично тому, как осуществляется идентификация отдельных программных продуктов, позволяет осуществлять управление целыми группами или наборами программных продуктов так же гибко, как и управление отдельными продуктами;

c) упрощение практических процессов стандартизации между различными создателями программного обеспечения и внутри самих организаций создателей программного обеспечения, определяющих, как именно следует идентифицировать различные версии программного обеспечения, что позволит потребителям программного обеспечения осуществлять более качественную идентификацию и управление этими различными версиями; например они смогут проводить различия между самостоятельными версиями и версиями, являющимися компонентами наборов, обновлений и пр.;

d) упрощение автоматизированных подходов к проверкам лицензионного соответствия с использованием информации, содержащейся как в теге идентификации программного обеспечения, так и в теге прав на использование программного обеспечения, который будет определен в ИСО/МЭК 19770-3;

e) возможность предоставления исчерпывающей информации о структурных составляющих пакетов, т.е. списка компонентов, таких как файлы и системные настройки, связанные с этим пакетом, с целью сопоставления процессов управления на уровне пакетов и на уровне файлов;

f) возможность предоставления информации о том, как именно должна осуществляться идентификация в случае активного или неактивного использования конкретного программного пакета;

g) Возможность управления сложностью программного обеспечения, установленного на съемных носителях, или носителях общего доступа, или в виртуальных средах (при условии, что платформы и программы-установщики будут совершенствовать технические возможности по идентификации устройств и окружений);

h) Возможность отражать в теге идентификации программного обеспечения идентификационные данные и требования различных объектов, в том числе создателей программного обеспечения, лицензиаров программного обеспечения, упаковщиков, дистрибьюторов, внешних по отношению к потребителю программного обеспечения, администраторов релизов в организации потребителя программного обеспечения и лиц, ответственных за установку и управление программным обеспечением, на постоянной основе;

i) Возможность выполнения проверки правильности (валидации) любой такой информации посредством дополнительного использования цифровых подписей любым лицом, создающим или изменяющим информацию в теге идентификации программного обеспечения;

j) Возможность для лиц, не являющихся создателями программного обеспечения (например, независимых поставщиков или внутреннего персонала), создавать теги идентификации программного обеспечения для устаревшего программного обеспечения, а также для программного обеспечения, поступившего от создателей программного обеспечения, которые сами не предоставили теги идентификации программного обеспечения;

k) по мере того, как отраслевые организации начнут применять единые подходы к работе с различными типами информации, не охватываемой в настоящее время данной частью настоящего стандарта, в настоящий стандарт будут вноситься формальные и неформальные усовершенствующие изменения, например в части активации продуктов.

1 Область действия

Настоящий стандарт устанавливает спецификации для создания и ведения тегов программного обеспечения с целью оптимизации процессов идентификации и управления таким программным обеспечением.

1.2 Область применения

Настоящий стандарт применяется к следующим объектам:

a) провайдеры платформы: Провайдерами платформы являются лица, отвечающие за компьютерное оборудование, или аппаратное устройство, и/или соответствующую операционную систему, или виртуальную среду, на которых может устанавливаться или запускаться программное обеспечение. Провайдеры платформы, поддерживающие данную часть настоящего стандарта, кроме того, реализуют функциональность управления тегами на уровне платформы или операционной системы;

b) поставщики программного обеспечения: Поставщиками программного обеспечения являются лица, которые создают («создатели программного обеспечения»), изменяют («модификаторы программного обеспечения») или лицензируют («лицензиары программного обеспечения») программное обеспечение для распространения или установки. К ним относятся производители программного обеспечения, независимые разработчики программного обеспечения, консультанты и переупаковщики ранее произведенного программного обеспечения. Поставщиками программного обеспечения также могут считаться разработчики программного обеспечения для внутренних целей организации;

c) поставщики тегов: Поставщиками тегов являются лица, которые создают («создатели тегов») или изменяют («модификаторы тегов») теги идентификации программного обеспечения. Поставщик тегов может являться частью организации поставщика программного обеспечения или может быть сторонней организацией или потребителем программного обеспечения;

d) поставщики инструментария для работы с тегами: К ним относятся лица, которые могут предоставлять любое количество инструментальных средств, с помощью которых можно создавать, изменять или использовать теги идентификации программного обеспечения. К такому инструментарию могут относиться среды разработки, обеспечивающие автоматическое формирование тегов идентификации программного обеспечения, средства установки, которые могут создавать и/или изменять теги от имени процесса установки, а также инструменты управления настольными системами, которые могут создавать теги для программного обеспечения, не имеющего тегов, и/или изменять теги, внося в них сведения о релизе, в течение жизненного цикла программного обеспечения. Более подробная информация о возможных способах использования тегов идентификации программного обеспечения поставщиками инструментария для работы с тегами приведена в приложении С;

e) потребители программного обеспечения: Потребителями программного обеспечения являются лица, которые приобретают, устанавливают и/или иным способом потребляют программное обеспечение, и которые считаются одними из главных получателей усовершенствованной информации, содержащейся в теге идентификации программного обеспечения, как это определено в данной части настоящего стандарта. Более подробная информация о возможных способах использования тегов идентификации программного обеспечения потребителями программного обеспечения приведена в приложении D.

1.3 Ограничения

В данной части настоящего стандарта не приводится описание процессов SAM, используемых для выверки прав на использование программного обеспечения с помощью тегов идентификации программного обеспечения.

В данной части настоящего стандарта не приводится описание процессов активации продуктов или контроля запуска.

Данная часть настоящего стандарта не имеет целью вступление в противоречие ни с политиками, процедурами и стандартами организации, ни с любыми внутригосударственными законами и регуляторными актами. Любое такое противоречие должно быть устранено до начала использования данной части настоящего стандарта.

2 Соответствие

2.1 Общие положения

Критерии соответствия могут применяться к продукту или организации. Для организационного соответствия определенная область действия должна охватывать как организационную область действия, так и продукты, включенные в эту область действия.

Если в отношении продукта или организации выдвигается претензия о соответствии, в претензии должна быть указана область действия, в которой было осуществлено тестирование соответствия.

В контексте данного пункта соответствие часто определяется в терминах, соответствующих требованиям 6.1, 8.3, 8.4 и 8.5. Требования к соответствию платформы также определены в 7.2. Также существуют нормативные требования, определенные в других подпунктах пунктов 6 и 7, при описании которых используются слова «должен», «должна», «должны» и пр., однако эти требования не включаются в содержание заявлений о соответствии, за исключением тех случаев, когда эти требования также включены в 6.1, 7.2, 8.3, 8.4 или 8.5. Заявления, содержащие слова «должен», «должна», «должны» и пр., являются рекомендательными, но не обязательными.

2.2 Соответствие продуктов

2.2.1 Примеры причин необходимости обеспечения соответствия продуктов

В организации могут иметься несколько причин, по которым организация может пожелать обеспечить соответствие отдельных продуктов данной части настоящего стандарта. Например, обеспечение соответствия может потребоваться, когда конкретный продукт поставляется на рынок, требующий соблюдения соответствия (например, если государственные организации требуют, чтобы продукт соответствовал данной части настоящего стандарта с целью включения в проект). Обеспечения соответствия также могут требовать провайдеры платформы, желающие организовать более безопасное и контролируемое хранилище тегов, которое может использоваться для однозначной идентификации того, какой именно конечный пользователь установил какой именно программный пакет.

2.2.2 Область действия продукта

Должно быть оформлено четко выраженное заявление об области действия продукта, однозначно описывающее программные продукты, к которым применяется данная область действия и, в соответствующих случаях, вносящее уточнения относительно продуктов, к которым данная область действия не применяется. Область действия соответствия продукта может определяться любым удобным способом, например, для конкретного программного продукта, для всех программных продуктов, для всех программных продуктов, установленных на конкретных платформах, для программных продуктов конкретных изготовителей и/или для всех программных продуктов, созданных после указанной даты, при условии, что такие определения области действия являются однозначными. В случае продукта, создающего или изменяющего теги идентификации программного обеспечения, областью действия будет считаться сам продукт и все программное обеспечение, произведенное или измененное продуктом при включенной функциональности обеспечения соответствия тегов.

2.2.3 Соответствие программных продуктов

Полное соответствие программного продукта достигается одним из двух способов:

a) Для продукта, предназначенного для установки, полное соответствие достигается посредством демонстрации того, что все теги идентификации программного обеспечения, установленные этим продуктом в процессе установки, соответствуют всем обязательным требованиям данной части настоящего стандарта, определенным в 6.1 и 8.3. Если используются дополнительные или расширенные элементы тегов, такие элементы тегов также должны соответствовать требованиям, определенным в 8.4 и 8.5.

Такое соответствие должно быть продемонстрировано посредством выполнения эквивалентного разбиения с критерием завершения, состоящим в том, что пройдены все тесты и достигнуто 100% эквивалентное разбиение в процессе создания/установки тега. Эквивалентные разбиения должны определяться на основании заявления об области действия продукта. Если программный продукт состоит из пакета других программных продуктов, то в программном продукте должны быть сохранены все теги компонентов и содержаться ссылки на все элементы дочерних тегов, которые при любых обстоятельствах по-прежнему должны идентифицироваться отдельно (с целью лицензирования, обеспечения безопасности или с другими целями);

b) для продукта, предназначенного для распространения, но еще не установленного, полное соответствие достигается посредством демонстрации того, что распространяемые сборки выпущены с уникальным тегом, который должен соответствовать всем обязательным требованиям данной части настоящего стандарта, определенным в 6.1 и 8.3. Если используются дополнительные или расширенные элементы тегов, такие элементы тегов также должны соответствовать требованиям, определенным в 8.4 и 8.5. Исключение: любые обязательные элементы, присущие конкретной системе, не включаются.

Такое соответствие должно быть продемонстрировано посредством выполнения эквивалентного разбиения с критерием завершения, состоящим в том, что пройдены все тесты и достигнуто 100% эквивалентное разбиение. Эквивалентные разбиения должны определяться на основании заявления об области действия продукта.

Если программный продукт состоит из пакета других программных продуктов, то в программном продукте должны сохраниться все теги компонентов и содержаться ссылки на все элементы дочерних тегов, которые при любых обстоятельствах по-прежнему должны идентифицироваться отдельно (с целью лицензирования, обеспечения безопасности или с другими целями).

2.2.4 Соответствие тегов идентификации программного обеспечения третьих сторон

Сторонние организации, предоставляющие теги, могут применять процессы создания тегов идентификации программного обеспечения для любых программных пакетов, не содержащих такие теги. Такие процессы могут применяться для программных продуктов более ранних версий, продуктов типа shareware/freeware или для продуктов компаний, принявших решение не обеспечивать соответствие данной части настоящего стандарта. Такие теги могут предоставляться организациям для того, чтобы они могли обнаруживать программное обеспечение и запускать процедуры идентификации.

Полное соответствие тегов идентификации программного обеспечения, созданных третьими сторонами, достигается посредством демонстрации того, что все теги идентификации программного обеспечения, созданные организацией, соответствуют всем обязательным требованиям данной части настоящего стандарта, определенным в 6.1 и 8.3. Если используются дополнительные или расширенные элементы тегов, такие элементы тегов также должны соответствовать требованиям, определенным в 8.4 и 8.5. Любые добавляемые новые данные должны соответствовать тем же стандартам, которые применяются к обеспечению соответствия устанавливаемого программного обеспечения.

Обеспечение соответствия тегов идентификации программного обеспечения, созданных третьими сторонами, требует, чтобы поставщики тегов продемонстрировали уникальность созданных ими идентификаторов программного обеспечения (software_id), и что для идентификации поставщиков программного обеспечения в таких идентификаторах используются согласованные значения. Предполагается, что поставщики тегов будут вести список уникальных поставщиков программного обеспечения для всех созданных тегов, причем такой список будет включать в себя согласованный регистрационный идентификатор (regid) поставщика программного обеспечения (являющийся ссылкой на домен поставщика) и уникальный идентификатор ID (которым может быть идентификатор GUID) для каждой ссылки, и эти сведения на согласованной основе будут использоваться в созданных тегах.

Такое соответствие должно быть продемонстрировано посредством выполнения эквивалентного разбиения с критерием завершения, состоящим в том, что пройдены все тесты и достигнуто 100% эквивалентное разбиение в процессе создания тега. Эквивалентные разбиения должны определяться как по диапазону программного обеспечения, к которому будет применяться инструментарий для работы с тегами, так и по соответствующим заявлениям об области действия продукта.

Источник