4.2.1 Методы разработки ПО
Разработчик должен использовать для всех работ по созданию ПО систематизированные, зарегистрированные методы. План разработки ПО должен содержать описание этих методов или включать в себя ссылки на источники, в которых они описаны.
4.2.2 Стандарты ПО
Разработчик должен разработать и использовать стандарты для представления требований, проекта, кода, тестовых вариантов, тестовых процедур и результатов тестирования. План разработки ПО должен содержать описание этой информации или ссылки на источники, в которых они описаны.
4.2.3 Программные средства многократного использования
Разработчик должен рассмотреть и оценить возможность применения ранее разработанных программных средств многократного использования для выполнения требований контракта. Область исследования и критерии, используемые для оценки, должны быть описаны в Плане разработки ПО. Выбранные для применения программные средства должны отвечать требованиям контракта по правам собственности.
Разработчик должен рассмотреть возможность многократного использования программных средств, разработанных по контракту, оценить и идентифицировать для заказчика выгоды и издержки такого использования в случае его совместимости с задачами проекта.
Примечание — В контракт может быть включено требование на разработку программных средств, пригодных для многократного использования.
4.2.4 Отработка критических требований
Разработчик должен идентифицировать ЭКПО или части их, критические с точки зрения безопасности, сбой в которых может привести к отказной ситуации для системы (см. 5.2).
Разработчик должен идентифицировать ЭКПО или их части, критические с точки зрения защиты, сбой в которых может привести к нарушению защиты системы. Если имеется такое ПО, разработчик должен предусмотреть стратегию обеспечения защиты. Эта стратегия должна гарантировать, что требования, проект, реализация и эксплуатационные процедуры для идентифицированного ПО минимизируют или устраняют потенциальные нарушения защиты системы. Разработчик должен описать стратегию в Плане разработки ПО, реализовать стратегию и провести доказательство как в части требуемых программных средств, так и в части выполнения стратегии обеспечения защиты.
Разработчик должен идентифицировать ЭКПО или части их, критические с точки зрения секретности, сбой в которых может привести к нарушению секретности системы. Если имеется такое ПО, то разработчик должен представить стратегию обеспечения секретности. Стратегия должна гарантировать, что требования, проект, реализация и эксплуатационные процедуры для идентифицированного ПО минимизируют или устраняют потенциальные нарушения секретности системы. Разработчик должен описать стратегию в Плане разработки ПО, реализовать стратегию и провести доказательство как в части требуемых программных средств, так и в части выполнения стратегии обеспечения секретности.
В случаях, когда система возлагает на ПО реализацию каких-либо требований, которые в соответствии с контрактом или спецификациями системы считаются критическими, разработчик должен идентифицировать те ЭКПО или их части, сбой в которых может привести к нарушению этих критических требований; разработать стратегию для гарантирования того, что требования, проект, реализация и эксплуатационные процедуры для идентифицированного ПО минимизируют или устраняют потенциал для таких нарушений; описать стратегию в Плане разработки ПО; выполнить стратегию и провести доказательство как в части требуемых программных средств, так и в части выполнения стратегии.
4.2.5 Использование ресурсов аппаратных средств компьютера
Разработчик должен проанализировать требования контракта, относящиеся к использованию ресурсов аппаратных средств компьютера (например, максимально возможная производительность процессора, объем памяти, пропускная способность устройств ввода/вывода). Разработчик должен распределить аппаратные ресурсы компьютера между ЭКПО, контролировать использование этих ресурсов при выполнении контракта и перераспределить их или идентифицировать потребность в дополнительных ресурсах по мере необходимости, чтобы удовлетворить требования контракта.
4.2.6 Доступ для проверки заказчиком
Разработчик должен обеспечить заказчику или его полномочному представителю доступ к средствам разработчика и субподрядчика, включая среды разработки и верификации ПО, для проверки программных средств и работ, требуемых в соответствии с контрактом.
5 Системные аспекты, связанные с разработкой ПО
Процесс обеспечения безопасности определяет информационный поток между процессами жизненного цикла системы управления и процессами жизненного цикла ПО. Вследствие взаимозависимости процесса обеспечения безопасности системы и процесса проектирования системы поток информации, описанный в следующих подразделах, является итерационным.
5.1 Поток информации между процессами жизненного цикла системы и ПО
5.1.1 Информационный поток от системных процессов к процессам ПО
В процессе оценки безопасности системы должны быть определены возможные отказные ситуации для системы и установлены их категории, определены требования, связанные с безопасностью, которые специфицируют желаемую отказоустойчивость и реакцию системы на отказные ситуации.
Требования, связанные с безопасностью, — это часть системных требований, которые являются входной информацией для процессов жизненного цикла ПО. Для гарантии правильной реализации требований, связанных с безопасностью, системные требования должны содержать (или ссылаются на):
— описание системы и определение аппаратуры;
— системные требования, относящиеся непосредственно к ПО, включая функциональные требования, требования по эффективности и требования, связанные с безопасностью;
— уровень(ни) ПО и информацию, подтверждающую их определение, отказные ситуации, их категории и функции, выполняемые ПО;
— стратегии обеспечения безопасности и ограничения проекта, включая методы проектирования, такие как использование разбиения, многоверсионного неидентичного ПО, избыточности или мониторинга безопасности.
Процессы жизненного цикла системы могут также определять требования к процессам жизненного цикла ПО, которые необходимы для поддержки верификации системы.
5.1.2 Информационный поток от процессов ПО к системным процессам
Процесс оценки безопасности системы должен определить влияние проектирования и реализации ПО на безопасность системы в целом, используя информацию, создаваемую процессами жизненного цикла ПО. Эта информация включает в себя идентификацию областей распространения отказов, требования к ПО, архитектуру ПО и источники ошибок, которые могут быть обнаружены или исключены посредством специальной организации архитектуры ПО или путем использования инструментальных средств, или другими методами, используемыми в процессе проектирования ПО. Для процесса оценки безопасности системы должна быть обеспечена трассируемость между системными требованиями и результатами проектирования ПО.
Изменения, внесенные при модификации ПО, могут воздействовать на безопасность системы и, следовательно, также должны быть идентифицированы для оценки безопасности системы.
5.2 Отказные ситуации и уровни ПО
Категорию отказной ситуации системы устанавливают, определяя серьезность проявления отказной ситуации на объекте управления. Ошибка в ПО может вызвать сбой, который приведет к отказной ситуации. Следовательно, необходимый для безопасного функционирования уровень ПО определяют исходя из отказных ситуаций системы.
5.2.1 Классификация отказных ситуаций
Категория А — катастрофическая: отказная ситуация, которая препятствует безопасному функционированию объекта управления.
Категория В — опасная/критическая: отказная ситуация, которая приводит к уменьшению возможностей объекта управления или способности персонала справиться с неблагоприятными эксплуатационными режимами, при которых возникают:
— большое снижение гарантийных резервов или функциональных возможностей;
— крайне тяжелое положение или перегрузки, которые могут вызвать неточное или неполное выполнение задачи;
— неблагоприятные или потенциально фатальные воздействия для окружающей среды.
Категория С — существенная: отказная ситуация, которая приводит к снижению возможностей объекта управления или способности персонала справиться с неблагоприятными эксплуатационными режимами, при продолжении которых могут возникать, например, большое снижение гарантийных резервов или функциональных возможностей, перегрузки или условия, вызывающие ухудшение работоспособности персонала.
Категория D — несущественная: отказная ситуация, незначительно уменьшающая безопасность объекта и требующая действий персонала, которые осуществимы в пределах их возможностей. Несущественная отказная ситуация может включать в себя, например, незначительное уменьшение гарантийных резервов или функциональных возможностей, незначительное увеличение рабочей нагрузки персонала или некоторое неудобство для персонала.
Категория Е — невлияющая: отказная ситуация, которая не воздействует на эксплуатационные возможности объекта управления или не увеличивает рабочую нагрузку персонала.
5.2.2 Определения уровня ПО
Уровень ПО определяется возможностью возникновения потенциальных отказных ситуаций, выявленных процессом оценки безопасности системы, в результате сбоев в ПО. Уровень ПО означает, что трудозатраты, необходимые для доказательства согласованности с требованиями сертификации, меняются в зависимости от категории отказной ситуации.
Уровень А: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, приводящее к катастрофической отказной ситуации для объекта управления.
Уровень В: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, приводящее к опасной/критической отказной ситуации для объекта управления.
Уровень С: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, приводящее к существенной отказной ситуации для объекта управления.
Уровень D: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, приводящее к несущественной отказной ситуации для объекта управления.
Уровень Е: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы, вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, не влияющее на эксплуатационные возможности объекта и работоспособность персонала. Если для ПО был установлен сертифицирующей организацией уровень Е, то в дальнейшем для сертификации такого ПО никакие требования данного документа не являются обязательными.
5.2.3 Назначение уровня ПО
Первоначально процесс оценки безопасности системы присваивает уровень(ни) ПО, соответствующий(ие) компонентам ПО конкретной системы. При проведении данного назначения учитывают воздействие отказов как потери функции или неправильного функционирования.
Примечание — Если систему или ЭКПО разрабатывают для нескольких построений, то компоненту ПО данного построения может быть назначен более высокий уровень, чем требуется процессом оценки безопасности системы, если использование этого компонента в других построениях требует такого уровня.
Если аномальное поведение компонента ПО вызвано более чем одной отказной ситуацией, уровень ПО для данного компонента ПО определяет наиболее серьезная категория отказной ситуации. Существуют архитектурные стратегии (см. 5.5), использование которых в процессе проектирования системы может привести к изменению назначенного уровня ПО.
Системная функция может быть реализована одним или несколькими компонентами ПО. Параллельная реализация — это такая реализация, когда функция системы реализуется несколькими компонентами ПО. Тогда для возникновения отказной ситуации требуется аномальное поведение более чем одного компонента. При параллельной реализации по крайней мере один компонент ПО будет иметь уровень ПО, связанный с наиболее серьезной категорией отказной ситуации этой функции системы. Уровень ПО для других компонентов определяют, используя категорию отказной ситуации, связанную с потерей этой функции. Примеры таких реализаций описаны в 5.5.2 и 5.5.3.
Последовательная реализация — это такая реализация, когда несколько компонентов ПО используются для реализации функции системы так, что аномальное поведение любого из компонентов может привести к отказной ситуации. При такой реализации все компоненты ПО будут иметь уровень ПО, связанный с наиболее серьезной категорией отказной ситуации этой функции системы.
Разработка ПО с заданным уровнем не подразумевает оценку интенсивности отказов для этого ПО. Таким образом, уровни ПО или оценки надежности ПО, основанные на уровнях ПО, не могут использоваться процессом оценки безопасности системы в отличие от использования интенсивности отказов аппаратуры.