Предоставление электронных публичных услуг (стр. 4 )

-  высокий – изменение оказывает серьезное влияние на работу нескольких пользователей;

-  средний – влияние изменения незначительно, но меры по устранению не могут откладываться до следующего по графику релиза;

-  низкий – изменение оправдано и необходимо, но может подождать до следующего по графику релиза.

Приоритет должен показывать порядок, в котором следует устранять проблемы.

5.3.2.4 Разработка, тестирование и внедрение изменений

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

-  сборку нового модуля;

-  создание новой версии одного или более программных модулей;

-  внешнюю закупку или получение оборудования;

-  подготовку модификации аппаратного обеспечения;

-  подготовку новой или обновленной документации;

-  подготовку пользователей.

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

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

Тестирование изменения должно учитывать следующие аспекты:

-  производительность;

-  безопасность;

-  возможность обслуживания;

-  поддерживаемость;

-  надежность и доступность;

-  функциональность.

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

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

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

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

5.3.2.5 Использование программных средств управления изменениями

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

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

-  наличие возможности находить связи между запросами на изменение, записями о проблемах и учетными элементами;

-  наличие возможности связывать запросы на изменение с проектами;

-  автоматическое создание запросов на оценку воздействия вовлеченных учетных элементов;

-  поддержка записи действий по этапам авторизации и внедрения запросов;

-  регистрация информации о разработке и тестировании изменений;

-  определение процедур отката при неудачных изменениях;

-  автоматическое напоминание о проведении анализа внедренных изменений;

-  автоматическая подготовка управленческой информации, связанной с изменениями;

-  способность сборки изменений;

-  автоматическое создание запросов на изменение;

-  отслеживание процесса управления изменениями и последовательности выполняемых действий.

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

5.3.3 Показатели эффективности процесса управления изменениями

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

-  количество отрицательных воздействий на качество услуг;

-  количество инцидентов, возникших в результате внедрения изменений;

-  количество откатов изменений;

-  количество срочных изменений;

-  соответствие между согласованным графиком изменений и реальным внедрением изменений;

-  отсутствие запросов на изменение с высоким приоритетом в списке ожидания;

-  регулярный анализ запросов на изменение и внедренных изменений;

-  коэффициент успешности внедрения изменений;

-  процент необоснованно отклоненных запросов на изменение.

Для эффективного управления процессом предоставления услуг необходимо организованное проведение изменений без ошибок и неверных решений. Для удовлетворительного предоставления услуг необходимо рациональное управление изменениями.

5.4 Процесс управления конфигурациями

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

Управление конфигурациями должно охватывать идентификацию, учет и отчеты об информационных компонентах ИТ-инфраструктуры. Элементы, которые должны контролироваться процессом управления конфигурациями, включают все компоненты ИТ-инфраструктуры и ПО.

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

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

-  контроль безопасности;

-  поддержку учетных элементов различной сложности;

-  легкое добавление новых учетных элементов и удаление старых;

-  автоматическую проверку вводимых данных;

-  автоматическую установку всех связей нового учетного элемента в момент его добавления;

-  поддержку учетных элементов с различными кодами моделей, номерами версий и копий;

-  ведение исторических записей обо всех учетных элементах;

-  гибкие средства отчетности.

5.4.1 Основные требования, предъявляемые к процессу управления конфигурациями

В процессе управления конфигурациями необходимо осуществить следующие деятельности:

-  планирование – определение назначения, масштаба, политики, целей, процедур для управления конфигурациями;

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

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

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

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

5.4.1.1 Планирование управления конфигурациями

Планирование управления конфигурациями должно определять:

-  стратегию, политику, рамки и цели управления конфигурациями;

-  сопутствующие политики, стандарты и процессы процесса управления услугами;

-  роли и обязанности управления конфигурациями;

-  анализ текущего состояния активов и конфигураций;

-  технические и управленческие действия процесса управления конфигурациями;

-  политику процессов управления изменениями и управления релизами;

-  взаимодействие между проектами, поставщиками, приложениями и группами поддержки;

-  местоположение хранилищ и библиотек для хранения аппаратного обеспечения, ПО и документации.

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

