Управление конфигурацией
Управление конфигурацией (configuration management) -- это про связь наших ожиданий (проектов) с реальностью.
Как всегда, "управление чем-то" ни разу не "управление", а обозначает "всё необходимое, чтобы это что-то было в приличном состоянии".
Конфигурация -- это знание о том, какова работающая (актуальная) система, выделенная из множества ее возможных вариантов (т.е. какие насосы лежат запчастями на складе, а какие таки установлены и работают; какой из пяти рассматривавшихся вариантов реализации предохранительного клапана пошёл в проект, а какие только остались в виде эскизов; какие из требований были отклонены, а какие утверждены и поэтому требуют внимания).
Управление конфигурацией -- это техническая дисциплина системной инженерии, обеспечивающая поддержание надлежащей (задуманной, одобренной) конфигурации системы во время всего её жизненного цикла. Если говорить попроще, то управление конфигурацией -- это практика, обеспечивающая на протяжении всего жизненного цикла совместимость версий (отсутствие коллизий!) и полноту частей системы (отсутствие коллизий!).
Отнесение управления конфигурацией к системной инженерии означает, что конфигурация обязательно относится ко всей системе. Управляющий конфигурацией -- системный инженер, наряду с инженером по требованиям, системным архитектором, интегратором.
Управление конфигурацией включает в себя "истинную теорию", ибо имеет собственные понятия: базис (baseline) -- утвержденная конфигурация, версия/ревизия (version/revision). Конечно, наличествует и "управленческиконфигурационный шовинизм", когда в состав управления конфигурацией записывают и много чего другого. Из этого "многого другого" нужно прежде всего выделить общую теорию учёта/регистрации. Это ведь общее знание для бухгалтерского, депозитарного, складского, регистрационного, конфигурационного учёта: каким образом обеспечивать взаимное соответствие реальности и записей о реальности.
Дисциплина управления конфигурацией имеет следующие основные основные практики:
1. Идентификация -- поддержка инженерных разбиений (классификаций, кодировок) и именования/кодировки отдельных конфигурационных единиц (configuration items). Именно тут обсуждаются PBS, GBS, WBS и разные системы кодировок типа RDS-PP, KKS, RTM, S1000D и т.д.
2. конфигурационный (т.е. специализированный -- так же, как бухгалтерский, депозитарный, складской и т.д.) учет/регистрация -- административное обеспечение взаимного соответствия: 1. проекта (включая требования), 2. исполнительной документации (as built, "что мы думаем о реальной системе"), 3. самой системы "в железе и бетоне". Обычно обеспечивается наличием конфигурационной базы данных (CMDB -- сonfiguration management data base) и административными процедурами по её ведению. Учёт включает в том числе и административные процедуры по назначению ведущего учёт (регистратора), передаче ведения учёта от регистратора регистратору, делегированию полномочий по учёту в порядке распределенной учётной деятельности и т.д.
3. контроль версий (version/revision control): обеспечение того, что базис (утвержденная для каких-то целей конфигурация) собирается из взаимно соответствующих версий частей системы (будь то версии проектной или исполнительной документации, или же версии самой системы "в железе и бетоне"). Софтверщикам с их CVS и SVN против git и Mercurial должно быть понятно, о чем это.
Управление конфигурацией очень просто, когда есть один административный центр, который вводит
а) обязательную идентификацию
б) обязательный регламент учёта
в) централизованное версионирование
Проблемы возникают при распределенной разработке (collaborative engineering, concurrent engineering), где каждая из участвующих в проекте организаций имеет собственные предпочтения по управлению конфигурацией (кодировки, учётные регламенты, версионирование). Собрать из этого распределенного конфигурационного месива базис обычно представляет собой непростую задачу. Так, любая PLM-cистема поддерживает управление конфигурацией. Но вот если у вас в расширенной организации (extended enterprise) используется несколько разных PLM-систем, то у вас немедленно начнутся проблемы. Еще бОльшие проблемы будут, если нет полноценной (организация+софт) системы управления жизненным циклом (СУЖЦ), а есть только неподдержанный организационными решениями (необходимым для управления конфигурацией workflow) софт PLM.
Коллизии, возникающие из проблем управления конфигурацией -- самые распространенные. Отсутствие управления конфигурацией как раз и характеризуется словами "у них там бардак". Поэтому разворачивание технологии управления конфигурацией -- центральная забота при создании СУЖЦ.
Конечно, управление конфигурацией требует указания метода (управлять конфигурацией можно очень и очень по-разному, есть самые разные теории на этот счёт -- теории идентификации, учёта, версионирования). Управление конфигурацией требует обучения людей -- это дисциплина, её нужно знать, и ей нужно дисцилинированно следовать. Управление конфигурацией требует разворачивания в организациях технологии: конфигурационных баз данных, справочников по кодировкам, систем версионирования и т.д.
Как всегда, "управление чем-то" ни разу не "управление", а обозначает "всё необходимое, чтобы это что-то было в приличном состоянии".
Конфигурация -- это знание о том, какова работающая (актуальная) система, выделенная из множества ее возможных вариантов (т.е. какие насосы лежат запчастями на складе, а какие таки установлены и работают; какой из пяти рассматривавшихся вариантов реализации предохранительного клапана пошёл в проект, а какие только остались в виде эскизов; какие из требований были отклонены, а какие утверждены и поэтому требуют внимания).
Управление конфигурацией -- это техническая дисциплина системной инженерии, обеспечивающая поддержание надлежащей (задуманной, одобренной) конфигурации системы во время всего её жизненного цикла. Если говорить попроще, то управление конфигурацией -- это практика, обеспечивающая на протяжении всего жизненного цикла совместимость версий (отсутствие коллизий!) и полноту частей системы (отсутствие коллизий!).
Отнесение управления конфигурацией к системной инженерии означает, что конфигурация обязательно относится ко всей системе. Управляющий конфигурацией -- системный инженер, наряду с инженером по требованиям, системным архитектором, интегратором.
Управление конфигурацией включает в себя "истинную теорию", ибо имеет собственные понятия: базис (baseline) -- утвержденная конфигурация, версия/ревизия (version/revision). Конечно, наличествует и "управленческиконфигурационный шовинизм", когда в состав управления конфигурацией записывают и много чего другого. Из этого "многого другого" нужно прежде всего выделить общую теорию учёта/регистрации. Это ведь общее знание для бухгалтерского, депозитарного, складского, регистрационного, конфигурационного учёта: каким образом обеспечивать взаимное соответствие реальности и записей о реальности.
Дисциплина управления конфигурацией имеет следующие основные основные практики:
1. Идентификация -- поддержка инженерных разбиений (классификаций, кодировок) и именования/кодировки отдельных конфигурационных единиц (configuration items). Именно тут обсуждаются PBS, GBS, WBS и разные системы кодировок типа RDS-PP, KKS, RTM, S1000D и т.д.
2. конфигурационный (т.е. специализированный -- так же, как бухгалтерский, депозитарный, складской и т.д.) учет/регистрация -- административное обеспечение взаимного соответствия: 1. проекта (включая требования), 2. исполнительной документации (as built, "что мы думаем о реальной системе"), 3. самой системы "в железе и бетоне". Обычно обеспечивается наличием конфигурационной базы данных (CMDB -- сonfiguration management data base) и административными процедурами по её ведению. Учёт включает в том числе и административные процедуры по назначению ведущего учёт (регистратора), передаче ведения учёта от регистратора регистратору, делегированию полномочий по учёту в порядке распределенной учётной деятельности и т.д.
3. контроль версий (version/revision control): обеспечение того, что базис (утвержденная для каких-то целей конфигурация) собирается из взаимно соответствующих версий частей системы (будь то версии проектной или исполнительной документации, или же версии самой системы "в железе и бетоне"). Софтверщикам с их CVS и SVN против git и Mercurial должно быть понятно, о чем это.
Управление конфигурацией очень просто, когда есть один административный центр, который вводит
а) обязательную идентификацию
б) обязательный регламент учёта
в) централизованное версионирование
Проблемы возникают при распределенной разработке (collaborative engineering, concurrent engineering), где каждая из участвующих в проекте организаций имеет собственные предпочтения по управлению конфигурацией (кодировки, учётные регламенты, версионирование). Собрать из этого распределенного конфигурационного месива базис обычно представляет собой непростую задачу. Так, любая PLM-cистема поддерживает управление конфигурацией. Но вот если у вас в расширенной организации (extended enterprise) используется несколько разных PLM-систем, то у вас немедленно начнутся проблемы. Еще бОльшие проблемы будут, если нет полноценной (организация+софт) системы управления жизненным циклом (СУЖЦ), а есть только неподдержанный организационными решениями (необходимым для управления конфигурацией workflow) софт PLM.
Коллизии, возникающие из проблем управления конфигурацией -- самые распространенные. Отсутствие управления конфигурацией как раз и характеризуется словами "у них там бардак". Поэтому разворачивание технологии управления конфигурацией -- центральная забота при создании СУЖЦ.
Конечно, управление конфигурацией требует указания метода (управлять конфигурацией можно очень и очень по-разному, есть самые разные теории на этот счёт -- теории идентификации, учёта, версионирования). Управление конфигурацией требует обучения людей -- это дисциплина, её нужно знать, и ей нужно дисцилинированно следовать. Управление конфигурацией требует разворачивания в организациях технологии: конфигурационных баз данных, справочников по кодировкам, систем версионирования и т.д.