ГОСТ Р МЭК 61508-7—2012
- неиспользуемые и ненужные функции элемента не помешают новой системе выполнения своих требова
ний к безопасности:
- все вероятные механизмы отказа элемента в новой системе были выявлены и было выполнено их соот
ветствующее ослабление.
Оценка функциональной безопасности новой системы должна установить, что повторно используемый эле
мент применяется строго в пределах возможностей, которые для этого элемента были ообосноеаны доказатель
ством и предположениями в «Руководстве по безопасности для применяемых изделий».
Литература:
Component-Based Software Development: Case Studies. Kung-Kiu Lau. World Scientific. 2004. ISBN 9812388281.
9789812388285.
Software Reuse and Reverse Engineering in Practice. P.A. V. Hall (ed.). Chapman & Hall. 1992, ISBN 0-412-39980-6.
Software criticality analysis of COTS/SOUP. P. Bishop. T. Clement. S. Guerra. In Reliability Engineering & System
Safety. Volume 81. Issue 3, September 2003. Elsevier Ltd.. 2003.
C.2.11 Прослеживаемость
Цель. Обеспечить согласованность между этапами жизненного цикла.
Описание. Для того, чтобы гарантировать для программного обеспечения, что результаты действий на эта
пах жизненного цикла соответствуют требованиям корректной работы системы, связанной с безопасностью, край
не важно гарантировать обеспечение соответствия между этапами жизненного цикла. Ключевым понятием здесь
является «прослеживаемость» между действиями. В сущности, это выполнение анализа влияния, проверяющего
(1). что решения, принятые на ранней стадии, адекватно реализованы на более поздних стадиях (прямая просле
живаемость). и (2). что решения, принятые на более позднем этапе, действительно необходимы и
санкционирова ны ранее принятыми решеними (обратная прослеживаемость).
Прямая прослеживаемость в основном связана с проверкой адекватности требований на более поздних этапах
жизненного цикла. Прямая прослеживаемость важна в нескольких точках жизненного цикла системы безопасности:
- между требованиями к системе безопасности и требованиями к программному обеспечению системы без
опасности:
- между спецификациями требований к программному обеспечению системы безопасности и к архитектуре
программного обеспечения;
- между спецификациями требований к программному обеспечению системы безопасности и к проекту про
граммного обеспечения;
- между спецификацией проекта программного обеспечения и спецификациями испытаний модуля и инте
грации;
- между требованиями к интеграции аппаратных средств/программного обеспечения проекта системы
и программного обеспечения и спецификациями испытаний интеграции аппаратных средств/программного обе
спечения:
- между спецификацией требований к программному обеспечению системы безопасности и планом под
тверждения соответствия программного обеспечения безопасности системы;
- между спецификацией требований к программному обеспечению системы безопасности и планом модифи
кации программного обеспечения (в том числе повторной проверкой и повторного подтверждения соответствия);
- между спецификацией проекта программного обеспечения и планом верификации программного обеспе
чения (включая верификацию данных);
- между требованиями МЭК 61508-3, раздел 8, и планом оценки функциональной безопасности программ
ного обеспечения.
Обратная прослеживаемость в основном связана с проверкой, насколько корректно любым требованием обо
сновывается каждое реализационное решение (реализация понимается в широком контексте, а не только реализация
кода). Если такое обоснование отсутствует, то реализация будет содержать что-то не столь необходимое, что приведет к
увеличению сложности, но не обязательно удовлетворит любому реальному требованию к системе, связанной с без
опасностью. Обратная прослеживаемость важна в нескольких течках жизненного цикла системы безопасности:
- между требованиями к системе безопасности и предполагаемыми потребностями безопасности:
- между архитектурой программного обеспечения и спецификацией требований к программному обеспече
нию системы безопасности:
- между детальным проектом программного обеспечения и архитектурой программного обеспечения;
- между программным кодом идетальным проектом программного обеспечения;
- между планом подтверждения соответствия программного обеспечения безопасности системы и специфи
кацией требований к программному обеспечению системы безопасности:
- между планом модификации программного обеспечения и спецификацией требований к программному
обеспечению системы безопасности:
- между планом верификации программного обеспечения (включая верификацию данных) и спецификацией
проекта программного обеспечения.
Литература:
Requirements Engineering. Е. Hull. К. Jackson. J. Dick. Springer. 2005. ISBN 1852338792. 9781852338794.
C.2.12 Проектирование программного обеспечения, не сохраняющего состояние (или проектирова
ние ПО, сохраняющего ограниченное описание состояния)
Цель. Ограничить сложность поведения программного обеспечения.
46