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