Мемтрика программмного обеспемчения

Мемтрика программмного обеспемчения (англ. software metric) — это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

Метрики для операционных процессов будут относиться к:

управлению инцидентами; службе Service Desk; управлению конфигурациями; управлению изменениями; управлению релизами (в том числе приложениями); управлению операциями (в том числе инфраструктурой).

Метрики для тактических процессов будут относиться к:

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

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

оценке перспектив развития бизнеса; программе постоянного улучшения качества обслуживания (Service Improvement Programme — SIP); управлению рисками; управлению документацией; компетентности, осведомленности, обучению (Competence, Awareness and Training — CAT).

       

Таблицы, в которых описываются метрики для управления ИТ-услугами, содержат следующие поля:

Метрика — максимально простое описание метрики. Вслед за ним приводятся в фигурных скобках {} используемые единицы. Описание — краткая характеристика метрики в дополнение к названию. Спецификация — краткое разъяснение, что и как измеряется. Обоснование — объяснение, чем полезна данная метрика и каково ее значение. Аудитория — перечень тех, кому данная метрика предположительно будет предоставлять полезную информацию. Ограничения — любые обстоятельства, представляющие препятствие для применения или интерпретации метрики. Опасное значение — условие, при котором показатель отображается красным цветом (что сигнализирует о возможных проблемах в области, которая измеряется данным показателем). Цель — значение метрики, к которому предлагается стремиться. Возможные значения — перечень значений, которые может принимать метрика.

Метрики для операционных процессов управления услугами

Управление инцидентами

Метрики для управления инцидентами:

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

Служба Service Desk

Метрики службы Service Desk:

Число звонков на специалиста. Процент звонков, закрытых с первого раза (на одного специалиста). Число звонков «не по адресу». Число звонков, заявки по которым были эскалированы на второй уровень поддержки. Степень удовлетворенности клиента. Число звонков, заявки по которым были эскалированы на третий уровень поддержки. Среднее время ожидания ответа на звонок. Средняя продолжительность попытки дозвониться до клиента (на один звонок). Процент обращений через веб. Процент неправильно эскалировнных заявок. Процент звонков, которые были прерваны пользователями. Процент звонков, по которым были открыты заявки на устранение проблемы. Процент инцидентов, поступивших от процесса управления событиями. Процент звонков, правильно назначенных с первого раза.

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

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

Число неиспользуемых лицензий. Число RFC, не выполненных из-за неверных данных в CMDB. Число неавторизованных конфигураций. Число инцидентов, связанных с невыполнением изменений из-за неправильно задокументированных CI. Число нарушений SLA, вызваных ошибками CMDB. Число RFC, по которым не было обновления CI. Процент некорректных CI. Степень удовлетворенности клиентов.

Управление изменениями

Метрики для управления изменениями:

Процент изменений, которые не удалось выполнить. Процент отклоненных RFC. Число неавторизованных изменений. Число не выполненных изменений. Простои во время изменений. Число неудачных изменений без плана возвращения в исходное состояние. Процент изменений, выполненных вовремя. Процент изменений, вызвавших инциденты. Число предложений Консультативного комитета по изменениям (Change Advisory Board — CAB), не реализованных вовремя. Степень удовлетворенности клиентов. Число экстренных изменений. Число изменений, не принесших ожидаемых результатов.

Управление релизами

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

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

Метрики для управления релизами включают:

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

Поддержка приложений

Метрики для поддержки приложений:

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

Разработка приложений

Метрики для разработки приложений:

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