Квалификационное тестирование системы выполняют для демонстрирования заказчику, что были удовлетворены системные требования. Квалификационное тестирование системы должно покрывать системные требования в Спецификации системы/подсистемы и в соответствующих Спецификациях требований к интерфейсу. Это тестирование противопоставляется внутреннему тестированию системы, выполненному разработчиком, как заключительная стадия интеграции и тестирования ЭКПО/ЭКА.
Если систему разрабатывают для нескольких различных построений, квалификационное тестирование системы в целом не может быть выполнено до завершения последнего построения. Квалификационное тестирование системы для каждого построения следует интерпретировать как планирование и выполнение тестирования для текущего построения системы с целью показать выполнение системных требований, которые должны быть реализованы в данной конфигурации.
Лицом, ответственным за выполнение требований 8.5.4, не должно быть лицо, принимавшее участие в выполнении проектирования или кодировании ПО системы. Это не исключает возможность оказания помощи в проведении квалификационного тестирования со стороны лиц, выполнявших проектирование или кодирование, например путем предоставления тестовых вариантов, основанных на знании внутренней реализации системы.
Квалификационное тестирование системы, выполняемое разработчиком, должно включать в себя тестирование в объектной или альтернативной среде, одобренной заказчиком.
Разработчик должен участвовать в разработке и регистрации процесса подготовки к тестированию, тестовых вариантов и тестовых процедур, которые нужно использовать для квалификационного тестирования системы, и прослеживании соответствия между тестовыми вариантами и требованиями к системе. Для систем ПО все полученные результаты должны быть включены в документ «Описание тестирования ПО». Разработчик должен предварительно уведомить заказчика о времени и месте проведения квалификационного тестирования системы.
Если квалификационное тестирование системы должно быть засвидетельствовано заказчиком, то до его проведения разработчик должен проверить тестовые варианты и тестовые процедуры, чтобы гарантировать, что они полны и точны и что ПО готово для проведения тестирования в присутствии заказчика. Разработчик должен зарегистрировать результаты этой работы в соответствующих файлах разработки ПО и должен модифицировать тестовые варианты и тестовые процедуры соответствующим образом.
Разработчик должен участвовать в квалификационном тестировании системы. Тестирование должно быть выполнено в соответствии с тестовыми вариантами и тестовыми процедурами системного тестирования.
Разработчик должен реализовать все необходимые изменения в ПО и участвовать в проведении повторного тестирования в требуемом объеме, заранее уведомляя заказчика о повторном тестировании. Разработчик обязан вносить необходимые изменения в файлы разработки ПО и другие программные средства в соответствии с результатами квалификационного тестирования системы.
Разработчик должен участвовать в анализе и регистрации результатов квалификационного тестирования системы. Все полученные результаты должны быть включены в соответствующий документ «Отчет о тестировании ПО».
9 Процесс управления конфигурацией ПО
Процесс управления конфигурацией ПО должен быть выполнен так, как определено процессом планирования ПО (раздел 6) и документом «План управления конфигурацией ПО» (12.5). Выходные результаты процесса управления конфигурацией фиксируют в Протоколах управления конфигурацией ПО (12.29) или в других документах жизненного цикла. Таблица А.8 представляет перечень целей и результатов процесса управления конфигурацией.
Разработчик должен осуществлять управление конфигурацией ПО в соответствии с нижеперечисленными требованиями.
Примечание — Если систему или ЭКПО разрабатывают для нескольких построений, то программные средства для каждого из построений могут иметь изменения или дополнения по отношению к программным средствам предыдущих построений. Управление конфигурацией ПО в каждом построении следует понимать как состояние программных средств и контроля в точке начала построения.
9.1 Цели процесса управления конфигурацией ПО
Процесс управления конфигурацией, выполняемый совместно с другими процессами жизненного цикла ПО, направлен на достижение основных целей, а именно на то, чтобы обеспечить:
— определяемую и управляемую конфигурацию ПО на протяжении жизненного цикла;
— целостность при тиражировании исполняемого объектного кода для производства ПО или, в случае необходимости, его повторной генерации для проведения исследований или модификации;
— управление входными и выходными данными процесса в течение жизненного цикла, что гарантирует непротиворечивость и повторяемость работ в процессах;
— контрольную точку для проверки, оценки состояния и контроля изменений посредством управления элементами конфигурации и определения базовой линии;
— контроль над тем, чтобы дефектам и ошибкам было уделено внимание, а изменения были зарегистрированы, утверждены и реализованы;
— оценку соответствия программного средства требованиям;
— надежное физическое архивирование, восстановление и сопровождение элементов конфигурации.
Цели процесса управления конфигурацией не зависят от уровня ПО. Однако выделяют две категории документов жизненного цикла ПО в зависимости от содержания работ управления конфигурацией (9.3).
9.2 Состав работ, выполняемых в процессе управления конфигурацией ПО
Процесс управления конфигурацией включает в себя работы, связанные с идентификацией конфигурации, контролем изменений, определением базовой линии разработки и архивированием программного средства, включая соответствующие документы жизненного цикла, аудитом конфигурации, компоновкой и поставкой программного средства. Процесс управления конфигурацией не прекращается после того, как программное средство принимается заказчиком, а продолжается в течение жизненного цикла системы.
9.2.1 Идентификация конфигурации
Цель работ по идентификации конфигурации заключается в однозначной маркировке каждого элемента конфигурации и последующих версий, чтобы установить базис для управления и ссылок на элементы конфигурации. Должны быть выполнены следующие работы:
— идентификация конфигурации для документов жизненного цикла ПО;
— идентификация конфигурации для каждого элемента конфигурации, для каждого отдельно управляемого компонента элемента конфигурации и для комбинаций элементов конфигурации, которые составляют программное средство;
— идентификация элементов конфигурации до начала реализации контроля изменений и трассируемости документов;
— идентификация элемента конфигурации прежде, чем он будет использован другими процессами жизненного цикла ПО или же будет использован для производства ПО или загрузки ПО;
— если идентификация программного средства не может быть определена физически путем осмотра (например, осмотр номера компонента платы), то исполняемый объектный код должен содержать идентификацию конфигурации, которая должна быть доступна для других компонентов системы. Это также применимо к ПО, загружаемому в полевых условиях (5.3.5).
Разработчик должен участвовать в выборе ЭКПО, выполняемом согласно проекту архитектуры системы, должен идентифицировать объекты, которые будут помещены под управление конфигурацией, и должен назначить уникальный для проекта идентификатор каждому ЭКПО и каждому дополнительному объекту, находящемуся под управлением конфигурацией. Эти объекты включают в себя программные средства, которые должны быть разработаны или использованы согласно контракту, и элементы среды разработки ПО. Схема идентификации должна быть составлена на том уровне, на котором объекты будут фактически контролироваться, например компьютерные файлы, электронные носители данных, документы, модули ПО, элементы конфигурации. Схема идентификации должна включать в себя статус версии/ревизии/выпуска официальной версии для каждого объекта.