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

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

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

 

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

С момента формального основания дисциплины управления конфигурацией, которое можно условно отсчитывать от даты введения стандарта IEEE-STD-610, она рассматривалась с разных точек зрения и в различных приложениях. Был накоплен богатый опыт использования процедур управления конфигурацией в различных проектах, который обобщался с точки зрения различных стандартов и моделей программной инженерии.

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

• конфигурационная идентификация артефактов (рабочих материалов), используемых или создаваемых в ходе проекта;

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

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

• ревизия и аудит конфигурации, в ходе которой оценивается состояние и готовность продукта;

• процедуры управления выпуском продукта (release management), его доставки и мониторинга состояния проекта;

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

К основным элементам процесса управления конфигурацией можно отнести (см. рисунок 1.) следующие четыре элемента:

1. Конфигурационная идентификация.

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

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

4. Ревизия и аудит конфигурации.

Рисунок 1. Основные элементы управления конфигурацией.

Рассмотрим подробнее состав каждого из этих элементов.

Конфигурационная идентификация основывается на следующих составляющих:

• правила идентификации и нумерации – что и каким образом идентифицируется;

• идентификация требований к продукту – каким образом идентифицируются требования к ПС;

• идентификация изменений в данных – каким образом идентифицируются изменения в данных;

• базовые версии – создаются для фиксации стабильных состояний системы и используются как кандидаты на релиз ПС;

• спецификации и диаграммы – документы, описывающие конфигурационную спецификацию ПС и диаграммы, используемые для этих же целей;

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

Контроль конфигурации включает:

• критерии утверждения изменений – определяют формальные критерии, на основании которых принимается решение об утверждении или отклонении предложенного изменения;

• спецификации, модели, документация и т.п. – все эти элементы конфигурации подвержены изменениям и находятся в сфере действия контроля конфигурации;

• процедуры контроля конфигурации – утвержденные процедуры, которым должны следовать участники проекта;

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

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

• ведение истории изменений конфигурации продукта – определяет кто, когда и какие изменения делал;

• ведение истории состояний утвержденных изменений – показывает, как менялись состояния утвержденных изменений от момента утверждения и до момента завершения их отработки;

• ведение истории верификации конфигурации – хранит данные о всех проведенных верификациях и их результаты;

• учет авторизации изменений – указывает на то, кто отвечает за сделанные изменения.

Ревизия и аудит конфигурации включает:

• формальные квалификационные ревизии – определяют соответствие элементов конфигурации предъявляемым к ним формальным требованиям, например, соответствие определенному шаблону документа;

• функциональный аудит конфигурации – определяет соответствие конфигурации ПС функциональным требованиям, предъявляемым к продукту;

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

 

3. Управление конфигурацией в стандартах

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

3.1 Виды стандартов

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

Все стандарты можно условно разделить на виды, в зависимости от широты их области действия:

1. Международные стандарты, действующие без ограничений во всех странах;

2. Государственные или отраслевые стандарты, действующие для группы предприятий или организаций, объединяемых некоторыми общими признаками;

3. Внутренние стандарты предприятия, действующие для конкретного предприятия и учитывающие специфику этого предприятия.

Некоторые часто используемые международные стандарты приведены ниже (см. таблицу 1). В таблице «SCM» обозначает возможность использования стандарта для УК ПС (software configuration management), а «HCM» – для оборудования (hardware configuration management). В рассматриваемой таблице выделены три наиболее значимые области использования стандартов:

• процесс приобретения, в ходе которого определяется степень совместимости приобретаемого продукта с уже эксплуатирующимися в организации системами и оборудованием;

• процесс поставки/разработки продукта, для которого особенно важным является согласованность действий поставщика/разработчика и заказчика продукта при определении конфигурационной идентификации, ревизий и аудита конфигурации, согласовании изменений, вносимых в продукт;

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

Таблица 1. Международные стандарты, описывающие процесс УК 

Стандарты и руководства	Область действия		Описание
	Процесс приобретения	Процесс поставки/ разработки
IEEE/EIA 12207.0-1996, Industry Implementation of International StandardISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology — Software Lifecycle Processes	SCM, SW	SCM, SW	Устанавливает общую структуру процессов жизненного цикла(ЖЦ) программных средств.
IEEE/EIA 12207.1-1996, Lifecycle data.	SCM, SW	SCM, SW	Представляет рекомендации о характере данных, которые должны сохраняться при выполнении задач и работ, приведенных в IEEE/EIA 12207.0
IEEE/EIA 12207.2-1996, Implementation Considerations	SCM, SW	SCM, SW	Представляет рекомендации по реализации требований стандарта IEEE/EIA 12207.0.
ISO 9000-3: Quality Mgmt & Quality Assurance Stds-Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software		SCM, SW	Излагает рекомендации по применению ISO 9001 в организациях, разрабатывающих, поставляющих и сопровождающих программное обеспечение (ПО).

 

В качестве примера отраслевого стандарта можно привести MIL-STD-2549 «Configuration Management Data Interface», который детализирует требования для обмена данными между правительственными системами конфигурационного управления.

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

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

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

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

• Международный стандарт – определение общих положений процесса УК;

• Методология, соответствующая выбранным общим положениям – детализация процесса УК на основе проверенных на опыте многих компаний принципов и правил;

• Стандарт предприятия – уточнение процесса и его адаптации к нуждам конкретного предприятия.

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