Управление конфигурацией (configuration management). Конфигурационное управление (Software Configuration Management)

Программная инженерия

Конфигурационное управление

(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-процесса (наравне с проектной информацией и

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

В большинстве случаев после принятия решения об управлении основными элементами ИТ-инфраструктуры все силы бросают на наполнение CMDB, в которую заносится максимальное количество информации об CI. Через некоторое время информация начинает терять актуальность, разрушаются связи между объектами, появляется нехватка описания не физических, а логических объектов инфраструктуры – все это приводит к отказу от дальнейшего развития. Причина неудач кроется в неправильной оценке внедрения процесса управления конфигурацией, ведь он включает в себя не только базу данных, но и логику в ее заполнении, актуализации и развитии.

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

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

Важность управления конфигурацией

Порой старшие менеджеры говорят, что у них нет денег на покупку дорогостоящих систем для управления конфигурацией (CMSs). Но, принимая такое решение, они не получают контроля над всеми расходуемыми средствами, связанными с восстановлением ИТ и бизнес-услуг; над внесением изменений, без контроля последствий их применения и возможных неблагоприятных последствий для бизнеса; над управлением и оптимизацией затрат на ИТ-имущество и управлением релизами без связи с другими процессами.

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

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

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

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

С чего стоит начать

В-первую очередь необходимо объяснить цель и смысл использования управления конфигурацией всем заинтересованным сторонам, включая владельцев систем, сетевых инженеров и других. Члены команды управления конфигурацией и специалисты, ответственные за данные, которые она содержит, должны предоставлять точную информацию коллегам, решающим инциденты и планирующим изменения. И наоборот: действия, производимые ИТ-специалистами с другими системами, должны отображаться в CMS или базе данных управления конфигурацией (CMDB). Каждая сторона рабочего процесса должна принимать непосредственное участие в управлении конфигурацией – это путь к достижению успеха, это необходимо знать и понимать каждому.

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

В целом внедрение управления конфигурацией можно разделить на 5 этапов:

  • планирование,
  • определение (в том числе исходного состояния),
  • контроль,
  • учет состояния,
  • проверка и аудит.

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

Составление плана

Мы рекомендуем начать планирование управления конфигурацией с наиболее критичных и важных для бизнеса процессов, таких как управление инцидентами и проблемам. Служба технической поддержки всегда загружена заявками от пользователей, и их своевременное исполнение – одна из головных болей руководства. Если вы начнете реализацию проекта именно с этих услуг, это поможет снизить нагрузку и оптимизировать работу специалистов Service Desk и результат заметят другие подразделения компании. Руководство обратит внимание на более быстрое разрешение инцидентов, уменьшение времени простоя, снижение числа неудачных изменений и обеспечит вас поддержкой для дальнейшей реализации.

Условно можно выделить 3 основных элемента (уровня) конфигурации:

  • конфигурация;
  • актив;
  • материально-технический ресурс.

Их распределение отображено на представленной ниже диаграмме.


  • Конфигурационные единицы (CI) являются строительными блоками для критически важных сервисов, они включают в себя серверы, маршрутизаторы, программное обеспечение и системы, на которых оно построено. Чтобы управлять всем этим, требуется много времени, денег и сил, поэтому мы рекомендуем сосредоточиться только на ключевых сервисах, чтобы не переполнить CMS и CMDB лишней информацией, а занести действительно нужную.
  • Активы – ПК, ноутбуки и другая техника, которая находится на финансовом контроле, но не требует управления.
  • Материально-технические ресурсы – это различные мелкие периферийные устройства, такие как клавиатуры, мышки, флешки и тому подобное.

Последовательность – ключ к планированию

При грамотном планировании важна последовательность действий и внимание к мелочам. Например, план может содержать описание способа формирования имен CI. Имя каждой единицы для CMDB должно быть уникально и содержать ключевую информацию, которая помогает ее идентифицировать. Примером может служить такая маска: Тип CI – расположение – служба поддержки. Имя CI «MSserver-Moscow-Level3» говорит оператору Service Desk о том, что Windows Server на московской площадке недоступен и нуждается в технической поддержке третьей группой. Такой уровень информации при регистрации инцидента позволяет сразу предупредить всех пользователей сервера о проблеме, а также назначить тикет именно той группе поддержки, которая за него отвечает, что сокращает время реакции за счет сокращения стадий эскалации.

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

План конфигурации должен быть масштабируемым

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

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

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


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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

1. Описание конфигурационного управления

2. Цели и задачи

3. Процедуры управления конфигурацией

4. Описание плана управления конфигурацией

4.1 Кто пишет план?

4.2 Когда готовят план управления конфигурацией?

4.3 Поддержка плана в актуальном состоянии

4.4 План управления конфигурацией в стандартах

4.5 Факторы, влияющие на структуру плана управления конфигурацией и его детализацию

Глоссарий

Список литературы

1. Описание конфигурационного управления

Конфигурационное управление (англ.

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

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

2. Цели и задачи

Цели конфигурационного управления:

· Контроль: SCM позволяет отслеживать изменения в контролируемых объектах, обеспечивает соблюдение процесса разработки

· Управление: SCM диктует процесс автоматической идентификации в ходе всего жизненного цикла ПО, обеспечивает простоту модификации и сопровождения ПО

· Экономия средств: снижается риск потерь от ротации кадров в организации, предоставить возможность сменить организацию-разработчика без перепроектирования

· Качество

Задачи конфигурационного управления:

· Идентификация конфигурации

· Контроль конфигурации: контроль над изменениями материалов

· Учёт текущего состояния: состояние документов, состояние кода, состояние отдельных задач и всего проекта в целом

· Управление процессом разработки

· Управление сборкой

· Управление окружением

· Отслеживание задач и проблем (в частности, отслеживание ошибок)

3. Процедуры управления конфигурацией

Ревизия конфигурации

Аудит конфигурации

Контроль конфигурации

Учет состояния конфигурации

4. Описание п лан а управления конфигурацией

Многие компании при попытке поставить любой процесс (не важно какой, но в данном случае - Управления Конфигурациями(УК)) ограничиваются только инсталляцией программных средств с минимальными затратами в дальнейшей работе. Так был загублен не один проект. Во-первых, всегда должна быть планомерная работа. А во-вторых, сначала внедряется процесс, а потом инсталлируются средства автоматизации (уж никак не наоборот). Соответственно, если есть процесс, то должен быть документ, описывающий его. Таким документом для процесса УК является «План управления конфигурациями», где излагается концепция процесса и имплементация средств автоматизации. В нем же расписываются все роли, и, что особенно важно, деятельности в зависимости от стадии жизненного цикла разработки ПО.

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

План должен быть документально оформлен и выполнен (план может быть частью плана управления конфигурацией системы).

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

4.1 Кто пишет план?

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

Если говорить применительно к терминологии УК, то есть роль, которая отвечает за физическое написание плана - Менеджер УК.

Менеджер Управления Конфигурациями - ключевая роль. Этот человек знает процесс разработки. Понимает цели и задачи УК. Все свои знания он излагает в плане УК. Сам управляет процессом УК.

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

Техническое применение плана (реализация плана в средствах поддержки УК)

Как мы уже говорили выше - план содержит высокоуровневое описание процесса, но чтобы инструментальные средства поддержки УК начали следовать плану, необходимо выполнить их физическую настройку:

· Установить средства;

· Разработать экранные формы запросов на изменение;

· Установить политику доступа;

· Определить жизненный цикл запросов на изменение;

· Поставить данные под УК в соответствии с планом;

Физическую настройку обычно проводит администратор, который на основании имеющегося плана проводит физические настройки инструментальных средств УК.

4.2 Когда готовят план управления конфигурацией?

конфигурационный управление программирование

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

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

4.3 Поддержка плана в актуальном состоянии

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

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

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

Очень часто при обследовании компаний, нам приходится сталкиваться с тем, что имеющийся план не соответствует тому процессу, который существует в организации. Самое любопытное заключено в том, что если специалисты на ранних этапах внедрения отслеживали актуальность плана, то со временем план УК (а вместе с ним и большинство документов по другим процессам) постепенно «задвигается» и работа по нему прекращается. И получается очень занятная ситуация: с одной стороны, если идти по формальным признакам, в организации есть процесс и есть НМО, описывающее его. С другой стороны, по факту, НМО описывает нечто, чего уже нет в организации. В итоге можно считать, что в организации нет плана УК, так как он не отражает реалии.

С подобным ходом вещей необходимо нещадно бороться. Мы все прекрасно понимаем, что нормальное состояние человека и организации -- это совершенствование (совершение процесса, самосовершенствование… и т.д.) имеющегося. Просто насущно необходимо совершенствовать документацию по процессу вместе с самим процессом. Их эволюционирование должно осуществляться параллельно. Только тогда можно будет говорить о зрелости процессов в организации.

4.4 План управления конфигурацией в стандартах

План УК является важнейшим документом процесса. По большому счету он является единственным документом процесса УК. Состав и содержимое плана УК определяется в некоторых стандартах, но в большинстве случаев существенно дорабатывается под нужды конкретной организации или проекта при внедрении процессов ЖЦ ПС. Все рассмотренные в данные книге стандарты определяют процесс, роли, но не все определяют и классифицируют планы УК. Рассмотрим подробнее требования стандартов на содержимое планов УК:

4.5 Ф акторы, влияющие на структуру плана управления конфигурацией и его детализацию

Возможные значения

Воздействие, описание

Тип проекта

Разработка модели (прототипа)

Проект сопровождения ПС

Коммерческий (с сопровождением)

Коммерческий без сопровождения

Субподрядный

Наличие нескольких офисов (регионально распределенная разработка)

Один офис

Более одного

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

Относительный размер проекта

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

Количество конфигурационных элементов

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

Количество компонентов и подсистем

Число компонентов и подсистем могут влиять на выборку элементов из репозитория (способ выборки и обращения). Также влияет на глубину изложения раздела, описывающего структуру проектного каталога

Фаза жизненного цикла

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

Модель разработки

В зависимости от того какая модель разработки принята за основу (каскад, итерации, спираль), необходимо откорректировать план УК в части состава фаз ЖЦ ПС, глубины их описания, способа идентификации базовых версий, выпуска релизов.

Доступность (наличие) средств УК и иных смежных средств

Базовые

Основные системы УК (как правило, только отслеживание версий)

Генераторы отчетов (обычно встроенные)

Средства управления библиотеками

Продвинутые, интегрированные

Тоже что и выше. Плюс средства управления изменениями

Встроенные средства сборки и аудита

Разрозненные

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

На ход проекта и на план оказывают существенное воздействие такие факторы как используемые средства разработки, платформа разработки (возможно разработка на нескольких платформах и для нескольких платформ одновременно).

Также большое значение имеют тип и количество средств реализации (автоматизации УК), их принадлежность одному или нескольким вендорам.

Например, в проекте можно использовать средство управления версиями от одного производителя, а средство управления изменениями от другого. Можно иметь интеграцию средства управления со средствами управления проектами а можно и не иметь.

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

Уровень формализации (как процессов организации, так и тип контроля плана)

Уровень формализации можно варьировать в зависимости от многих факторов, в том числе отраженных в данной таблице.

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

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

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

Глоссарий

1. Конфигурационное управление (англ. software configuration management , SCM) в программной инженерии -- комплекс методов, направленных на систематический учёт изменений, вносимых разработчиками в программный продукт в процессе его разработки и сопровождения, сохранение целостности системы после изменений, предотвращение нежелательных и непредсказуемых эффектов, формализацию процесса внесения изменений.

2. План управления конфигурацией - основной документ, регламентирующий все проектные действия, связанные с конфигурационным управлением.

3. Программное средство - набор компьютерных программ, процедур и связанных с ними документации и данных.

4. Инструментальное программное обеспечение -- программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ.

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

6. Техническая документация -- набор документов, используемых при проектировании (конструировании), изготовлении и эксплуатации каких-либо технических объектов.

7. Ревизия конфигурации -- процесс проверки того, что документ нижнего уровня соответствует всем требованиям документа верхнего уровня.

8. Аудит конфигурации -- процесс проверки того, что готовый продукт или его часть соответствуют документации.

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

10. Учет состояния конфигурации -- процесс подготовки отчетов о текущем состоянии продукта и состоянии утвержденных изменений.

Список литературы

1. Липаев В.В. «Документирование и управление конфигурацией программных средств», М., «Синтег», 1998.-203с.

2. Липаев В.В. « Документирование сложных программных средств», М.,» Синтег».2005-200 с.

3. http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5 Википедия “Конфигурационное управление”

4. http://cmcons.com/articles/CC_CQ/paln_cm/ Описание плана управления конфигурацией

5. http://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%98%D1%81%D1%82%D0%BE%D1%87%D0%BD%D0%B8%D0%BA%D0%B8_%D0%BA%D0%BD%D0%B8%D0%B3/0321685865 Aiello, R. (2010). Configuration Management Best Practices: Practical Methods that Work in the Real World (1st ed.). Addison-Wesley. ISBN 0-321-68586-5.

6. http://www.sorlik.ru/swebok/3-6-software_engineering_configuration_management.pdf Сергей Орлик. Программная инженерия. Конфигурационное управление

7. http://citforum.ru/SE/quality/configuration_management/ Дмитрий Лапыгин, Александр Новичков. Конфигурационное управление проектами разработки программного обеспечения (2004).

8. http://cmcons.com/articles/CC_CQ/paln_cm/ Александр Новичков, Дмитрий Лапыгин. Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа

9. http://experience.openquality.ru/software-configuration-management/ Юрий Удовиченко. Управление конфигурациями или кессонная болезнь проектов

10. http://scm-notes.blogspot.ru/ Записки отставного сиэмщика: блог, статьи и книги по Software Configuration Management

Размещено на Allbest.ru

Подобные документы

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

    курсовая работа , добавлен 19.04.2012

    Сущность управления проектами, этапы его реализации и необходимые для этого знания, порядок составления и назначение Плана управления проектом. Концепция тройственной ограниченности. Использование программы MS Oficce Project в управлении проектами.

    реферат , добавлен 16.11.2009

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

    лабораторная работа , добавлен 08.06.2009

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

    дипломная работа , добавлен 23.06.2012

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

    реферат , добавлен 10.02.2011

    Понятие системы управления, ее виды и основные элементы. Критерии оценки состояния объекта управления. Классификация структур управления. Особенности замкнутых и разомкнутых систем автоматического управления. Математическая модель объекта управления.

    контрольная работа , добавлен 23.10.2015

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

    презентация , добавлен 09.11.2015

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

    реферат , добавлен 16.03.2009

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

    курсовая работа , добавлен 03.10.2008

    Характеристика информационных систем управления предприятием. Виды информационных систем управления предприятием, их применение. Специфика систем управления торговым предприятием класса ERP и применение данной системы в деятельности торговой компании.

Или 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.

Т. е. меню со списком выбора вариантов. -Прим. ред.

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

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

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

Управление конфигурацией - практика системноинженерного менеджмента - она занимается поддержанием целостности системы на протяжении всего ЖЦ. В рамках этой практики выпускаются различные виды спецификаций закупаемого/изготавливаемого оборудования/изделий - BOM (bill of materials, список комплектующих).

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

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

Основные понятия

Управление конфигурацией включает в себя следующие понятия:

  • базис (configuration baseline) - исходная (утвержденная) конфигурация. Базис определяется на следующих этапах:
Базис Определяется на этапе Тип спецификации Характеристики Описываемый элемент
Функциональный Выбор концепции A Функциональные спецификации Система
Физический (Allocated) Техническое проектирование B Проектная документация Элемент конфигурации
Продукции (Product) Техническое проектирование C, D, E Производственно-технологическая документация Элемент конфигурации
  • версия/ревизия (version/revision);
  • элемент конфигурации (configuration item, CI) - элемент системы, который является основой для описания и формального управления проектированием системы, базовая часть системы, которая проектируется, конструируется и создается силами одной организации. Характеристики и интерфейсы CI с другими составными частями должны быть определены и контролироваться, чтобы гарантировать надлежащее функционирование CI в составе системы в целом. Различают:
    • аппаратные элементы конфигурации (hardware CI - HWCI)
    • элементы конфигурации программного обеспечения компьютера (computer software CI - CSCI)

Практики

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

  • практика выпуска (release) инженерных артефактов (например, выпуск чертежей) - можно обсуждать, является ли hand-over данных входящим в эту практику, или должен рассматриваться отдельно
  • практика выпуска заказных спецификаций (BOM, bill of materials)
  • практика запросов на изменения
  • практика изменения проекта
  • практика управления данными (чтобы нужные заинтересованным сторонам данные оказывались у них в нужное время. Да, "управление требованиями", как часть инженерии требований, отвечающая именно за то, чтобы требования адекватно хранились и адекватно предоставлялись по запросам заинтересованных сторон - это часть именно этой практики. Ибо нет никаких особенностей именно у "управления требованиями" в отличии их от управления любыми другими данными).

Дисциплина управления конфигурацией имеет следующие основные основные практики:

  • Идентификация - поддержка инженерных разбиений (классификаций, кодировок) и именования/кодировки отдельных конфигурационных единиц (configuration items).
Именно тут обсуждаются PBS , GBS, WBS и разные системы кодировок типа RDS-PP, KKS, RTM, S1000D и т.д.
  • Конфигурационный учет/регистрация - административное обеспечение взаимного соответствия:
    • проекта (включая требования),
    • исполнительной документации (as built, "что мы думаем о реальной системе"),
    • самой системы "в железе и бетоне".
Обычно обеспечивается: наличием конфигурационной базы данных (CMDB - сonfiguration management data base) административными процедурами по её ведению (в т.ч. по назначению ведущего учёт (регистратора), передаче ведения учёта от регистратора регистратору, делегированию полномочий по учёту в порядке распределенной учётной деятельности и т.д.)
  • Контроль версий (version/revision control): обеспечение того, что базис (утвержденная для каких-то целей конфигурация) собирается из взаимно соответствующих версий частей системы (будь то версии проектной или исполнительной документации, или же версии самой системы "в железе и бетоне"). Софтверщикам с их CVS и SVN против git и Mercurial должно быть понятно, о чем это.

Основные принципы

Управление конфигурацией очень просто, когда есть один административный центр, который вводит

  1. обязательную идентификацию
  2. обязательный регламент учёта
  3. централизованное версионирование

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

Так, любая PLM-система поддерживает управление конфигурацией. Но если в расширенной организации (extended enterprise) используется несколько разных PLM-систем, то немедленно начнутся проблемы. Еще бОльшие проблемы будут, если нет полноценной (организация+софт) системы управления жизненным циклом (СУЖЦ) , а есть только неподдержанный организационными решениями (необходимым для управления конфигурацией workflow) софт PLM.

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

Управление конфигурацией требует:

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

Инструментарий

Для управления конфигурацией определения системы сейчас используют информационные системы.

  • Сергей Савенков

    какой то “куцый” обзор… как будто спешили куда то