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