ГОСТ Р ИСО/МЭК 19770-2-2014
Данная часть настоящего стандарта подтверждает важность обеспечения соответствия управляе
мого окружения для проведения приемосдаточных испытаний требованиям целевого производствен
ного окружения посредством создания дополнительного элемента «Release verification» (Верификация
релиза) (см. 8.4.19).
с)В ИСО/МЭК 20000-2:2005.10.1. оговаривается следующее: «Важно, чтобы релиз был поставлен
в целости и сохранности в место назначения в состоянии, которое ожидает получатель».
Данная часть настоящего стандарта подтверждает необходимость эффективной и безопасной по
ставки релизов, предлагая созданиедополнительногоэлемента «Release rollout» (Развертывание рели
за). с помощью которого организация сможет проверять, кто именно утвердил программный пакет как
готовый к использованию в коммерческих целях, и когда было осуществлено утверждение (см. 8.4.18).
6 Реализация процессов создания и ведения тегов идентификации
программного обеспечения
6.1 Общие требования и инструкции
6.1.1 Обзор тегов идентификации программного обеспечения
В приложении А приводится более концептуальный обзор принципов работы с тегами идентифи
кации программного обеспечения (с целью облегчения понимания).
6.1.2 XML и XSD
Тег идентификации программного обеспечения должен определяться как структура XML-данных.
Используемым языком XML Schema Definition (Определение схемы XML) (XSD) должен быть язык,
определенный в Приложении G. или любая его (обновленная) версия, которую можно загрузить по
адресу:
http://standards.iso.org/iso/19770/-2/2009/schema.xsd.
Также могут иметься дополнительные версии схемы, имеющие идентификатор версии схемы,
указанный в пути к схеме. Все предыдущие версии схемы должны сохраняться.
6.1.3 Уникальный регистрационный идентификатор (registration ID, rogid)
Дескрипторы идентификации ПО могут создаваться несколькими различными организациями и
не обязательно должны регистрироваться через централизованный орган. Кроме того, данная часть
настоящего стандарта позволяет организациям создавать дескрипторы идентификации ПО для соз
данных не ими элементов конфигурации ПО (например, организация может создавать дескрипторы
идентификации ПО для собственных внутренних процессов обнаружения программного обеспечения).
С целью удовлетворения этих требований в данной части настоящего стандарта используется т. н. rogid
(регистрационный идентификатор). Идентификатор regid создается на базе классифицированного име
ни iSCSI, как это определено в стандартах IETF RFC 3720 (см. 3.2.6.3.1) и IETF RFC 3721 (см. 1.1). и
представляет собой уникальную ссылку на владельца имен.
Идентификатор regid может быть создан только частным лицом или организацией, являющимися
или являвшимися владельцами регистрационных удостоверений на имя домена (как это определено в
стандартах IETF RFC 1034 (см. 3.5) и IETF RFC 1123 (см. 2.1)). Имя домена не обязательнодолжно
быть активировано и не обязательно должно преобразовываться в конкретный адрес. Сами по себе
имена домена не являются уникальными идентификаторами, поскольку срок их действия может
закончить ся. и/или они могут быть приобретены другими объектами. Другими словами, в
идентификаторе rogid также должны содержаться сведения о дате, в которую объект зарегистрировал
домен. Для объектов, которые хотят получить еще большую гибкость в присвоении уникальных имен
своим подобъектам, в идентификаторе regid выделяется дополнительный суффикс, который можно
использовать, например, для того чтобы предоставить крупным разработчикам программных
продуктов средства, с помощью которых каждое из их бизнес-подразделений могло бы независимо
управлять собственными тегами идентификации программного обеспечения.
Имя идентификатора regid должно состоять из следующих элементов:
- строка «regid» - определяет элемент в качестве регистрационного идентификатора (registration
id) для тегов идентификации программного обеспечения:
- символ точки
- код даты в формате ГГГГ-ММ. Этой датой должна быть дата, во время которой объект, при
сваивающий имя. зарегистрировал домен. Под этой датой должно подразумеваться гринвичское время
14