ГОСТРМЭК 62061—2013
c) включать внутренний проект и архитектуру всех идентифицированных компонентов, которые
не являются «черными ящиками»;
d) определить модули программного обеспечения, входящие в СБЭСУ, но не использующиеся
в каком-либо связанном с безопасностью режиме эксплуатации.
П р и м е ч а н и е — Особенно важно, чтобы документация на архитектуру СБЭСУ была актуальной и полной.
6.11.3.3.3 Чтобы удовлетворить спецификации, должен быть описан и обоснован набор методов
и мер. необходимых для проектирования прикладного программного обеспечения. Эти методы и меры
должны быть направлены на обеспечение предсказуемости поведения СБЭСУ и согласовываться с
лю быми ограничениями, указанными в документации СБЭСУ.
6.11.3.3.4 Должны быть описаны и обоснованы меры, используемые для сохранения полноты
всех данных. Такими данными могут быть данные входные/выходные. коммуникационные, операцион
ные данные интерфейса, технического обслуживания и содержание базы данных.
6.11.3.4 Требования к инструментальным средствам поддержки, руководству пользователя и язы
кам программирования
6.11.3.4.1 Должен быть выбран подходящий набор инструментальных средств, в том числе
по управлению конфигурациями, моделированию и тестированию. Следует учитывать способность ин
струментальных средств (необязательно тех. которые использовались при первоначальной разработке
системы) выполнять необходимые задачи на протяжении всего срока жизни СБЭСУ. Такую способность
необходимо объяснить и документально оформить.
П р и м е ч а н и е — Выбор средства разработки зависит от характера деятельности при разработке про
граммного обеспечения, встроенного программного обеспечения и архитектуры программного обеспечения. Могут
быть необходимы верификация и подтверждение соответствия инструментальных средств, таких как анализаторы
кода, а также средства моделирования.
6.11.3.4.2 В случае необходимости должно быть определено подмножество прикладного языка
программирования.
6.11.3.4.3 Прикладное программное обеспечение должно быть спроектировано с учетом ограни
чений и известных недостатков, включенных в руководство пользователя СБЭСУ и подсистем.
6.11.3.4.4 Выбранный прикладной язык должен либо обладать следующим:
- иметь транслятор/компилятор. который должен быть оценен для установления его пригодности;
- быть полностью и однозначно определенным, либо ограниченным до подмножества однозначно
определяемых элементов;
- соответствовать характеристикам применения:
П р и м е ч а н и е — К характеристикам применения, например, относятся любые ограничения рабочих ха
рактеристик.
- обладать свойствами, облегчающими обнаружение ошибок программирования;
- поддерживать характеристики, соответствующие методу проектирования, либо недостатки языка
должны быть документально оформлены в описании проекта архитектуры программного обеспечения и
должна быть разъяснена пригодность языка для конкретной цели, включая дополнительные меры,
необходимые для устранения выявленных недостатков языка.
6.11.3.4.5 Процедуры использования прикладного языка должны задавать хорошую практику кон
фигурирования. запрещать небезопасные возможности программного обеспечения (например, неопре
деленные особенности языка, неструктурированные конструкции и т. д.), определять проверки, которые
могут быть использованы для обнаружения ошибок в конфигурации и указывать процедуры докумен
тирования прикладных программ. Документация, относящаяся к прикладной программе, должна содер
жать. по меньшей мере, следующую информацию:
a) юридическое лицо (например, компании, автор(ы). и т. д.):
b
) описание;
c) отслеживание функциональных требований применения;
d) отслеживание стандартных функций библиотеки;
e) входные и выходные данные:
f) историю изменения конфигурации.
6.11.3.5 Требования к проектированию прикладного программного обеспечения
6.11.3.5.1До начала детального проектирования прикладного программного обеспечения должна
быть доступна следующая информация:
40