Процесс 5. Разработка и тестирование изменения

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

 

Рис. 7. Разработка и тестирование изменения

Действия по разработке и тестированию изменения

Действия по разработке и тестированию изменения тесно связаны с этапом «Внедрение» жизненного цикла ИТ-услуги. Дополнительные сведения о разработке и тестировании изменений см. в документе Обзор этапа «Внедрение» и в описании следующих SMF-функций этапа «Внедрение»:

· SMF-функция «Предварительное планирование»

· SMF-функция «Планирование проекта»

· SMF-функция «Создание»

· SMF-функция «Стабилизация»  

· SMF-функция «Развертывание»

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

· Стандартные изменения. Используйте существующие процедуры для стандартных изменений.

· Незначительные изменения. Используйте процессы для незначительных изменений, описанные в настоящем документе. Дополнительные сведения см. в описании SMF-функций этапа «Внедрение».

· Важные и значительные изменения. См. описание SMF-функций этапа «Внедрение».

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

В следующей таблице перечислены действия, которые входят в эту процедуру:  

· Проектирование изменения

· Выявление зависимостей конфигурации

· Создание и тестирование изменения

· Анализ готовности изменения к выпуску

· Обновление запроса на изменение

Таблица 8. Действия и основные аспекты процесса разработки и тестирования изменения

Действия	Аспекты
Проектирование изменения	Основные вопросы · Учтены ли в проекте бизнес-требования и определены ли функции, которые необходимы пользователям для выполнения работы? · Разработаны ли надлежащие сценарии использования? · Учтены ли в проекте требования к эксплуатации? · Учтены ли в проекте требования к системе? Входные данные · Требования пользователей и бизнес-подразделений · Сценарии использования · Требования к эксплуатации и к системе Конечный результат · Проектные документы Рекомендации · Поддерживайте связь между требованиями и функцииями решения. Это позволяет проверять правильность проек­та и его соответствие целям и требованиям решения.
Выявление зависимостей конфигурации	Основные вопросы · Существуют ли другие конфигурационные элементы, которые зависят от предлагаемого изменения или могут быть затронуты им? · Зависит ли предлагаемое изменение от других изменений? Другими словами, нужно ли для внесения предлагаемого изменения сначала выполнить другие изменения? · Сохранены ли в системе управления конфигурациями сведения обо всех изменениях (как о предварительных требованиях, так и о конечном изменении)? Входные данные · Сведения о других предлагаемых изменениях в системе управления конфигурациями Конечный результат · Запись в системе управления конфигурациями, показывающая зависимости конфигурационных элементов, на которые может влиять предлагаемое изменение или которые могут влиять на него Рекомендации · Данные в CMS должны обновляться при каждом утвер­ждении RFC. Это поможет отслеживать изменения, запланированные для конфигурационного элемента или группы конфигурационных элементов. После успешного завершения изменения данные в CMS также необходимо обновить.
Разработка и тестирование изменения	Основные вопросы · Соответствует ли готовое изменение спецификациям заказчика? · Подготовила ли группа разработчиков среду разработки? · Подготовила ли группа разработчиков процесс отслеживания ошибок? Каким образом информация об этих ошибках будет передана группе эксплуатации для использования в базе знаний? · Проводили ли группы разработки и тестирования совместную работу по подготовке тестовых заданий? · Подготовила ли группа несколько версий-кандидатов и протестировала ли каждую из них, чтобы проверить, можно ли выпускать соответствующую версию для пилотной группы? · Завершила ли группа приемочное тестирование пользователями? · Выполнила ли группа пилотное развертывание решения и получила ли отзывы? Входные данные · Документ с описанием концепции и области действия проекта · Функциональная спецификация · Требования заказчиков · Код. · Техническое задание на проведение тестирования · План тестирования · Лабораторная среда · База данных, политики и процедуры отслеживания ошибок Конечный результат · Версии-кандидаты · Версия-кандидат, готовая к пилотному тестированию Рекомендации · Разрешайте все известные проблемы (разрешение может заключаться в исправлении или отсрочке). · Создайте стандарты для определения приоритета и серьезности ошибок и проинформируйте о них всех участников группы, включая роли разработки, тестирования и взаимодействия с пользователем. · Предоставьте специалистам по обучению и поддержке доступ к базе данных для отслеживания ошибок, чтобы они могли получить представление об истории создания решения и о проблемах, возникавших во время разработки. · Для анализа ошибок и выработки стратегий их разре­шения проводите регулярные собрания с участием разработчиков и тестировщиков.
Анализ готовности изменения к выпуску	Основные вопросы · Существует ли выравнивание бизнеса и ИТ и понятны ли приоритеты? · Определены ли ответственные за все операции и действий? · Подписаны ли все планы надлежащими руководителями? · Проинформированы ли надлежащим образом все группы, которых затрагивает изменение?  · Знают ли пользователи и владельцы зависимых услуг о влиянии, которое окажет на них это изменение, и о том, что оно запланировано?  · Готовы ли пользователи к использованию новых процессов и одобряют ли их? · Завершено ли тестирование? · Готовы ли к выпуску группы эксплуатации и поддержки? Входные данные · Отчеты о состоянии для руководителя процесса управления релизами Конечный результат · Решение о готовности/неготовности релиза Рекомендации                              · Убедитесь, что руководителю процесса управления релизами предоставлены надлежащие отчеты о состоянии.  · Предоставьте отзывы и подтверждения тем, кто должен поддерживать релиз, и напомните организации об ожидаемых выгодах.
Обновление RFC	Основные вопросы · Внесены ли обновления, отражающие намеченную дату выпуска, планы и причины возврата (если таковой необходим), требования к поддержке, план развер­тывания, результаты тестирования, выявленные проблемы и дату анализа после внедрения (PIR)? Дополнительные сведения о PIR см. в разделе «Процесс 7. Проверка и анализ изменения». · Ведется ли в ходе процесса мониторинг и обновление состояния? · Может ли инициатор изменения просматривать RFC и определять его состояние в ходе процесса? · Осуществлялось ли при выпуске информирование инициатора изменения? Входные данные · Обновления для изменения Конечный результат · Обновленный запрос на изменение Рекомендации · Чтобы убедиться, что информация обновлена, руководитель процесса управления релизами должен осуществлять мониторинг выполняемых изменений, которые задерживают выпуск. Чтобы установить ожидае­мые результаты, можно использовать соглашение об уровне операционного обслуживания.

Процесс 6. Выпуск изменения

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

 

Рис. 8. Выпуск изменения