ГОСТ РМЭК 62061—2015
Управление конфигурацией программного обеспечения должно позволить получить точную и однозначную
идентификацию версии программного обеспечения. Управление конфигурацией должно связать все обьекты (и их
версии), необходимыедля демонстрации функциональной безопасности.
Все обьекты в конфигурации программного обеспечения должны быть охвачены процедурой управления
конфигурацией до проверки или до запроса аналитиком для оценки окончательной версии программного обеспе
чения.
Примечание — Цель состоит в том. чтобы обеспечить выполнение процедуры оценки программного
обеспечения со всеми его элементами в точно определенном состоянии. Любое последующее изменение может
потребовать пересмотра программного обеспечения, которое должно быть идентифицируемо аналитиком.
Должны быть установлены процедуры для архивирования программного обеспечение и связанных с ним
данных (методы для хранения резервных копий и архивов).
Примечание — Эти резервные копии иархивы могут быть использованы для поддержания и изменения
программного обеспечения в течение срока жизни его функционирования.
С.3.5 Управление изменениями программного обеспечения
Любое изменение программного обеспечения, оказывающее влияние на функциональную безопасность
СБЭСУ, должно подчиняться правилам, установленным для управления изменениями и конфигурацией, поэтому
процесс разработки возвращается на самый высокий уровень, необходимыйдля учета изменения и не снижающий
функциональную безопасность.
Примечание — В частности, также должна быть обновлена документация и выполнены все необходи
мые мероприятия по проверке. Это гарантирует, что программное обеспечение будет сохранять все свои первона
чальные свойства после любых модификаций.
С.4 Инструментальные средства разработки
Инструменты, используемые в процедуре разработки (компилятор, компоновщик, тесты ит.д.), должны быть
определены (имя. ссылка, версия и т.д.) вдокументации, связанной с версией программного обеспечения (напри
мер. 8 документации управления версиями).
Примечание — Различные версии инструментальных средств необязательно дают одинаковые резуль
таты. Таким образом, точная идентификация инструментального средства прямо свидетельствует о непрерывно
сти процесса генерации исполняемой версии в том случае, если версия изменяется.
С.5 Воспроизводство, поставка
С.5.1 Создание исполнимого кода
Любой выбор или изменение при генерации во время создания программного обеспечения должны быть
записаны (например, в листе версий) так. чтобы можно было определить, как и когда программа была создана.
С.5.2 Установка и эксплуатация программного обеспечения
Все отказы, относящиеся к связанным с безопасностью функциям управления, доводятся до сведения раз
работчика системы и должны быть записаны и проанализированы.
Примечание — Это означает, что разработчик знает о любом отказе, связанного с безопасностью про
граммного обеспечения, которые доводятся до него, и он принимает соответствующие меры (например, пред
упреждения другим пользователям, модификацию программного обеспечения и т.д.).
С.8 Верификация и подтверждение соответствия программного обеспечения
Цель верификации — продемонстрировать, что элементы программного обеспечения, созданные на данной
стадии цикла разработки соответствуют требованиям, установленным на предыдущих стадиях, а также всем при
меняемым стандартам и правилам. Они также служат средством выявления иучета любых ошибок, которые могли
попасть в программное обеспечение в процессе его разработки.
Верификация программного обеспечения не просто серия тестов, даже при том. что она является основным
действием для сравнительно небольшого элемента программного обеспечения, которое рассматривается в данном
приложении. Другие виды действий, связанные с этими тестами или нет. такие как обзор и анализ, также считаются
действиями по верификации. В некоторых случаях они могут заменить некоторые тесты (например, в том случае,
если тест не может быть выполнен, потому что это может привести кухудшению компонентов аппаратных средств).
С.7 Общие руководящие указания по верификации и подтверждению соответствия
Аналитик должен уметь выполнять оценку соответствия программного обеспечения путем проведения лю
бых аудитов или экспертиз, считающихся полезными на различных стадиях разработки программного обеспечения.
Все технические аспекты процессов жизненного цикла программного обеспечения подлежат оценке анали
тиком. Ему должны быть доступны все отчеты о проверке (тесты, анализы и т.д.) и все технические документы,
используемые при разработке программного обеспечения.
63