ГОСТ Р МЭК 60880—2010
Приложение А
(обязательное)
Жизненный цикл безопасности программного обеспечения
и детализация требований к программному обеспечению
А.1 Жизненный цикл программного обеспечения
Процесс разработки программного обеспечения представлен на рисунке 3. на котором показаны деятель
ность по жизненному циклу, начиная со спецификации, включая проектирование и реализацию и заканчивая
верификацией и валидацией.
Детализация требований к программному обеспечению описана в разделе А.2.
А.2 Детализация требований к программному обеспечению
А.2.1 Описание взаимных ограничений между техническим и программным обеспечениями
А.2.1.1 Должны быть описаны следующие аспекты:
- общие рабочие характеристики (разрядность, типы обмена, быстродействие и т.п.); во многих случаях
достаточно бывает ссылки на справочники производителя оборудования;
- рабочие характеристики специального оборудования (конкретные драйверы, оборудование для передачи
данных и т.п.);
- числовые ограничения;
- требования к коглплектам стандартных программ;
- требования к саглоконтролю технических средств;
- должна быть дана, по крайней мере, ссылка на докуглент с требованиями к техническим средствагл.
А.2.1.2 Должны быть определены взаиглные требования к техническим и программныгл обеслечениягл с
учетом регистрации отказа и реакции на выявление отказа.
Критерии, установленные в Руководстве МАГАТЭ NS-G-1.3. недопускают никакогодополнительного расши
рения, касающегося технического обеспечения ко»лпьютерных систегл. Однако необходи»ла докуглентация ко всем
трвбованиягл к техническоглу обеспечению, влияющим на програмглное обеспечение, для того чтобы обеспечить
основу интеграции технического и программного обеспечений и валидацию компьютерной систеглы.
А.2.1.3 Должно быть описано взаимодействие между функциями, принадлежащими к разным уровням
безопасности (например, функциями категории А и функциями других категорий), и выполняемым програмглным
обеспечением.
А.2.2 Самоконтроль
А.2.2.1 Рекоглендуется. чтобы при отказах програ»лмного обеспечения автоматически предпринимались
соответствующиедействия с учетом следующих факторов:
- отказы должны быть определены с разуглной степенью детализации;
- должен быть гарантирован максиглально возможный отказоустойчивый выход;
- если такой гарантии нельзя предоставить, то несоответствие выхода системы должно касаться только
менее существенных для безопасности требований:
- последствия отказов должны быть минимизированы;
- должны быть рассмотрены возможности включения корректирующих программ, таких, например, как воз
вращение в предыдущее состояние, восстановление системы;
- обслуживающему персоналу должна быть представлена достаточно подробная информация об отказах.
А.2.2.2 Систегла должна быть спроектирована так. чтобы был возгложен соответствующий самоконтроль.
Принципы проектирования. ислользуе»лые для осуществления этой возможности, включают в себя:
- разбиение на модули;
- проглежуточные проверки достоверности;
- использование резервирования и разнообразия; разнообразив может быть реализовано в качестве фун
кционального разнообразия или разнообразия програ»л»лного обеспечения;
- обеспечение достаточного вре»лени исполнения и обьегла пагляти для целей самопроверки;
- для подтверждения адекватности элементов самоконтроля может быть использовано моделирование
отказов.
А.2.2.3 В любых обстоятельствах самоконтроль не должен препятствовать своевременному реагированию
систеглы.
А.2.3 Представление спецификаций программного обеспечения
А.2.3.1 Спецификации программного обеспечениядолжны быть легко понимаемыми всеми группагли пользо
вателей.
А.2.3.2 Представление должно быть достаточно подробным, свободным от противоречий и. по возможнос
ти. не содержать повторений.
46