ГОСТРМЭК 62279—2016
шее содержание и формат для автоматической передачи на вход к последующему инструментальному сред
ству. таким образом, минимизируя возможность введения ошибки человеком при доработке промежуточных
результатов.
Инструментальные средства обычно выбираются и демонстрируются так. чтобы они были совместимыми с
потребностями приложения.
Также рассматривается доступность подходящих инструментальных средств, предоставляющих определен
ные сервисы, которые необходимы на протяжении всего жизненного цикла программного обеспечения.
6.7.4.2 Выбор инструментальных средств для классов Т2 и ТЗ должен быть обоснован (см.
7.3.4.12). Обоснование должно включать идентификацию возможных отказов, которые могут оказаться в
выходном результате инструментальных средств, и меры для предотвращения или обработки таких
отказов.
6.7.4.3 Все инструментальные средства для классовТ2 иТЗдолжны иметь спецификацию или ру
ководство. которое четко определяет поведение этого инструментального средства и любые команды
или ограничения на его использование.
6.7.4.4 Для каждого инструментального средства в классе ТЗ доказательство должно быть до
ступным, то есть либо выход инструментального средства соответствует спецификации выхода, или
обнаружены отказы в выходе. Доказательство может основываться на тех же шагах, которые необхо
димы для выполняемого процесса вручную вместо инструментального средства, и представленном
объяснении, если эти шаги заменены альтернативными (например на подтверждении соответствия ин
струментального средства). Доказательство может также основываться на:
a) подходящей комбинации истории успешного использования в аналогичном окружении и для
подобных применений (в данной или других организациях).
b
) подтверждении соответствия инструментального средства, как определено в 6.7.4.S;
c) разнообразном избыточном коде, который позволяет обнаружить и управлять отказами, полу
ченными в результате сбоев, внесенных инструментальным средством:
d) соответствии с уровнями полноты безопасности, полученными из анализа рисков процесса и
процедур, включая инструментальные средства;
e) других подходящих методах для предотвращения или обнаружения и управления отказами,
внесенными инструментальными средствами.
П рим ечан ия
1 История версий может гарантировать зрелость инструментального средства и записи ошибок
I
неоднознач
ностей. связанных с его использованием в некотором окружении.
2 Доказательство, перечисленное для ТЗ. может также использоваться для инструментальных средств Т2
при оценке правильности их результатов.
6.7.4.5 Результаты подтверждения соответствия инструментального средства должны быть до
кументально оформлены, включая следующие результаты:
a) запись действий, выполняемых для подтверждения соответствия:
b
) версия используемого руководства инструментального средства;
c) функции инструментального средства, подтверждение соответствия которых было выполнено;
d) используемые инструменты и оборудование:
e) результаты действия, выполняемого для подтверждения соответствия, документально оформ
ленные результаты подтверждения соответствия должны установить, что либо программное обеспече
ние проходит подтверждение соответствия, либо определены причины его отказа;
f) тестовые сценарии и их результаты для последующего анализа:
д) несоответствия между ожидаемыми и фактическими результатами.
6.7.4.6 Если доказательство соответствия 6.7.4.4 недоступно, тодолжны бытьэффективные меры
управления отказами исполнимого, связанного с безопасностью программного обеспечения, которые
следуют из сбоев, относящихся к инструментальному средству.
П рим ечан ия
1Примером является генерация разнообразного избыточного кода, который позволяет обнаружение и управ
ление отказами, к которым приводят сбои, внесенные транслятором.
2 Например, пригодность для определенной цели не доверенного компилятора может быть обоснована сле
дующим образом.
24