Основными действиями процесса управления конфигурациями по планированию являются:

-  подробный анализ взаимодействия процесса управления конфигурациями с другими процессами управления оказанием услуг;

-  анализ возможностей процесса управления конфигурациями;

-  обзор конфигурационных данных;

-  сбор и пересмотр данных по требованиям и функциональным спецификациям;

-  выбор средств автоматизации Конфигурационной базы данных учетных элементов;

-  определение типов учетных элементов, их атрибутов, типов взаимосвязей;

-  разработка процессов и процедур управления конфигурациями;

-  планирование и обеспечение безопасных хранилищ учетных элементов совместно с процессом управления релизами.

5.4.1.2 Идентификация конфигураций

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

5.4.1.2.1 Конфигурационная база данных учетных элементов

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

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

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

5.4.1.2.2 Компоненты идентификации конфигурации

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

-  аппаратное обеспечение, включая компоненты сети;

-  системное ПО;

-  системы и приложения организации, разработанные по заказу;

-  готовые программные пакеты, стандартные продукты и продукты работы с базами данных;

-  конфигурационные базисы;

-  релизы ПО;

-  конфигурационная документация, лицензии, соглашения о сопровождении, соглашения об уровне услуг.

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

5.4.1.2.3 Атрибуты учетных элементов

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

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

-  название учетного элемента;

-  номер копии, серийный номер (уникальный идентификатор учетного элемента);

-  категория учетного элемента;

-  тип учетного элемента;

-  номер модели для аппаратного обеспечения;

-  дата истечения гарантийного обслуживания;

-  номер версии учетного элемента;

-  местоположение учетного элемента;

-  ответственный владелец;

-  источник, поставщик учетного элемента;

-  лицензия;

-  даты поставки и приемки;

-  статус учетного элемента;

-  связи учетного элемента со всеми другими учетными элементами;

-  номера запросов на изменения, номера изменений, проблем, инцидентов.

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

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

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

Эталонные копии ПО в библиотеке эталонного ПО должны иметь маркировку ПО, содержащую наименование учетного элемента и номер версии. Все носители, содержащие ПО, должны быть четко маркированы названием учетного элемента, номером копии и номером версии каждого элемента ПО, содержащегося на носителе.

5.4.1.3 Контроль конфигураций

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

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

Постоянные процедуры контроля конфигураций должны включать:

-  регистрацию всех новых учетных элементов и их версий;

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

-  обновление запросов на изменения;

-  защиту целостности конфигураций;

-  обновление Конфигурационной базы данных учетных элементов.

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

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

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

Управление конфигурациями должно обеспечивать целостность сохраненных учетных элементов типа ПО при помощи:

-  выбора носителя для хранения, для минимизации ошибок, связанных с восстановлением и возможным повреждением данных;

-  осуществления проверок и обновлений архивных учетных элементов;

-  сохранения дубликатов в контролируемых местах.

Постоянное дублирование учетных элементов важно для обеспечения отсутствия посторонних элементов.

5.4.1.4 Учет статусов конфигураций

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

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

5.4.1.5 Проведение проверок и аудита конфигураций

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

Аудит конфигураций должен осуществляться вследствии:

-  внедрения новой системы управления конфигурациями;

-  крупных изменений в ИТ-инфраструктуре;

-  релиза ПО;

-  восстановления, последовавшего за крупной аварией;

-  обнаружения неавторизированных учетных элементов.

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

5.4.1.6 Составление управленческих отчетов

Управленческие отчеты процесса управления конфигурациями должны включать:

-  результаты аудита конфигураций;

-  информацию об обнаруженных незарегистрированных или неверно зарегистрированных учетных элементах;

-  информацию о количестве зарегистрированных учетных элементов и их версий с разбивкой по категориям, типу и статусу;

-  информацию о скорости внесения изменений в Конфигурационную базу данных учетных элементов;

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

-  анализ эффективности, роста и аудита управления конфигурациями;

-  ценность и местоположение учетных элементов.

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

5.4.2 Действия процесса управления конфигурациями

В процессе управления конфигурациями должны выполняться следующие действия:

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

-  2) определение и документирование процедур процесса управления конфигурациями;

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

