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

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

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

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

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

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

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

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

• базис (configuration baseline) — исходная (утвержденная) конфигурация. Базис определяется на следующих этапах:

Базис	Определяется на этапе	Тип спецификации	Характеристики	Описываемый элемент
Функциональный (Functional)	Выбор концепции	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.

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

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

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

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

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

• VCS (version control system) — система управления версиями в программной инженерии;
• PDM-система (product data management) — система хранения информации проекта-design;
• PLM-система (product life cycle management) — система управления жизненным циклом, это PDM + система управления изменениями и поддержка интерфейсов в другие информационные системы других стадий жизненного цикла — системы закупок, например;
• EAM-система (enterprise asse management) — система управления активами, используется для учёта установленного оборудования на стадии эксплуатации.

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

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

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

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

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

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

Ссылки

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