ГОСТ IEC 62304—2022
В.5.5 Имплементация и верификация ПРОГРАММНОГО БЛОКА
Данная ДЕЯТЕЛЬНОСТЬ требует от ИЗГОТОВИТЕЛЯ записать и проверить код для ПРОГРАММНЫХ
БЛОКОВ.
Детальный дизайн преобразовывается в исходный код. Кодирование представляет собой момент, в котором
заканчивается декомпозиция спецификаций и начинается составление реализуемого исполняемого ПО. Чтобы
последовательно достигать желаемых характеристик кода, должны использоваться стандарты кодирования для
определения предпочитаемого стиля кодирования. Примеры стандартов кодирования включают требования к по
нятности, правила использования языка или ограничений и сложность управления. Код для каждого модуля ВЕ
РИФИЦИРУЕТСЯ на предмет функционирования как определено в детальном дизайне, и что он соответствует
установленным стандартам кодирования.
Пункт 5.5.5 требует от ИЗГОТОВИТЕЛЯ проверять код. Если код не реализует дизайн правильно, программ
ное обеспечение МЕДИЦИНСКОГО ИЗДЕЛИЯ не будет функционировать так, как предназначено.
В.5.6 Интеграция и тестирование интеграции программного обеспечения
Данная ДЕЯТЕЛЬНОСТЬ требует от ИЗГОТОВИТЕЛЯ планировать и реализовывать интеграцию ПРО
ГРАММНЫХ БЛОКОВ в ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ также, как и интеграцию ПРОГРАММНЫХ СОСТАВ
НЫХ ЧАСТЕЙ в более сложносоставные ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ, и проверять, что полученные в
результате данной сборки ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ функционируют так, как предназначено.
Подход к интеграции может варьироваться от неинкрементной интеграции до любой формы пошаговой ин
теграции. Свойства собираемой ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ диктуют выбираемый метод интеграции.
Тестирование интеграции ПО направлено на передачу данных иуправление всей ПРОГРАММНОЙ СОСТАВ
НОЙ ЧАСТИ через внешние и внутренние интерфейсы. Внешние интерфейсы — это те, которые имеют другое
программное обеспечение, включая программное обеспечение операционной системы иаппаратные средства МЕ
ДИЦИНСКОГО ИЗДЕЛИЯ.
Точность тестирования интеграции и уровень детализации документации, связанной с тестированием инте
грации, должны быть соизмеримы с РИСКОМ, связанным с изделием, с зависимостью изделия от программного
обеспечения для потенциально опасных функций, а также с ролью определенных ПРОГРАММНЫХ СОСТАВНЫХ
ЧАСТЕЙ вфункционале изделия с большей степенью РИСКА. Например, несмотря на то, что все ПРОГРАММНЫЕ
СОСТАВНЫЕ ЧАСТИ должны быть протестированы, элементы, которые влияют на БЕЗОПАСНОСТЬ, должны под
вергаться более направленным, всесторонним и детальным тестам.
В соответствующих случаях тестирование интеграции демонстрирует поведение программы на границах ее
входных и выходных доменов (областей) и подтверждает реакцию ПО на недействительные, неожиданные и спе
циальные входные данные. Действия программы обнаруживаются при введении комбинации входных данных или
неожиданной последовательности входных данных, или когда нарушены определенные требования синхрониза
ции. Требования тестирования в плане должны включать, соответственно, типы тестирования методом «белого
ящика», чтобы быть выполненными как часть интеграционного тестирования.
Тестирование методом «белого ящика», также известное как тестирование «стеклянного ящика», «структур
ное», «прозрачного ящика» и «открытого ящика», — это техника тестирования, где используется точное знание
внутреннего функционирования ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ, чтобы выбирать данные тестирования. Те
стирование методом «белого ящика» использует определенные знания о ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ,
чтобы проверять выходные данные. Это тестирование является точным, только если тестовый инженер знает, что
ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ должна делать. Тогда тестовый инженер может видеть, когда ПРОГРАММ
НАЯ СОСТАВНАЯ ЧАСТЬ отклоняется от его намеченной цели. Тестирование методом «белого ящика» не может
гарантировать, что была реализована полная спецификация (на программное обеспечение), поскольку оно фо
кусируется на тестировании реализации ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ. Тестирование методом «черного
ящика», также известное как «поведенческое», «функциональное», тестирование «непрозрачного ящика» или те
стирование «закрытого ящика», фокусируется на тестировании функциональной спецификации и не может гаран
тировать, что были протестированы все реализованные части. Таким образом, тестирование методом «черного
ящика» является тестированием на спецификацию и обнаруживает дефекты пропусков, определяя, какая часть
спецификации не была выполнена. Тестирование методом «белого ящика» является тестированием на реали
зацию и обнаруживает дефекты выполнения, указывая, какая часть реализации неисправна. Чтобы полностью
протестировать ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ МЕДИЦИНСКОГО ИЗДЕЛИЯ, могут потребоваться как тестиро
вание методом «черного ящика», так и тестирование методом «белого ящика».
Планы и документация тестирования, определенные в подразделах 5.6 и 5.7, могут быть отдельными до
кументами, привязанными к конкретным стадиям разработки или эволюционным прототипам. Они могут быть объ
единены в единый документ или набор документов, охватывающих требования множества подразделов. Все доку
менты или часть документов могут быть включены в проектные документы более высокого уровня, такие как план
обеспечения качества проекта или ПО, или план комплексного тестирования, который охватывает все аспекты
тестирования аппаратных средств и программного обеспечения. Втаких случаях следует создавать перекрестную
ссылку, которая определяет, как различные документы проекта связаны с каждой из ЗАДАЧ интеграции программ
ного обеспечения.
36