ГОСТ Р МЭК 60880—2010
Эта стратегия должна также обеспечивать обоснованность перехода к новой версии инструментальной
программы, а также соответствующую аттестацию, т.е. оценку в соответствии с требованиями настоящего
стандарта.
14.3.1.5Для инструментальных программ, используемых для обеспечения разнообразия, т.е. для
компиляторов, применяемыхдля разработки многоверсионных разнородных систем программного обеспе чения.
следует подтвердить их разнородность. Этого можно достичь путем подтверждения того, что:
1) все инструментальные программы были получены от различных поставщиков (например, одна
программа может быть разработана, а другая— приобретена в готовом виде) или
2) инструментальные программы имеют различные языки на входе и/или на выходе или
3) инструментальные программы имеют различные требования и процессы проектирования.
14.3.2 Аттестация инструментальных программ
14.3.2.1 Должна быть составлена стратегия аттестации инструментальных программ, и аттестация
этих программ должна проводиться в соответствии сданной стратегией. В стратегии должны быть учтены
требования к надежности инструментальных программ и тип инструментальных программ.
14.3.2.2 Должны быть определены качественные требования по надежности с учетом:
1) последствийдефекта в инструментальной программе;
2) вероятность того, что инструментальная программа вызовет или активизируетдефекты в программ
ном обеспечении, реализующем функцию безопасности;
3) какиедругие инструментальные программы или процессы смягчают последствия дефектов вдан
ной инструментальной программе.
П р и м е ч а н и е — Принципы «защиты в глубину» и разнообразив могут способствовать снижению
требований к надежности.
14.3.2.3 В стратегии аттестации инструментальных программ должны быть учтены:
1) анализ процесса разработки инструментальной программы и информация о ней от поставщика,
2) адекватность документации по инструментальной программе, позволяющая проведение верифи
кации ее выходныхданных и обеспечивающая простоту изучения:
3) тестирования и валидация инструментальной программы;
4) оценка инструментальной программы за период ее применения;
5) информация по опыту применения инструментальной программы.
П р и м е ч а н и е — Раздел 15 содержит требования к применению ранее разработанного программного
обеспечения, что также следует учитывать в стратегии аттестации инструментальных программ.
14.3.2.4 Выходныеданные инструментальной программы должны систематически подвергаться ве
рификации (например, посредством тестирований, анализа или сравнения с выходными данными функци
онально аналогичных инструментальных программ), если эти выходные данные включаются в конечное
программное обеспечение.
14.3.2.5 Инструментальные программы должны быть объектом оценки всоответствии с тем. как это
описано в разделе 15, либо они должны разрабатываться в соответствии с требованиями к обеспечению
качества в соответствии с разделами с 1— 12. за исключением случаев, когда:
- инструментальная программа не может внести дефекты в программное обеспечение (например,
текстовый редактор для документации) либо
- имеются средства смягчения всех возможных дефектов инструментальных программ (например,
путем разнообразия процессов или проектирования системы [см. перечисление 5) пункта 14.3.1.3]. либо
- выходные данные инструментальной программы подвергаются систематической верификации
[см. перечисление 4) пункта 14.3.1.3]. В процессе аттестации может быть учтен опыт предшествующего
использования инструментальной программы, где была подтверждена ее адекватность применению, важ
номудля безопасности.
14.3.3 Управление конфигурацией инструментальной программы
14.3.3.1Все инструментальные программы должны находиться под управлением конфигурацией для
обеспечения полной идентификации выбранных инструментальных программ (включая название, версию,
вариант и, возможно, конфигурацию) и параметры инструментальной программы, используемой для фор
мирования основного программного обеспечения (см. 5.6).
П р и м е ч а н и е — Это полезно не только для согласованности конечного программного обеспечения, но
также помогает оценивать источник возникновения дефекта, который может находиться в исходном коде, инстру
ментальной программе или параметрах инструментальной программы. Это может также оказаться необходи
мым при оценке вероятности возникновения ООП из-за инструментальных программ.
35