-  4) контроль и хранение эталонных, авторизированных и проверенных копий спецификаций, документации и ПО;

-  5) отслеживание и регистрация данных о конфигурациях в соответствии с действительным состоянием информационной инфраструктуры;

-  6) отчетность по метрикам учетных элементов;

-  7) аудит и отчетность о нарушениях стандартов инфраструктуры и процедур управления конфигурациями.

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

-  содержание, местоположение и носитель для каждой библиотеки;

-  условия поставки элемента на хранение;

-  меры по защите библиотеки и процедуры восстановления;

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

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

Средства управления конфигурациями должны выполнять автоматическую поддержку следующих действий:

-  идентификации связанных учетных элементов;

-  внедрения изменений;

-  регистрации изменений статусов учетных элементов при внедрении авторизированных изменений и релизов;

-  записи конфигурационных базисов учетных элементов и пакетов учетных элементов.

В процессе управления конфигурациями должны использоваться Интернет-технологии и различные программные средства поддержки, такие как:

-  системы управления документооборотом;

-  средства построения архитектуры систем;

-  средства автоматической разработки систем;

-  средства управления аудитом баз данных;

-  средства распространения и инсталляции;

-  средства сравнения, внедрения релизов и сборки;

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

-  средства обнаружения и восстановления.

5.4.3 Показатели эффективности процесса управления конфигурациями

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

-  количество неавторизированных учетных элементов конфигурации;

-  инциденты и проблемы, как последствие неправильно сделанных изменений;

-  изменения среднего времени и затрат на диагностику и разрешение обращений в ЦЭП;

-  изменения количества и серьезности ситуаций нарушения Соглашения об уровне услуг;

-  не разрешенные успешно запросы на изменения;

-  время цикла между утверждением и внедрением изменений;

-  количество потерянных и неиспользованных лицензий ПО;

-  данные, полученные в результате проведения аудита конфигураций;

-  изменения количества и значимости инцидентов и проблем;

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

5.5 Процесс управления релизами

Цели процесса управления релизами:

-  планирование и надзор за успешным развертыванием ПО и связанного с ним аппаратного обеспечения;

-  проектирование и внедрение процедур для распространения и инсталляции изменений;

-  обеспечение инсталляции только правильных, авторизованных и протестированных версий;

-  взаимосвязи с заказчиками и контроль ожиданий заказчика во время планирования и развертывания новых релизов;

-  согласование точного содержимого релиза и его плана развертывания;

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

-  обеспечение безопасного хранения копий всего ПО;

-  обеспечение безопасности и отслеживаемости при развертывании или изменении аппаратного обеспечения.

В процессе управления релизами необходимо концентрировать внимание на защите среды эксплуатации и ее услуг посредством процедур и проверок.

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

5.5.1 Основные требования, предъявляемые к процессу управления релизами

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

Основными требованиями, соблюдаемыми в процессе управления релизами, являются:

-  разработка политики и планирование релизов;

-  проектирование, сборка и конфигурирование релизов;

-  приемка релизов;

-  планирование развертывания релизов;

-  всестороннее тестирование релизов по установленным критериям приемки;

-  подтверждение завершения релиза для последующего внедрения;

-  оповещение, подготовка и обучение персонала;

-  проведение аудита аппаратного и программного обеспечения до и после внедрения изменений;

-  инсталляция нового и модернизированного аппаратного обеспечения;

-  хранение контролируемого ПО в централизованных и распределенных системах;

-  релиз, распространение и инсталляция ПО.

5.5.1.1 Разработка политики и планирование релизов

5.5.1.1.1 Составление политики релизов

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

Политика релизов должна четко объяснять роли и обязанности в процессе управления релизами.

Политика релизов должна включать следующую информацию:

-  уровень контроля инфраструктуры для каждого определенного типа релиза;

-  правила именования и нумерации релизов;

-  определение комплексных и частичных релизов;

-  указания по частоте проведения комплексных и частичных релизов;

-  ожидаемые результаты для каждого типа релиза;

-  указания, как и где должны документироваться релизы;

-  создание и тестирование планов отката;

-  описание процесса контроля управления релизами;

-  документирование конфигурации библиотеки эталонного ПО и определение критериев приемки для добавления нового ПО.

