ГОСТ РМЭК 62061—2013
связанного с безопасностью. Следует оценить ограничения, связанные с окружением программного обе
спечения (например, зависимость от операционной системы и компилятора).
6.11.3.1.9Любые модификации или изменения прикладного программного обеспечения подлежат
анализу, который должен выявить все затронутые изменениями программные модули и определить не
обходимые действия для повторной верификации, чтобы подтвердить, что программное обеспечение
по-прежнему удовлетворяет спецификации требований к безопасности.
6.11.3.2 Управление конфигурацией программного обеспечения
6.11.3.2.1 План функциональной безопасности должен определять стратегию разработки, инте
грации. верификации и подтверждения соответствия программного обеспечения.
6.11.3.2.2 Управление конфигурацией программного обеспечения должно:
- обеспечить выполнение всех необходимых операций и продемонстрировать, что требуемая
полнота безопасности программного обеспечения была достигнута;
- поддерживать аккуратно и с уникальной идентификацией все документы, относящиеся к объ
ектам конфигурации, необходимым для поддержания полноты СБЭСУ. Объекты конфигурации должны
включать, по крайней мере, следующее:
- анализ безопасности и требований к ней;
- спецификацию программного обеспечения и проектную документацию;
- модули программного обеспечения в исходных кодах;
- планы и результаты тестирования;
- уже существующие программные модули и пакеты, которые должны быть включены в СБЭСУ;
- все инструментальные средства и среды разработки, которые используются для создания, те
стирования или выполнения любых действий по применению программного обеспечения;
- применять процедуры контроля изменений для:
- предотвращения несанкционированных изменений;
- запросов на изменение документов;
- анализа влияния предлагаемых изменений, а также для того, чтобы принять или отклонить
запрос(ы);
- подготовки документа, подробно описывающего и разрешающего все принятые изменения;
- документирования конфигурации программного обеспечения в соответствующих точках при раз
работке программного обеспечения;
- документально оформить следующую информацию, чтобы позволить последующий аудит: ста
тус релиза, обоснование и согласование всех модификаций, а также подробную информацию о моди
фикации;
- официально зарегистрировать выпуск прикладного программного обеспечения. Мастер-копии
программного обеспечения и вся связанная с ним документация должны храниться, чтобы обеспечить
обслуживание и модификацию в течение всего срока эксплуатации выпущенного программного обе
спечения.
6.11.3.3 Требования к архитектуре программного обеспечения
П р и м е ч а н и я
1 Архитектура программного обеспечения определяет основные элементы и подсистемы системы и при
кладного программного обеспечения, их взаимосвязь, и как достигаются требуемые характеристики. Примерами
модулей прикладного программного обеспечения являются прикладные функции, которые реплицируются по всей
машине, ввод/вывод машины, переопределение и запрет выполнения компонентов, проверка достоверности дан
ных и диапазонов их значений и т.д.
2 Архитектура программного обеспечения также зависит от базовой архитектуры подсистемы, предоставля
емой поставщиком.
6.11.3.3.1 Проект архитектуры программного обеспечения должен быть основан на заданной
спецификации обеспечения безопасности СБЭСУ в рамках ограничений системной архитектуры про
екта СБЭСУ и подсистемы.
6.11.3.3.2 Проект архитектуры программного обеспечения должен:
a) обеспечить полное описание внутренней структуры и функционирования СБЭСУ и его компо
нентов (см. примечание);
b
) включать спецификации всех идентифицируемых компонентов программного обеспечения,
а также описание связей и взаимодействия между этими компонентами (программного обеспечения
и аппаратных средств);
39