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

Спецификация требований к функциональной надежности ПО

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

Входными документами должны быть[20]:

• • спецификация требований к критически важной системе (КВС);
• • спецификация требований к функциональной надежности КВС;
• • описание архитектуры КВС;
• • план обеспечения качества ПО системы,

выходными документами являются:

• • спецификация требований к функциональной надежности ПО КВС;
• • спецификация требований для испытаний надежности ПО КВС.

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

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

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

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

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

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

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

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

Для формирования спецификации архитектуры ПО (единственный выходной документ) должны быть применены следующие входные документы:

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

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

• • являются ли эти компоненты новыми, существующими или принадлежащими конкретной компании или частному лицу;
• • были ли эти компоненты ранее аттестованы, и если да, то каковы были условия аттестации;
• • является ли конкретный компонент связанным с функциональным отказом КВС или нет.

При использовании стандартного ПО в КВС должны быть соблюдены следующие меры предосторожности:

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

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

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

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

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