ГОСТ Р МЭК 61513—2011
f)Документы, подлежащие пересмотру, должны определяться в плане обеспечения качества
системы.
д)Документы, относящиеся к деятельности по верификации, например, исходные требования и ре
зультаты деятельности. верификационные отчеты и. возможно, средства, использованные для достиже
ния результата, должны быть учтены в планах управления конфигурацией.
h) Для систем класса 1 верификация должна проводиться лицом, независимым от разработчиков
системы (в соответствии с 6.2.1 МЭК 60880).
6.2.1.2 План управления конфигурацией системы
Пр и м е ч а н и е — Часть требований к плану управления конфигурацией системы (см. ниже) заимствована
из IEEE 828 [3].
a) Идентификация конфигурации:
- должны быть определены основное направление (критический путь) с контрольными точками в
пределах жизненного цикла системы, а также объекты, подлежащие контролю. Контролируемые объекты
могут быть промежуточными или окончательными (например, оборудование, программное обеспечение,
документация по верификации, инструкции пользователя), а также элементами инструментальной среды
(например, компиляторы, инструментальные средства, испытательные стенды):
- все объекты, подлежащие контролю, должны быть идентифицированы; каждый отдельный объект
должен иметь собственный адрес, а также должны быть однозначно определены различные варианты
конфигурации;
- связи между устройствами, находящимися на критическом пути, и устройствами, из которых они
были собраны, должны быть установлены и зарегистрированы;
- управление конфигурацией системыдолжно обеспечивать изменение конфигурации всех критичес
ких путей системы:
- должны быть предусмотрены поисковые средства, с помощью которых можно легко определить
связи и многократное применение объектов.
b
) Контроль конфигурации:
- для контроля конфигурации должны быть предусмотрены средства приостановки проекта, необхо
димо определить процедуры и обоснование для любой корректировки проекта после его приостановки:
- необходимо отслеживать статус каждого контролируемого объекта, что подразумевает получение
сведений о первоначальной согласованной версии, статусе предлагаемых изменений, а также внедрении
согласованных изменений.
c) План управления конфигурацией должен разрабатываться в начале проектирования и поддержи
ваться в течение всего жизненного цикла системы.
6.2.2 План защищенности системы
План защищенности системы разрабатывается в соответствии с общим планом защищенности
(см. 5.4.2):
a) В процессе разработки спецификации на систему и при проектировании требований к техническим
контрмерам, определенным для системы в общем плане защищенности (см. 5.4.2). должны трансформи
роваться втребования технического проекта и бытьдокументально оформлены.
b
)Для проверки правильного применения контрмер, определенных при проведении анализа защиты
системы, должна быть проведена оценка проектнойдокументации.
c) При верификации и валидации системы путем испытаний в ее окончательной конфигурации долж
на быть продемонстрирована эффективностьфункций защищенности.
6.2.3 План интеграции системы
План интеграции системы определяет технические и организационные меры по объединению подси
стем в систему и интеграции оборудования и программного обеспечения. План охватывает следующие
действия, описанные в 7.4 МЭК 60880.
a) в плане интеграции системы должны быть описаны типы необходимых испытаний, проверка воз
действий окружающей среды и критерии приемки:
b
) испытания интеграции должны проводиться в соответствии с концепцией поэтапной интеграции;
c) необходимо различать испытания, связанные с самой системой (функции аппаратного и программ
ного обеспечения системы), и испытания, относящиеся кфункционированию АС (прикладные функции).
П р и м е ч а н и е — Для того, чтобы избежать проведения идентичных испытаний или необязательных
проверок, могут быть использованы результаты испытаний модулей (оборудование, программное обеспечение,
комбинированные модули), проведенных в процессе типовых испытаний или предыдущих проектов.
43