Приложение В (справочное). Сценарии действий и инструкции для поставщиков программного обеспечения

Приложение В
(справочное)

Сценарии действий и инструкции для поставщиков программного обеспечения

В.1 Введение

Поставщик программного обеспечения может реализовывать настоящий стандарт по нескольким причинам:

a) Простота идентификации

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

b) Точность идентификации

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

c) Контроль над процессами идентификации программного обеспечения

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

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

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

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

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

В.2 Роли, задействованные в процессе создания/изменения тега идентификации программного обеспечения

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

a) менеджер по продукту - это лицо определяет разрабатываемый/усовершенствуемый продукт и определяет множество аспектов продукта, которые должны быть отражены в теге. Использование для определения продукта информации, представленной в теге, позволят создавать более подробную документацию по продукту;

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

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

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

В.3 Роль менеджера по продукту

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

Для менеджера по продукту наибольшую важность могут представлять следующие элементы (которые он должен хорошо понимать).

a) Обязательные элементы

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

1) entitlement required (необходима выверка прав на использование) - этот тег определяет, должно ли учитываться обнаруженное программное обеспечение в ходе процесса выверки прав на использование. Менеджер по продукту может четко указать случаи, когда выверка прав на использование необходима (когда лицензия на программное обеспечение продается потребителям программного обеспечения), а когда нет (если программное обеспечение устанавливается в режиме пробного использования или предоставляется бесплатно);

2) product title (наименование продукта) - этот элемент соответствует официальному рыночному наименованию продукта, определенному создателем программного обеспечения. Обычно этим именем является имя, которым специалист-практик по использованию процессов SAM и IT-специалисты называют продукт. Само по себе наименование не должно оказывать непосредственное воздействие на процессы выверки;

3) product version (версия продукта) - этот важный элемент позволяет определять как маркетинговую (текстовую) версию продукта (обычно используемую создателями программного обеспечения для упрощения именования конкретной версии с рекламными целями), так и официальную числовую версию программного обеспечения. Числовая версия может включать до четырех элементов, определяющих полную информацию о версии: основной номер версии, дополнительный номер версии, сборочный номер версии и корректирующий номер версии. Поставщик программного обеспечения может лицензировать программный продукт только по основной или дополнительной версии. В этих случаях менеджер по продукту должен убедиться в том, что информация о правах на использование программного обеспечения (заказ на покупку, счет, сертификат лицензии на программное обеспечение или его эквивалент) могут быть четко привязаны к конкретному номеру версии, чтобы во время выполнения процесса выверки не происходила путаница;

4) software creator identity (идентификационные данные создателя программного обеспечения) - назначение этого элемента состоит в уникальной и согласованной идентификации поставщика, изготовившего программное обеспечение. Учитывая, что названия некоторых региональных отделений программных компаний могут несколько отличаться друг от друга, важно добавить к имени идентификатор, который будет оставаться постоянным во всех странах, регионах и на всех языках - эта информация указывается в элементе regid. Это значение должно быть одинаковым для всех продуктов и релизов, созданных создателем программного обеспечения;

5) software unique identifier (уникальный идентификатор программного обеспечения) - менеджер по продукту совместно с остальными лицами, представляющими организацию-разработчика, определяет уникальный идентификатор для каждой версии продукта. Уникальный идентификатор позволяет обеспечивать надлежащее сравнение в процессе выверки.

b) Дополнительные элементы

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

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

2) license and channel information (информация о лицензии и канале) - этот дополнительный элемент еще более упрощает идентификацию программного обеспечения, установленного на данной машине, повышая эффективность работы специалиста-практика по использованию процессов SAM и эффективность всего процесса выверки лицензионных прав. Например, зная источник установки, специалисты-практики по использованию процессов SAM смогут с легкостью отделять программное обеспечение, приобретенное непосредственно, от ОЕМ-продуктов, включаемых в новые приобретаемые персональные компьютеры (ПК);

3) package footprint ("отпечаток" пакета) - этот элемент позволяет создателю программного обеспечения указывать файлы, записи реестра и другую информацию, которая может быть использована для идентификации программного пакета. Этот элемент разрешает размещение в файле нескольких записей, поэтому в одном ссылочном файле могут обрабатываться и патчи, и незначительные релизы программного обеспечения. Цель этого элемента состоит в предоставлении информации, которую агент обнаружения может использовать для проверки правильности идентификации тегом установленного программного обеспечения. Дополнительным преимуществом является то, что этот элемент позволяет инструментарию для обнаружения тегов исключать из списка обнаруженных файлов все "известные" файлы. Имея достоверный список файлов, записей реестра, записей WMI, а также другую информацию, относящуюся к платформе, по конкретному продукту, инструментарий для обнаружения тегов и специалисты-практики по использованию процессов SAM могут отфильтровывать информацию из списка всех обнаруженных элементов. Отфильтровывая "известную информацию", специалисты-практики, получают точную картину неизвестного или нового программного обеспечения, которое может быть установлено в их рабочем окружении;

4) product identifier (идентификатор продукта) - этот элемент представляет собой идентификатор, сопровождающий конкретный продукт от релиза к релизу. Этот элемент не должен использоваться в качестве маркетингового элемента продукта (как, например, наименование продукта), это должен быть просто идентификатор, не меняющийся от релиза к релизу. Например, организация может создавать и продавать продукт, называемый "Acme Widgets 2007 Pro". Если следующий релиз этого продукта выйдет под другим названием, к примеру, "Acme Widgets 2008 Expert", то специалист-практик, имея только наименование продукта, не будет знать, подпадают ли эти два продукта под действие конкретного соглашения об обслуживании. Тем не менее, если оба продукта имеют идентификатор продукта, например, "fc3cc419-b5a1-9f16-ed203e537c40", то специалист-практик может определить, что оба продукта подпадают под действие одного и того же соглашения об обслуживании, и затем установить их соответствие. Этот элемент позволяет организации, не идентифицируя конкретное наименование, указывать, какие обновления разрешаются осуществлять в рамках соглашений об обслуживании;

5) serial number (серийный номер) - необходимость включения серийного номера в состав тега прямо пропорциональна важности серийного номера как элемента прав на использование программного обеспечения для лицензии на программное обеспечение, приобретаемой потребителями программного обеспечения. Издателям программного обеспечения, требующим ввода серийного номера, привязанного к потребителю программного обеспечения и/или конкретной покупке, для установки и использования программного обеспечения, настоятельно рекомендуется включить в тег элемент serial number (серийный номер) для установления прямой взаимосвязи с заказом на покупку и/или правами на использование программного обеспечения в процессе выверки. Серийные номера известны на момент установки, поэтому между установкой и лицензированием прав на использование программного обеспечения можно определить прямую связь,

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

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

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

8) software creator alias (алиас создателя программного обеспечения) - этот дополнительный элемент отражает имя создателя, использовавшееся до получения текущего имени; данный элемент очень важен в том случае, если разрешается обновление от версии предыдущего создателя до версии текущего создателя. Этот элемент следует включать в тег при выпуске новых версий программных продуктов после приобретения;

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