Или CI), но и о том, как они связаны друг с другом. Взаимоотношения и взаимосвязи между Конфигурационными Единицами составляют основу для анализа степени воздействия инцидентов, проблем, изменений и т. д. на ИТ-инфраструктуру. Процесс Управления Конфигурациями проверяет, правильно ли регистрируются изменения в ИТ-инфраструктуре, включая взаимоотношения между Конфигурационными Единицами (CI), и ведет мониторинг статуса ИТ-компонентов чтобы гарантировать наличие точной информации о версиях существующих Конфигурационных Единиц (CIs).
В случае если Управление Конфигурациями реализовано эффективно, то этот процесс может дать информацию о следующем:
Финансовая информация и политика компании в отношении продуктов
Какие ИТ-компоненты используются в настоящее время по каждой модели (версии) и на протяжении какого времени?
Какие тенденции существуют в разных группах продуктов?
Какова текущая и остаточная стоимость ИТ-компонентов?
Какие ИТ-компоненты нужно выводить из операционной среды и какие требуют модернизации?
Сколько будет стоить замена определенных компонентов?
Какие имеются лицензии и достаточно ли их?
Какие контракты на сопровождение следует пересмотреть?
Какова степень стандартизации инфраструктуры?
Выявление неисправностей и оценка результатов
Какие ИТ-компоненты необходимы для поддержки процесса восстановления в случае чрезвычайной ситуации?
Будет ли работать план восстановления на случай чрезвычайных обстоятельств, если была изменена Конфигурация Инфраструктуры?
Какие ИТ-компоненты будут затронуты при развертывании новых сервисов?
Как оборудование подключено к сети?
Какие программные модули входят в каждый из комплектов программного обеспечения?
Какие ИТ-компоненты затрагиваются изменениями?
Какие Запросы на Изменения (RFC) конкретных ИТ-компонентов находятся на рассмотрении и какие инциденты и проблемы произошли в прошлом и сейчас продолжают оставаться актуальными?
Какие ИТ-компоненты вызывают известные ошибки?
Какие ИТ-компоненты были закуплены у конкретного поставщика в течение определённого периода?
Предоставление услуг и выставление счетов
Какие Конфигурации ИТ-компонентов являются существенными для определенных услуг?
Какие ИТ-компоненты используются в том или ином месте и кем?
Какие стандартные ИТ-компоненты может заказать пользователь и какие из них поддерживаются (каталог продуктов)?
6.1.1. Основные понятия
По терминологии процесса Управления Конфигурациями ИТ-компоненты и предоставляемые на их основе услуги называются Конфигурационными Единицами (CI). Каждый ИТ-компонент, чье наличие и версия зарегистрированы, является Конфигурационной Единицей. Как видно из рис. 6.1. Конфигурационными Единицами могут быть технические средства, все виды программного обеспечения, активные и пассивные сетевые элементы, серверы, системные блоки, документация, процедуры, услуги и все другие ИТ-компоненты, контролируемые ИТ-организацией. Если Управление Конфигурациями применено к информационным системам, а не только к информационным технологиям, то Конфигурационная База Данных (CMDB) может хранить и управлять детальной информацией о пользователях, персонале ИТ-организации и бизнес-структурах. Эти Конфигурационные Единицы также попадают под действие процесса Управления Изменениями, например, при найме и увольнении работников.
Рис. 6.1. Конфигурационные Единицы
Все Конфигурационные Единицы должны быть включены в Конфигурационную Базу Данных (CMDB), которая отслеживает все ИТ-компоненты и взаимоотношения между ними. В самой примитивной форме Конфигурационная База Данных представляет собой набор бумажных форм или электронных таблиц.
Разработчики часто используют нечто подобное Конфигурационной Базе Данных для контроля версий всех программных модулей. Некоторые платформы предоставляют такой вид контроля. Конфигурационная База Данных может состоять из нескольких физически раздельных баз данных, которые вместе составляют единое логическое целое. Рекомендуется оптимально интегрировать различные источники Конфигурационных Данных.
Не следует путать Конфигурационную Базу Данных со складскими или инвентаризационными базами данных. Такие программы предоставляют только ограниченную информацию о действующем аппаратном и программном обеспечении, сетевых компонентах и компонентах среды. Кроме того, Конфигурационная База Данных (CMDB) демонстрирует, какой должна быть инфраструктура, если все идет по плану (см. также Управление Изменениями), включая документацию. Данные в базе CMDB фактически представляют авторизованную Конфигурацию Инфраструктуры. Список расхождений (дельта) между бухгалтерскими и Конфигурационными Базами Данных является источником ценной информации.
Управление Конфигурациями не следует путать с Управлением Активами.
Управление Активами – это бухгалтерский процесс мониторинга амортизации активов, чья закупочная цена превышает определенную величину. Мониторинг ведется путем учета закупочных цен, амортизации, месторасположения активов. Эффективно работающая система Управления Активами может послужить основой для системы Управления Конфигурациями.
Управление Конфигурациями идет дальше, учитывая также информацию о взаимоотношениях между Конфигурационными Единицами и решая задачу стандартизации и авторизации единиц CI. Управление Конфигурациями также контролирует информацию о статусе ИТ-компонентов, их расположении, произведенных в них изменения и т. д.
6.2. Цель процесса
Цель процесса Управления Конфигурациями – содействие в Управлении Значимостью ИТ-услуг (сочетание требований заказчика, качества и затрат) путем поддержки логической модели ИТ-инфраструктуры и ИТ-услуг и предоставления информации о них другим бизнес-процессам. Это достигается посредством идентификации, мониторинга, контроля и предоставления информации о Конфигурационных Единицах и их версиях. Задачами данного процесса являются:
Точная регистрация детальной информации об ИТ-компонентах и услугах, предоставляемых организацией;
Предоставление точной информации и документации для поддержки других процессов сервис-менеджмента.
6.2.1. Преимущества использования процесса
Управление Конфигурациями содействует рентабельному предоставлению высококачественных ИТ-услуг с помощью:
Управления ИТ-компонентами – ИТ-компоненты являются крайне важным элементом при предоставлении ИТ-услуг. Каждая услуга включает одну или несколько Конфигурационных Единиц, и процесс Управления Конфигурациями контролирует, что происходит с этими единицами.
Повышения качества коммерческих услуг – процесс Управления Конфигурациями помогает в обработке изменений, выявлении и разрешении проблем и поддержке пользователей. Это приводит к сокращению количества ошибок и, как следствие, к уменьшению расходов.
Эффективного разрешения проблем – Управление Конфигурациями помогает в определении Конфигурационных Единиц, затронутых проблемой, и контролирует модификацию и замену этих элементов. Данный процесс также предоставляет информацию о тенденциях, которая является также входной информацией для Управления Проблемами.
Более быстрой обработки изменений – Управление Конфигурациями помогает в проведении более быстрого и точного анализа степени влияния, поэтому изменения могут быть реализованы быстрее и эффективнее.
Лучшего контроля аппаратного и программного обеспечения – распространение пакетов программ по возможности нужно объединять с установкой (распространением) аппаратного обеспечения и проведением предварительного тестирования. Конфигурационную Базу Данных и Базисные Конфигурации (т. е. мгновенные «фотографии» состояния инфраструктуры) можно использовать для разработки плана тестирования и распространения конкретным группам пользователей. В базе также содержится информация о проверенных версиях программного обеспечения, которые можно использовать при проведении изменений в случае необходимости возврата в исходное состояние.
Улучшенной безопасности – Управление Версиями дает информацию об авторизованных изменениях в Конфигурационных Единицах и использовании различных модификаций программного обеспечения. Такая информация из Конфигурационной Базы Данных также помогает в мониторинге лицензий.
Соблюдения требований закона – незаконные копии будет выявляться при сравнении результатов аудиторской проверки с Конфигурационной Базой Данных. Это может принести дополнительную пользу организации, т. к. незаконные версии могут содержать вирусы, а процесс Управления Конфигурациями может защитить организацию от их проникновения. В некоторых организациях не так легко помешать персоналу использовать незаконное и потенциально зараженное программное обеспечение, тем не менее тот факт, что такие версии могут быть обнаружены с помощью процесса Управления Конфигурациями, Конфигурационной Базы Данных и аудиторских проверок и что по результатам проверок будут приняты дисциплинарные меры, послужат предостережением персоналу. На нарушение правил персонал обычно толкает мысль, что об этом никто не узнает.
Более точного планирования расходов – Конфигурационная База Данных предоставляет информацию о затратах на сопровождение и контракты, лицензии и продукцию с истекшим сроком эксплуатации.
Лучшей поддержки процессов Управления Доступностью и Управления Мощностями – эти процессы в части планирования и анализа услуг зависят от правильной детальной информации о Конфигурациях.
Крепкого надежного фундамента для Управления Непрерывностью ИТ-услуг - Конфигурационная База Данных, если имеется ее резервная копия в надежном месте, может играть важную роль в восстановлении услуг в случае чрезвычайных обстоятельств. База также помогает в определении Конфигурационных Единиц, необходимых для такого восстановления, включая соответствующие процедуры и руководства, если они входят в состав базы.
Определение скрытых затрат - большая часть персонала ведет учетные записи о той части инфраструктуры, за которую они отвечают. Поскольку такая информация может собираться разными людьми и с разными целями, то в ней могут наблюдаться частичные совпадения. Дублирование и противоречивость в данных всегда влекут за собой дополнительные затраты и связаны с риском.
Рис. 6.2. Взаимоотношения между Конфигурационной Базой Данных и другими процессами (источник: OGC)
6.3. Процесс
Входом для процесса Управления Конфигурациями является информация об изменениях и информация из процесса Управления Закупками, а выходом – отчеты для других процессов и ИТ-руководства. Есть еще другой выход, когда Управление Конфигурациями предоставляет данные из Конфигурационной Базы Данных другим процессам, необходимые им для выполнения своих задач.
Процесс Управления Конфигурациями связан с многими другими процессами.
6.3.1. Управление Инцидентами
Процессу Управления Инцидентами необходима информация о всей инфраструктуре. При регистрации инцидентов процессу нужен доступ к информации о Конфигурационных Единицах, например, для определения расположения единицы и ее владельца, для уточнения связи этой единицы с проблемой или известной ошибкой, уже имеющей обходное решение, для какого заказчика или услуги единица предназначена и каким Соглашением об Уровне Услуг (SLA) регулируется.
6.3.2. Управление Проблемами
Процессу Управления Проблемами нужна информация об инфраструктуре со всеми ее сложными связями и взаимоотношениями. У процесса должны быть возможности для привязки проблем или известных ошибок к Конфигурационным Единицам и для использования информации из Конфигурационной Базы Данных для анализа инцидентов и проблем. Путем сравнения фактической Конфигурации Инфраструктуры с Авторизованной Конфигурацией, хранящейся в базе данных, можно выявить возможные отклонения и дефекты в инфраструктуре.
6.3.3. Управление Изменениями
Процесс Управления Изменениями использует Конфигурационную Базу Данных для оценки степени воздействия планируемых изменений. Данный процесс авторизует проведение изменений, и эти изменения должны быть связаны с соответствующими Конфигурационными Единицами. Управление Изменениями несет ответственность за регистрацию Запросов на Изменения и предоставляет важную входную информацию для обновления Конфигурационной Базы Данных.
6.3.4. Управление Релизами
Процесс Управления Релизами дает информацию о планах выпуска релизов и их версиях, например, о плановых датах основных и второстепенных релизов, а также о произведенных изменениях. Перед выполнением изменения процесс запрашивает информацию о Конфигурационной Единице, например, статус CI, ее расположение, исходный код и т. д.
6.3.5. Управление Уровнем Услуг
Процессу Управления Уровнем Услуг нужна информация о характеристиках услуг и взаимоотношениях между услугами и лежащей в их основе инфраструктурой. Данные из Соглашений об Уровне Услуги в качестве атрибутов могут храниться в Конфигурационной Базе Данных вместе с другой информацией о Конфигурационных Единицах. Данные об Уровне Сервиса (например, «золотой», «серебряный», «бронзовый») записываются для соответствующей сервисной Конфигурационной Единицы или CI для используемого программного или технического компонента.
6.3.6. Управление Финансами
Процессу Управления Финансами необходима информация об использовании услуг, например, у кого имеется в распоряжении PC. Процесс объединяет эту информацию с данными из Соглашений об Уровне Услуг (SLA) для определения цены. Данный процесс также ведет мониторинг инвестиций и стоимости ИТ-компонентов (Управление Активами).
6.3.7. Управление Доступностью
Процесс Управления Доступностью использует Конфигурационную Базу Данных для определения Конфигурационных Единиц, задействованных в услуге, для составления плана изменений и для выявления слабых мест, например, с помощью методики CFIA (Component Failure Impact Analysis – анализ влияния сбоев компонентов на предоставление сервиса). Доступность услуги (цепь компонентов инфраструктуры) определяется тем, насколько надежным является самый слабый компонент (звено цепочки). Процесс Управления Конфигурациями предоставляет информацию о составе цепочки, а также о каждом ее звене.
6.3.8. Управление Непрерывностью ИТ-услуг
Процесс Управления Непрерывностью ИТ-услуг использует стандартные Конфигурации из Конфигурационной Базы Данных (Базисные Конфигурации) для формулирования требований к восстановлению услуг в случае возникновения чрезвычайных обстоятельств и проверяет наличие этих Конфигураций на запасной территории.
6.3.9. Управление Мощностями
Процесс Управления Мощностями использует данные из Конфигурационной Базы Данных для оптимизации ИТ-инфраструктуры, распределения рабочей нагрузки и разработки плана мощностей.
6.3.10. Виды деятельности
Хотя процесс Управления Конфигурациями, как и другие процессы, представляет собой логическую последовательность действий, в данном процессе они не всегда выполняются строго последовательно. Виды деятельности при Управлении Конфигурациями имеют тенденцию выполняться параллельно. Приведенная ниже последовательность, прежде всего, отражает очередность действий при разработке процесса, а также при обработке и реализации новых информационных требований.
Планирование : определяются стратегия, политика и задачи процесса, анализируется имеющаяся информация, определяются инструментальные средства и ресурсы, создаются интерфейсы с другими процессами, проектами, поставщиками и т. д.
Идентификация : формируется процесс поддержки базы данных в актуальном состоянии. В этот этап входит разработка модели данник для регистрации всех ИТ-компонентов инфраструктуры, взаимоотношений между ними и информации о владельце этих компонентов или лица, ответственного за них, статусе единиц, а также об имеющейся документации. Также должны быть разработаны процедуры создания новых Конфигурационных Единиц и для изменения уже существующих. Поскольку потребности в информации постоянно меняются, определение состава данных о Конфигурации также меняется.
Контроль : контроль обеспечивает актуальное состояние Конфигурационной Базы Данных путем принятия, регистрации и мониторинга авторизованных и идентифицированных Конфигурационных Единиц. Наличие контроля гарантирует, что ни одна Конфигурационная Единица не будет добавлена, изменена, заменена или удалена без соответствующего документа, например, утвержденного Запроса на Изменение или скорректированной спецификации.
Мониторинг статуса : хранение текущей информации и истории статуса Конфигурационной Единицы на протяжении ее жизненного цикла. С помощью мониторинга статуса можно отследить, как меняется статус единицы, например «в разработке», «в тестировании», «в наличии», «в использовании», - «выведено из рабочей среды».
Верификация : верификация Конфигурационной Базы Данных путем аудита ИТ-инфраструктуры на наличие в ней зарегистрированных Конфигурационных Единиц и правильности регистрационных записей.
Отчетность : предоставление информации в другие процессы и подготовка отчетов об использовании Конфигурационных Единиц, тенденциях и т. д.
Ниже дается подробное описание этих действий.
6.4. Виды деятельности
6.4.1. Планирование
Задачи процесса Управления Конфигурациями, сфера его действия, а также приоритеты должны определяться в рамках Сервис-менеджмента и обязаны соответствовать бизнес-целям организации. Соответствующие этапы в реализации Управления Конфигурациями выходят за рамки данной книги.
6.4.2. Идентификация
Идентификация связана с определением и поддержкой соглашений о присвоении имен и нумерации версий физических компонентов инфраструктуры, взаимоотношений между ними и атрибутов. Базисные Конфигурации Аппаратного Обеспечения, используемого в настоящий момент и в будущем, описываются в форме специальных групп Конфигурационных Единиц (кластеров CI). Общий вопрос, на который должна дать ответ идентификация ИТ-компонентов состоит в следующем:
Какие услуги и связанные с ними компоненты ИТ-инфраструктуры должны находиться под контролем Сервис-менеджмента и какая информация необходима для этого?
При разработке системы идентификации должны быть приняты решения относительно охвата (границ) процесса и уровня детализации регистрируемой информации. Для каждого параметра (характеристики) следует определить владельца или заинтересованное лицо . Чем больше параметров регистрируется, тем больше усилий потребуется на обновление этой информации. Общий вопрос «Что же регистрировать?» может быть сведен к перечню конкретных вопросов для определения требуемой информации, например:
Какие ресурсы имеются для сбора и обновления информации?
Насколько зрелыми являются наши административные и материально-технические (логистические) процессы?
На каких уровнях организация выполняет инсталляцию, замену, разработку и/или распространение компонентов отдельно от основного компонента?
Какие виды деятельности, выполняемые сторонними организациями, должны измеряться и контролироваться?
Какие компоненты могут повлиять на услуги в случае сбоя и какая нужна информация для диагностики этих сбоев?
Для каких компонентов следует регистрировать статус и его предысторию?
Какие компоненты используются в организации в различных версиях или вариантах?
Изменения в каких компонентах могут повлиять на возможности и доступность услуг?
Какие компоненты являются дорогостоящими и их следует защищать от кражи или утери?
Какова настоящая и будущая информационная потребность у других процессов?
Для каких компонентов требуется такая информация, как серийный номер, дата покупки и поставщик, и какая информация необходима для бухгалтерии?
Какие требования вытекают из условий, закрепленных в Соглашениях об Уровне Услуг?
Какая информация необходима для выставления счетов заказчикам?
Насколько реальны наши стремления, не нужна ли корректировка?
Ответы на эти вопросы дают представление об объеме работ, которые необходимо выполнить. Следует принять решение об охвате (ширине, границах) CMDB и уровне ее детализации (глубине). Понятие детализации включает в себя: количество уровней в базе данных, взаимоотношения, подлежащие мониторингу, соглашения о присвоении имен и атрибуты. Все они будут рассмотрены ниже.
Охват (сфера действия, границы)
При создании Конфигурационной Базы Данных и обновлении модели данных следует определиться, какая часть ИТ-инфраструктуры будет находиться под контролем процесса Управления Конфигурациями. Например, следует ли включать в сферу действия данного процесса такие компоненты, как «электронные органайзеры» (PDA), сетевые копировальные устройства, факсы, клавиатуры и ИТ-персонал, или же они должны находиться за пределами действия процесса? Границы, определенные для процесса Управления Конфигурациями, влияют на границы, в которых, например, процесс Управления Проблемами выполняет диагностирование, на анализ степени воздействия, проводимый процессом Управления Изменениями, планирование, выполняемое процессом Управления Доступностью и т. д.
Кроме того, работая над границами процесса можно произвести анализ вклада ИТ-услуг в конечную деятельность заказчика или степень воздействия на нее, а также рассмотреть соглашения с пользователями об уровне поддержке и услугах.
Сферу действия процесса можно разделить на области, каждая со своими требованиями и подходом к проектированию. Примерами таких областей могут стать настольные рабочие места, системы передачи данных, файловые сервисы, сервисы печати и прикладного ПО, центральная процессинговая система, базы данных, телефонные услуги. Для разработки каждой области может быть инициирован отдельный проект в соответствующей управленческой среде.
Границы Конфигурационной Базы Данных могут включать аппаратное и программное обеспечение, а также документацию, например, Соглашения об Уровне Услуг (SLAs), процедуры, руководства, технические спецификации, организационные схемы, персонал и планы проектов. Как и другие Конфигурационные Единицы, эти документы физически могут находиться в разных местах, но информация о них находится в базе данных с номерами версий, датами публикаций, именами авторов и т. д. В этом случае процессы Управления Конфигурациями и Управления Изменениями могут контролировать эти характеристики документов.
На рис. 6.3 показаны взаимоотношения между услугами и компонентами Конфигурационной Базы Данных. Отслеживание этих взаимоотношений облегчает определение степени воздействия инцидентов на услуги. Это также позволяет создавать отчет обо всех компонентах, вовлеченных в предоставление сервиса. Такая информация в дальнейшем может быть использована для улучшения услуг. У такой «сервисной» Конфигурационной Единицы могут быть взаимоотношения с другими единицами, такие как договоренности с заказчиком в форме Соглашения об Уровне Услуг. В приведенном примере услуга «В» полностью выходит за границы базы данных. Из рисунка видно, что не все Конфигурационные Единицы, участвующие в услуге «А», входят в сферу действия Конфигурационной Базы Данных (например, находятся в рассматриваемой организации), это означает, что услуга «А» не может полноценно поддерживаться.
Рис. 6.3. Охват Конфигурационной Базы Данных (источник: OGC)
После определения областей, включенных в сферу действия процесса, возможно определить этапы жизненного цикла Конфигурационных Единиц, которые будут содержаться в CMDB. Будут ли единицы со статусом «в разработке» или «заказана» включены в базу данных или же их включат в CMDB только после того, как они будут введены в работу? Преимущество включения в базу данных продуктов, находящихся на стадии разработки, состоит в том, что в этом случае их спецификации уже нельзя будет менять без получения одобрения, и их передача в рабочую среду будет происходить согласованно. От этого выбора будет зависеть мониторинг статуса CI в рамках процесса Управления Конфигурациями, к тому же это позволит расширить диапазон контроля жизненного цикла продукта в рамках этого процесса.
Уровень Детализации CMDB
Определение Уровня Детализации для каждого типа Конфигурационных Единиц является важным этапом разработки процесса Управления Конфигурациями. Здесь нет универсальных решений. На этом этапе анализируется информация о Конфигурационных Единицах. Для определения Уровня Детализации составляется схема взаимоотношений между задействованными Конфигурационными Единицами и выбирается требуемая глубина детализации CMDB. Кроме того, определяются имена и атрибуты для Конфигурационных Единиц.
При определении глубины Конфигурационной Базы Данных и взаимоотношений между Конфигурационными Единицами, отражаемыми в CMDB, нужно добиться сбалансированности требований к CMDB – с одной стороны, и загруженности персонала и имеющихся ресурсов – с другой. Количество взаимоотношений растет экспоненциально количеству уровней.
Взаимоотношения между Конфигурационными Единицами
Информация о взаимоотношениях между Конфигурационными Единицами является очень полезной для диагностики ошибок и прогнозирования доступности услуг. Можно определить много разных типов взаимоотношений на логическом и физическом уровнях.
Взаимоотношения на физическом уровне :
- Является частью : это взаимоотношения типа «parent/child» («родитель/ребенок»), например, дисковод является частью PC, а программный модуль – частью программы.
- Подключена к : например, PC подсоединен к сегменту сети.
- Требуется для : например, технические средства требуются для работы приложения.
Взаимоотношения на логическом уровне :
- Является копией : что-то является копией стандартного модуля, Базисной Конфигурации или программы.
- Связано с : процедурой, руководством и документацией, Соглашением об Уровне Услуг или группой заказчиков.
- Используется : например, Конфигурационная Единица, участвующая в предоставлении услуги, или программный модуль, к которому обращаются несколько программ.
Глубина CMDB
При определении Уровней Конфигурационных Единиц создается иерархия компонентов и элементов. Выбираются родительские Конфигурационные Единицы и определяется количество уровней, необходимых для их детализации. На самом высоком уровне находится сама ИТ-инфраструктура. Самым низким уровнем является наиболее детальный уровень, на котором необходимо осуществлять контроль. Включение Конфигурационных Единиц в Конфигурационную Базу Данных будет целесообразным только в том случае, если информация об этих CI будет полезна для других процессов ITIL. Определяя уровни и глубину Конфигурационной Базы Данных, следует помнить, что изменение в любой Конфигурационной Единице, зарегистрированной в CMDB, должно пройти через формальный процесс Управления Изменениями, прежде чем оно будет произведено. Поэтому регистрируя такой компонент как компьютерная мышь в Конфигурационной Базе Данных, создается ситуация, при которой любой Запрос на новую мышь уже не будет проходить как Запрос на Обслуживание , а должен будет проводиться через процесс Управления Изменениями в форме Запроса на Изменение (RFC). Это показательный пример для организаций, которые чрезмерно увлекаются детализацией.
При определении структуры Конфигурационной Базы Данных руководствуются следующими соображениями:
Чем больше уровней в базе данных, тем больше информации надо обрабатывать. Это ведет к увеличению рабочей нагрузки и созданию более сложной CMDB.
Чем меньше уровней, тем слабее контроль и хранится меньше информации об инфраструктуре.
Если степень детализации CMDB слишком мала, то становится невозможным эффективный мониторинг изменений, происходящих в компонентах нижнего уровня. В этом случае любое изменение в компонентах родительской Конфигурационной Единицы приведет к созданию варианта этой единицы . Например, PC с двумя видами жесткого диска будет проходить как Вариант «А» и Вариант «В». Если в дочернем компоненте много изменений, их нумерация становится сложной и трудной для сопровождения. Однако, если имеются уровни, расположенные ниже, то варианты можно поддерживать на соответствующем уровне. Для дочерних компонентов также можно регистрировать больше атрибутов и связывать с ними известные ошибки. Кроме того, при выполнении диагностики можно ставить такие вопросы, как: «Какой драйвер нужен для этого типа технических средств?», «К какому сегменту подсоединена сетевая плата?» и «Какая программа использует эту библиотеку?».
Соглашения о присвоении имен
У каждой Конфигурационной Единицы должно быть уникальное имя, которое отличает его от других единиц. Самым элементарным вариантом является простая система присвоения номеров с возможным делением на диапазоны для каждой области. Для вновь созданной Конфигурационной Единицы генерируется новый номер. Имена, по возможности, должны иметь смысловое значение для облегчения контактов с пользователями.
Соглашения о присвоении имен также можно использовать для физической маркировки Конфигурационных Единиц, для упрощения их идентификации при инвентаризации (аудите), в процессе сопровождения и регистрации инцидентов. Некоторые из предложенных библиотекой ITIL правил присвоения имен:
Метки на аппаратных средствах должны быть легко различимыми и легкими в чтении для пользователей, они должны прочно фиксироваться на поверхности. По договоренности со сторонним поставщиком услуг, в договорах о поддержке могут существовать ссылки на эти метки. Пользователи также должны указывать метки при сообщении об инциденте.
Контролируемые документы, такие как Соглашения об Уровне Услуг (SLA), процедуры и организационные схемы должны маркироваться с указанием номера Конфигурационной Единицы, номера версии и даты выпуска версии.
Копии программного обеспечения должны храниться в Библиотеке эталонного программного обеспечения (DSL), см. главу «Управление Релизами». Все компоненты программного обеспечения должны иметь номер CI, а инсталлированное ПО еще и номер версии и номер копии.
Атрибуты
Помимо структуры Уровней Конфигурационных Единиц, взаимоотношений между ними и соглашений о присвоении имен, детальная проработка модели CMDB также включает в себя описание атрибутов. Атрибуты используются для хранения информации, имеющей отношение к Конфигурационной Единице. При формировании CMDB можно использовать приведенные ниже атрибуты.
Таблица 6.1. Примеры атрибутов
В зависимости от возможностей используемых инструментальных средств (программного обеспечения) автоматизации Сервис-менеджмента в CMDB включается информация о взаимоотношениях с инцидентами и другие аналогичные им взаимоотношения в виде атрибутов или в какой-либо другой форме.
Таблица 6.2. Примеры других записей, связанных с Конфигурационными Единицами
Обычно номера соответствующих Конфигурационных Единиц входят в состав регистрационных записей инцидентов, проблем и изменений. Независимо от выбранного подхода должны поддерживаться взаимоотношения между Конфигурационными Единицами и следующими записями (табл. 2).
Таблица 6.3. Атрибуты взаимоотношений
Как уже обсуждалось, поддержка информации о взаимоотношениях между Конфигурационными Единицами является важным аспектом процесса Управления Конфигурациями. В зависимости от типа базы данных эти взаимоотношения могут быть представлены в виде атрибутов CI или в отдельной таблице.
В некоторых базах данных есть дополнительная возможность для записи изменений содержимого поля, что обеспечивает ведение журнала истории. Это помогает, например, получать информацию о простоях, ремонте, техническом обслуживании по истории состояния поля «Текущий статус», кроме того, это полезно для отслеживания истории владения.
Кроме рассмотренных выше атрибутов, необходимыми являются перечни атрибутов с технической информацией о каждом типе Конфигурационной Единицы. У каждого типа свои характеристики. Например, для PC это емкость жесткого диска, изготовитель BIOS и версия BIOS, размер оперативной памяти, IP-адрес и т. д. Многие инструменты системного администрирования фиксируют такую информацию, в этом случае достаточно установить связь с типом Конфигурационной Единицы, чтобы избежать дублирования информации. Однако следует помнить, что такие системы предоставляют текущую информацию, не указывая, является ли она результатом реализации утвержденных изменений или же это результат неавторизованных действий.
Для облегчения ввода и обновления атрибутов можно использовать открывающиеся меню . Можно устанавливать связи и с другими надежными источниками для получения информации о месторасположении Конфигурационной Единицы, пользователях, подразделениях, номерах телефонов, владельцах и параметрах бюджета. Вариантов много, но всегда следует учитывать нагрузку, связанную с поддержкой актуальности этих файлов.
Базисная Конфигурация
Базисная Конфигурация – это мгновенный снимок группы Конфигурационных Единиц, сделанный в определенный момент времени. Базисную Конфигурацию можно использовать в качестве:
Стандартных Конфигурационных Единиц для учета информации о стоимости;
Базы при разработке и тестировании новых Конфигураций;
Для выполнения возврата к исходному состоянию, если возникают проблемы с новой Конфигурацией после проведения изменений;
Стандарта для поставки Конфигураций пользователям, например, «стандартное рабочее место»;
Базы при установке нового программного обеспечения.
Стандартная рабочая станция является типичным примером Базисной Конфигурации. Ограничивая количество разных стандартных рабочих станций, можно облегчить оценку результатов и определение ресурсов, необходимых для реализации новых функций и улучшения их тестирования. Базисные Конфигурации также могут помочь в проведении политики комбинирования и планирования изменений, например, для пакетных релизов. Они способствуют сокращению затрат на Управление и облегчают планирование проектов.
Другим полезным применением Базисной Конфигурации является Каталог Продуктов. В нем даются Сертифицированные Конфигурации, которые можно использовать в ИТ-инфраструктуре и которые доступны для заказа пользователями. В этом случае новая Конфигурационная Единица является копией единицы из Каталога с ее номером и меткой.
До того как новая модель или продукт будут добавлены в инфраструктуру, они должны появиться в Каталоге. Для этого нужно принять решения по трем вопросам:
Бизнес : отвечает ли модель/продукт бизнес-интересам пользователя?
Финансы : приемлемы ли затраты на поддержку?
Влияние : приемлем ли уровень воздействия модели/продукта на услугу?
Регистрация
Первоначально База данных CMDB наполняется информацией из финансовых систем, записями о существующей ИТ-инфраструктуре, техническими данными от поставщиков. Регистрируется только информация из известных (проверенных) источников. Организация должна быть готова к поддержанию этой информации в актуальном состоянии.
6.4.3. Мониторинг статуса
Цикл жизни компонента можно разделить на несколько этапов, каждому из которых присваивается свой статус. Этапы зависят от тех характеристик ИТ-инфраструктуры, которые организация хочет регистрировать. Регистрация даты каждого изменения статуса дает важную информацию о жизненном цикле продукта: о времени заказа, времени инсталляции, о сопровождении и поддержке продукта.
Рис 6.6. Пример мониторинга статуса Конфигурационной Единицы
Статус компонента также помогает определить, какие действия можно выполнять с ним. Например, если составлен отчет об элементах со статусом «неэксплуатирующиеся запасные части», то эти технические средства нельзя перераспределять куда-либо еще без предварительного согласования, например, в рамках развертывания плана восстановления после чрезвычайных ситуаций. Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными изменениями или неавторизованными изменениями или инцидентами.
Может быть использована следующая классификация:
Новые Конфигурационные Единицы :
В разработке/заказе;
Протестирована;
Принята (по результатам тестирования).
Существующие Конфигурационные Единицы :
Получена (принята в операционную среду);
Открыт Запрос на Изменение (RFC) Конфигурационной Единицы, запрошена новая версия;
Изменение утверждено и включено в план изменений, новая Конфигурационная Единица и документация (также являющаяся Конфигурационной Единицей) будут предоставлены;
На обслуживании;
Не функционирует.
Архивированные Конфигурационные Единицы :
Выведена из операционной среды;
Исключена (deleted);
Удалена (removed);
Похищена;
Продана или истек срок аренды/лизинга;
В архиве в ожидании безвозмездного дарения, продажи или уничтожения;
Уничтожена.
Все Конфигурационные Единицы :
В наличии;
Получена по заказу или доступна новая версия;
Тестируется;
Одобрена для инсталляции;
Активная Конфигурационная Единица находится в использовании;
Запасные части.
6.4.4. Контроль
Для поддержания Конфигурационной Базы (CMDB) в актуальном состоянии необходимо эффективное Управление Информацией. При любом изменении зарегистрированных характеристик Конфигурационных Единиц или взаимоотношений между ними, вызванном выполнением любого действия, это изменение должно быть отражено в базе данных.
Примечание. Изменять характеристики Конфигурационных Единиц можно только путем проведения изменений авторизованных процессом Управления Изменениями; Управление Инцидентами может изменять только статус существующих Конфигурационных Единиц.
Управление Конфигурациями контролирует все ИТ-компоненты, существующие в организации, и отвечает за их регистрацию в системе. Аппаратные средства можно регистрировать при их заказе или получении, а программное обеспечение – при его включении в Библиотеку эталонного программного обеспечения (Definitive Software Library – DSL).
Одна из задач контроля – гарантировать регистрацию только авторизованных и включенных в Каталог Продуктов Конфигурационных Единиц. Для этого должно быть организовано активное взаимодействие процесса Управления Конфигурациями с поставщиками и процессами Управления Инцидентами, Проблемами и Изменениями.
Если по согласованию с Управлением Изменениями произведены некоторые изменения в ИТ-инфраструктуре, процесс Управления Конфигурациями обязан отразить эти изменения в Конфигурационной Базе Данных. Хотя публикации ITIL не дают четких указаний по этому вопросу, на практике ответственность за регистрацию Запросов на Изменение (RFC) происходит под контролем процесса Управления Изменениями . Формализованные записи об изменениях являются основным источником информации об изменениях в инфраструктуре, которая используется для обновления Конфигурационной Базы Данных. По существу процесс Управления Конфигурациями предъявляет требования к уровню зрелости процессов в организации, особенно к Управлению Изменениями, операционной средой и проведения закупок.
Добавление Конфигурационной Единицы;
Изменение статуса Конфигурационной Единицы, например, «работает» или «не работает» (полезно для процесса Управления Доступностью);
Изменение владельца Конфигурационной Единицы;
Изменение взаимоотношений Конфигурационной Единицы с другими Конфигурационными Единицами;
Удаление Конфигурационной Единицы;
Возникновение новых взаимоотношений Конфигурационной Единицы с каким-либо сервисом, другой Конфигурационной Единицей, документацией и т. д.;
Возобновление или изменение лицензии;
Обновление детальной информации о Конфигурационной Единице после аудита.
6.4.5. Верификация и аудит
Аудит проводится для проверки, насколько точно отражена текущая ситуация в CMDB. Например, инструментальные средства аудита могут автоматически выполнять анализ рабочих станций и формировать отчеты о текущей ситуации и статусе ИТ-инфраструктуры. Эта информация будет использоваться для проверки и обновления Конфигурационной Базы Данных. Аудит возможен в следующих ситуациях:
После внедрения новой Конфигурационной Базы Данных;
К примеру, спустя полгода с момента внедрения;
Перед серьезными изменениями и после них;
После чрезвычайных обстоятельств;
В любое другое удобное время.
При проведении аудита рассматриваются следующие вопросы:
Регистрируются ли в CMDB данные всех Запросов на Изменения на всех этапах их реализации, и контролирует ли процесс Управления Конфигурациями эту регистрацию?
Находится ли Конфигурационная База Данных в актуальном состоянии, если нет, то почему? Какое воздействие это оказывает на процесс Управления Изменениями (анализ текущего воздействия запланированных изменений)?
Производится ли присвоение имен новым Конфигурационным Единицам в соответствии с соглашением о присвоении имен?
Правильно ли используются варианты?
Правильно ли регистрируются Базисные Конфигурации и становятся ли они сразу же доступными к использованию?
Соответствует ли содержимое Библиотеки эталонного программного обеспечения (DSL) и Склада эталонного аппаратного обеспечения (DHS) информации в Конфигурационной Базе Данных? Если нет, то почему?
Аудиторские проверки также можно проводить, выбирая объекты случайным образом или проводить там, где Руководитель Процесса Управления Конфигурациями считает, что информация может быть некорректной. Если существует связь с автоматическими инструментальными средствами аудита, тогда можно делать аудит соответствующих областей или формировать по ним дельта-отчеты практически ежедневно.
Если обнаруживаются расхождения, то инструментальные средства аудита не должны автоматически обновлять Конфигурационную Базу Данных. Все расхождения свидетельствуют о том, что изменения были произведены в обход процесса Управления Изменениями, и теперь эти прецеденты должны быть изучены.
6.5. Контроль процесса
6.5.1. Отчеты и Ключевые показатели эффективности
В отчет по процессу Управления Конфигурациями возможно включение следующей информации:
Информация о качестве процесса;
Расхождения между регистрационными записями и реальной ситуацией, обнаруженные во время аудита (дельта);
Количество случаев, когда используется неавторизованная Конфигурация;
Количество случаев, когда зарегистрированная Конфигурация не находилась на своем месте;
Отклонения на Уровне Атрибутов, обнаруженные аудиторскими проверками;
Длительность обработки Запросов на Регистрацию информации;
Перечень Конфигурационных Единиц, в отношении которых количество зарегистрированных инцидентов или изменений превышало заданную величину;
Статистическая информация о структуре и составе ИТ-инфраструктуры;
Данные о росте и другая информация о развитии ИТ-инфраструктуры;
Сводные данные, отчеты и предложения по улучшению, например, рекомендации по изменению охвата (границ) процесса и Уровня Конфигурационных Единиц, отслеживаемых процессом Управления Конфигурациями, связанные с изменениями в бизнесе, технических средствах, рыночных ценах и т. д.;
Расходы на персонал при внедрении процесса.
6.5.2. Критические факторы успеха
Условием успешной работы по Управлению Конфигурациями является получение необходимой информации для поддержания базы данных в актуальном состоянии. Это означает, что обязательно нужно поддерживать взаимосвязи с процессом Управлением Изменениями, а для регистрируемых характеристик всегда должен быть найден тот, кому они требуются.
Внедрение процесса важно правильно разбить на этапы. Попытки ввести требование регистрации компонентов инфраструктуры без соответствующей подготовки обычно заканчиваются неудачей, т. к. дисциплина, необходимая для Управления Конфигурациями, не может появиться мгновенно. Записи, которые велись до ввода процесса, должны быть выведены из обращения во избежание дублирования. При запуске процесса в работу важно продемонстрировать несколько явных преимуществ, которые дает Управление Конфигурациями (быстрые удачи). Кроме того, важно, чтобы обязанности по регистрации были закреплены за теми сотрудниками, у кого есть не только необходимые навыки, но и должное отношение к работе.
6.5.3. Функции и роли
Работа процессов происходит в горизонтальной плоскости, относительно вертикальной иерархической структуры организации. Это возможно только при четком распределении ответственностей и полномочий по их реализации. Для повышения гибкости может быть использован ролевой подход. В небольших организациях или в силу экономических причин возможно комбинирование ролей, например, Руководителя Процесса Управления Изменениями и Управления Конфигурациями. В задачи Руководителя Процесса Управления Конфигурациями может входить следующее:
Предложения по изменению сферы действия и Уровня Детализации Процесса Управления Конфигурациями;
Информированность всей организации о существующем Процессе Управления Конфигурациями;
Обеспечение процесса персоналом и его обучение;
Разработка системы идентификации и соглашений о присвоении имен;
Разработка интерфейсов с другими процессами;
Оценка существующих систем и внедрение новых систем автоматизации процесса;
Планирование и внедрение системы наполнения информации в Конфигурационной Базе Данных;
Формирование отчетов;
Организация аудиторских проверок.
6.6. Затраты и проблемы
6.6.1. Затраты
Расходы на запуск и реализацию процесса Управления Конфигурациями во многом зависят от области действия и Уровня Детализации Процесса. В число расходов входят затраты на аппаратное и программное обеспечение и персонал. Расходы на аппаратное и программное обеспечение состоят из затрат на:
Дополнительные технические средства и их конфигурирование;
Дополнительное программное обеспечение и его конфигурирование;
Лицензии, пропорционально количеству пользователей;
Разработку приложений и базы данных, наполнение их данными, настройку на требования заказчика и внедрение;
Поддержку и сопровождение базы данных;
Дополнительный персонал, необходимый для работы процесса.
6.6.2. Проблемы
ИТ-организация должна четко определить свои намерения относительно того, какие характеристики ИТ-инфраструктуры должны регистрироваться и обеспечить необходимые руководящие ресурсы для исполнения намеченного. В организации должна существовать твердая приверженность в использовании Конфигурационной Базы Данных (CMDB). Необходимо произвести перенос всех ранее использованных данных из других баз в CMDB.
На успешную реализацию процесса могут повлиять следующие проблемы:
Неправильно определен охват (границы) Конфигурационной Базы Данных или Уровень Детализации Конфигурационных Единиц – если сфера действия Конфигурационной Базы Данных слишком мала, то важные части инфраструктуры будет невозможно проверить, исправить, защитить или восстановить. Если же наоборот охват слишком большой, то громоздкость базы данных будет препятствием, замедляющим все процессы Сервис-менеджмента. При большом количестве уровней, атрибутов и взаимоотношений будет трудно поддерживать базу данных в актуальном состоянии. Слишком низкий Уровень Детализации приведет к регистрации неполной информации о Конфигурационных Единицах и связанных с ними инцидентах, проблемах, известных ошибках и Запросах на Изменение.
Неадекватная система ручной обработки – некоторые организации стараются как можно дольше хранить данные на бумажных носителях и покупают автоматизированные средства только тогда, когда работать становится невозможно. Это может приводить к задержкам в работе, путанице, потере персонала и ресурсов и т. д. Рекомендуется закупать автоматизированные средства обработки как можно раньше, ориентируясь на функциональные требования процесса.
Влияние срочных изменений – всегда будут возникать ситуации, когда нужно срочно произвести изменение. Часто это происходит во внерабочее время. Если изменяемые Конфигурационные Единицы находятся под контролем Конфигурационной Базы Данных, то рекомендуется немедленно произвести запись результатов изменения в CMDB, но может возникнуть ситуация, когда отсутствует сотрудник, ответственный за эту задачу. В этом случае регистрацию изменений и обновление CMDB необходимо будет сделать при первой возможности.
Чрезмерно плотный график работы – если график изменений (Запросов на Изменения) не оставляет времени на выполнение действий в рамках процесса Управления Конфигурациями, то в работе могут появляться задержки и данный процесс будет восприниматься как препятствие. Следует составлять реалистичные графики, основываясь на прошлом опыте.
Понимание руководством важности процесса – поскольку Управление Конфигурациями является относительно новым процессом, не всегда достаточно видимым для сотрудников, персонал может сопротивляться его принятию. Должна быть достаточная приверженность к необходимости процесса со стороны руководства. Поэтому руководитель процесса должен информировать об Управлении Конфигурациями сотрудников компании и пропагандировать этот процесс в компании. Опыт показывает, что затраты на реализацию процесса будут значительно ниже, если процесс Управления Конфигурациями представлен в компании как отдельная дисциплина с закрепленным за ней персоналом и руководителем, отвечающим за процесс.
Попытки обхода процесса – в состоянии спешки персонал может пытаться обойти правила работы процесса Управления Конфигурациями. Если такая ситуация возникает регулярно, то после разъяснения негативных последствий таких действий возможно применение дисциплинарных мер.
Примечания:
Configuration Items – CI.
Configuration Management Database – CMDB.
Service Request.
Варианты используются, если имеются несколько существующих одновременно форм Конфигурационной Единицы, т. е. если существуют параллельные отношения. Версии появляются, например, если одновременно используется и новая, и старая версии Конфигурационной Единицы, т. е. когда существуют последовательные отношения. Использование этих двух концептуальных понятий помогает при планировании изменений. Если в последующем каждый из вариантов будет разрабатываться отдельно, то для каждого из них нужно вводить отдельную систему нумерации версий, что нежелательно, т. к. это делает ИТ-инфраструктуру более сложной и ведет к увеличению работ по сопровождению. В большинстве случаев рекомендуется продолжать разработку исходного экземпляра всех вариантов, а там, где возможно, использовать новую версию для создания необходимых вариантов. – Прим. автора.
Naming Convention.
Definitive Software Library – DSL.
Т. е. меню со списком выбора вариантов. -Прим. ред.
В то же время Управление Конфигурациями сохраняет наивысшую ответственность за актуальность Конфигурационной Базы Данных, то есть возможно делегирование полномочий (но не ответственности) по регистрации результатов изменений из процесса Управления Конфигурациями в процесс Управления Изменениями. – Прим. ред.
Программная инженерия
Конфигурационное управление
(Software Configuration Management)
Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK® , 2004. Содержит перевод описания области знаний SWEBOK® “Software Configuration Management”, с
комментариями и замечаниями.
"Основы программной инженерии" разработаны на базе IEEE Guide to SWEBOK® 2004 в соответствии с IEEE SWEBOK 2004 Сopyright and Reprint Permissions: "This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy."
Русский перевод SWEBOK 2004 с замечаниями и комментариями подготовлены Сергеем Орликом
при участии Юрия Булуя . Дополнительные главы написаныСергеем Орликом . Текст расширений SWEBOK отмечен ццветом, отличным от перевода оригинального текста.
"Основы программной инженерии" Сopyright © 2004-2010 Сергей Орлик . Все права защищены.SWEBOK Сopyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved.
Официальный сайт “Основ программной инженерии” (по SWEBOK) - http://swebok.sorlik.ru
Основы программной инженерии (по SWEBOK) | ||
Программная инженерия. Конфигурационное управление. | ||
Программная инженерия | ||
Конфигурационное управление (Software Configuration Management) | ||
Программная инженерия.......................................................................................................................... | ||
Конфигурационное управление (Software Configuration Management) ................................................ | ||
1. Управление SCM-процессом (Management of SCM Process) ....................................................... | ||
Организационный контекст SCM (Organizational Context for SCM) ......................................... | ||
Ограничения и правила SCM (Constraints and Guidance for the SCM Process)....................... | ||
Планирование в SCM (Planning for SCM)................................................................................. | ||
План конфигурационного управления (SCM Plan) .................................................................. | ||
Контроль выполнения SCM-процесса (Surveillance of Software Configuration Management) .. | ||
2. Идентификация программных конфигураций (Software Configuration Identification) .................. | ||
Идентификация элементов, требующих контроля (Identifying Items to Be Controlled).......... | ||
Программная библиотека (Software Library) .......................................................................... | ||
3. Контроль программных конфигураций (Software Configuration Control) ..................................... | ||
Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving | ||
Software Changes) ........................................................................................................................ | ||
Реализация изменений (Implementing Software Changes)..................................................... | ||
Отклонения и отказ от изменений (Deviations and Waivers) .................................................. | ||
4. Учет статусов конфигураций (Software Configuration Status Accounting).................................... | ||
Информация о статусе конфигураций (Software Configuration Status Information)................ | ||
Отчетность по статусу конфигураций (Software Configuration Status Reporting)................... | ||
5. Аудит конфигураций (Software Configuration Auditing) ................................................................ | ||
Функциональный аудит программных конфигураций (Software Functional Configuration Audit) |
||
...................................................................................................................................................... | ||
Физический аудит программных конфигураций (Software Physical Configuration Audit) ....... | ||
Внутренние аудиты базовых линий (In-process Audits of Software Baseline) ........................ | ||
6. Управление выпуском и поставкой (Software Release Management and Delivery) ..................... | ||
Сборка программного обеспечения (Software Building)......................................................... | ||
Управление выпуском программного обеспечения (Software Release Management)........... | ||
Система может быть определена как коллекция компонент, организованных для выполнения заданных функций или реализации комплекса функциональности (IEEE 610.12-90, Standard Glossary for Software Engineering Terminology).Конфигурация системы – функциональные и/или физические характеристики аппаратного, программно-аппаратного, программного обеспечения или их комбинации, сформулированные в технической документации и реализованные в продукте. Конфигурация также может восприниматься как сочетание конкретных версий аппаратных, программно-аппаратных или программных элементов, объединенных вместе, в соответствии с заданными процедурами сборки и отвечающих определенному назначению.Конфигурационное управление (CM - Configuration Management), в свою очередь, дисциплина идентификации конфигурации системы в определенные (заданные) моменты времени, с целью систематического контроля изменений конфигурации, а также поддержки и сопровождения целостной и отслеживаемой (трассируемой) конфигурации на протяжении всего жизненного цикла системы.
Конфигурационное управление формально определяется глоссарием IEEE 610 как “дисциплина приложения технических и административных указаний (инструкций) и контроля (надзора) для: идентификации и документирования функциональных и физических характеристик элементов конфигураций, контроля (управления) изменений этих характеристик, записи (сохранения) и ведения отчетности по обработке изменений и статусу их реализации, а также проверки (верификации) соответствия заданным требованиям.”
В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207, конфигурационное управление в области программного обеспечения (“6.2 Управление конфигурацией” по ГОСТ) –Software Configuration Management (SCM*) – один из вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающих проектный менеджмент, деятельность по разработке и сопровождению, обеспечению качества, а также, заказчиков и пользователей конечного продукта.
http://swebok.sorlik.ru
Основы программной инженерии (по SWEBOK)
Программная инженерия. Конфигурационное управление.
* в ряде источников можно увидеть аббревиатуру SCCM – Software Configuration and Change Management. При том, что в понимании SWEBOK и соответствующих стандартов, содержание SCM и SCCM тождественно, термин SCCM иногда используется для того, чтобы подчеркнуть принципиальную значимость управления изменениями как составной части конфигурационного управления.
Концепции конфигурационного управления применяются в отношении всех элементов, которые необходимо контролировать (несмотря на то, что существуют определенные отличия между конфигурационным управлением в приложении к аппаратному и программному обеспечению).
SCM-деятельность тесно связана с работами по обеспечению качества программного обеспечения (Software Quality Assurance - SQA ). В соответствии с определением области знаний SWEBOK “Качество программного обеспечения” (Software Quality), SQA-процессы обеспечивают гарантию того, что программные продукты и процессы жизненного цикла в проекте соответствуют заданным требованиям, за счет планирования и выполнения работ, направленных на достижение определенного (приемлемого,прим. автора ) уровня качества создаваемого программного продукта. SCM-деятельность помогает в достижении этих SQA-целей. В контексте некоторых проектов, определенные работы по конфигурационному управлению задаются требованиями SQA (например,
в IEEE 730-02 “Standard for Software Quality Assurance Plans”).
Работы по конфигурационному управлению <программного обеспечения> включают: управление и планирование SCM-процессов, идентификацию программных конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также управление выпуском (release management) и поставкой
На рисунке 1 изображено стилизованное представление этих работ.
Рисунок 1. Работы по конфигурационному управлению (SCM Activities)
Данная область знаний связана со всеми другими областями знаний и дисциплинами программной инженерии, так как объектами приложения SCM являются все артефакты, создаваемые и используемые в процессах программной инженерии.
К сожалению, SCM-деятельность во многих проектных командах сводится лишь кконтролю версий (version control) исходных текстов и, в лучшем случае, документации (причем не проектной документации, в целом, а документации на создаваемое программное обеспечение).Попытка ограничить конфигурационное управление только вопросами контроля версий , в какой-то степени,
является результатом непонимания того, что результаты проекта – это не только исходный код, исполняемые модули и пользовательская документация, но и все то, что создавалось (пусть и для
http://swebok.sorlik.ru
Основы программной инженерии (по SWEBOK)
Программная инженерия. Конфигурационное управление.
решения тактических задач, как это часто бывает с некоторыми моделями и результатами пилотных работ по созданию прототипов) на протяжении всего проекта . Активами проекта (результатами, артефактами) являются и описания бизнес-процессов и бизнес-сущностей, и архитектурные модели, и требования, и план проекта/проектные задачи (как комплекс параметров, связанных с распределением ресурсов), и запросы на изменения (включая информацию о дефектах) и многое другое. Безусловно, упрощение вопросов конфигурационного управления до уровня управления версиями, с коньюктурной точки зрения, выгодно многим поставщикам соответствующих инструментальных средств.В определенных случаях , особенно, для малых проектов или временно используемых/”одноразовых” систем (например, по односторонней, “one-way” миграции данных из унаследованной системы в новую),упрощенный взгляд на конфигурационное управление может быть вполне обоснован . Однако, как это ни прискорбно, часто приходится наблюдать позиционирование такой, с позволения сказать, “практики”, как некоего “стиля гибкой работы”, подменяющей реальную динамику и гибкость agile-подходов (например, XP) отсутствием управления (важно понимать и помнить, что управление далеко не всегда является директивным), как такового (например, по определению содержания проекта на основе консенсуса проектной команды и вовлеченных в проектные работы представителей заказчика). В свою очередь, даже когда все активы проекта находятся под контролем соответствующих SCM-систем, необходимо осознавать,
что конфигурационное управление предполагаетпостоянно действующий процесс, а не просто комплекс определенных периодически выполняемых операций. Только восприятие SCMдеятельности в качестве инфраструктурной основы процессов жизненного цикла может обеспечить эффективность управления программными проектами, то есть – достижение поставленных целей и создание результатов, удовлетворяющих заданным критериям. В то же время, конфигурационное управление - необходимое, но не достаточное условие, так как только совокупность процессов жизненного цикла, включая управление требованиями, проектирование и другие, не менее важные аспекты, определяют весь комплекс работ по созданию программных систем.
Рисунок 2. Область знаний “Конфигурационное управление”
1. Управление SCM-процессом (Management of SCM Process)
SCM-деятельность контролирует эволюцию и целостность продукта, идентифицируя его элементы, управляя и контролируя изменения, а также, проверяя, записывая и обеспечивая отчетность по конфигурационной информации. С инженерной точки зрения, SCM способствует разработке и реализации изменений. Успешное внедрение SCM требует точного планирования и управления. Это,
http://swebok.sorlik.ru
Основы программной инженерии (по SWEBOK)
Программная инженерия. Конфигурационное управление.
в свою очередь, предполагает понимание организационного контекста и тех ограничений, которые связаны с проектированием и реализацией процесса конфигурационного управления.
1.1 Организационный контекст SCM (Organizational Context for SCM)
Для планирования SCM-процесса необходимо понимать организационный контекст и связи между организационными элементами. SCM-работы предполагают взаимодействие с другими аспектами проектной деятельности (не путайте с управлением проектами – это, при всей своей значимости, лишь один из видов проектной деятельности и организационными элементами.
Организационные элементы, отвечающие за процессы поддержки программной инженерии, могут быть структурированы несколькими способами. Несмотря на то, что ответственность за выполнение определенных SCM-задач может быть назначена (принята или ассоциирована, в зависимости от управленческих принципов и установок, т.е. общего менеджмента - general management) различным частям(лицам, группам, подразделениям и т.п. ) организации, например, структуре, отвечающей за разработку программного обеспечения, общая ответственность за конфигурационное управление часто возлагается на отдельный (специализированный) организационный элемент или назначенную персону.
Программное обеспечение часто разрабатывается как составная часть бо льшей системы, содержащей аппаратные и программно-аппаратные/встраиваемые элементы. В этом случае, SCMдеятельность ведется параллельно с работами по конфигурационному управлению (CM) в отношении аппаратной или программно-аппаратной части, строго согласуясь с общим конфигурационным управлением на уровне системы, в целом. Ряд источников (см. библиографию SWEBOK, связанную с данной областью знаний) описывает SCM в сочетании с контекстом, в рамках которого проводится такая деятельность.
SCM может играть роль интерфейса к работам, направленным на обеспечение качества (quality assurance), вытекающим, например, из отслеживания записей <по изменениям> и несогласующихся элементов (например, выявленным в процессе сборки очередной версии системы, прим. автора ). С точки зрения составителей <данной области знаний SWEBOK>, некоторые элементы, находящиеся под управлением SCM <процесса>, могут также служить объектами рассмотрения в рамках организационных программ по обеспечению качества. Управление несогласующемися элементами обычно относится к работам по управлению качеством. Однако, SCM может обеспечить существенную помощь в отслеживании (трассировке) и создании отчетности по элементам программных конфигураций, попадающих в такую <проблемную> категорию.
SWEBOK отмечает, что возможно тесное взаимодействие между организационными структурами, отвечающими за разработку и сопровождение (и SCM играет роль инфраструктуры, обеспечивающей такую связь ).
В зависимости от контекста, существует множество подходов и практик в части выполнения задач конфигурационного управления в приложении к программному обеспечению. Часто, одни и те же инструменты поддерживают и разработку, и сопровождение, обеспечивая достижение целей и содержания SCM.
1.2 Ограничения и правила SCM (Constraints and Guidance for the SCM Process)
Ограничения и правила в отношении процесса конфигурационного управления порождаются различными источниками. Политики и процедуры, формулируемые на корпоративном или другом организационном уровне, могут влиять или предписывать структуру и реализацию SCM-процесса для заданного проекта. Кроме того, контракт между заказчиком и поставщиком может содержать положения, затрагивающие процесс конфигурационного управления. Например, может требоваться проведение определенных процедур проверки (аудита) или специфицирован набор элементов (активов, артефактов), передаваемых под управление <процедур и системы> конфигурационного управления (или в части формализации обработки и контроля реализации запросов на изменения, поступающих от заинтересованных лиц ). Когда разрабатываемый программный продукт потенциально затрагивает аспекты публичной безопасности, могут налагаться определенные ограничения со стороны соответствующих регулирующих органов (например, USNRC Regulatory Guide 1.169, “Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear
http://swebok.sorlik.ru
Основы программной инженерии (по SWEBOK)
Программная инженерия. Конфигурационное управление.
Power Plants”, U.S. Nuclear Regulatory Commission, 1997). Наконец, на структуру и реализацию SCM-
процесса в проекта влияют выбранные (с точки зрения модели и адаптированных характеристик) процессы жизненного цикла и инструменты, применяемые для реализации программной системы.
Рекомендации по структуре и реализации SCM-процесса могут быть также результатом применения лучших практик (best practices), представленных в стандартах, выпущенных соответствующими стандартизирующими организациями. Лучшие практики также отражены в моделях совершенствования и оценки процессов, например, в CMMI – Capability Maturity Model Integration Института программной инженерии (SEI – Software Engineering Institute) университета Карнеги-
Меллон (Carnegie-Mello University) и ISO/IEC 15504 (SPICE) “Software Engineering – Process Assessment”.
1.3 Планирование в SCM (Planning for SCM)
Планирование процесса конфигурационного управления для заданного проекта должно согласовываться с организационным контекстом, соответствующими ограничениями, общепринятыми рекомендациями, а также характеристиками и природой самого проекта (например, его размером или значимостью). Основные работы, проводимые при планировании SCMдеятельности включают:
Идентификацию программных конфигураций (Software Configuration Identification)
Контроль конфигураций (Software Configuration Control)
Учет статусов конфигураций (Software Configuration Status Accounting)
Аудит конфигураций (Software Configuration Auditing)
Управление выпуском и поставкой (Software Release Management and Delivery)
Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного управления, как организационные вопросы, обязанности, ресурсы и расписание, выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а также, контроль интерфейсов <взаимодействия программных модулей>. Результаты планирования сводятся в план конфигурационного управления (SCM Plan - SCMP ), обычно, являющийся объектом оценки и аудита в рамках деятельности по обеспечению качества (SQA – Software Quality Assurance).
1.3.1 Организация и обязанности (SCM organization and responsibilities)
Для предотвращения путаницы в том, кто будет выполнять заданные работы и задачи конфигурационного управления, должны быть четко идентифицированы организации (организационные структуры), вовлеченные в SCM-процесс. Конкретные обязанности по выполнению заданных работ и задач SCM должны быть назначены соответствующим организационным сущностям. Также, должны быть идентифицированы общие полномочия и пути отчетности, даже если это выполняется в процессе планирования управления проектом или деятельности по обеспечению качества.
1.3.2 Ресурсы и расписание (SCM resources and schedules)
В процессе планирования конфигурационного управления идентифицируется персонал и инструменты, привлекаемые для выполнения соответствующих работ и задач SCM. Планирование касается вопросов определения расписания, устанавливая последовательность задач конфигурационного управления и идентифицируя их связь с расписанием проекта и его вехами, определенными на стадии планирования проекта. Также должны быть специфицированы требования по обучению персонала, необходимые для реализации планов.
1.3.3 Выбор инструментов и реализация (Tool selection and implementation)
SCM-деятельность поддерживается различными типами инструментальных средства и процедур по их использованию. В зависимости от ситуации, эти инструменты могут включать комбинацию различных возможностей – автоматизированные средства могут решать отдельные задачи SCM, интегрированные средства могут обслуживать потребности многих участников процесса программной инженерии (например, SCM, разработку, проверку и аттестацию и т.п.). Значимость инструментальной поддержки конфигурационного управления (как и других аспектов деятельности в области программной инженерии) растет с каждым днем вместе со сложностью внедрения, ростом
http://swebok.sorlik.ru
Основы программной инженерии (по SWEBOK)
Программная инженерия. Конфигурационное управление.
размера проектов и сложности проектного окружения. Возможности инструментальных средств развиваются для обеспечения поддержки:
SCM-библиотек (проектно-ориентированных баз знаний,прим. автора )
Запросов на изменения (software change request - SCR) и процедур утверждения (approval)
Управления кодом (и связанных рабочих продуктов) и изменениями
Отчетности по статусу конфигураций и сбору соответствующих метрических показателей
Аудиту конфигураций
Управлению и отслеживанию <состояния и полноты> программной документации
Выполнению задач по сборке программных продуктов и их модулей
Управлению, контролю и поставке выпусков (релизов) программных продуктов
Инструменты, используемые для обеспечения конфигурационного управления, могут также предоставлять метрики, необходимые для совершенствования процессов. SWEBOK обращает внимание (рекомендуя соответствующий первоисточник ) на следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and Progress) и индикаторы качества – поток изменений (Change Traffic), стабильность <конфигураций> (Stability), раздробленность (Breakage), модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility), среднее время между сбоями (MTBF – Mean Time Between Failures), зрелость/полнота <информации> (Maturity).
Отчетность по этим индикаторам может быть организована различным образом, например, по элементам конфигураций или по типу запросов на изменения.
Рисунок 3 демонстрирует отображение инструментальных возможностей и процедур на работы по конфигурационному управлению.
Рисунок 3. Характеристики SCM-инструментов и связанные процедуры.
В этом примере система управления кодом поддерживает программные библиотеки контролируя доступ к элементам библиотек, координирует действия множества пользователей и помогает в проведении рабочих процедур. Другие инструменты поддерживают процесс сборки и выпуска программного обеспечения и документации на основе программных элементов, содержащихся в библиотеках. Инструменты для управления запросами на изменения программного обеспечения используются для контролируемых <системой конфигурационного управления> программных элементов. Другие инструменты могут обеспечивать управление базой данных и необходимыми менеджменту отчетными средствами, а также деятельностью по разработке и обеспечению качества. Как уже упоминалось выше, в рамках SCM-системы может быть объединен целый ряд
http://swebok.sorlik.ru
Основы программной инженерии (по SWEBOK)
Программная инженерия. Конфигурационное управление.
инструментов различных типов. При этом сама система конфигурационного управления может быть тесно связана и поддерживать другие виды работ, касающиеся не только SCM.
В процессе планирования инженеры выбирают те SCM-средства, которые применимы для решения стоящих перед ними задач.
Вопрос выбора SCM-системы должен решаться исходя из целей, сформулированных в отношении используемых процессов программной инженерии и уровня зрелости этих процессов. Кроме того, необходимо учитывать и вопросы унификации программных средств, используемых для поддержки инфраструктуры разработки и сопровождения всего портфеля программных проектов, выполняемых в организации. В силу фундаментальной значимости SCM-системы для обеспечения базовых процессов программной инженерии и управления всеми проектными активами, принимать решение об использовании той или иной SCM-системы для каждого отдельно взятого проекта выглядит необоснованным. SCM-система, система управления требованиями (более чем желательно, связанная с SCM), средства бизнес-моделирования и проектирования, среды разработки – все это должно быть стандартизировано в рамках организации, за исключением тех случаев, когда требования в отношении тех или иных инструментальных средств сформулированы со стороны заказчика и являются составной частью требований, предъявляемых к проекту. Возвращаясь к вопросу выбора SCM-системы, безусловно, необходимо учитывать мнение инженеров, однако, сложившиеся привычки не должны “перевешивать” функциональность предлагаемых к унификации SCM-средств, обеспечиваемую ими доступность и прозрачность информации о состоянии проекта в любой момент времени и, конечно, возможность эффективного администрирования активов проекта, в том числе, в контексте необходимых для этого трудозатрат.
В процесс планирования рассматриваются аспекты, которые могут “всплыть” в процессе внедрения (и, даже, на этапе эксплуатации ) выбираемой системы конфигурационного управления. В частности, обсуждаются и вопросы возможных “культурных” изменений, если это необходимо (с точки зрения поставленных целей – проекта и/или совершенствования процессов ). Дополнительная информация, затрагивающая SCM-инструментарий, представлена в области знаний SWEBOK “Software Engineering Tools and Methods”.
1.3.4 Контроль поставщиков/подрядчиков (Vendor/Subcontractor Control)
Программные проекты могут требовать необходимости приобретать или использовать уже приобретенное программное обеспечение – компиляторы и другие инструменты (среды разработки, библиотеки компонент ). Планирование должно касаться вопросов – надо и, если надо, то как помещать эти инструменты (например, интегрируя в программные библиотеки проекта) под управление SCM-системы и как их изменения и обновления будут оцениваться и управляться.
Аналогичные соображения существуют и в отношении программного обеспечения, создаваемого подрядчиками. В этом случае, в отношении SCM-процесса подрядчика предъявляются специальные требования со стороны заказчика и они вносятся в контракт, предполагая не только возможность мониторинга, но и соответствие его возможностей заданным требованиям. В последнее время все чаще отмечается важность доступности SCM-информации для эффективного мониторинга соответствия (compliance monitoring).
1.3.5 Контроль интерфейсов (Interface Control)
Когда программные элементы должны связываться с другими программными или аппаратными элементами, изменения в одних элементах могут влиять на другие элементы. Планирование SCMпроцесса рассматривает, в частности, как будут идентифицироваться связанные элементы и как будут управляться и сообщаться их изменения. Конфигурационное управление может быть частью более масштабного процесса системного уровня (т.е. в рамках всей системы, к которой относятся соответствующие программные элементы) по определению и контролю интерфейсов, включая описание в соответствующих спецификациях интерфейсов, планах контроля интерфейсов и других документах. В этом случае, SCM-планирование контроля интерфейсов проводится в контексте процесса системного уровня.
1.4 План конфигурационного управления (SCM Plan)
http://swebok.sorlik.ru
Основы программной инженерии (по SWEBOK)
Программная инженерия. Конфигурационное управление.
Результаты SCM-планирования для заданного проекта определяются вплане конфигурационного управления (Software Configuration Management Plan, SCMP ), который является документом,
используемом в качестве описание SCM-процесса. Он всегда поддерживается в актуальном состоянии (обновляясь и утверждаясь по мере внесения в него необходимых изменений) на протяжении всего жизненного цикла. При описании SCM-плана обычно необходимо разработать ряд детальных процедур, определяющих как конкретные требования будут выполняться в повседневной деятельности.
Создание и сопровождение плана конфигурационного управления основывается на информации, получаемой в процессе работ по планированию. Рекомендации по созданию и сопровождению SCMP можно найти, например, в одном из ключевых SCM-стандартов IEEE 828-98 “Standard for Software Configuration Management Plans” . Этот стандарт описывает требования к информации, содержащейся в плане конфигурационного управления, а также определяет шесть категорий SCMинформации, содержащейся в плане (обычно, представленных в виде соответствующих разделов,
Введение (Introduction) – описывает цели, содержание и используемые термины.
Управление (SCM Management) – описывает структуру, обязанности, полномочия, политики, директивы (указания, обязательные для исполнения) и процедуры.
Работы (SCM Activities) – определяет идентификацию конфигураций, их контроль и т.п.
Расписание (SCM Schedule) – определяет связь работ по конфигурационному управлению с другими аспектами и процессами проектной деятельности
Ресурсы (SCM Resources) – описывает инструменты, физические ресурсы, персонал и т.п.
Сопровождение плана (SCMP Maintenance) – определяет правила, по которым в план вносятся изменения и описывает как эти изменения внедряются в повседневный SCMпроцесс.
1.5 Контроль выполнения SCM-процесса (Surveillance of Software Configuration Management)
После того, как внедрен процесс конфигурационного управления, может быть необходимо контролировать (проводить надзор) над SCM-процессом для обеспечения того, что SCM-план исполняется надлежащим образом. В ряде случаев определяются конкретные требования по обеспечению качества (SQA), контролирующие исполнение процессов и процедур конфигурационного управления. Для этого может быть необходимо введение соответствующих полномочий и назначение обязанностей по контролю выполнения задач SCM. Аналогичные полномочия и обязанности по надзору над SCM-процессом могут существовать в контексте SQAдеятельности.
Использование интегрированных SCM-инструментов с возможностью контроля процесса может сделать процедуру надзора более легкой и прозрачной. Некоторые инструменты предоставляют высокий уровень настраиваемости для обеспечения гибкой адаптации процессов. Другие инструменты являются менее гибкими, диктуя те или иные процессы и их характеристики. Требования контроля (надзора), с одной стороны, и уровень гибкости и адпатируемости, с другой, являются определяющими критериями выбора того или иного инструмента.
1.5.1 Метрики и процесс количественной оценки в SCM (SCM measures and measurement)
Количественные показатели (метрики) могут определяться для обеспечения информации о разрабатываемом продукте или для оценки исполнения самого процесса конфигурационного управления. Связанной целью SCM-мониторинга может быть и раскрытие возможностей по совершенствованию процесса (не только SCM-процесса, но и других процессов программной инженерии ). Количественная оценка SCM-процессов предоставляет хорошие средства для мониторинга эффективности деятельности по конфигурационному управлению на постоянной основе. Эти измерения полезны для оценки текущего состояния процесса и проведения сравнений во времени(как прогресса в отношении развития продукта, так и качества выполнения процесса, как такового). Анализ измерений позволяет понять причины изменения процесса и внести соответствующие коррективы в план конфигурационного управления (SCMP).
Программные библиотеки и различные возможности SCM-средств предоставляют источники для получения информации о характеристиках SCM-процесса (наравне с проектной информацией и
Применение средств конфигурационного управления (SCM - Software Configuration Management) тесно связано с методиками конфигурационного управления, которые существуют в рамках и определяются организацией процесса разработки ПО. Связь эта очень тесная, другими словами, организация процесса разработки и, главное, ее тенденции выражаются в конфигурационном управлении и его средствах. Вот об этих трех взаимосвязанных вещах и пойдет речь.
Что такое конфигурационное управление
Информация - одна из самых изменчивых вещей в мире. Но более всего изменчива информация на этапе разработки, поскольку эта деятельность как раз и заключается во внесении целенаправленных изменений. Групповая разработка, ставшая уже делом обычным, катастрофически увеличивает непостоянство системы и ее сложность.
Сложность информационных систем делает их недоступными непосредственному представлению. В порядке ли собственный костюм, легко проверить, взглянув в зеркало, но нет возможности охватить взглядом состояние реальных информационных систем, а если бы даже такая возможность была, то человеческое сознание просто не способно воспринимать системы такой сложности.
Сопровождать быстро и неочевидно меняющиеся информационные системы также трудно. Вы никогда не можете быть вполне уверены, что именно вы сопровождаете. Например, если вы сопровождаете некоторый программный продукт и кто-то вам звонит по телефону и сообщает о том, что в программе ошибка, то прежде всего вы спросите, в какой именно версии программы она обнаружена. Из-за непостоянства программного обеспечения пользователи имеют право требовать (и должны получать!) необходимые им изменения.
Основная проблема конфигурационного управления и состоит в управлении изменениями независимо от их сущности, в отличие от содержательной части разработки, где изменения важны именно в связи с их значением.
Проблема изменений для сложной системы может быть описана двояко: с точки зрения действий, совершаемых в процессе изменений, или с точки зрения объектов изменения, т. е. компонентов, составляющих конфигурацию. Я приведу два примера систем управления: управление действиями - бухгалтерский учет и управление компонентами - библиотечное дело.
Бухгалтерский учет как учет изменений. Что учитывает бухгалтерия? Многочисленные операции, состоящие в передаче денег и других материальных ценностей нематериальным способом. Учитываемые в бухгалтерии хозяйственные операции в совокупности образуют финансовое состояние хозяйствующего субъекта, - состояние почти столь же изменчивое, как и состояние в процессе разработки информационной системы. Нет ничего необычного в том, что механизм управления изменениями состояния - бухгалтерский учет - имеет много общего с конфигурационным управлением.
В обыденной жизни мы обычно обходимся без ведения специальных книг (т. е. бухгалтерии), но при мало-мальски усложненных операциях учет становится насущным делом.
Библиотечное дело как контроль компонентов конфигурации. Другая общепонятная аналогия конфигурационного управления - это библиотечное дело. В данном случае значим не учет действий по изменениям, как в бухучете, а контроль изменяемых данных. Подчеркнем, что данная аналогия не охватывает проблему образования конфигурации, т. е. совокупности состояний образующих ее (конфигурацию) объектов, поскольку для библиотеки, в отличие от программной системы, состояние хранилищ не так уж важно.
При работе с многочисленными потоками изменений среду изменений можно представить в виде объектов, временно предоставляемых пользователям (книга в библиотеке). Если в библиотеке книги выдаются не только для чтения, но и для записи (как, например, в Министерстве Правды Оруэлла), то этот образ неплохо отображает систему хранения версий. В действительности аналогия еще шире - в библиотеке могут быть различные залы, книга может быть занята, может выдаваться только через спецхран и т. д. Всему этому есть аналоги в области версионного хранения.
Так что же такое SCM? Наиболее простое и в то же время достаточно полное определение того, что такое конфигурационное управление, содержится в документации к PVCS.
“Конфигурационное управление, - считает фирма Intersolv (разработчик PVCS), - это организация изменений и управления изменением компонентов в процессе разработки программного обеспечения”.
Это некоторая сквозная деятельность (активность, “вспомогательный процесс” в терминологии стандарта ISO 12207-1), выполняемая в течение всего производственного процесса. Определение не учитывает конфигурационного управления на этапе поддержки информационной системы, но оно вполне достаточно для выявления характерных черт SCM.
За этим простым, на первый взгляд, определением стоит достаточно много: во-первых, каждодневная деятельность по контролю и учету изменений; во-вторых, организация деятельности - процедуры, выраженные в методиках и других документах, управляющих конфигурационным управлением; в-третьих, средства автоматизации, реализующие эти методики и процедуры; в-четвертых, отнюдь не простая и не очевидная проблема налаживания учета в рамках данной конкретной разработки; в пятых, процесс разработки в целом, только рассматриваемый с определенной точки зрения.
Проблема автоматизации конфигурационного управления
Конфигурационное управление как проблема учета и контроля в сложных программных системах имеет достаточно богатую историю. Сначала задача управления конфигурацией решалась организационными мерами и технически выглядела таким образом: носители с компонентами конфигурации хранились на специальных полках или копировались в специальные каталоги файловой системы. Однако современные системы настолько сложны, что эти методы не работают. Поэтому была поставлена и успешно решена задача автоматизации основных действий конфигурационного управления в условиях групповой разработки сложных систем. Сейчас при разработке на первый план выходит проблема интеграции средств автоматизации различных действий в рамках конфигурационного управления между собой и проблема интеграции со средствами автоматизации других действий (не конфигурационного управления). В результате, по-видимому, будет создано интегрированное средство автоматизации процесса разработки в целом.
Дисциплина конфигурационного управления. Прежде всего, конфигурационное управление существует как дисциплина, изложенная в стандартах. Из них можно отметить следующие:
Стандарт IEEE Std-828 и заменивший его IEEE Std-1042;
Стандарт ANSI, основанный на IEEE Std-828.
Стандарт ISO 12207, основанный на IEEE Std-828.
На основании упомянутых (или иных - например, корпоративных) стандартов для каждого проекта разрабатываются документы, содержащие в себе методику конфигурационного управления. Эти стандарты и методики учитывают сложный характер современной групповой разработки программных проектов. В SCMP (SoftWare Configuration Management Plan) детально расписываются все действия, обязанности и ответственность участников проекта по отношению к SCM.
Действующие в России стандарты (19-я и 34-я серии ГОСТов) не содержат предписаний, касающихся конфигурационного управления, хотя советская программная инженерия выработала оригинальные подходы - достаточно упомянуть сборочное программирование, представляющее собой систему как проектирования, так и конфигурационного управления. В отсутствие национальных стандартов должны применяться стандарты международные, в частности, по отношению к конфигурационному управлению документом прямого действия является ISO 12207-2.
Организация процесса разработки. Современные способы организации разработки ПО далеки от наивного представления о программе, как о результате того, что программист что-то пишет.
Принято считать, что разработка состоит из ряда этапов жизненного цикла. Иногда эти этапы как бы накладываются один на другой и сливаются, но чаще всего существуют в виде различных действий, выполняемых в разное время или разными членами коллектива разработчиков. Кроме действий, соответствующих основным этапам жизненного цикла, в разработке будут существовать и другие - контроль качества, планирование и конфигурационное управление.
Это разделение процесса разработки на “действия” (терминология ISO 12207-1), соответствующее этапам жизненного цикла, дополняется распределением задач по отдельным исполнителям и группам. Разнообразие действий, задач и исполнителей образует среду современной организации разработки.
Средства автоматизации конфигурационного управления. Для автоматизации многих действий конфигурационного управления разработаны многочисленные программные средства.
Ниже мы будем рассматривать почти исключительно PVCS. Средства PVCS очень широко распространены и фактически стали стандартом в области конфигурационного управления. Мне даже приходилось слышать, как SourceSafe (средство версионного хранения фирмы Microsoft) называли PVCS’ом.
ОРГАНИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПО И КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ
С точки зрения конфигурационного управления разработка ПО выглядит как непрерывный поток коллективно совершаемых изменений. Чтобы описать такую ситуацию, нужно ответить на следующие вопросы:
Куда вносятся изменения?
Кто вносит изменения?
Какова процедура внесения изменений?
Как процедура внесения изменений связана с объектом изменения, этапом разработки, лицом, вносящим изменения?
Жизненный цикл. Жизненный цикл современной разработки состоит из ряда стадий (фаз), на которых могут изменяться не только исходные коды, но и другие объекты.
Рассмотрим вначале каскадный жизненный цикл разработки ПО. В нем выделяют обычно следующие этапы:
Анализ требований (на этом этапе создаются и изменяются текстовые документы, содержащие требования к системе, часто эти документы могут содержать диаграммы той или иной методики анализа);
Проектирование (на этом этапе создается и/или изменяется представление о создаваемой программной системе в виде тех или иных методик проектирования; также на этапе детального проектирования (дизайна) могут создаваться первоначальные версии исходных текстов;
Кодирование (на этом этапе создаются и изменяются исходные тексты, а также исполняемые, т. е. коды, непосредственно используемые для исполнения машиной [если они отличны от исходных кодов]);
Тестирование (на этом этапе создаются тестовые процедуры, включая тестовые данные, а также результаты их выполнения);
Сопровождение (на этом этапе изменения как таковые не вносятся [внесение изменений здесь можно рассматривать как кратковременный откат к предшествующим этапам], основной рассматриваемый объект - выпускаемые версии).
При переходе от этапа к этапу могут появляться новые объекты SCM, поэтому именно в этих точках (baselines) особенно важны процедуры идентификации, которые выявляют объекты SCM, обозначают их уникальным образом и тем самым вводят в систему конфигурационного управления.
В действительности жизненный цикл разработки может весьма отличаться от каскадного, но в нем всегда можно выделить действия, которые соответствуют рассмотренным этапам.
Изменения. На каждом этапе жизненного цикла могут возникать запросы на изменения. Обычно считается, что эти запросы не формализуются в отношении тех объектов, которые массово изменяются на этом этапе (за одним исключением, которое будет описано в разделе “Метрики и управление проектом”). Так, изменения в исходном коде на этапе кодирования будут вноситься непосредственно. Если же на этапе кодирования возникнет запрос на изменение в дизайне, то этот запрос оформляется принятой процедурой регистрации и прохождения изменения.
Процедура прохождения изменения обычно документируется в методике конфигурационного управления (SCMP) и зависит от масштаба вносимых изменений.
Изменяемые данные. Объекты конфигурационного управления мы рассматриваем как логически выделенные части системы. Физическая их реализация может быть разнообразной - файлы, группы файлов (соответствующих одному объекту конфигурационного управления), содержимое базы данных, репозитория или даже бумажные документы.
Организация хранения объектов конфигурационного управления - один из важнейших вопросов конфигурационного управления. Исторически именно его решали методики конфигурационного управления. Ядром большинства средств SCM являются средства хранения версий.
Георгий Серяков
(Окончание следует)
Если вашей команде успешно удалось завершить хотя бы один проект, то согласно модели CMMI , процессу, который вы использовали для создания продукта, может быть присвоен первый уровень зрелости из пяти. Последующие уровни зрелости достигаются постановкой определенных процессов, связанных с разработкой программного обеспечения, одним из которых является управление конфигурацией (configuration management).
"The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits."
Процесс управления конфигурацией программных продуктов заключается в следующем:
- Идентификация конфигураций рабочих продуктов, которые представляют собой некоторую основу (baseline) в некоторый момент времени, где под рабочим продуктом понимаются любые артефакты, создаваемые или используемые в процессе разработки: дефекты, коды, сборки, планы, тесты, пользовательская документация и т.п.
- Контроль за изменениями, произошедшими с элементами конфигурации, например изменения в требованиях, программном коде и т.п. Обеспечение возможности создания рабочих продуктов (спецификаций, исходного и исполняемого кода) с использованием только системы управления конфигурациями.
- Обеспечение целостности и согласованности каждого из выделенных baselines, позволяющих относительно свободно перемещаться между различными baselines, то есть, получить согласованный срез конфигурации рабочих продуктов (требований, доработок, исходного кода, исполняемого кода) на некоторый момент времени.
- Предоставление текущего состояния и данных конфигурации программного продукта для разработчиков, конечных пользователей, заказчиков и др.
Если перевести этот высокоуровневый процесс на конкретные практики, которые используются при разработке программного обеспечения, то получится следующих список практик, реализующих управление конфигурацией:
- Идентификация версий разрабатываемого продукта, где номер версии и является основой (baseline) для конфигураций.
- Управление скоупом будущих версий, то есть фиксация бизнес требований в рамках некоторой версии продукта.
- Производство исполняемого кода на основе исходного кода, что достигается использованием сборочных станций или серверов.
- Тестирование работы исполняемого кода (программ) с целью выявления согласованности с исходными функциональными требованиями и различными критериями качества (нефункциональными требованиями).
- Подготовка заметок к релизу (release notes), которые описывают состав некоторой версии продукта, с указанием реализованных требований, выполненных доработок, исправленных ошибок, проверенных тестовых сценариев, места расположения исполняемых файлов и т.д.
- Трассировка одних артефактов в другие: доработок в требования, требований в тестовую и пользовательскую документацию, доработок и дефектов в исходный код, исходный код в исполняемый код и т.д. Тем самым обеспечивается возможность аудита и контроля за целостностью конфигурации некоторой версии продукта.
- Сохранение истории изменений и контроль версий каждого артефакта, например, требований, исходного кода, исполняемого кода. Типичные системы контроля версий как раз реализуют данную часть процесса управления конфигурацией.
DEVPROM совместно с системой контроля версий, инфраструктурами автотестирования и выпуска сборок, реализует полноценную систему управления конфигурацией:
- Все артефакты, создаваемые при разработке продукта, имеют свой уникальный идентификатор в системе, позволяя тем самым идентифицировать конфигурационные элементы.
- Этапы разработки программного продукта неразрывно связаны с версиями продукта, к которым привязываются все артефакты: пожелания, требования, тестовая и пользовательская документация, тесты, файлы и т.д.
- , управление требованиями, тестовой и пользовательской документацией позволяют создавать весь необходимый набор артефактов для заданной версии продукта, то есть определять конфигурацию для заданного baseline.
- Автоматическое создание связей между пожеланиями, задачами, требованиями, тестовой и пользовательской документацией, позволяет организовать согласованную конфигурацию программного продукта и выполнять аудит с целью выявления рассогласований. DEVPROM автоматически отслеживает неактуальные связи и предлагает выполнить согласование (приведение в соответствие) артефактов между собой.
- Все изменения в системе протоколируются, что позволяет контролировать любые изменения в конфигурации, выполненные участниками проекта.
- Формирование заметок к релизу (release notes) для определенной версии продукта, включающих в себя список реализованных доработок и исправленных ошибок.
Управление конфигурациями – процесс, отвечающий за управление информацией о конфигурационных единицах (включая их взаимоотношения), необходимой для предоставления ИТ-услуг.
Цель процесса управления конфигурациями - сбор и актуализация информации о составляющих частях IT-инфраструктуры, обеспечение данной информацией прочих процессов Управления услугами.
Конфигурационная единица (сonfiguration item или CI ) – элемент инфраструктуры или объект, связанный с элементами инфраструктуры (например, RFC), который находится/ должен находиться под контролем процесса управления конфигурациями. Конфигурационными единицами могут являться любые элементы, которыми необходимо управлять с точки зрения жизненного цикла ИТ-услуги. Точных рекомендаций по тому, что считать конфигурационной единицей, не существует. Однако различные источники (в том числе ITIL ) дают подсказки: это может быть аппаратное и программное обеспечение, документация и даже персонал. То есть любой ИТ-актив, сервисный компонент или любой другой элемент, который задействован на протяжении жизненного цикла ИТ-услуги.
Конфигурационная база данных (Configuration Management Database или CMDB ) – база данных, содержащая все необходимые сведения по всем CI и о связях между ними. Все Конфигурационные Единицы должны быть включены в Конфигурационную Базу Данных (CMDB), которая отслеживает все ИТ-компоненты и взаимоотношения между ними. В самой примитивной форме Конфигурационная База Данных представляет собой набор бумажных форм или электронных таблиц.
Базисная конфигурация (сonfiguration baseline или CB ) – конфигурация продукта/ системы в определенный момент времени, отражающая структуру и детали этого продукта/ системы. Базисная конфигурация позволяет восстановить состояние продукта/ системы. По сути это актуальное состояние Конфигурационной Единицы.
Управление активами – бухгалтерский процесс мониторинга активов, цена приобретения которых превышает установленный предел. Учитываются не только ИТ-объекты, но связи между объектами не отслеживаются.
Управление конфигурациями (Configuration Management) – процесс хранения технической информации о CI и связях между ними. Это процесс, который отвечает за необходимые конфигурационные элементы для оказания ИТ услуги и за их связи с управлением. Этой информацией управляют через конфигурационные элементы на протяжении всего жизненного цикла.
Управление конфигурациями не следует путать с Управлением активами .
- Управление активами – это бухгалтерский процесс мониторинга амортизации активов, чья закупочная цена превышает определенную величину. Мониторинг ведется путем учета закупочных цен, амортизации, месторасположения активов. Эффективно работающая система Управления активами может послужить основой для системы Управления Конфигурациями.
- Управление конфигурациями идет дальше, учитывая также информацию о взаимоотношениях между Конфигурационными Единицами и решая задачу стандартизации и авторизации единиц CI. Управление Конфигурациями также контролирует информацию о статусе ИТ-компонентов, их расположении, произведенных в них изменения и т. д.
Основные действия по управлению конфигурациями это:
- Сбор информации о каждом конфигурационном элементе
- Определение и анализ связей и взаимодействий между разными конфигурационными элементами
- Накопление информации в специальные базы данных управления конфигурациями (CMDB Configuration Management Database), где хранятся записи о конфигурациях на протяжении всего их жизненного цикла.
- Контроль целостности системы после каждого изменения конфигураций
- Постоянное слежение за ИТ инфраструктурой и ее анализ
Процесс конфигурационного управления дает логичную модель ИТ инфраструктуры и услуг. Он определяет, следит, обеспечивает и контролирует развитие различных конфигурационных элементов в инфраструктуре.
Когда речь идет об ИТ-инфраструктуре (оборудование и программное обеспечение, документация и вспомогательные службы, окружающая среда и подготовленный персонал), обычно возникают следующие задачи:
- разработка правил учета элементов ИТ-инфраструктуры;
- осуществление учета в соответствии с разработанными правилами;
- разработка правил получения/предоставления информации и проверки точности;
- осуществление повседневной деятельности в соответствии с разработанными правилами.
При разработке правил учета особое внимание следует уделить разработке системы классификации конфигурационных элементов.
CMDB должна содержать и предоставлять подробные данные о конфигурационных единицах, предоставляемых и используемых услугах, о потребителях и конечных пользователях различных служб, ИТ-персонале, поставщиках, субподрядных организациях и т.д., а также о взаимосвязях между всеми перечисленными элементами.
Так-же база в идеале должна содержать информацию об известных ошибках, структуре и размещении бизнес-подразделений. CMDB позволяет выдавать ответы на самые различные запросы, в том числе, быстро предоставляя следующую информацию:
- состав релиза приложения, включая все необходимые конфигурационные единицы и их версии;
- составные конфигурационные единицы, их компоненты, номера версий, тестовое и эксплуатационное окружения;
- конфигурационные единицы, на которые может оказать влияние некоторый запрос на внесение изменения;
- все запросы на внесение изменений в конкретную конфигурационную единицу;
- конфигурационные единицы, закупленные у некоторого поставщика за определенный период;
- оборудование и программы, находящиеся в некотором определенном месте, например, с целью обслуживания и проверки;
- конфигурационные единицы, подлежащие обслуживанию, обновлению или замене;
- связанные с конфигурационной единицей зарегистрированные проблемы и инциденты;
- все конфигурационные единицы, имеющие отношение к проблеме.
Существует несколько различных подходов к построению CMDB :
- использование существующей в организации бухгалтерской системы;
- создание собственной базы данных;
- использование специализированного средства автоматизации.
Создание собственной системы - наиболее гибкий и полный вариант. Основным его недостатками является высокая ресурсоемкость.
Адаптация бухгалтерских систем для нужд управления конфигурациями часто оказывается малореальной в связи с отсутствием возможности удобного предоставления доступа к информации большому числу сотрудников ИТ-службы и невозможностью качественного отображения взаимосвязей между различными конфигурационными единицами. Доработка таких систем своими силами достаточно ресурсоемкий процесс, как и привлечение к доработке разработчиков этой системы.
Специализированные системы лишены этих недостатков, поскольку требуют лишь незначительной настройки и могут быть внедрены в сжатые сроки. С другой стороны, за это приходится платить некоторой потерей гибкости и снижением возможностей глубокой настройки, а иногда и процессы должны строиться так, как того требует продукт. Системы различаются качеством реализации процессов, полнотой соответствия рекомендациям ITIL , качеством и полнотой отображения информации, удобством ее визуализации и, что немаловажно для систем этого класса в нашей стране, полнотой и качеством локализации.
Часто внедрение подходов библиотеки ITIL приносит успех, если начинать внедрение с Управления конфигурациями и Управления изменениями (Configuration & Change Management). Такая связка логична, потому что эти процессы наиболее взаимозависимы и при этом сильно влияют на другие процессы. С одной стороны информация об актуальной конфигурации ИТ-сервисов, хранящаяся в CMDB , является необходимым условием для Управления инцидентами и других процессов, как оперативных (Управление проблемами, изменениями, релизами ), так и тактических (Управление уровнем сервиса, финансами, мощностью, доступностью, непрерывностью ). С другой – без эффективного Управления изменениями невозможно достичь главной цели Управления конфигурациями – актуальности данных в CMDB .