Процесс управления конфигурацией ПО должен быть выполнен так, как определено процессом планирования ПО (раздел 6) и документом «План управления конфигурацией ПО» (12.5). Выходные результаты процесса управления конфигурацией фиксируют в Протоколах управления конфигурацией ПО (12.29) или в других документах жизненного цикла. Таблица А.8 представляет перечень целей и результатов процесса управления конфигурацией.

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

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

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

— определяемую и управляемую конфигурацию ПО на протяжении жизненного цикла;

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

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

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

— контроль над тем, чтобы дефектам и ошибкам было уделено внимание, а изменения были зарегистрированы, утверждены и реализованы;

— оценку соответствия программного средства требованиям;

— надежное физическое архивирование, восстановление и сопровождение элементов конфигурации.

Цели процесса управления конфигурацией не зависят от уровня ПО. Однако выделяют две категории документов жизненного цикла ПО в зависимости от содержания работ управления конфигурацией (9.3).

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

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

— идентификация конфигурации для документов жизненного цикла ПО;

— идентификация конфигурации для каждого элемента конфигурации, для каждого отдельно управляемого компонента элемента конфигурации и для комбинаций элементов конфигурации, которые составляют программное средство;

— идентификация элементов конфигурации до начала реализации контроля изменений и трассируемости документов;

— идентификация элемента конфигурации прежде, чем он будет использован другими процессами жизненного цикла ПО или же будет использован для производства ПО или загрузки ПО;

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

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

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

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

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

б) установить базовую линию для программного средства и определить ее в Указателе конфигурации ПО (12.26).

Примечание — Модифицируемое пользователем ПО не входит в базовую линию программного средства, за исключением связанных с ним компонентов защиты и граничных компонентов. Следовательно, в модифицируемое пользователем программное средство могут быть внесены изменения, которые не будут влиять на идентификацию конфигурации базового программного средства;

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

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

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

е) когда правомерно сертификационное доверие к работам или документам процессов жизненного цикла ПО, связанным с разработкой предшествующей версии элемента конфигурации, каждый элемент конфигурации должен быть трассируем к тому элементу конфигурации, производным от которого он является;

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

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

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

Требования к выполнению данных работ:

— должно быть подготовлено сообщение о дефекте, которое описывает несоответствие процесса планам, отсутствие выходных данных или аномальное поведение ПО, а также о предпринятых корректирующих действиях (как это установлено в 12.28);

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

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

Примечание — Отчетность о дефектах и работы по контролю изменений являются взаимосвязанными.

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

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

— входная информация системы должна состоять из сообщений о дефектах/изменениях;

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

— каждый дефект должен быть классифицирован по категориям и приоритетам;

— должен быть выполнен анализ для выявления возможных тенденций в зарегистрированных дефектах;

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

Цель контроля изменений — обеспечить регистрацию, оценку, рассмотрение и утверждение изменений на протяжении жизненного цикла ПО. Требования к выполнению работ по контролю изменений:

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

б) контроль изменений должен гарантировать, что каждое изменение элемента конфигурации учтено в изменении идентификации конфигурации;

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

Примечание — Общепризнанно, что ранняя реализация контроля изменений помогает управлению и организации работ в процессах жизненного цикла ПО;

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

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

Работы по контролю изменений следует сопровождать работами по просмотру изменений.

Цель работ по просмотру изменений — обеспечить оценку дефектов и изменений, их утверждение или неутверждение, реализацию утвержденных изменений и обратную связь с процессами, на которые изменения воздействуют, путем выполнения отчетности о дефектах и использования методов контроля изменений. Методы контроля определяют в процессе планирования ПО. Работы по просмотру изменений:

— подтверждение того, что затронутые изменениями элементы конфигурации идентифицированы;

— оценка воздействия изменений на требования безопасности и обеспечение обратной связи с процессом оценки безопасности системы;

— анализ дефектов или изменений и решений о действиях, которые следует предпринять для их коррекции;

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

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

— регистрация идентификации элементов конфигурации, идентификации базовых линий, состояния сообщений о дефектах, хронологии изменений и состояния выпускаемой линии;

— определение информации, подлежащей сопровождению, и способов регистрации и ведения отчетности о состоянии конфигурации этой информации.

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

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

а) документы жизненного цикла ПО, связанные с программным средством, должны быть получены из утвержденного источника (например, от организации-разработчика);

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

 1) гарантировать, что никакое несанкционированное изменение не может быть выполнено;

 2) выбирать носители данных, которые минимизируют ошибки регенерации и износа;

 3) проверять и/или обновлять архивные данные с частотой, соответствующей сроку службы носителя;

 4) хранить копии в физически отдаленных архивах, что минимизирует риск потери данных в катастрофической ситуации;

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

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

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

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

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

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

Цель контроля среды жизненного цикла ПО — гарантировать, что инструментальные средства, используемые для создания ПО, идентифицируются, контролируются и могут быть получены из соответствующих источников. Инструментальные средства среды жизненного цикла ПО определяются в процессе планирования ПО и идентифицируются в документе «Указатель конфигурации среды жизненного цикла ПО» (12.25). Требования к выполнению работ данного вида:

— установка идентификации конфигурации для исполняемого объектного кода (или его эквивалента), используемого для разработки, управления, компоновки, верификации и загрузки ПО;

— контроль соответствия процесса управления конфигурацией для управления аттестованными инструментальными средствами целям, относящимся к категории 1 или 2 контроля документов (9.3), как определено в 13.2.3, перечисление б);

— если требования 9.2.9 неприменимы, то процесс управления конфигурацией для управления исполняемым объектным кодом (или его эквивалентом) для инструментальных средств, используемых для компоновки и загрузки ПО (например, компиляторов, ассемблеров, редакторов связей), должен соответствовать целям, относящимся, как минимум, к категории 2 контроля документов.

Документы жизненного цикла ПО могут быть отнесены к одной из двух категорий: категории контроля 1 (КК1) и категории контроля 2 (КК2). Эти категории касаются функций управления конфигурацией в части документов. Таблица 1 определяет перечень целей процесса управления конфигурацией, связанных с каждой категорией контроля. В таблице 1 указано, какие функции управления конфигурацией должны быть выполнены для документов жизненного цикла ПО, относящихся к данной категории. Таблицы приложения А определяют категорию контроля каждого документа жизненного цикла ПО для уровней ПО. Для категорий контроля документов требуется:

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

— целевые функции процесса управления конфигурацией для документов жизненного цикла ПО, отнесенных к категории КК2, применять согласно таблице 1, как минимум.

Таблица 1 — Целевые функции процесса управления конфигурацией, связанные с документами категорий КК1 и КК2

Обозначения:

* — цель должна быть удовлетворена для документов данной категории;

пробел — удовлетворение цели на усмотрение разработчика.

Разработчик должен поддерживать проводимый заказчиком аудит конфигурации, как определено в контракте.

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