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

8.1.4 План конфигурационного управления (SCM Plan)

Результаты SCM-планирования для заданного проекта определяются в плане конфигурационного управления (Software Configuration Management Plan, SCMP), который является документом, используемом в качестве описание SCM-процесса. Он всегда поддерживается в актуальном состоянии (обновляясь и утверждаясь по мере внесения в него необходимых изменений) на протяжении всего жизненного цикла. При описании SCM-плана обычно необходимо разработать ряд детальных процедур, определяющих как конкретные требования будут выполняться в повседневной деятельности.

Создание и сопровождение плана конфигурационного управления основывается на информации, получаемой в процессе работ по планированию. Рекомендации по созданию и сопровождению SCMP можно найти, например, в одном из ключевых SCM-стандартов IEEE Std. 828-2012, «Standard for Configuration Management in Systems and Software Engineering». Этот стандарт описывает требования к информации, содержащейся в плане конфигурационного управления, а также определяет шесть категорий SCM-информации, содержащейся в плане (обычно, представленных в виде соответствующих разделов, прим. автора):

· Введение (Introduction) – описывает цели, содержание и используемые термины.

· Управление (SCM Management) – описывает структуру, обязанности, полномочия, политики, директивы (указания, обязательные для исполнения) и процедуры.

· Работы (SCM Activities) – определяет идентификацию конфигураций, их контроль и т.п.

· Расписание (SCM Schedule) – определяет связь работ по конфигурационному управлению с другими аспектами и процессами проектной деятельности.

· Ресурсы (SCM Resources) – описывает инструменты, физические ресурсы, персонал и т.п.

· Сопровождение плана (SCMP Maintenance) – определяет правила, по которым в план вносятся изменения и описывает как эти изменения внедряются в повседневный SCM-процесс.

8.1.5 Контроль выполнения SCM-процесса
(Surveillance of Software Configuration Management)

После того, как внедрен процесс конфигурационного управления, может быть необходимо контролировать (проводить надзор) над SCM-процессом для обеспечения того, что SCM-план исполняется надлежащим образом. В ряде случаев определяются конкретные требования по обеспечению качества (SQA), контролирующие исполнение процессов и процедур конфигурационного управления. Для этого может быть необходимо введение соответствующих полномочий и назначение обязанностей по контролю выполнения задач SCM. Аналогичные полномочия и обязанности по надзору над SCM-процессом могут существовать в контексте SQA-деятельности (Software Quality Assurance – обеспечение качества ПО).

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

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

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

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

8.2.1 Программная конфигурация и элементы конфигурации

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

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

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

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

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

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

Рисунок 8.2 – Возможные связи между элементами конфигурации (Карл Вигерс, 2014)

8.2.3 Версия ПО (Software Version)

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

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

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

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

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

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

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

8.3 Контроль программных конфигураций
(Software Configuration Control)

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

8.3.1 Предложение, оценка и утверждение изменений
(Requesting, Evaluating, and Approving Software Changes)

Первый шаг по управлению изменениями контролируемых элементов состоит в определении того, какие именно изменения надо производить. Процесс обработки запросов на изменения (software change request process), представленный на рисунке 8.3, включает формальные процедуры по предложению (submitting) и записи (recording) запросов на изменения, оценки потенциальной стоимости и влияния предлагаемых изменений, а также принятию, модификации или отказу от внесенных предложений по изменениям. Запросы на изменения элементов программных конфигураций могут вноситься любым лицом в любой точке жизненного цикла и может включать предлагаемые решения и соответствующий уровень приоритетности. Один из источников запросов на изменения состоит в инициировании корректирующих действий в ответ на сообщения о проблемах (problem reports). Вне зависимости от источника запроса, в самом запросе на изменение (software change request, SCR) обычно записывается информация о его типе (например, “дефект” или “заявка на расширение функциональных возможностей”/”пожелание” – enchancement/suggestion).

Рисунок 8.3 – Поток процесса контроля изменений

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