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

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

7.4.3 Дополнительные задачи интеграции

Далее рассмотрены задачи, связанные с отключенным кодом и заплатами в ПО. Управляющая система или оборудование могут быть предназначены для включения нескольких вариантов конфигураций, не все из которых предназначены для использования в каждом приложении. Это может привести к появлению отключенного кода, который может быть не выполнен, или данных, которые могут быть не использованы. Такой код отличается от мертвого кода, который определен в разделе 3 и объяснен в 8.4.4. Требования для отключенного кода и заплат следующие:

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

— должны быть использованы методы работы с отключенным кодом в соответствии с планами ПО;

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

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

7.5 Трассируемость

Требования трассируем ости включают в себя обеспечение соответствия:

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

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

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

8 Процесс верификации ПО

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

Таблицы А.З — А.7 содержат резюме целей и результатов верификации в зависимости от уровня ПО.

Примечание — Чем ниже уровень ПО, тем меньше внимания уделяют:

— верификации требований нижнего уровня;

— верификации архитектуры ПО;

— полноте покрытия тестами;

— контролю процедур верификации;

— независимости работ процесса верификации ПО;

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

— тестированию отказоустойчивости;

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

8.1 Цели верификации ПО

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

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

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

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

— исполняемый объектный код удовлетворяет требованиям к ПО;

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

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

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

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

Выходные результаты верификации ПО должны быть включены в документы «Процедуры верификации ПО» (12.21), «Результаты верификации ПО» (12.23), «Описание квалификационного тестирования ПО» (12.22), «Отчет о квалификационном тестировании ПО» (12.24).

8.3 Просмотры и анализы ПО

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

8.3.1 Просмотры и анализы требований верхнего уровня

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

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