Идентификация элементов, требующих контроля (Identifying Items to Be Controlled)

Идентификация программных конфигураций (Software Configuration Identification)

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

Первый шаг в организации контроля изменений состоит в идентификации программных элементов, которые необходимо контролировать в рамках SCM-процесса. Это предполагает понимание программной конфигурации в контексте системной конфигурации, выбор элементов программной конфигурации, разработку стратегии отметки (labeling) программных элементов и описание связи между ними, а также идентификацию базовых линий (baselines, это понятие будет обсуждаться позднее в этой теме) вместе с процедурами включения элементов в базовую линию.

2.1.1 Программная конфигурация (Software configuration)

Программная конфигурация – набор функциональных и физических характеристик программного обеспечения, сформулированная в документации или воплощенная в продукте (см. IEEE 610.12-90, Standard Glossary for Software Engineering Terminology). Программная конфигурация может рассматриваться как составная часть общей системной конфигурации.

2.1.2 Элемент конфигурации (Software configuration item)

Элемент программной конфигурации (software configuration item, SCI) – фрагмент программного обеспечения, вовлеченный в процесс конфигурационного управления (и, возможно, помещенный под управление SCM-системы) и рассматриваемый как одна (атомарная) сущность в рамках SCM-процесса (см. IEEE 610.12-90). SCM контролирует множество различных элементов, включая не только программный код. Программные элементы, потенциально полезные в качестве элементов программной конфигурации (SCI), включают планы, спецификации и документы (например, полученные в результате моделирования и проектирования), программные инструменты, исходный и исполнимый код, библиотеки кода, данные и словари данных, а также документацию по установке, сопровождению, эксплуатации и использованию программного обеспечения.

Выбор SCI является важным процессом, в рамках которого необходимо достигать баланса между обеспечением адекватного уровня прозрачности представления (дословно – “видимости”, visibility) в контексте контроля проекта. Правильный выбор элементов конфигурации важен для обеспечения управляемого набора контролируемых элементов. SWEBOK дает ссылку на источник, описывающий список критериев по выбору элементов конфигураций.

2.1.3 Связи между элементами конфигурации (Software configuration item relationships)

Структурные связи между выбранными элементами конфигурации (и их составляющими) влияют на другие SCM работы и задачи, например, сборку программного обеспечения или анализ влияний (impact analysis) предлагаемых изменений. Надлежащее отслеживание этих связей является важным для поддержания актуальной трассировки (traceability) между активами проекта. Разработка схемы идентификации элементов конфигураций (SCI) должна учитывать отображение между идентифицируемыми элементами и структурой программного обеспечения, а также потребность в поддержке эволюционирования программных элементов и их связей по мере развития системы.

2.1.4 Версия программного обеспечения (Software version)

Программные элементы развиваются по мере выполнения проекта. Версия (version) программного элемента – конкретно идентифицированный и специфицированный элемент. Версия элемента может также рассматриваться в качестве определенного состояния (state) эволюционирующего элемента. Обновление (revision) – новая версия элемента, предназначенная для замены его старой версии. Вариант (variant) – новая версия элемента, добавляемая в конфигурацию без замены старой версии (то есть сосуществующая с другой версией того же элемента).

2.1.5 Базовая линия, срез (Baseline)

Базовая линия или <фиксированный> срез (baseline) программного обеспечения –набор элементов программной конфигурации, формально определенный и зафиксированный по времени в процессе жизненного цикла программного обеспечения. Этот термин также иногда используется для указания конкретной версии элемента конфигурации, если это согласовано заранее. В определенных случаях, базовая линия может изменяться только через формальную процедуру контроля изменений. Фиксированный срез в сочетании со всеми утвержденными изменениями в отношении его представляет собой текущую утвержденную конфигурацию.

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

В общем случае, используются следующие типы базовых линий – функциональные, утвержденные, эволюционные или промежуточные, а также, базовые линии продукта. Функциональный срез соответствует принятым программным требованиям. Утвержденный срез соответствует принятым программным требованиям и требованиям в отношении интерфейсов. Базовая линия продукта представляет собой срез активов, относящихся к продукту, на заданный момент времени (при этом, базовая линия продукта не всегда является его версией, готовой к выпуску, т.е. к передаче в эксплуатацию). Полномочия по изменению заданной базовой линии обычно находятся в ведении организационной структуры, отвечающей за разработку программного обеспечения, но могут также разделяться и с другими организационными структурами (например, отвечающей за конфигурационное управление или тестирование). Базовая линия продукта соответствует завершенному программному продукту, готовому для проведения работ по интеграции в рамках целевой системы (system integration). Базовые линии, используемые для данного проекта, вместе с ассоциированным уровнем полномочий, необходимым для утверждения изменений, обычно идентифицируется в конфигурационном плане – SCMP.

Здесь уместно провести параллель между вехами (milestone) проекта и базовыми линиями. Выглядит вполне обоснованным отображение вех проекта на базовые линии, как “выходы” (результаты) выполнения процессов проекта к моменту достижения соответствующей проектной вехи.

2.1.6 Включение элементов в программную конфигурацию (Acquiring software configuration items)

Различные элементы программной конфигурации передаются под управление SCM-процесса в различные моменты времени и включаются в базовые линии в определенных точках жизненного цикла. Инициирующим событием является завершение определенных форм формального утверждения задач, таких как формальная оценка (review). Рисунок 4 характеризует развитие базовой линии в процессе жизненного цикла. Этот рисунок базируется на каскадной (waterfall) модели только в целях иллюстрации; нижние индексы используются для обозначения версий эволюционирующих элементов. Запросы на изменения (software change requests, SCR), присутствующие на рисунке, описываются в теме 3.1 “Requesting, Evaluating, and Approving Software Changes”.

Рисунок 4. Включение элементов в конфигурацию. [SWEBOK, 2004, с.7-7, рис. 4]

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