Чтение онлайн

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

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

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

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

9 Процесс управления конфигурацией ПО

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

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

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

9.1 Цели процесса управления конфигурацией ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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