5.5.1.1.2 Планирование релизов

Планирование релизов должно включать:

-  формирование общего согласия о содержании релиза;

-  согласование этапов по времени;

-  составление обобщенного графика релизов;

-  проведение опросов для оценки используемого программного и аппаратного обеспечения;

-  планирование уровней загрузки персонала;

-  согласование ролей и обязанностей;

-  предложения по закупке нового программного и аппаратного обеспечения;

-  составление планов отката;

-  разработка плана обеспечения качества релиза;

-  планирование приемки группами поддержки и заказчиком.

5.5.1.2 Проектирование, сборка и конфигурирование релизов

Необходимо планировать и документировать процедуры для сборки релизов ПО. Инструкции по сборке релиза являются частью определения релиза.

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

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

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

Процедуры сборки и автоматизация должны контролироваться как отдельные учетные элементы. Процедуры управления сборкой и распространения ПО должны быть протестированы до начала их использования. На первом этапе эксплуатации необходимо выделить время на разрешение проблем, связанных с введением новшеств.

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

5.5.1.3 Приемка релизов

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

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

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

Конечным результатом действий по проверке должно быть подтверждение полного и точного завершения всего релиза.

5.5.1.4 Планирование развертывания релизов

Планирование развертывания релизов должно расширить план релиза и включать следующую информацию:

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

-  списки учетных элементов для инсталляции и списания;

-  формирование описания релиза и коммуникаций;

-  планирование коммуникаций с конечным пользователем;

-  разработку плана закупок;

-  приобретение программного и аппаратного обеспечения.

В случае частичной или полной неудачи при развертывании релиза должен составляться план отката для документирования действий по восстановлению услуги. Возможны два подхода:

-  неудачное развертывание полностью возвращается в исходное состояние до полного восстановления услуг к их предыдущему известному состоянию;

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

План отката должен быть проверен в ходе оценки рисков в общем плане развертывания и признан достаточным заказчиком.

5.5.1.5 Приемочное тестирование и подтверждение завершения релиза

Перед развертыванием релиза в среду эксплуатации, он должен пройти обязательное тестирование и приемку пользователем, которое делится на:

-  функциональное тестирование;

-  операционное тестирование;

-  эксплуатационное тестирование;

-  интеграционное тестирование.

Перед развертыванием релиза пользователь должен подтвердить завершение релиза. Наиболее часто встречаемая причина неудачных изменений и релизов – недостаточное тестирование.

5.5.1.6 Оповещение, подготовка и обучение персонала

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

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

5.5.1.7 Релиз, распространение и инсталляция ПО

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

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

В процессе управления релизами должен осуществляться контроль следующих компонент:

-  программных приложений собственной разработки;

-  заказного ПО;

-  вспомогательного ПО;

-  системного ПО;

-  аппаратного обеспечения и его спецификаций;

-  инструкций по сборке и документации.

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

5.5.2 Типы и классификация релизов

5.5.2.1 Типы релизов

Единица релиза описывает часть инфраструктуры ПО. Единица релиза зависит от типа или элемента программного и аппаратного обеспечения.

Выбор уровня единицы релиза должен учитывать следующие факторы:

-  объем необходимых изменений;

-  объем ресурсов и время, требуемое на сборку, тестирование, распространение и внедрение релизов на каждом уровне;

-  простота внедрения;

-  сложность интерфейсов между предлагаемой единицей и остальной инфраструктурой;

-  доступное дисковое пространство в среде сборки, в тестовой среде, в среде распространения и в среде эксплуатации.

Различают следующие типы релизов:

-  комплексный релиз – все компоненты единицы релиза собираются, тестируются, распространяются и внедряются вместе. В этом релизе исключается опасность использования устаревших версий учетных элементов. Недостатком такого подхода является увеличение объема, усилий и компьютерных ресурсов, которые задействованы при сборке, тестировании, распространении и внедрении релизов. Необходимо провести регрессионное тестирование для исключения ухудшения системных функций или поведения системы;

-  дельта-релиз (частичный) – включает только те учетные элементы в рамках единицы релиза, которые были изменены, или новые учетные элементы;