Возникновение основных терминов управления конфигурацией

Затем было решено, что разрабатываемый конечный продукт будет называться «конфигурационным объектом» (configuration item). Конфигурационные объекты (КО) могут представлять собой стол или самолет, если рассматривать оборудование, или программные средства в виде инсталляционных пакетов, если речь идет о программных средствах.

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

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

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

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

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

Базовые процедуры управления конфигурацией

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

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

Другой способ – сравнение разрабатываемого документа с документами более высокого уровня, которые были утверждены ранее в процессе разработки. Для этой работы было использовано понятие «ревизия» (review) с добавлением слова «конфигурация». «Ревизия конфигурации» (configuration review ) представляет собой сравнение документа низкого уровня с предшествующим ему документом или документом верхнего уровня с тем, чтобы удостовериться, что документ нижнего уровня удовлетворяет всем требованиям, присутствующим в документе верхнего уровня, и нет никаких неожиданных добавлений. Это позволяет постепенно и аккуратно детализировать требования верхнего уровня в документах низкого уровня, уточняя конфигурационную идентификацию по мере разработки конфигурационного объекта.

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

Подобная техника проверки того, что продукт создается по установленным правилам и требованиям, используется при проведении «аудита конфигурации» (configuration audit ). Аудит конфигурации подобен процессу ревизии за исключением одной особенности – объектом приложения аудита является конфигурационный объект или конечный продукт, который сравнивается с документацией, составляющей его конфигурационную идентификацию. Объектом приложения ревизии являются отдельные документы.

Еще один способ гарантировать точность конфигурационной спецификации – иметь специальную группу (возможно, состоящую из одного специалиста), которая отслеживала бы все предлагаемые изменения продукта и отвергала или одобряла их. Такая деятельность получила название «контроль конфигурации» (сonfiguration сontrol). Группы, выполняющие функции контроля конфигурации обычно получают название «Группа контроля над изменениями» (Change Control Board) или «Группа контроля конфигурации» (Configuration Control Board, сокращенно CCB). Среди важных функций такой группы – контроль того, что все документы являются актуальными в каждый момент времени и того, что при внесении изменения сначала изменяются документы конфигурационной идентификации, а уже после – сам объект изменений (исходный код, модель и т.п.). Изменение объекта после изменения его описания выгодно еще и тем, что исполнитель, вносящий изменение в объект, будет иметь возможность ознакомиться с описанием этого изменения до начала работы.

Другой областью ответственности управления конфигурацией стала подготовка отчетности о состоянии продукта и состоянии утвержденных изменений на протяжении всего хода работ. Эта деятельность получила название «учет состояния конфигурации» (configuration status accounting)