Состав работ, выполняемых в процессе управления конфигурацией ПО

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

9.2.1 Идентификация конфигурации

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

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

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

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

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

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

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

9.2.2 Контроль конфигурации

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

9.2.3 Базовые линии и трассируемость

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

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

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

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

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

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

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

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

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

9.2.4 Отчетность о дефектах, трассируемость и корректирующие действия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.2.5 Контроль изменений и трассируемость

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

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

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

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

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

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

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

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

9.2.6 Просмотр изменений

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

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

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

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

9.2.7 Отчет о состоянии конфигурации

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

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

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

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

9.2.8 Архивирование и получение документов. Выпуск версии

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

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

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

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

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

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

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

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

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

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

9.2.9 Контроль загрузки ПО

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

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

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

9.2.10 Контроль среды жизненного цикла ПО

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

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

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

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

⇐ Предыдущая3456789101112Следующая ⇒

Поделиться: