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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— сообщения о дефектах, для которых требуются корректирующие действия в отношении