■ очень редкое появление Релизов (а в идеале - их отсутствие), для которых требуется проведение отката из-за неприемлемых ошибок (следует отметить, что не всегда требуется, чтобы Релизы ПО вообще не содержали ошибок. Должно быть принято решение о том, чтобы продолжать Релиз даже при наличии ошибок при условии, что эти ошибки - малы и сбои находятся в допустимых пределах; см. главу 6. «Управление проблемами»);.
■ малый процент отказов при сборке;.
■ безопасность и четкое управление DSL;.
■ отсутствие в DSL ПО, не прошедшего проверку качества, и отсутствие свидетельств того, что взятое из DSL ПО было переделано;.
■ размеры дискового пространства соответствуют потребностям DSL. Своевременные и тщательные служебные действия по отношению к DSL;.
■ соответствие всем ограничениям законодательства, связанным с купленным ПО;.
■ точное распространение Релизов во все удаленные офисы;.
■ своевременное внедрение Релизов во всех офисах, включая удаленные;.
■ отсутствие фактов неавторизованного возврата к предыдущим версиям во всех офисах;.
■ отсутствие фактов использования неавторизованного ПО во всех офисах;.
■ отсутствие фактов оплаты лицензионных взносов или невостребованного обслуживания - для неиспользуемого ПО ни в одном из офисов;.
■ отсутствие фактов нерационального дублирования при сборке Релизов (например, наличие нескольких сборок в удаленных офисах, тогда как достаточно копии одной сборки);.
■ точная и своевременная запись в CMDB всех действий по сборке, распространению и внедрению;.
■ проведение анализа всех действий, связанных с Релизами и принятие всех необходимых корректирующих мер и мер по улучшению процесса;.
■ планируемый состав Релизов совпадает с их действительным составом (что демонстрирует хорошее планирование Релизов);.
■ использование ИТ и человеческих ресурсов, требуемых для Управления релизами, планируется заблаговременно, и делается это хорошо.
9.7.2 Управленческая отчетность.
Другие метрики, за которыми можно вести наблюдение, включают:.
■ количество крупных и небольших Релизов за отчетный период;.
■ количество проблем в среде эксплуатации, появление которых можно отнести к новым Релизам (эту метрику следует измерять только в первые несколько месяцев жизни Релиза) и которые классифицируются по корневой причине (например, «неверная версия файла» или «отсутствие файлов»);.
■ количество новых, измененных и удаленных объектов, введенных новым релизом, например, количество модулей и программ;.
■ количество Релизов, завершенных в рамках согласованного графика; это требует, чтобы центральное подразделение Управления релизами публиковало определенные целевые показатели (уровни обслуживания или SLA) для распространения ПО и других общих задач.