ГОСТ Р МЭК 61508-3—2007
документирования исходного текста. Документация, относящаяся к исходному тексту, должна содер
жать, по меньшей море, следующую информацию.
a) юридическое лицо (например, компания, авторы и т.п.);
b
) описание;
c) входные и выходные данные;
d) историю изменения конфигурации.
7.4.5 Требования к детальному проектированию и разработке
П р и м е ч а н и я
1 См. также таблицы А.4 (приложение А). В.1. В.7 и В.9 (приложение В).
2 Под детальным проектированием здесь понимается разделение основных компонентов архитектуры на
систему программных модулей, проектирование отдельных программных модулей и их программирование. В
небольших приложениях проектирование программных систем и архитектуры могут быть объединены.
3 Характердетального проектирования и разработки может изменяться в зависимости от характера процес
сов разработки программ и архитектуры программного обеспечения (см. 7.4.3). Когда прикладное программирова
ние выполняет пользователь, использующий языки с ограниченной варьируемостью, например языки
многозвенных логических схем иязыкифункциональных блоков,детальное проектирование может рассматривать
ся скорее как конфигурирование, чем как программирование. Тем не менее, хороший стиль программирования
состоит в структурировании программного обеспечения, включая организацию модульной структуры, которая
выделяет (настолько, насколько это возможно) блоки, связанные с безопасностью, в использовании проверок на
попадание в интервал допустимыхзначений идругих возможностей защиты отошибокпри вводе исходныхданных;
а использовании ранее верифицированных программных модулей; в применении конструкций, которые облегчают
выполнение будущих модификаций программного обеспечения.
7.4.5.1 В зависимости от характера программного обеспечения ответственность за соответствие
7.4.5 может лежатьтолько на поставщике, только на пользователе или на обеих сторонах (см. примеча
ние 3). Разделение ответственности должно быть документировано во время планирования
безопас ности (см. раздел 6).
7.4.5.2 До начала детального проектирования должна быть следующая информация:
- спецификация требований к безопасности программного обеспечения (см. 7.2);
- описание проекта архитектуры (см. 7.4.3);
- план проверки безопасности (см. 7.3).
7.4.5.3 Программное обеспечение следует разрабатывать таким образом, чтобы достигалась
модульность, тестируемость и способность к безопасной модификации.
7.4.5.4 Дальнейшее уточнение проектадля каждого главного комлонента/подсистемы вописании
проекта архитектуры программного обеспечения (см. 7.4.3) должно основываться на разделении на
программные модули (т.е. на спецификации конструкции программной системы). Необходимо опреде
лить конструкцию каждого программного модуля ипроверки, которыедолжны использоваться для этих
модулей.
П р и м е ч а н и е — Для стандартных или ранее разработанных компонентов программных модулей не тре
буется проекта или спецификации тестирования, если может быть показано, что они удовлетворяют требованиям
7.4.2.11.
7.4.5.5 Должны быть определены соответствующие проверки интеграции программных систем,
показывающие, что программные системы удовлетворяют требованиям к безопасности программного
обеспечения для заданного уровня полноты безопасности (см. 7.2).
7.4.6Требования к реализации исходных текстов программ
П р и м е ч а н и е — См. также таблицы А.4 (приложение А). В.1. В.7 и В.9 (приложение В).
7.4.6.1 Исходные тексты программ должны:
a) быть читаемыми, понятными и пригодными к проверке:
b
) удовлетворять специфицированным требованиям к конструкции программного модуля
(см. 7.4.5);
c) удовлетворять специфицированным требованиям к стандартам составления программ
(см. 7.4.4);
d) удовлетворять всем требованиям, определенным при планировании безопасности (см. раз
дел 6).
7.4.6.2 Каждый модуль программного обеспечения должен быть просмотрен.
П р и м е ч а н и е — Просмотр кода относится к процессам верификации (см. 7.9).
19