Дипломная (вкр): Обзор решений моделирования бизнес-процессов управления ИT сервисами

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

o   Надежность оригинальных копий программ в используемой организацией Библиотеке эталонного программного обеспечения (DSL), а также регулярного обновления базы данных управления конфигурациями CMDB; то же касается аппаратных средств на складе DHS.

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

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

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

•        Контроль и отслеживание потоков инвестиций в ПО, от которых сильно зависит развитие бизнеса.

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

•        Уменьшение вероятности возникновения дефектов, инцидентов и ошибок в результате политики тестирования и контроля внедрения.

•        Обучение бизнес пользователей и привлечение их к участию в непосредственном тестировании релизов.

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

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

•        Обнаружение и изъятие неавторизованных и не лицензионных копий и некорректных версий ПО.

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

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

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

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

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

·              Рациональное и правильное использование среды тестирования и сборки;

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

·              Четкое использование методик тестирования, принятое в компании;

·              Контроль входов и выходов этапа сборки и тестирования;

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

·              Стандартизация;

·              Проверка требований по информационной безопасности и контроль доступа к компонентам ПО;

·              Проверка готовности релиза к запуску или передаче его на следующий этап;

·              Запуск или передача релиза на следующий этап.

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

Функции

-       планировать и контролировать успешное развертывание ПО и сопутствующих аппаратных средств;

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

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

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

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

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

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

Окружение процесса

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

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

Рисунок 2.2 - Окружение процесса

Управление релизами взаимодействует со следующими процессами:) Управление Конфигурациями

Процесс управление конфигурациями занимается регистрацией всех доступных версий программно-аппаратного обеспечения в базе данных управления конфигурациями (CMDB), как базисная конфигурация. Программное обеспечение, поставляемое в библиотеку DSL, а также аппаратное обеспечение для DHS обязательно проходит процедуру регистрации в базе данных управления конфигурациями с согласованием обеспечиваемого уровня детализации. Статус каждой конфигурационной единицы при мониторинге может отражать ход выполнения задачи и выглядеть может так: «в разработке», «готов к тестированию», «в тестировании», «обнаружен дефект», «отклонен», «исправлен» и так далее.)      Управление Изменениями

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

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

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

Метрика

Описание

Задача метрики

Аудитория

Число установленных программных пакетов

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

контролировать релиз ПО в инфраструктуре, чтобы свести к минимуму число вероятных сбоев.

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес- клиент, члены команды, владелец процесса SIP.

Число срочных релизов

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

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

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Число инцидентов, вызванных новым релизом

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

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

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Процент своевременных релизов

Управление релизами включает планирование сроков всех релизов в CMDB. Все изменения этих сроков учитываются данной метрикой.

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

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Число непротестированных релизов

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

Показывает число незавершенной работы

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес- клиент, члены команды, владелец процесса SIP.

Средние трудозатраты на релиз (часы)

фактические трудозатраты в человеко-часах.

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

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Число неиспользуемых лицензий на ПО

Лицензии на ПО, которые не инсталлированы и не подтверждены со стороны процесса управления мощностями

Сокращение количества, используемого нелицензионного или неавторизованного ПО

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Число приложений/ревизий, выпущенных в производство {сборки}

Одобренные релизы

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

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Число дефектов, обнаруженных по журналам регистрации {дефекты}

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

характеризует работу системы решения проблем по выявлению еще не проявившихся ошибок.

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Число ошибок, выявленных при разработке или тестировании {ошибки}

Дефекты, обнаруженные в ПО собственной разработки.

Показывает степень дефектизации приложения

Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP.

Число ошибок, исправленных при тестировании

Дефекты, зарегистрированные как исправленные и протестированные.

Мера производительности

Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP

Число ошибок, которые были отклонены

Дефекты, которые были решены путем наладки тестируемой среды или помечены, как нормальное состояние системы

Показатель качества сборки

Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP

Число дней, потраченных на развертывание приложения

Время отсчитывается согласно числу дней, заранее отведенных на поставку протестированного кода в DSL

успешно соблюдается календарный план при разработке приложений.

Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP.

Число дней, потраченное на тестирование приложения

Полный срок тестирования приложения

Визуализация скорости работы команды тестирования

Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP.


Документирование процесса

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

Руководство пользователя (или обновление руководства пользователя). В данном документе описывается новый или модифицированный функционал, который влияет особенности использования ИТ-системы для конечного пользователя.

Руководство администратора (или обновление руководства администратора). Здесь описываются все особенности нового релиза, которые могут повлиять на действия администратора приложения, базы данных или системного ПО. Здесь также указываются все изменения в структуре данных и кода, которые могут привести к изменению плана резервного копирования ИТ-системы.Notes - краткое описание изменений в ИТ-системе. Является сокращенным вариантов обновления руководства пользователя и предназначена для рассылки всем пользователям данной ИТ-системы накануне установки нового релиза в продуктивную среду.

План обучения пользователей. Используется при сложных релизах, для которых недостаточно документа Release Notesback Plan (план отката релиза ИТ-системы к предыдущей стабильной версии). В данном плане должны указываться все особенности восстановления как кода, так и данных, которые могли измениться после начала работы некорректной версии ИТ-системы.

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

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

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


Описание процесса

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

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

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

Источник: https://www.bibliofond.ru/detail.aspx?id=908122