Управление конфигурацией является основополагающей дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы проекта, вносимые в них изменения и информация о состоянии отдельных задач и всего проекта в целом. Успех проекта в большой степени зависит от того, насколько хорошо построен процесс управления конфигурацией, который может как спасти проект, так и похоронить его, если сам процесс УК работает плохо.
Первым заметным шагом в развитии управления конфигурациями (сокращенно – УК) было изобретение микрометра в 1636 году (William Gascoigne). Это устройство сыграло важную роль в индустриальной революции и переходе к массовому производству. Этот инструмент позволил использовать взаимозаменяемые части в различных устройствах, что являлось существенной причиной для того, чтобы использовать процедуры управления конфигурацией.
Первые инженерные концепции, которые привели к становлению дисциплины управления конфигурацией, начали формироваться в начале 20-го века и обрели реальную форму в 60-х годах прошлого века.
Изначально создатели концепции управления конфигурацией преследовали цель улучшения способов разработки и сопровождения программных средств (ПС). «Отцы-основатели» управления конфигурацией хотели создать дисциплину, которая обеспечивала бы соответствие разработанного ПС потребностям пользователей, для которых это ПС разрабатывалось. Они изучили успешные проекты и обобщили опыт применения тех технологий, которые хорошо себя проявили. Другой важной целью было обеспечить простоту модификации и сопровождения ПС и (так как «отцы-основатели» в основном работали на правительственные учреждения) возможность для заказчика ПС сменить разработчика без того, чтобы заново проходить весь цикл разработки ПС с нуля.
Кроме того, в качестве дополнительной цели рассматривалось обеспечение оценки состояния проекта на основе отчетности по ключевым показателям. Они сосредоточились на достижении долгосрочных целей и не рассчитывали получить сразу очевидные преимущества от использования разрабатываемых ими технологий. Следует заметить, что преимущества такого сорта трудно выразить количественно, так как при успешном использовании управления конфигурацией в организации просто перестают растрачивать ресурсы на лишнюю работу. Например, на повторное исправление ошибки, которая уже была исправлена ранее, но появилась вновь из-за того, что при сборке ПС правильный код случайно заменили на неправильный.
«Отцы-основатели» осознали, что в первую очередь им требуется контролировать то, какие части входят в готовый продукт (под продуктом может пониматься как ПС, так и оборудование и, в широком смысле, любое изделие, состоящее из различных частей) и каким образом они взаимосвязаны, а также отслеживать изменения в отдельных частях продукта и в их взаимосвязях друг с другом. Они выбрали слово «конфигурация» для обозначения «относительного взаиморасположения частей». Слово «управление» вполне подходило по смыслу, и в итоге получилось «управление конфигурацией».
Рано или поздно любой долгосрочный проект, связанный с разработкой программного обеспечения, разрастается до необъятных размеров, становясь трудно управляемым и трудно прогнозируемым. Руководство больше не в состоянии отслеживать конкретную деятельность подчиненных. Но, пожалуй, самая главная проблема в том, что руководящий состав не имеет четкого представления о качестве выпускаемого изделия. Подчиненные же, в свою очередь, лишены всестороннего осознания поставленных проектных задач, руководствуясь в своей работе не научной базой, а вдохновением и порывами души.
Вполне вероятно, что даже в таком случае определенный контроль над проектом, с той или иной долей успеха, возможен. Правда, трудно определить качественный уровень выходного изделия, как это принято в промышленном производстве.
Вот здесь и возникает потребность перехода на иную качественную ступень. И это обусловлено не только тем, что руководство компании желает из альтруистических побуждений повысить уровень качества изделия - вовсе нет! Улучшение качества - важное условие выживания IT-компаний в современных рыночных условиях.
Одна из дисциплин, которая позволит существенно повысить как качество самого процесса разработки, так и качество выходного продукта - Управление Конфигурациями программных средств. Дисциплина включает в себя управление как версиями ПС (программных средств), так и изменениями.
К сожалению, в российской печати и российском же Интернете практически нет достойных книг и статей, которые детально раскрывали бы Цели и Задачи процесса, описывали бы их (все материалы либо коммерческие либо банальные перепечатки слово в слово стандартов). К тому же имеет место низкая культура разработчиков, считающих УК неким видом тотального контроля над собой (если не насилия). В этом их заблуждение. Любой формализованный процесс - это не насилие, а благо, и мы надеемся это объяснить. К нашей радости, ситуация в России в плане отношения к процессу УК последний год начала резко меняться: начинаются разработки крупных программных продуктов, разработка которых невозможна без данного процесса.
Данный материал - это нарезка из глав книги, которую авторы пишут на протяжении последнего года-полутора. Книги обычно пишутся не быстро, поэтому было решено опубликовать материал в Интернете и собрать отзывы потенциальных читателей.
Статья описывает историю возникновения Управления Конфигурациями и базовые концепции, на которых зиждется данный процесс. Также рассматриваются основные аспекты данного процесса в призме международных стандартов, таких как ISO-12207 и CMM. В материале даются цитаты из требований стандартов с авторскими комментариями.
Полезные ссылки перед прочтением, чтобы войти в курс дела: Проблемы разработки ПО , Осознание необходимости в УК , Что такое RUP)
Приятного чтения.
Управление конфигурацией является основополагающей дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы проекта, вносимые в них изменения и информация о состоянии отдельных задач и всего проекта в целом. Успех проекта в большой степени зависит от того, насколько хорошо построен процесс управления конфигурацией, который может как спасти проект, так и похоронить его, если сам процесс УК работает плохо.
Первым заметным шагом в развитии управления конфигурациями (сокращенно - УК) было изобретение микрометра в 1636 году (William Gascoigne). Это устройство сыграло важную роль в индустриальной революции и переходе к массовому производству. Этот инструмент позволил использовать взаимозаменяемые части в различных устройствах, что являлось существенной причиной для того, чтобы использовать процедуры управления конфигурацией.
Первые инженерные концепции, которые привели к становлению дисциплины управления конфигурацией, начали формироваться в начале 20-го века и обрели реальную форму в 60-х годах прошлого века.
Изначально создатели концепции управления конфигурацией преследовали цель улучшения способов разработки и сопровождения программных средств (ПС). «Отцы-основатели» управления конфигурацией хотели создать дисциплину, которая обеспечивала бы соответствие разработанного ПС потребностям пользователей, для которых это ПС разрабатывалось. Они изучили успешные проекты и обобщили опыт применения тех технологий, которые хорошо себя проявили. Другой важной целью было обеспечить простоту модификации и сопровождения ПС и (так как «отцы-основатели» в основном работали на правительственные учреждения) возможность для заказчика ПС сменить разработчика без того, чтобы заново проходить весь цикл разработки ПС с нуля.
Кроме того, в качестве дополнительной цели рассматривалось обеспечение оценки состояния проекта на основе отчетности по ключевым показателям. Они сосредоточились на достижении долгосрочных целей и не рассчитывали получить сразу очевидные преимущества от использования разрабатываемых ими технологий. Следует заметить, что преимущества такого сорта трудно выразить количественно, так как при успешном использовании управления конфигурацией в организации просто перестают растрачивать ресурсы на лишнюю работу. Например, на повторное исправление ошибки, которая уже была исправлена ранее, но появилась вновь из-за того, что при сборке ПС правильный код случайно заменили на неправильный.
«Отцы-основатели» осознали, что в первую очередь им требуется контролировать то, какие части входят в готовый продукт (под продуктом может пониматься как ПС, так и оборудование и, в широком смысле, любое изделие, состоящее из различных частей) и каким образом они взаимосвязаны, а также отслеживать изменения в отдельных частях продукта и в их взаимосвязях друг с другом. Они выбрали слово «конфигурация» для обозначения «относительного взаиморасположения частей». Слово «управление» вполне подходило по смыслу, и в итоге получилось «управление конфигурацией».
Затем было решено, что разрабатываемый конечный продукт будет называться «конфигурационным объектом » (configuration item ). Конфигурационные объекты (КО) могут представлять собой стол или самолет, если рассматривать оборудование, или программные средства в виде инсталляционных пакетов, если речь идет о программных средствах.
Но каким образом можно управлять конфигурацией объекта? Это можно сделать, контролируя документы, которые описывают конфигурационный объект, требования к нему, его архитектуру и чертежи (или модель). Создатели дисциплины управления конфигурацией осознали, что такие документы являются самой важной частью процесса разработки и что управлять конфигурацией какого-либо объекта можно, управляя содержанием документов, описывающих эту конфигурацию.
Поэтому вместо того, чтобы предполагать, что такие документы могут быть созданы и могут точно описывать конфигурацию, необходимо было это гарантировать . Было решено, что наиболее важным результатом процесса управления конфигурацией должно быть обеспечение разработки документации, точно описывающей конфигурацию объекта в любой момент времени на протяжении всего проекта. Создатели дисциплины УК основывались на предположении, что если иметь набор точной и актуальной документации, то на ее основе всегда можно создать новую копию продукта.
Затем они занялись определением набора документов, который является критически важным для успешной разработки. Такой набор документов должен содержать, как минимум, требования, спецификации, дизайн, модели (чертежи), перечень компонентов, тестовую документацию, исходные коды и документацию пользователя. Требовалось общее выражение для обозначения любого из этих документов или всех документов, описывающих конфигурационный объект, для проекта любого размера. Так как основное предназначение этих документов было в «идентификации конфигурации» объекта, этот набор документов назвали «конфигурационной идентификацией » (configuration identification ). Тогда это казалось разумным, но сейчас мало кто считает, что «конфигурационная идентификация» означает «документы».
Другое важное понятие, определяющее набор документов - «базовая версия » (baseline ). Базовая версия представляет собой полный набор документов, составляющих конфигурационную идентификацию, соответствующий определенному моменту времени, т.е. «моментальный снимок» конфигурации. Момент времени, в который создается базовая версия, обычно соответствует какому-либо запланированному событию, например, завершению стадии жизненного цикла продукта или этапа проекта.
Таким образом, было установлено, что точное документирование - наиболее важный момент в управлении конфигурацией. При этом сознательно не перечислялись документы, которые должны создаваться (кроме документов с требованиями).
Итак, после определения требований, список остальных документов, составляющих конфигурационную спецификацию, определялся для каждого участниками проекта. Но как удостовериться в том, что эти документы создаются с нужным качеством и с достаточной степенью детализации?
Обычно используется метод декомпозиции требований (или «функциональной декомпозиции») - требования разбиваются на отдельные элементы и детализируются на следующем шаге разработки (дизайн). Затем детализация продолжается на следующем шаге и так далее до тех пор, пока не достигнут требуемый уровень детализации.
Другой способ - сравнение разрабатываемого документа с документами более высокого уровня, которые были утверждены ранее в процессе разработки. Для этой работы было использовано понятие «ревизия» (review) с добавлением слова «конфигурация». «Ревизия конфигурации» (configuration review ) представляет собой сравнение документа низкого уровня с предшествующим ему документом или документом верхнего уровня с тем, чтобы удостовериться, что документ нижнего уровня удовлетворяет всем требованиям, присутствующим в документе верхнего уровня, и нет никаких неожиданных добавлений. Это позволяет постепенно и аккуратно детализировать требования верхнего уровня в документах низкого уровня, уточняя конфигурационную идентификацию по мере разработки конфигурационного объекта.
Ревизия конфигурации используется также для того, чтобы проверить работоспособность продукта на основе документа соответствующего уровня. Например, ревизия исходного кода служит для того, чтобы удостовериться в том, что исходный код написан в соответствии с установленными правилами. Таким образом, ревизия конфигурации служит как для проверки правильности декомпозиции документов всех уровней, так и для проверки этих документов с точки зрения их соответствия правилам, шаблонам и форматам, используемым при создании такого рода документов.
Подобная техника проверки того, что продукт создается по установленным правилам и требованиям, используется при проведении «аудита конфигурации » (configuration audit ). Аудит конфигурации подобен процессу ревизии за исключением одной особенности - объектом приложения аудита является конфигурационный объект или конечный продукт, который сравнивается с документацией, составляющей его конфигурационную идентификацию. Объектом приложения ревизии являются отдельные документы.
Еще один способ гарантировать точность конфигурационной спецификации - иметь специальную группу (возможно, состоящую из одного специалиста), которая отслеживала бы все предлагаемые изменения продукта и отвергала или одобряла их. Такая деятельность получила название «контроль конфигурации » (сonfiguration сontrol ). Группы, выполняющие функции контроля конфигурации обычно получают название «Группа контроля над изменениями » (Change Control Board ) или «Группа контроля конфигурации » (Configuration Control Board , сокращенно CCB ). Среди важных функций такой группы - контроль того, что все документы являются актуальными в каждый момент времени и того, что при внесении изменения сначала изменяются документы конфигурационной идентификации, а уже после - сам объект изменений (исходный код, модель и т.п.). Изменение объекта после изменения его описания выгодно еще и тем, что исполнитель, вносящий изменение в объект, будет иметь возможность ознакомиться с описанием этого изменения до начала работы.
Другой областью ответственности управления конфигурацией стала подготовка отчетности о состоянии продукта и состоянии утвержденных изменений на протяжении всего хода работ. Эта деятельность получила название «учет состояния конфигурации » (configuration status accounting )
Нельзя сказать, что никто до этого не использовал таких методов работы. Разработка и раньше велась параллельно с документированием. Ревизии документов проводились и раньше. Тестирование и испытания продукции на предмет соответствия требованиям проводились и до этого. Отчетность использовалась в проектах и раньше. Основатели дисциплины управления конфигурацией сделали другое - они собрали вместе, упорядочили и дали названия всем этим техникам, используемым при разработке, так что в итоге получилась отдельная дисциплина - управление конфигурацией.
Во время формирования дисциплины управления конфигурацией в ней были воплощены следующие важные концепции:
Используя введенную выше терминологию управления конфигурацией, эти концепции были сгруппированы в следующие четыре элемента управления конфигурацией:
Такова была первоначальная концепция управления конфигурацией как для программных средств (software), так и для оборудования (hardware). Представленную здесь первоначальную терминологию дисциплины управления конфигурацией можно также найти в стандарте IEEE-STD-610. Далее будут рассмотрены стандарты, определяющие основные положения и терминологию управления конфигурацией.
Недостаточно четкое понимание терминологии управления конфигурацией, происходящее обычно из-за отсутствия формального обучения этой дисциплине, зачастую приводит к смещению концептуальных понятий и путанице в основополагающих принципах УК.
Так, например, основной элемент управления конфигурацией «конфигурационная идентификация» зачастую воспринимается в значении наименования или нумерации документа или продукта, что должно соответствовать понятию «идентификации документа» или «идентификации продукта». В то время как понятие «конфигурация» не относится к документу или продукту. Это понятие относится к содержанию документов, обозначая содержание технической документации, описывающей продукт. Кстати говоря, правила наименования и нумерации документов и продуктов относятся к следующему элементу УК - «контролю конфигурации», и называются «соглашением по наименованию и нумерации».
С момента формального основания дисциплины управления конфигурацией, которое можно условно отсчитывать от даты введения стандарта IEEE-STD-610, она рассматривалась с разных точек зрения и в различных приложениях. Был накоплен богатый опыт использования процедур управления конфигурацией в различных проектах, который обобщался с точки зрения различных стандартов и моделей программной инженерии.
Процесс управления конфигурацией состоит из следующих взаимосвязанных видов деятельности:
К основным элементам процесса управления конфигурацией можно отнести (см. рисунок 1.) следующие четыре элемента:
Рисунок 1. Основные элементы процесса управления конфигурацией
Рассмотрим подробнее состав каждого из этих элементов.
Конфигурационная идентификация основывается на следующих составляющих:
Контроль конфигурации включает:
Учет состояния конфигурации предполагает:
Ревизия и аудит конфигурации включает:
До сих пор мы говорили об управлении конфигурацией в широком смысле как о дисциплине. Это было позволительно, пока не рассматривались стандарты. Теперь же и далее, если не будет явно оговорено что-то другое, мы будем рассматривать процесс управления конфигурацией. Ниже рассматриваются стандарты, определяющие процесс управления конфигурацией, а также рассматривается сам процесс стандартизации с точки зрения применения процедур УК.
Для определения основных положений процесса управления конфигурацией представляется разумным воспользоваться существующими стандартами, описывающими процесс УК. При этом следует определить тот стандарт, который будет в наибольшей степени соответствовать потребностям конкретного предприятия.
Все стандарты можно условно разделить на виды, в зависимости от широты их области действия:
Некоторые часто используемые международные стандарты приведены ниже (см. таблицу 1). В таблице «SCM» обозначает возможность использования стандарта для УК ПС (software configuration management), а «HCM» - для оборудования (hardware configuration management). В рассматриваемой таблице выделены три наиболее значимые области использования стандартов:
Таблица 1. Международные стандарты, описывающие процесс УК
|
Стандарты и руководства |
Область действия |
Описание |
|
|---|---|---|---|
|
Процесс приобретения |
Процесс поставки/ разработки |
||
|
IEEE/EIA 12207.0-1996, Industry Implementation of International Standard ISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology - Software Lifecycle Processes |
Устанавливает общую структуру процессов жизненного цикла (ЖЦ) программных средств. |
||
|
IEEE/EIA 12207.1-1996, Lifecycle data. |
|||
|
IEEE/EIA 12207.2-1996, Implementation Considerations |
|||
|
ISO 9000-3: Quality Mgmt & Quality Assurance Stds-Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software |
|||
В качестве примера отраслевого стандарта можно привести MIL-STD-2549 «Configuration Management Data Interface», который детализирует требования для обмена данными между правительственными системами конфигурационного управления.
Международные и отраслевые стандарты не дают возможности напрямую применять описываемый в них процесс на уровне предприятия, так как само описание процесса УК в них приведено недостаточно подробно для прямого использования.
Обычная практика использования таких стандартов состоит в их адаптации для нужд конкретного предприятия. При адаптации стандарта определяется, в какой степени он будет использоваться на предприятии - полностью; за исключением определенных ситуаций; отдельные положения стандарта. Далее положения стандарта детализируются и дополняются с учетом специфики конкретного предприятия.
Для детализации процесса УК при его адаптации можно использовать методологии, разработанные различными международными организациями и фирмами (например, Rational Unified Process). Такие методологии обычно содержат более детальное описание процесса и часто имеют руководства по применению инструментальных средств автоматизации, что существенно упрощает адаптацию методологии. Впрочем, бывают ситуации, когда специфика предприятия настолько отличается от общих правил, предлагаемых методологией, что проще детализировать процесс УК самостоятельно, без привязки к какой-либо методологии.
Итогом такой адаптации обычно является внутренний стандарт предприятия на процесс управления конфигурацией. Таким образом, прослеживается следующая цепочка:
Стандарт предприятия требует серьезной проработки своих положений, и работа по вводу его в действие обычно занимает несколько лет. До момента ввода в действие стандарта предприятия в проектах могут действовать отдельные нормативные и организационно-распорядительные документы.
Прежде чем переходить к подробному рассмотрению описания процесса УК в одном из стандартов, необходимо дать некоторые разъяснения, касающиеся современного представления о процессе УК и изменениях, произошедших с момента формирования первоначального представления о дисциплине управления конфигурацией.
Первоначально управление конфигурацией включало в себя и управление требованиями, и управление изменениями, и версионный контроль. Это зафиксировано во всех основных стандартах, касающихся УК. С точки зрения стандартов программной инженерии этот подход действует и сейчас.
С теоретической точки зрения вполне разумно оставить все три взаимосвязанных процесса - управление требованиями, управление изменениями и версионный контроль - в рамках единого процесса управления конфигурацией. Но на практике дело в настоящий момент обстоит иначе.
Трудно сказать, что было первопричиной - реальные потребности пользователей или маркетинговые стратегии фирм-производителей инструментальных средств, но в настоящий момент управление требованиями в подавляющем большинстве проектов рассматривается как отдельный процесс, а управление изменениями в половине проектов рассматривается как отдельный процесс, а в другой половине - как часть процесса управления конфигурацией. И только версионный контроль всегда рассматривается как часть управления конфигурацией.
Далее мы будем рассматривать управление требованиями как отдельный процесс, не являющийся частью процесса управления конфигурацией, хотя и тесно с ним связанный (хотя это и противоречит ряду стандартов, не выделяющих управление требованиями в отдельный процесс).
Разделение управления конфигурацией и управления изменениями на отдельные процессы или рассмотрение единого процесса управления конфигурацией с технологической точки зрения имеет мало отличий. Вопрос о разделении рассматривается главным образом с точки зрения организационной структуры, обеспечивающей выполнение единого процесса или двух взаимосвязанных процессов, и с точки зрения использования инструментальных средств автоматизации процесса управления конфигурацией и управления изменениями. Авторам удавалось одинаково успешно реализовывать проекты и в том, и в другом случае.
Далее, если явно не оговорено противное, управление изменениями всегда будет рассматриваться как часть процесса управления конфигурацией, что соответствует стандартам, используемым при определении процесса УК.
Один из таких стандартов - ГОСТ Р ИСО/МЭК 12207 - рассматривается ниже.
Почему при выборе стандарта, определяющего процесс управления конфигурацией, для подробного рассмотрения мы остановились на стандарте ГОСТ Р ИСО/МЭК 12207 «Информационные технологии. Процессы жизненного цикла программных средств»? Для этого есть несколько важных причин:
Прежде чем переходить непосредственно к процессу управления конфигурацией, определяемому в данном стандарте, рассмотрим кратко стандарт в целом.
Российский стандарт ГОСТ Р ИСО/МЭК 12207 рассматривает процессы жизненного цикла (ЖЦ) программных средств (ПС) и подразделяет их на три группы:
Стандарт ГОСТ Р ИСО/МЭК 12207 устанавливает общую структуру процессов жизненного цикла (ЖЦ) программных средств (ПС), определяет процессы, работы и задачи, выполняемые в ходе ЖЦ ПС.
Процесс конфигурационного управления определяется как вспомогательный процесс (см. рисунок 2).
Рисунок 2. Процессы жизненного цикла ПС по ГОСТ Р ИСО/МЭК 12207.
В соответствии с рассматриваемым стандартом, данный процесс состоит из следующих работ:
Ниже приведены краткие описания всех работ процесса.
Должен быть разработан план управления конфигурацией. План должен определять: работы по управлению конфигурацией; процедуры и график выполнения данных работ; организацию(и), ответственную(ые) за выполнение данных работ; связь данной организации(й) с другими организациями, например, по разработке и сопровождению программных средств. План должен быть документально оформлен и выполнен (план может быть частью плана управления конфигурацией системы).
Должна быть определена схема обозначения программных объектов и их версий (объектов программной конфигурации), которые контролируются при реализации проекта. Для каждого программного объекта и его версий должны быть определены: документация, в которой фиксируется состояние его конфигурации; эталонные версии и другие элементы обозначения.
Анализ и оценка изменений; принятие или непринятие заявки; реализация, верификация и выпуск измененного программного объекта. Для каждого изменения должны отслеживаться проводимые аудиторские проверки, посредством которых анализируется каждое изменение, его причина и разрешение на его внесение. Должны быть выполнены контроль и аудиторская проверка всех доступных контролю программных объектов, которые связаны с критическими функциями безопасности или защиты.
Должны быть подготовлены протоколы управления и отчеты о состоянии, которые отражают состояние и хронологию изменения контролируемых программных объектов, включая состояние их конфигурации. Отчеты о состоянии должны включать количество изменений в данном проекте, последние версии программных объектов, обозначения выпущенных версий, количество выпусков и сравнения программных объектов различных выпусков.
Должны быть определены и обеспечены: функциональная законченность программных объектов с точки зрения реализации установленных к ним требований; физическая завершенность программных объектов с точки зрения реализации в проекте и программах всех внесенных изменений.
Должны официально контролироваться выпуск и поставка программных продуктов вместе с соответствующей документацией. Оригиналы программ и документации должны сопровождаться в жизненном цикле. Программы и документация, связанные с обеспечением критических функций безопасности или защиты, должны обрабатываться, храниться, упаковываться и поставляться в соответствии с установленными правилами.
CMM (Capability Maturity Model) - модель зрелости процессов создания ПО, или эволюционная модель развития способности компании разрабатывать качественное программное обеспечение.
Изначально CMM разрабатывалась и развивалась как методика, позволяющая крупным правительственным организациям США выбирать наилучших поставщиков ПО. Для этого предполагалось создать исчерпывающее описание способов оценки процессов разработки ПО и методики их дальнейшего усовершенствования. В итоге авторам удалось достичь такой степени подробности и детализации, что стандарт оказался пригодным и для обычных компаний-разработчиков, стремящихся качественно улучшить существующие процессы разработки, привести их к определенным стандартам.
Ключевым понятием стандарта является зрелость организации. Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров, а решения зачастую просто импровизируются «на ходу» - то, что на современном языке называется творческим подходом, или искусством. В этом случае велика вероятность превышения бюджета или выхода за рамки сроков сдачи проекта, поэтому менеджеры и разработчики вынуждены заниматься только разрешением актуальных проблем, становясь тем самым заложниками собственного программного продукта. К сожалению, на данном этапе развития находится большинство компаний (по градации CMM этот уровень обозначается числом 1).
В зрелой организации, напротив, имеются четко определенные процедуры создания программных продуктов и отработанные механизмы управления проектами. Все процедуры и механизмы по мере необходимости уточняются и совершенствуются в пилотных проектах. Оценки времени и стоимости выполнения работ основываются на накопленном опыте и достаточно точны. Наконец, в компании существуют стандарты на процессы разработки, тестирования и внедрения, а также правила оформления конечного программного кода, компонентов, интерфейсов и т.д. Все это составляет инфраструктуру и корпоративную культуру, поддерживающую процесс разработки программного обеспечения. Технология выпуска будет лишь незначительно меняться от проекта к проекту на основании абсолютно стабильных и проверенных подходов.
CMM определяет пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или понижаться. Следует отметить, что каждый следующий уровень включает в себя все ключевые характеристики предыдущих.
(1) Начальный уровень (initial level ) - это основной стандарт. К данному уровню, как правило, относится любая компания, которой удалось получить заказ, разработать и передать заказчику программный продукт. Предприятия первого уровня не отличаются стабильностью разработок. Как правило, успех одного проекта не гарантирует успешность следующего. Для компаний данного уровня свойственна неравномерность процесса разработки - наличие авралов в работе. К этой категории можно отнести любую компанию, которая хоть как-то исполняет взятые на себя обязательства.
(2) Повторяемый уровень (repeatable level ). Данному уровню соответствуют предприятия, обладающие определенными технологиями управления проектами. Планирование и управление в большинстве случаев основывается на имеющемся опыте. Как правило, в компании данного уровня уже выработаны внутренние стандарты и организованы специальные группы проверки качества.
(3) Определенный уровень (defined level ). Уровень характеризуется наличием формального подхода к управлению (то есть описаны все типичные действия, необходимые для многократного повторения: роли участников, форматы документов, производимые действия и пр.). Для создания и поддержания подобного стандарта в актуальном состоянии в организации уже подготовлена специальная группа. Компания постоянно проводит специальные тренинги для повышения профессионального уровня своих сотрудников. Начиная с этого уровня организация перестает зависеть от личностных качеств конкретных разработчиков и не имеет тенденции скатываться на нижестоящие уровни. Абстрагирование от разработчиков обусловлено продуманным механизмом постановки задач и контроля исполнения.
(4) Управляемый уровень (managed level ). Уровень, при котором устанавливаются количественные показатели качества.
(5) Оптимизирующий уровень (optimizing level ) характеризуется тем, что мероприятия по совершенствованию рассчитаны не только на существующие процессы, но и на оценку эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное совершенствование существующих процессов, которое в идеале призвано способствовать предупреждению возможных ошибок или дефектов. Применяется механизм повторного использования компонентов от проекта к проекту, например шаблоны отчетов, форматы требований.
Из градации уровней видно, что технологические требования сохраняются только до 3-го уровня, далее же в основном следуют требования к административному управлению. То есть уровни 4 и 5 по большей части управленческие и для их достижения важно не только выпустить программный продукт, но и проанализировать ход проекта, а также построить планы на будущий проект, основываясь на текущих шаблонах. Применение данных подходов должно обеспечить планомерно-плавное улучшение используемых процессов.
Хотя в России знают аббревиатуру СММ, в большинстве организаций не представляют себе, каким образом можно добиться качественного скачка. И дело не только в том, что неизвестно направление этого скачка, а в том, что каждой отдельно взятой компании довольно трудно выстроить свои процессы под требования CMM самостоятельно, без внешнего вмешательства. А зачем изобретать велосипед? Не проще ли взять готовый набор решений (например методологию, IBM Rational Unified Process или аналогичную), внедрить их (здесь уже можно и своими силами обойтись), получив готовый набор решений для качественного построения процесса Управления Конфигурациями, а уж затем приглашать специалистов и аттестоваться на определенный уровень? В России уже есть примеры компаний, которые аттестовались на более высокий уровень СММ именно благодаря внедрению решений на основе IBM Rational Unified Process . Вы можете найти их поиском в Интернет.
На Западе технологии компании IBM Rational сегодня уже широко используют для оптимизации процесса выпуска ПО. Причин тому несколько: во-первых, IBM Rational Software - практически единственная компания, которая четко описала весь производственный цикл по выпуску программного обеспечения (IBM Rational Unified Process), определила все возможные виды документов, сопровождающие проект, строго расписала роли (входные/выходные документы, шаблоны документов и пр.) каждого участника проекта. Во-вторых, компания создала специальное программное обеспечение для качественного исполнения как каждого этапа в отдельности, так и всего проекта в целом. Важно и то, что IBM Rational посредством RUP предлагает перейти от программирования как искусства к программированию как к науке, где все понятно и прозрачно благодаря научному подходу к разработке. По некоторым оценкам западных аналитиков, соотношение возврата капитала до и после внедрения процессов варьируется от 5:1 до 8:1.
Конфигурационное управление участвует в идентификации конфигурации выпускаемого ПО (то есть в выборе программного продукта и в его описании) в срок. SCM (Source Configuration Management) обеспечивает систематизированное управление изменениями конфигурации, поддержание их целостности и актуальности на протяжении всего жизненного цикла проекта. Результаты разработки, которые поставляются клиенту, находятся под управлением конфигурационной системы. Также под ее управлением находятся все документы и результаты компиляции (документы требований, отчеты, исходные данные на любом языке программирования).
Библиотеки базовых линий должны быть установлены и содержать работающие версии релизов. Под базовыми версиями здесь и далее понимается набор версий исходных файлов, составляющих конкретную версию откомпилированного релиза. Изменения базовых линий программного продукта, построенных на основе библиотеки базовых линий, должны быть управляемыми посредством контроля изменений и конфигурационного аудита функций в SCM, что полностью обеспечивается продуктом Rational ClearCase (версионное управление).
Все данные из ключевых областей процесса (Key Process Area ) охватывают возможные методы исполнения функции конфигурационного управления. В СММ все качественные требования представляются именно как KPA. Каждый из этих методов четко описывает определенный участок с формализованными требованиями, а RUP способен привести этот участок в соответствие означенному требованию.
Механизмы, идентифицирующие определенные единицы конфигурации, содержатся в KPA и описывают развитие и сопровождение каждой единицы конфигурации (исходные тексты, картинки, документация и пр.).
Ниже приведены требования CMM к процессу конфигурационного управления с вольными авторскими комментариями. Это требования 2 и 3 уровней. Хочется отметить, что внедрение УК в соответствии с RUP автоматически дает уровень 3 CMM
1. Управление конфигурацией происходит на плановой основе
Многие компании при попытке поставить любой процесс (не важно какой, но в данном случае -Управления Конфигурациями ) ограничиваются только инсталляцией программных средств с минимальными затратами в дальнейшей работе. Так был загублен не один проект. Во-первых, всегда должна быть планомерная работа. А во-вторых, сначала внедряется процесс, а потом инсталлируются средства автоматизации (уж никак не наоборот). Соответственно, если есть процесс, то должен быть документ, описывающий его. Таким документом для УК является «План управления конфигурациями», где излагается концепция процесса и имплементация средств автоматизации. В нем же расписываются все роли, и, что особенно важно, деятельности в зависимости от стадии жизненного цикла разработки ПО.
2. Все изменения происходят управляемо
Практически следствие из первого пункта. В проекте не бывает и не может быть неконтролируемых изменений.
1. Проект следует документированной организационной политике
1.1. Есть ответственные за выполнение проекта
Мало иметь ответственных. Они должны быть формально утверждены. Должен быть документ (например, приказ) в котором назначаются ответственные за реализацию.
1.2. УК реализуется на протяжении всего жизненного цикла разработки
Недостаточно использовать УК только на этапе разработки. УК реализуется на протяжении всего жизненного цикла: от бизнес-моделирования и постановки требований до ввода в эксплуатацию и сопровождения (если ведется поддержка разработанного программного обеспечения, то УК заканчивается только с окончанием поддержки).
1.3. УК реализуется для конечных продуктов, промежуточных, экспериментальных и перспективных
Очень часто бывает, что разработчикам разрешают промежуточные версии, перспективные макеты и т.д. разрабатывать локально. Логика руководства понятна - пусть он работает - придет время, все, что сделал, впишет в проект. Это неправильно. Нормально поставленный процесс подразумевает, что все изменения делаются в средстве автоматизации процесса УК, так как здесь хранится история изменений и комментарии к ним. Ведь если разработчик уйдет, то в случае такой организации проект пойдет дальше. А если разработка велась локально, то можно и потерять сегменты кода, а значит потерять массу времени на восстановление.
1.4. Все проекты имеют собственный репозиторий
(Примечание: здесь приводятся только основные требования к процессу. В стандарте СММ их существенно больше. Пропуски отмечены символами "*". Более подробную информацию о стандарте можно получить на сайте SEI-CMM)
4. Работы по УК должны быть обеспечены ресурсами
Очень часто внедрение процессов происходит по сценарию: «Витек или Васек все сделают». В итоге ничего не сделано. Процесс должен быть обеспечен ресурсами. Должны быть назначены ответственные, им должны быть вменены дополнительные обязанности. Если это не сделано, то проект рассыплется очень скоро.
4.1. Назначение менеджера УК
Ключевая роль. Этот человек знает процесс разработки. Понимает цели и задачи УК. Все свои знания он излагает в плане УК. Сам управляет процессом УК. Очень часто пытаются либо вообще обойтись без такой роли, либо «спихивают» ее на разработчиков. Естественно, это неправильно, так как разработчик не видит всей картины процесса разработки, может не понимать структурных взаимодействий между отделами… и т.д. Перечень непониманий можно продолжать далее. На первых порах, на порах становления роль менеджера берет на себя человек, который имеет представление о процессе разработки. Такой человек всегда есть в коллективе.
4.2. Назначение администратора УК
Для того, чтобы все работало и проверялось, необходим человек, занимающийся поддержкой процесса. Если менеджер процесса отвечает за его логическую стройность, непротиворечивость и необходимую детальность (все это отражено в плане), то администратор должен имплементировать эту концепцию в дело (превратить в скрипты, настройки). Ведь план - это верхний уровень, а его реализация - нижний. Так вот, администратор и отвечает за реализацию и поддержание процесса. Без него также не обойтись.
4.3. Работы обеспечены инструментальными средствами и оборудованием
5. Участники УК должны пройти обучение целям, процедурам и методам выполнения работ по УК
6. Члены группы разработки ПО должны пройти обучение по своим задачам
Проблема проблем - инструмент поставили, а что делать не сказали. Все участники должны пройти обучение, для понимания того, чего же от них требуется в плане знания инструмента и что же им нужно делать в проекте. Конечно, можно обойтись и без обучения, только риски запороть дело очень высоки, ведь никому в голову не придет сажать за руль автомобиля человека, который не умеет водить, а лишь слышал, как это делается. Кажется, что в деле разработки ПО все не так. Но законы природы одинаковы везде - сначала обучение - потом практика (это общий комментарий к пунктам 5 и 6).
1. Для каждого проекта готовится план УК
Что хорошо в плане УК, так это то, что он долго пишется всего ОДИН раз. Далее для каждого проекта пишется новый план, на основе существующего, так как способы и методы в новом проекте могут отличаться, то и план описывает все особенности данного проекта. Но план должен относиться к этому проекту, даже если проект ведется точно так же, как все остальные.
1.1. План разрабатывается на ранних стадиях общего планирования проекта
План должен быть подготовлен на самых ранних стадиях, еще до того, как разработчики включили компьютеры.
1.2. План рассматривается всеми участниками процесса и рецензируется ими
План - живой документ. План пишут живые люди, которые могут ошибиться. План - не секретный документ - он должен храниться на видном месте, его должны все читать, так как план описывает процесс разработки, то его ОСОБЕННО должны читать вновь пришедшие разработчики, тестировщики, менеджеры. Чтобы план был живым плодом любви, а не засохшим листком в гербарии - его необходимо читать и корректировать - избавлять от косноязычия и от неправильных формулировок. Такая ошибка, как неправильное понимание процесса, ведет к простоям и частым доработкам продукта.
1.3. План должен быть доступен и управляем в части его изменений
3. Устанавливается библиотечная система УК, служащая репозиторием проекта
Все в третьем пункте относится не столько к процессу, сколько к средству автоматизации. Конечно, можно поставить процесс и без средств автоматизации, только это будет очень неправильно. На рынке есть масса средств, которые при должной настройке смогут поддерживать процесс. Требования к ним приведены ниже.
3.1. Многоуровневая поддержка контроля УК
3.2. Хранение и извлечение элементов конфигурации
3.3. Совместное использование элементов группами разработчиков
3.4. Помощь в применении производственных стандартов УК
3.5. Хранение и извлечение архивных версий
3.6. Обеспечение корректного создания продуктов
3.7. Хранение и обновление записей по УК
3.8. Поддержка создания отчетов
3.9. Поддержка структуры и содержимого библиотеки
4. Идентификация промежуточных программных продуктов, находящихся в системе УК
4.1. Выбор элементов на основании документированных критериев
4.2. Элементам репозитория назначаются уникальные идентификаторы
4.3. Определяются характеристики каждого блока конфигурации
4.4. Определяются базовые линии
4.5. Для каждого блока определена стадия разработки, на которой он помещается в систему УК
4.6. Определен ответственный за каждый элемент
6. Изменение базовых версий (baseline) происходит подконтрольно, в соответствии с документированной процедурой
6.1. Выполнение проверок и регрессионных тестов
6.2. Внесение в библиотеку базовых версий лишь утвержденных блоков конфигурации
6.3. Внесение и извлечение блоков конфигурации не нарушает целостность проекта
7. Создание продуктов на основе библиотек базовых версий и контролирование их выпуска в соответствии с документированной процедурой
7.1. Комиссия контролирует создание продуктов на основе библиотеки базовых версий
7.2. Все элементы создаются только из блоков конфигурации, содержащихся в библиотеке базовых версий
8. Запись статуса элементов конфигурации в соответствии с документированной процедурой
8.1. Запись действий по УК производится с детальностью, достаточной для того, чтобы иметь в наличии статус всех элементов
8.2. Иметь возможность восстановить прежние версии файлов
8.3. Ведение истории изменений
1. Выполнение измерений и использование их результатов для определения состояния работ по УК
Все, с чем мы сталкиваемся в жизни, можно измерить. Процесс УК не исключение - его тоже можно измерить. Мало того, ЕГО НУЖНО измерять. Ведь при активной работе в репозитории (хранилище) скапливается огромное число статистических сведений. Формирование отчетов и аналитических срезов - есть неотъемлемая часть как процесса разработки вообще, так и УК в частности. Ведь только на основе анализа собранной статистики можно принимать решения о дальнейших действиях. СММ оговаривает только самые важные срезы и отчеты.
1.1. Отчеты по количеству запросов за единицу времени
1.2.Отчеты по выполнению этапов работ по УК в сравнении с планом
1.3. Отчеты по объему выполненных работ по УК
1.4. Отчеты по ресурсам
Хочется напомнить, что здесь приведены только самые основные ключи СММ. Остальное смотрите в стандарте.
Но перед тем, как вы закроете данную статью - выпишите требования к процессу, выдвигаемые СММ и сравните с тем, как обстоят дела в вашей компании. Мы будем рады, если хотя бы 50% требований у вас совпало!
Если это не так, то вам нужно серьезно задуматься над улучшением процесса УК.
Конфигурация - это знание о том, какова работающая (актуальная) система, выделенная из множества ее возможных вариантов. Конфигурация находится под контролем, если конфигурация определения системы соответствует конфигурации воплощения системы . Если какие-то части этих конфигураций не соответствуют друг другу, то говорят о конфигурационных коллизиях .
Управление конфигурацией (configuration management) - техническая дисциплина системной инженерии, обеспечивающая поддержание надлежащей (задуманной, одобренной) конфигурации системы во время всего её жизненного цикла. Если говорить попроще, то управление конфигурацией - это практика, обеспечивающая на протяжении всего жизненного цикла совместимость версий (отсутствие коллизий!) и полноту частей системы (отсутствие коллизий!).
Управление конфигурацией - практика системноинженерного менеджмента - она занимается поддержанием целостности системы на протяжении всего ЖЦ. В рамках этой практики выпускаются различные виды спецификаций закупаемого/изготавливаемого оборудования/изделий - BOM (bill of materials, список комплектующих).
Отнесение управления конфигурацией к системной инженерии означает, что конфигурация обязательно относится ко всей системе.
Управляющий конфигурацией - системный инженер, наряду с инженером по требованиям, системным архитектором, интегратором.
Управление конфигурацией включает в себя следующие понятия:
| Базис | Определяется на этапе | Тип спецификации | Характеристики | Описываемый элемент |
|---|---|---|---|---|
| Функциональный | Выбор концепции | A | Функциональные спецификации | Система |
| Физический (Allocated) | Техническое проектирование | B | Проектная документация | Элемент конфигурации |
| Продукции (Product) | Техническое проектирование | C, D, E | Производственно-технологическая документация | Элемент конфигурации |
Управление конфигурацией, в том числе и управление изменениями невозможно рассматривать отдельно от управления данными (управления информацией, интеграции данных жизненного цикла и т.д.). Сюда попадают следующие практики:
Дисциплина управления конфигурацией имеет следующие основные основные практики:
Управление конфигурацией очень просто, когда есть один административный центр, который вводит
При распределенной разработке (collaborative engineering , concurrent engineering) каждая из участвующих в проекте организаций имеет собственные предпочтения по управлению конфигурацией (кодировки, учётные регламенты, версионирование). Собрать из этого распределенного конфигурационного месива базис обычно представляет собой непростую задачу.
Так, любая PLM-система поддерживает управление конфигурацией. Но если в расширенной организации (extended enterprise) используется несколько разных PLM-систем, то немедленно начнутся проблемы. Еще бОльшие проблемы будут, если нет полноценной (организация+софт) системы управления жизненным циклом (СУЖЦ) , а есть только неподдержанный организационными решениями (необходимым для управления конфигурацией workflow) софт PLM.
Коллизии , возникающие из проблем управления конфигурацией - самые распространенные. Отсутствие управления конфигурацией как раз и характеризуется словами "у них там бардак". Поэтому разворачивание технологии управления конфигурацией - центральная забота при создании СУЖЦ.
Управление конфигурацией требует:
Для управления конфигурацией определения системы сейчас используют информационные системы.
Многие компании внедряют Управление активами до внедрения Управления конфигурациями. Процессы в этом разделе применимы как к Управлению активами, так и к Управлению конфигурациями.
Контроль над ИТ-инфраструктурой и услугами по всем распределенным системам, осуществляемый во множестве местоположений различными группами поддержки, требует тщательного планирования. Это планирование должно включать процессы Управления изменениями, Управления конфигурациями и Управления релизами, поскольку эти процессы взаимозависимы. Необходимо рассмотреть планирование и внедрение централизованных процессов Управления изменениями, Управления конфигурациями и Управления релизами, которые будут работать при поддержке распределенных групп специалистов (см. Приложение 7А).
7.5.1 Начальное планирование.
Действия по начальному планированию проекта по Управлению конфигурациями включают:.
■ согласование цели, задач, масштаба, приоритетов и подхода к внедрению процесса Управления конфигурациями;.
■ назначение ответственного за процессы и системы Управления конфигурациями;.
■ анализ существующих систем Управления конфигурациями, данных и процессов;.
■ разработка обобщенного Плана управления конфигурациями (который может быть включен в планы Управления изменениями и Управления конфигурациями в организации) и проекта создания системы Управления конфигурациями;.
■ планирование и получение финансирования для средств Управления конфигурациями и обязательства по предоставлению дополнительных ресурсов;.
■ достижение соглашения о корпоративной политике и процессах и определение тех моментов, которые будут «подстраиваться» во время развертывания.
Для всех систем, кроме самых малых, средства поддержки Управления изменениями и Управления конфигурациями особенно необходимы из-за непрактичности систем бумажного документооборота. Для размещения средств Управления конфигурациями, в особенности CMDB, требуется аппаратное обеспечение и ресурсы для хранения данных. Средства поддержки должны, как минимум, позволять осуществлять передачу данных из отдельных систем «проектного Управления конфигурациями» без необходимости повторного ввода. В идеале средства Управления конфигурациями для системы, находящейся в эксплуатации, и для проектов, находящихся в разработке, должны работать интегрированно.
После согласования и подписания обобщенного Плана управления конфигурациями можно начинать планирование внедрения. Рекомендуется поэтапное внедрение, начиная с одной четко определенной услуги и корпоративных данных. Это позволит раньше продемонстрировать преимущества и улучшить эффективность действий по внедрению на последующих этапах.
7.5.2 Согласование цели, задач, масштаба, приоритетов и подхода к внедрению в соответствии с требованиями бизнеса.
Цель, задачи, масштаб и приоритеты Управления конфигурациями должны быть согласованы с Менеджером услуг и другими менеджерами и соответствовать требованиям бизнеса. Должно быть выработано соглашение, будет ли этот процесс централизован совместно с Управлением изменениями и Управлением релизами.
Цель и масштаб могут быть следующими:.
Согласованно внедрить процессы Управления конфигурациями, Управления изменениями и Управления релизами для всех операционных сред, пакетных приложений и бизнес-систем.
Задача может быть следующей:.
Установить контроль над всеми ИТ-услугами и компонентами инфраструктуры вместе с сопутствующей документацией и предоставить информационные услуги, чтобы способствовать эффективному и продуктивному планированию, подготовке и внедрению Изменений в услуги ИТ.
Подробные задачи для Управления конфигурациями должны включать:.
■ предоставление всем, кто работает в процессах Управления услугами и поддержки, правильной и точной информации о существующих конфигурациях и их физических и функциональных спецификациях;.
■ определение и документирование процедур и порядка работы, которому необходимо следовать;.
■ идентификация, маркировка и запись наименований и версий УЭ, которые составляют услуги ИТ, инфраструктуру и их взаимосвязи;.
■ отчетность о текущем статусе и истории всех элементов ИТинфраструктуры;.
■ обеспечение записи всех Изменений в УЭ как можно быстрее;.
■ отслеживание и приведение всех записей о конфигурациях и конфигурационных данных в соответствие с действительным состоянием ИТ-инфраструктуры;.
■ обучение и проведение тренингов по процессам контроля в организации;.
■ отчетность по метрикам, связанным с УЭ, Изменениями и Релизами;.
В аудит и отчетность о нарушениях стандартов инфраструктуры и процедур Управления конфигурациями.
Для многих организаций поэтапный подход к внедрению, включая Управление изменениями, особенно важен. Подход к внедрению может быть определен по организационным единицам, по местоположениям, по группам Заказчиков, по группам поддержки или по какому-либо другому признаку Некоторые организации указывают приоритеты внедрения по типам контролируемых УЭ.
Самые высокие приоритеты могут быть указаны для следующих типов:.
В серверы поддержки инфраструктуры;.
В мейнфрейм-системы;.
В базы данных Заказчиков и поставщиков;.
В операционные среды и приложения, поддерживающие бизнес-системы, регулируемые законодательством;.
В услуги, критичные для целей бизнеса;.
В сборки рабочих станций и лицензии на ПО;.
Все эти приоритеты должны быть сбалансированы по отношению к процедурам и порядку проведения Изменений в различных группах. Группам сложно внедрять сразу несколько процессов, связанных с Управлением изменениями и Управлением конфигурациями, кроме как короткими промежутками времени.
Необходимо спланировать затраты на средства поддержки, учитывая требования к аппаратному обеспечению. Несмотря на то, что средства, способные интегрировать работу Управления инцидентами, Управления изменениями, Управления конфигурациями, Управления релизами, Управления проблемами и Службы Service Desk, могут стоить значительно дороже, чем «простые» средства Управления конфигурациями, дополнительная стоимость часто будет оправдана за счет более высокой степени интеграции. Для более крупных организаций эти процессы управления практически невозможны без адекватных средств поддержки.
7.5.3 Назначение Менеджера конфигураций и планирование группы Управления конфигурациями.
Возможно создание функционального центра, который будет нести ответственность за управление Изменениями в аппаратном обеспечении, коммуникационном оборудовании и ПО, системном ПО, прикладном программном обеспечении, находящемся в эксплуатации, и всей документации и процедурах, которые связаны с функционированием, поддержкой и сопровождением эксплуатируемых систем. Рекомендации по созданию функционального центра описаны в Приложении 7А.
Процесс Управления конфигурациями требует от задействованного персонала усердной работы и внимания к деталям. Для центра поддержки требуется персонал (кроме случаев небольших организаций). При планировании количества персонала для Управления конфигурациями должны быть рассмотрены следующие факторы:.
■ есть ли возможность загрузки персонала Управления конфигурациями выполнением других обязанностей, или требуется полное внимание выделенных специалистов;.
■ будет ли группа Управления конфигурациями нести ответственность за проекты так же, как и за ИТ-инфраструктуру и услуги;.
■ будет ли эта группа частью объединенной группы по Управлению изменениями, конфигурациями и релизами;.
■ размер ИТ-инфраструктуры, уровень, на котором должен поддерживаться контроль, и, следовательно, количество УЭ, которое необходимо контролировать;.
■ количество персонала, который будет осуществлять действия по контролю в других группах и проектах;.
■ доступность средств поддержки;.
■ размеры, частота и сложность Изменений и Релизов.
Для Управления конфигурациями необходимо разработать спецификации ролей. Примеры обязанностей показаны в Приложении 7Б. Типичные роли включают Менеджера конфигураций, Библиотекаря конфигураций. Необходимо назначить Менеджера конфигураций и определить другие ключевые роли как можно раньше, поскольку назначенные сотрудники смогут быть вовлечены во внедрение как основные бизнес-Пользователи.
7.5.4 Анализ существующих систем.
Даже в организациях, не использующих процессы в своей работе, существуют процессы и процедуры Управления конфигурациями. Они могут быть встроены в другие процедуры или связаны с какой-либо отдельной группой. Если одна из поставленных целей - внедрение общей системы Управления конфигурациями вместе с соответствующими процессами, то важно определить и проанализировать:.
■ владельцев УЭ высокого уровня;.
■ текущие рамки процесса и ресурсы (человеческие ресурсы и средства автоматизации);.
■ текущий порядок, процессы и процедуры Управления изменениями и Управления конфигурациями;.
■ обобщенные конфигурационные данные для текущих списков оборудования, печатных материалов, локальных таблиц или баз данных;.
■ роли, ответственности и возможности персонала, вовлеченного в Управление конфигурациями.
7.5.5 Разработка планов Управления конфигурациями и проектирование систем.
Для некоторых технологий и платформ Управление конфигурациями может быть распространено по всей организации, например для мейнфрейм-систем, сетей и рабочих станций. Ряд организаций передает контроль группам поддержки, являющимся экспертами в какой-либо технологии или платформе, поскольку обучение центрального персонала в специализированных областях невыгодно. В этих случаях менеджер группы поддержки несет ответственность за контроль Учетных элементов, которыми владеет и которые поддерживает эта группа. Процедуры для Управления изменениями, Управления конфигурациями, Управления релизами и централизованную CMDB следует использовать везде, где это возможно. Эти процедуры могут быть определены в плане Управления изменениями и конфигурациями для организации (см. Приложение 7 А) и поддерживаться документацией по эксплуатации и проектной документацией для системы Управления конфигурациями. Связи между этими планами должны быть документированы, чтобы помочь персоналу видеть контекст Управления конфигурациями применительно к их группе. Менеджер каждой группы должен подписаться под этим планом. Пример связей показан на Рисунке 7.2.
Подробные планы должны соответствовать обобщенным планам и ссылаться на них, чтобы избежать повторений.
Возможны ситуации, когда обязанности по Управлению конфигурациями будут передаваться различным подразделениям (в рамках организации), обладающим соответствующей квалификацией. Однако в идеале, если позволяют ресурсы, лучше иметь функциональный центр, который обеспечит единые процессы и процедуры. Передача обязанностей, с другой стороны, нуждается в тщательном управлении и регулярных аудитах. Важно всегда иметь только одного владельца процесса - и это становится еще более важным, если есть несколько разделенных групп, выполняющих действия по Управлению конфигурациями.
Рисунок 7.2 - Примеры планов Управления конфигурациями в организации.
Планы управления конфигурациями определяют масштаб Управления конфигурациями, что необходимо при проектировании системы и на следующем этапе планирования.
7.5.6 Подробное планирование внедрения.
Когда основные решения о масштабе Управления конфигурациями приняты и планирование завершено, необходимо разработать план внедрения Управления конфигурациями. Если только рассматриваемая область не является «непаханой целиной», какие-либо процедуры и записи, скорее всего, уже существуют. Необходимо помнить об этом при планировании внедрения.
Основные действия следующие:.
■ более подробно проанализировать сложившийся порядок Управления конфигурациями, а также его взаимодействие с другими процессами Управления услугами, закупками и разработками;.
■ проанализировать возможности существующих подразделений и сотрудников, вовлеченных в Управление конфигурациями, изменениями и релизами;.
■ провести обзор конфигурационных данных, содержащихся в печатном виде, в локальных электронных таблицах или базах данных, и разработать стратегию переноса/загрузки этих данных;.
■ собрать, пересмотреть и достичь соглашения по требованиям и функциональным спецификациям;.
■ разработать критерии выбора поставщиков средств автоматизации Управления конфигурациями;.
■ оценить и выбрать средства автоматизации CMDB и Управления конфигурациями;.
■ купить и инсталлировать средства автоматизации CMDB и Управления конфигурациями;.
■ составить подробный проект системы Управления конфигурациями, включая интерфейсы с Управлением изменениями, Управлением релизами, другими процессами Управления услугами, закупками и разработкой;.
■ определить типы УЭ, их атрибуты, типы взаимосвязей, обобщенные УЭ;.
■ разработать бизнес-процессы Управления конфигурациями и процедуры, интегрированные со средствами Управления конфигурациями;.
■ проверить CMDB и другие средства поддержки, выделив достаточно времени для исправления проблем, включая незначительные и не влияющие на успешную работу; их также обязательно надо устранить до внедрения Управления конфигурациями;.
■ спланировать и обеспечить безопасные хранилища УЭ (то есть, шкафы, контролируемые библиотеки и каталоги) совместно с Управлением релизами;.
■ разработать и достичь соглашения о ролях, обязанностях и планах по обучению;.
■ объяснить персоналу важность Управления изменениями и Управления конфигурациями и обучить его использованию этих процессов.
Может потребоваться дополнительный персонал для внедрения Управления конфигурациями, аудита существующей инфраструктуры и наполнения данными CMDB. Иногда руководство будет назначать персонал для помощи в выполнении этих задач, если оно видит преимущества Управления конфигурациями, и если ресурсы персонала планируются заранее.
Планирование поэтапного внедрения Управления конфигурациями поможет получить преимущества раньше и обосновать необходимость в финансировании и ресурсах на последующих этапах. Для каждого этапа необходимо спланировать следующие действия:.
■ составить график ознакомительного обучения для ключевого персонала, вовлеченного в Управление конфигурациями;.
■ определить и разработать планы Управления конфигурациями для каждой группы или технологии и создать локальные процедуры там, где это необходимо;.
■ проанализировать, спроектировать и собрать модули системы Управления конфигурациями для поддержки процессов Управления конфигурациями и всех связанных процессов, интерфейсов и данных;.
■ оценить и учредить обновленные роли и обязанности персонала, включающие действия процесса Управления конфигурациями;.
■ разработать и спланировать процедуры регистрации для новых УЭ, и начать выполнять их как можно раньше (предпочтительно перед тем, как собраны данные о существующих УЭ);.
■ загрузить начальную конфигурацию и связанные учетные записи в систему Управления конфигурациями;.
■ обучить персонал незадолго до начала использования новых процедур и программных средств;.
■ начать промышленную эксплуатацию и поддерживать внедрение;.
■ продолжать наполнение CMDB и Библиотеки Эталонного ПО; самая длительная часть внедрения - сбор информации об УЭ и наполнение CMDB и Библиотеки Эталонного ПО (Definitive Software Libaray, DSL);.
■ наблюдать за ходом работ, чтобы обеспечить эффективное и продуктивное использование новых процедур и программных средств.
Если Управление конфигурациями используется для поддержки выполнения других процессов, таких как Управление инцидентами, то, чтобы разворачивать эти системы параллельно, потребуется дополнительное планирование. Локальные планы Управления конфигурациями могут определить процессы идентификации и контроля УЭ для определенных технологических групп. Руководитель группы может назначить Менеджера конфигураций для владения локальным планом Управления конфигурациями и общения с персоналом центрального подразделения Управления конфигурациями, а также в качестве представителя в Консультативном комитете (или комитетах) по изменениям (Change Advisory Board, CAB).
Планируйте наполнение CMDB по мере проведения инвентаризации для каждого этапа внедрения. Необходимо выделить время для правильного выполнения этих задач. Для таких задач рассмотрите возможность использования временного персонала, обладающего навыками ввода данных. Тем не менее, если позволяет время, выполнение этих задач может предоставить возможность персоналу Управления конфигурациями лучше освоить использование средств поддержки. Если для других целей какая-либо часть данных уже существует в электронном виде, рассмотрите возможность переформатирования и переноса этих данных.
В идеале во время наполнения CMDB состояние УЭ должно быть «заморожено» или «в ожидании», но такое решение может оказаться непрактичным. Тем не менее, после сбора данных Управления конфигурациями об определенных УЭ эти УЭ должны быть сразу же переданы под контроль Управления конфигурациями. В этом случае возможно наполнять CMDB поэтапно (то есть начать с аппаратного обеспечения, потом постепенно перейти к программному обеспечению, сетям) см. параграф 7.5.7.
Может случиться так, что передача элементов под контроль Управления конфигурациями будет невозможна из-за того, что оборудование передано в эксплуатацию. В этих случаях необходимо спланировать процедуры для отслеживания и записи Изменений, которые происходят с момента передачи оборудования в эксплуатацию до начала контроля Управления конфигурациями (то есть, когда наполнение CMDB завершено).
Когда вся подготовительная работа завершена, при вводе в эксплуатацию потребуется, чтобы персонал начал использовать новые процедуры в согласованные день и время. Опубликуйте дату и время внедрения новых процедур для тех, кого это затрагивает, в особенности всего персонала службы поддержки ИТ, внешних поставщиков и поставщиков услуг. Персоналу необходимо напоминать об их обязанностях соблюдать новые процедуры с самого начала работы.
7.5.7 Наполнение CMDB и DSL.
УЭ должны быть переданы под контроль Управления конфигурациями, как только о них собраны данные. Не следует добавлять новые элементы в ИТинфраструктуру без контроля Управления конфигурациями.
Идеальный вариант для наполнения CMDB - «заморозить» Изменения во время наполнения CMDB. Тогда все Изменения будут проходить под контролем Управления конфигурациями. Это не всегда может быть практично, но все же такую возможность необходимо рассмотреть. Управление конфигурациями и Управление изменениями работают совместно - на самом деле очень сложно выстроить один процесс без другого. Сразу же после наполнения CMDB необходимо обеспечить определенный уровень Управления изменениями для обновления записи о конфигурациях и конфигурационных данных.
Если такой подход невозможен, то важно записывать все Изменения, которые возникают между сбором данных об УЭ, последующим вводом этих данных в CMDB и передачей УЭ под контроль Управления конфигурациями. Для этого следует минимизировать интервал между этими этапами для каждого УЭ. Вначале должны быть собраны Запросы на Изменение (RFC) и записи о Релизах, соответствующие еще не внедренным Изменениям. Все RFC после этого должны быть включены в CMDB. При таком подходе CMDB может быть использована для записи всех последующих действий по внесению Изменений, включая авторизацию и внедрение. Сбор любых требуемых исторических записи может быть отложен для выполнения в удобное время.
Процесс Управления релизами должен наполнять Библиотеку эталонного ПО (DSL) параллельно с внедрением CMDB. Требуются процедуры для обеспечения того, что:.
■ чтобы это находящееся в DSL программное обеспечение было защищено;.
После того как обеспечено наличие необходимого персонала, аппаратного обеспечения и средств поддержки, а также завершено все необходимое обучение, необходимо создать DSL и среду сборки. Следует установить права доступа, чтобы доступ мог осуществлять только авторизованный персонал. Необходимо протестировать DSL и среду сборки на соответствие критериям, определенным на этапе планирования.
Персонал, участвующий в проектах и в разработке и поддержке приложений, должен быть проинформирован, когда необходимо начать доставлять материал и кому его отправлять для включения в DSL. Необходимо организовать хранение определенного готового коммерческого ПО в CMDB и DSL вместе с сопутствующей документацией (например, лицензиями).
Внедрение управления сборкой, распространением и наполнением должно проходить через некоторое время после создания DSL. Перед началом использования этих процедур их следует протестировать. При использовании поэтапного подхода первая сборка Релиза произойдет тогда, когда результаты выбранного проекта или поставщика переходят на этап операционного приемочного тестирования. К тому времени, когда необходимо передать Релизы в среду эксплуатации, процедуры контроля сборки и Релиза уже будут задействованы для передачи ПО в среду операционного приемочного тестирования. Следовательно, представляется еще одна возможность для выявления и устранения множества типов потенциальных проблем, связанных с процедурами и программными средствами.
Тем не менее, должны быть созданы планы действий в чрезвычайных ситуациях на случай отказа в работе новых процедур и средств. Когда срочно требуется Релиз ПО, может понадобиться временно вернуться к старым процедурам, пока новые процедуры не будут исправлены. Рекомендуется, по возможности, тестировать процедуры и средства для распространения ПО отдельно от средств для инсталляции и тестирования ПО на местах, что позволит изолировать проблемы, связанные с каждым из этих этапов, и устранять их по отдельности.
Несмотря на то, что процедуры должны быть тщательно протестированы перед их вводом в эксплуатацию, необходимо выделить время для разрешения конфликтов и проблем, связанных с введением новшеств, на ранних этапах эксплуатации.
7.5.8 Переключение на новые процессы.
Переключение на новые процессы может проходить параллельно с наполнением CMDB и DSL. УЭ могут поэтапно передаваться под контроль Управления конфигурациями по мере сбора данных обУЭ и записи этой информации в CMDB. Обо всех Изменениях в Учетных элементах, которые еще не перешли под контроль Управления конфигурациями, должно сообщаться в центральное подразделение. Если возможно, УЭ, которые были затронуты Изменением, должны быть сразу же взяты под контроль. Все УЭ, которые появились после начала работы системы Управления конфигурациями, должны быть сразу же переданы под контроль процесса.
Во многих случаях метрики процедур и использование средств автоматизации для некоторых процессов контроля конфигураций, Релизов, распространения и аудита могут предотвратить или, как минимум, обнаружить возврат к какой-либо предыдущей процедуре или порядку.
После начала эксплуатации новой системы Управления конфигурациями жизненно важно, чтобы новые элементы не добавлялись в ИТ-инфраструктуру без авторизации Управления конфигурациями. Это требует интерфейсов для процессов разработок, приобретения или закупок материала. Существующие элементы, находящиеся под контролем Управления конфигурациями (то есть все УЭ, кроме тех, которые временно не рассматриваются, исходя из поэтапного внедрения), не должны изменяться без авторизации. Все неавторизованные версии УЭ и сами УЭ должны быть либо ликвидированы, либо переведены под контроль Управления конфигурациями.
7.5.9 Другие вопросы, связанные с внедрением.
Управление конфигурациями для инфраструктуры и услуг требует хорошего планирования и проектирования, чтобы обеспечить выполнение целей и получение ожидаемых преимуществ.
Для эффективной работы Управления конфигурациями требуется долгосрочная приверженность руководства и персонала. Успешное внедрение зависит от достаточного количества обученных сотрудников. Если существует нехватка персонала в подразделении, отвечающем за Управление конфигурациями, или сотрудники недостаточно обучены, то это может стать «узким местом» при внедрении процесса, привести к критическим ошибкам, затраты на исправление которых могут быть больше, чем расходы на оплату квалифицированных струдников. На короткий период при внедрении проекта может потребоваться дополнительный персонал (например, для помощи при проведении инвентаризации и/или наполнении CMDB).
Рекомендуется внедрять Управление конфигурациями постепенно, начиная с тех типов УЭ или с тех частей ИТ-инфраструктуры, где контроль воспринимается как наиболее важный, или там, где есть наибольшая необходимость в улучшениях, а потом расширять систему для включения других областей.
Учитывая сложность ИТ-систем и услуг, важно обеспечить поддержку системы Управления конфигурациями, иначе конфигурационные данные быстро станут неактуальными и им перестанут доверять. Должны быть спланированы анализ и аудит деятельности для обеспечения.
■ аудита действий по Управлению конфигурациями на предмет их соответствия Планам управления конфигурациями;.
■ достаточного (хотя и не слишком подробного) набора УЭ, находящихся под Управлением конфигурациями, с целью обеспечения контроля и.
поддержки эффективного Управления проблемами, Управления изменениями и Управления релизами;.
■ доступности ресурсов и достаточной квалификации персонала для эффективного выполнения действий по Управлению конфигурациями;.
■ достаточного уровня автоматизации, позволяющего уменьшить количество трудоемких действий и действий с высокой вероятностью ошибок;.
■ постоянного доступа персонала Управления ИТ-услугами к обновленным, точным и полным записям о конфигурациях и конфигурационным данным.
7.5.10 Затраты.
Полученные преимущества от внедрения Управления конфигурациями превысят затраты. Например, многие организации не могут удовлетворительно выполнять свои функции, если они не в состоянии управлять большим объемом Изменений в программном и аппаратном обеспечении без потери качества. При отсутствии соответствующего контроля организации подвержены риску компьютерного мошенничества, случайного повреждения программного обеспечения, программных вирусов и другого ПО, используемого со злым умыслом. Восстановление повреждений, повлеченных вышеуказанными причинами, может стоить громадных денег.
Затраты, связанные с внедрением подразделения Управления конфигурациями, включают зарплату персонала и накладные расходы, средства поддержки, затраты на помещение для группы и затраты на обучение. В начальный период операционные затраты могут превышать нормальный уровень, пока персонал изучает процедуры.
Практическое применение Управления изменениями и Управления конфигурациями приведет к улучшению качества услуг, которое с избытком возместит все накладные расходы. Накладные расходы зависят от многих факторов, включая:.
■ затраты на персонал для разработки и выполнения процедур;.
■ идентификацию конфигураций АО и ПО и уровня контроля над ними;.
■ аппаратное и программное обеспечение для CMDB и DSL, включая затраты на лицензии и сопровождение;.
■ специализированное ПО управления конфигурациями для каждой платформы, включая соответствующее АО;.
■ количество Пользователей, которым необходимо иметь доступ к системе Управления конфигурациями, и местоположение этих Пользователей;.
■ необходимость перестройки системы Управления конфигурациями для удовлетворения нужд организации;.
■ необходимость интеграции средств Управления конфигурациями и средств Управления услугами;.
■ разнородность и качество существующей информации, которая должна быть загружена в CMDB.
При начальном сборе данных могут возникнуть дополнительные затраты на персонал. Тем не менее, не делайте ошибки, классифицируя затраты на персонал, задействованный в процессах, связанных с Изменениями и Конфигурациями, как накладные расходы! Если Управление конфигурациями ранее не выполнялось, то скорее всего произойдет увеличение количества требуемого персонала. Потребуется время для исправления того, чего можно было избежать при функционировании процессов, и понадобится больше сотрудников для обработки Изменений и Проблем.
Другие затраты по внедрению Управления конфигурациями связаны также:.
■ с обучением персонала и образованием;.
■ с затратами на персонал для разработки и выполнения процедур;.
■ с количеством Пользователей, которым необходимо иметь доступ к системе Управления конфигурациями;.
■ с разнородностью и качеством существующей информации, которая будет загружена в CMDB и DSL, и с усилиями, требуемыми для ее обработки и загрузки;.
■ со временем и ресурсами, требуемыми для приведения в порядок низкокачественных данных;.
