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

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

Ниже приведен пример способа записи идентификаторов рабочих продуктов и путей в структуре каталогов продукта.

<система>[<A>]_[<подсистема>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

<система> определяет систему

<A> обозначает трехбуквенный акроним (TLA!). Используется для различных видов рабочих продуктов, участвующих в создании системы. Например,

PLN	Планы проекта
REQ	Файлы требований
USC	Варианты использования
MOD	Файлы модели
SRC	Файлы с исходным кодом
INT	Общие интерфейсы
TST	Тестовые сценарии и результаты тестирования
DOC	Документация (информация о пользователе, информация о выпуске)
BIN	Исполняемые файлы

<подсистема> определяет каждую подсистему

<A> обозначает трехбуквенный акроним для различных видов рабочих продуктов, участвующих в создании подсистемы. См. приведенную выше таблицу.

R|A|B	Обозначают альфа-версию или бета-версию
<X>	Целое число, обозначает основную версию (например, 1)
<Y>	Целое число (указывается при необходимости), обозначает промежуточную версию
<Z>	Целое число (указывается при необходимости), обозначает дополнительную версию (программы по исправлению, порты и т.п.)
BL	Обозначает базовый уровень (внутренняя версия)
#	Целое число, обозначает внутренние версии

Некоторые примеры приведены ниже:

T2K_R1.0	Версия 1 системы Thorn 2000
T2K_GUI_R2.0.BL5	Внутренний выпуск графического интерфейса, подготовленный для версии 2
T2K_B1.1	Бета-версия 1.1 системы Thorn 2000
T2K_R2.0.BL16	Внутренняя контрольная версия #16 системы Thorn 2000, предназначенная для создания версии 2
T2K_R1.0.5	Обслуживающий выпуск системы Thorn 2000

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

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

Контрольные версии различаются, если вы создаете:

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

• Контрольную версию системы с одной версией всех файлов и каталогов всех подсистем.

Для упрощения работы с версиями рекомендуется создавать контрольные версии системы при прохождении больших и малых вех проекта, а контрольные версии подсистем - чаще или по мере необходимости. Также рекомендуется создавать контрольную версию подсистемы, если было изменено более 30% ее элементов.

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

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

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

Отчеты о статусе конфигурации содержит описание источников создания отчетов о состоянии конфигурации.

Выбрать отчеты, основанные на запросах изменений

На этом шаге выберите отчеты, которые можно составить на основе запросов изменений. Существует множество полезных отчетов, основанных на запросах изменений.

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

• Подан
• Выполняется
• Реализован
• Важность

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

В категории "распределение" отчеты помогают ответить на следующие примерные вопросы:

• Кто занимается поиском неполадок, каких видов неполадок и на каких стадиях проекта?
• Кому поручено устранение неполадок?
• Сколько неполадок обнаружено в результатах работы конкретного специалиста?
• Насколько серьезны эти неполадки?
• В чем состоят коренные причины неполадок?
• Когда устраняются эти неполадки?
• Сколько всего неполадок?
• Насколько серьезны эти неполадки?

Эти показатели можно использовать для анализа нагрузки, определения, кто работает над самыми важными неполадками и как быстро неполадки устраняются.

В категории "тенденция" отчеты помогают ответить на следующие примерные вопросы:

• Сколько неполадок возникло сегодня, за эту неделю, за этот месяц?
• Сколько неполадок устранили сегодня, за эту неделю, за этот месяц?

Эту информацию можно использовать для оценки уровня устранения неполадок и определения эффективности работы специалистов.

Определить частоту составления отчетов

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

• Ежедневно - вряд ли потребуется составлять отчеты настолько часто
• Еженедельно - для следующих категорий отчетов: тенденции, распределение, вычисления и компиляция
• Ежемесячно - для следующих категорий отчетов: тенденции, распределение, вычисления и компиляция
• При каждой итерации - для следующих категорий отчетов: тенденции, распределение, вычисления, компиляция, описание версии
• На каждом этапе - для следующих категорий отчетов: тенденции, распределение, вычисление, проверки, компиляция, описание версии
• По завершении проекта - для следующих категорий отчетов - тенденции, распределение, вычисления, проверки, компиляция, описание версии