Отредактировано - 18676 - CFX Maestro Dx Verification Plan Rev A

BIO-RAD LABORATORIES, LIFE SCIENCE GROUP
Проект: CFX Maestro Dx Номер документа: 18676

Название документа: План верификации CFX Maestro Dx Редакция: A
ПРЕДУПРЕЖДЕНИЕ: ИНФОРМАЦИЯ, СОДЕРЖАЩАЯСЯ В ДАННОМ ДОКУМЕНТЕ,

ЯВЛЯЕТСЯ КОНФИДЕНЦИАЛЬНОЙ. НИ ОДНА ЧАСТЬ ДАННОГО ДОКУМЕНТА НЕ
МОЖЕТ БЫТЬ РАСКРЫТА БЕЗ ПРЕДВАРИТЕЛЬНОГО ПИСЬМЕННОГО СОГЛАСИЯ
КОМПАНИИ «БИО- РАД ЛАБОРАТОРИИ» (BIO-RAD LABORATORIES).
Утверждено:
Дата
Отдел Ф. И. О. Подпись
подписания
Научных
исследований и
Документ подписан:
разработок,
Заррин Мохаммади /Подпись/ 06.11.2020
специалист по
FFAE4505F3BA485…
обеспечению
качества ПО
Научных Документ подписан:
исследований и Прабхат Мастей /Подпись/ 06.11.2020
разработок, ПО F61FBB748E8C432…
Научных
Кевин Торнтон /Подпись/ 10.11.2020
клеточной и
A53C1325F37A44E…
молекулярной
биологии
Жаклин Гонзалез-
Маркетинга /Подпись/ 06.11.2020
Рубио
8547DD7981C3468…
Управления
Рэйчел Иаконо /Подпись/ 06.11.2020
проектами
85A5FFC10D76483…
Маркетинга Мэри Нгуен /Подпись/ 16.11.2020
801AB6744C2B4A7…
Научных
Джои Лин /Подпись/ 06.11.2020
специалист по
969ACC8AB50B444…
обеспечению
качества ПО
Управления
Кристин де Гузман /Подпись/ 06.11.2020
проектами
B0CD871D728443C…
КОНФИДЕНЦИАЛЬНО Страница 1 из 11
История редакций
Редакция Дата Автор Описание изменения
05.11.202
A 0 Заррин Мохаммади Первоначальная версия
\
Содержание
1. ВВЕДЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ.....................................................................................4
2. ВЕРИФИКАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.............................................................4
2.1. Определение верификации.............................................................................................................4
2.2. Метод верификации программного обеспечения.........................................................................4
3. ФУНКЦИИ И ОБЯЗАННОСТИ........................................................................................................5
4. ОБЗОР ПРОЦЕССА ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.......................5
4.1. Объекты, требующие верификации...............................................................................................5
4.2. Метод верификации, основанный на оценке рисков...................................................................5
4.3 Стратегия и разработка контрольных примеров..........................................................................7
4.4. Разработка автоматизированных функциональных тестов.........................................................8
4.5. Выполнение тестов.........................................................................................................................8
4.7. Среда тестирования........................................................................................................................9
4.8. План усложнения тестирования....................................................................................................9
4.9. Дефекты, обнаруженные во время тестирования.......................................................................10
4.10.Критерии завершения верификации............................................................................................10
4.11. Отчет о результатах верификации..............................................................................................10
4.12.Ссылки...........................................................................................................................................11
ВВЕДЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ
Программное обеспечение CFX Maestro Dx SE с системой для ПЦР в реальном времени

CFX Opus 96 Dx или системой для ПЦР в реальном времени CFX Opus 384 Dx
предназначены для проведения ПЦР на основе флуоресценции для выявления и
количественного определения последовательностей нуклеиновых кислот. Прибор и
программное обеспечение предназначены для использования в диагностике in vitro
обученными лаборантами.
План верификации очерчивает действия, связанные только с верификацией

программного обеспечения. Любое интеграционное испытание прибора должно
происходить в соответствии с соответствующим планом верификации прибора.
1. ВЕРИФИКАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
1.1. Определение верификации
В процессе разработки программного обеспечения верификация и валидация

программного обеспечения являются отдельными и отличающимися друг от друга
операции. Действия по верификации выполняются непрерывно в процессе
разработки проекта для обеспечения того, что процесс сборки продукта
осуществляется должным образом. Действия по валидации выполняются после
завершения верификации, чтобы убедиться, что на выходе был получен правильно
собранный продукт.
Понятие верификация программного обеспечения в данном документе имеет

следующее определение: Подтверждение путем проверки и предоставление
объективных доказательств о выполнении проектной спецификации программного
обеспечения.
Верификация программного обеспечения выполняется непрерывно и постепенно

по мере создания продукта. Каждая новая или измененная функция проходит
проверку на каждом этапе разработки.
1.2. Метод верификации программного обеспечения
Целью верификации программного обеспечения, проводимой относительно

программного обеспечения CFX Maestro Dx SE, является подтверждение того, что
продукт выдает правильные выходные данные на каждом этапе процесса,
верификация согласованности и полноты и верификация того, а также проверка
правильности сборки продукта.
Действия по верификации программного обеспечения включают:
 определение приемочных испытаний и критериев;

 интеграционное тестирование;
 функциональное тестирование;
 регрессивное тестирование на английской, китайской и российской версиях
операционной системы;
 тестирование производительности;
 автоматизированное функциональное тестирование.
2. ФУНКЦИИ И ОБЯЗАННОСТИ
Для получения информации о функциях и обязанностях участников проектной группы

см. план проектирования и разработки 18393_CFX Maestro Dx.
3. ОБЗОР ПРОЦЕССА ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
3.1. Объекты, требующие верификации
Каждую новую или модифицированную проектную спецификацию программного

обеспечения необходимо тестировать и верифицировать по меньшей мере один раз
в ходе процесса разработки. Как минимум каждая новая и модифицированная
спецификация должна быть протестирована специалистами по обеспечению
качества ПО во время верификационного тестирования.
3.2. Метод верификации, основанный на оценке рисков
Все проектные спецификации программного обеспечения можно

классифицировать как:
 Спецификации не связанные с безопасностью – спецификации, не влияющие

на безопасность (т. е. незначительный уровень риска по классификации FDA и
класс А безопасности согласно IEC 62304);
 Спецификации связанные с безопасностью – объект программного
обеспечения, влияющий на безопасность, представляет собой любой объект,
ошибка надлежащей работы которого может привести к угрозе безопасности.
Спецификации, несущие умеренный или высокий уровень риска для пациента
или оператора (умеренный или значительный уровень беспокойства в FDA GPSV
и класс B или класс C в IEC 62304:2006). Объекты, классифицируемые как
связанные с безопасностью, попадают по меньшей мере в одну из указанных
ниже категорий:
 спецификации, уменьшающие опасность, – спецификация программного
обеспечения, которая уменьшает опасность/вред, имеющиеся в системе.
Также известны как меры предосторожности (т. е. аварийные сигналы,
флаги и т. д.);
 спецификации опасности – спецификация программного обеспечения,
которая, если не реализована или имеет дефект реализации или скрытую
ошибку проектирования, обладает потенциалом к нанесению вреда (т. е. для
вычисления результата, интерпретации штрихкода и сопоставления порядка
и т. п.).
4.2.1. Тестирование спецификаций, связанных с безопасностью
Все спецификации в программном обеспечении CFX Maestro Dx SE не

связаны с безопасностью. Поэтому тестирование спецификаций, связанных
с безопасностью, для программного обеспечения CFX Maestro Dx SE не
проводится.
4.2.2. Тестирование спецификаций, не связанных с безопасностью
Спецификации, не связанные с безопасностью, проходят функциональное

тестирование и отражаются в контрольном примере или сценарии
верификации.
3.3. Итеративный процесс верификации
Разработка программного обеспечения выполняется в рамках гибкого фреймворка

Scrum. Таким образом, требования выражаются как высказанные пользователями
пожелания вместе с определенным набором критериев приемлемости и
определением готовности. Для того чтобы верифицировать, что заново
реализованный код удовлетворяет критериям приемлемости, записывают тестовые
примеры. По мере разработки тестовых примеров их автоматизируют, чтобы
обеспечить возможность регрессивного тестирования. По мере разработки новых
функций автоматическое регрессионное тестирование обеспечивает правильную
работу ранее разработанных функций.
Регрессионный анализ используют для определения того, что:
 необходимо написать и выполнить новые тесты;

 необходимо обновить и выполнить существующие тесты;
 дополнительные существующие тесты необходимо выполнить как есть.
При каждом малом расширении ПО следуют следующему процессу:
 специалисты по обеспечению качества ПО / разработчики анализируют каждое

требование и спецификацию;
 специалисты по обеспечению качества ПО обеспечивают обратную связь для
усовершенствования спецификаций при необходимости;
 специалисты по обеспечению качества ПО имеют задания, связанные с
написанием новых вариантов тестирования для всех требований и
спецификаций на каждой итерации;
 специалисты по обеспечению качества ПО имеют задания по обновлению
вариантов тестирования из текущего руководства, автоматизации контрольных
примеров, выполнению регрессионного анализа, выполнению тестов и
документированию обнаруженных дефектов;
 разработчики имеют задания, связанные с проектированием, написанием кода,
блочным тестированием, анализом кода и непрерывным внесением изменений
в общее описание проекта системы;
 разработчики запускают блочные тесты для своего кода; при сбое в тесте,
разработчик продолжает работать над кодом, пока он не будет удовлетворять
спецификациям;
 последовательность операций тестов на общую работоспособность выполняют
ежедневно, чтобы убедиться в том, что, существующие функциональные
возможности не нарушены.
4.2.3. Деятельность группы разработчиков по верификации
Группа разработчиков программного обеспечения выполняет следующие

действия по верификации во время процесса проектирования и реализации:
 анализ исходного кода программного обеспечения;

 блочное тестирование исходного кода программного обеспечения.
4.2.4. Действия по проверке обеспечения качества программного обеспечения

Группа специалистов по обеспечению качества программного обеспечения
выполняет следующую верификацию по мере внедрения и/или изменения
признаков:
 по мере реализации пожеланий пишут тестовые случаи, и

функциональное тестирование выполняют с помощью ручного
тестирования. Функциональное тестирование включает тестирование
положительной реакции, тестирование отрицательной реакции и
граничное тестирование (если применимо).Тестовые случаи, которые
могут быть исполнены с использованием симулятора, автоматизируются
группой специалистов по обеспечению качества ПО с использованием
средства автоматизации Ranorex и добавляются к набору регрессивного
тестирования;
 автоматизированные регрессивные тесты используют для того, чтобы
определить, влияет ли изменение в одной части программного
обеспечения на другие существующие части программного обеспечения,
которые должны оставаться неизменными.
Группа специалистов по обеспечению качества программного обеспечения

выполняет следующее верификационное тестирование при наличии
соответствующих сборок:
 полная автоматическая регрессия выполняется ежедневно на развернутой

версии сборки. Полные регрессивные тесты выполняют на всех сборках
выпуска. При возникновения сбоя в тесте, в результате которого удается
определить наличие дефекта продукта, специалисты по обеспечению
качества ПО заносят данный дефект в систему отслеживания ошибок Jira.
Если сбой теста свидетельствует о наличии ошибки в написании,
специалисты по обеспечению качества ПО обновляют сценарии
тестирования.
4.2.5. Тестирование для проверки системы
Группа специалистов по клеточной и молекулярной биологии проверяет
предполагаемое функционирование программного обеспечение от
системного уровня, что включает использование импортированных (ранее
собранных) биологических наборов данных ПЦР для тестирования анализа
данных. Сюда входит биологическое испытание и/или испытание
влажностью с использованием расходных материалов, реагентов и
образцами при необходимости. Во время цикла разработки проекта
программного обеспечения могут быть созданы одна или более сборок. В
дальнейшем их передают группе специалистов по клеточной и
молекулярной биологии, заданием которых является определить
удовлетворяют ли данные сборки ожидаемые результаты проекта.
Для того, чтобы убедиться, что программное обеспечение удовлетворяет

всем требованием итерации и фиксирует новые дефекты, проводят
итерационное тестирование. Целью итерационного тестирования является
многократное и надежное выполнение основных рабочих процессов. После
того, как все функции будут завершены, будет выполнено верификационное
тестирование системы, чтобы убедиться, что система производит
правильный продукт и соответствует ожидаемым клиентом результатам.
4.3 Стратегия и разработка тестовых случаев
Для каждого пожелания группа специалистов выполняет анализ метода
тестирования во время той итерации, в которой его реализуют. Это делают для
того, чтобы проанализировать новые и модифицированные спецификации,
реализация которых запланирована во время этой итерации, и определить объем
требуемого специального и неспециального тестирования. Специальное
тестирование включает запуск тестовых случаев, специально нацеленных на

реализацию новых признаков. Неспециальное тестирование нацелено на области,
которые могут быть затронуты реализацией новых признаков или модификацией
кода. Анализ стратегии тестирования используют для определения того, нужно ли:
 написать, проанализировать и выполнить новые тестовые случаи;

 обновить и выполнить существующие тестовые случаи;
 дополнительные существующие тестовые случаи выполнить «как есть».
Все тестирование выполняют на утвержденных системных конфигурациях.
4.4 Разработка автоматизированных функциональных тестов
Все тесты выполняют вручную по меньшей мере один раз. Где возможно, эти
ручные тестовые случаи автоматизируют.
Когда тест автоматизирован, его подвергают экспертному анализу, чтобы:
 оценить структуру, чистоту и выразительность кода;

 убедиться, что автоматизированный тестовый случай является точным
представлением тестового случая, выполненного вручную (а значит и
подходящей заменой для него);
 верифицировать, что автоматизированный тест может правильно
идентифицировать те же положительные и отрицательные тестовые случаи, что
и ручной тестовый случай, который он заменяет.
Весь комплект автоматизированных тестов запускают на каждой ежедневной

сборке. Целью такого частого запуска комплекта является быстрая идентификация
и устранение любых аномалий, возникающих вследствие разработки нового кода, а
также обеспечение поддержки высококачественного продукта. Результаты каждого
контрольного примера (как успешно пройденного, так и проваленного)
записывают. Если тестовый случай провален, о дефекте сообщают, и он проходит
через весь цикл последовательности операций по устранению дефекта в Jira (см.
раздел 4.8 данного документа).
4.5 Выполнение тестов
Когда разработка спецификации завершена, специалисты по обеспечению качества

ПО выполняют тестовые случаи для этой спецификации, определенные стратегией
тестирования. Выполнение всех верификационных тестовых случаев анализируют.
Всем выполненным тестовым случаям должен быть предоставлен один из
следующих статусов.
Статус Описание
Пройден
Программное обеспечение отвечает требованию.
успешно
Программное обеспечение отвечает требованию.
(Примечание: возможно, что программное обеспечение
Пройден с
демонстрирует ошибку, но все же отвечает требованию).
исключениями
Реализация может содержать ошибки, которые были оценены
как отложенные.
Провален Программное обеспечение не отвечает требованию.
4.6 Тестовый случай / детали выполнения
Ниже представлена информация, описывающая структуру тестового случая. Сюда входит:

 наименование/номер тестового случая или сценария;
 номер(-а) сборки программного обеспечения, использованной при выполнении;
 прибор(-ы), использованный(-ые) во время выполнения теста, где применимо;
 фамилия и инициалы инженера-испытателя;
 дата(-ы) выполнения;
 тестовые случаи / протоколы включают:
 детально изложенные этапы теста с соответствующими ожидаемыми
результатами (где применимо – не требуется, чтобы этапы подготовки
теста имели ожидаемые результаты);
 тип прибора: было ли тестирование осуществлено на промышленно
произведенном приборе или симуляторе;
 испытываемая(-ые) спецификация(-ии);
 статус выполнения для каждого тестового случая («пройден
успешною/провален). Если тестовый случай находится в состоянии
«провален», к нему могут прилагаться дополнительные комментарии. Если
появляется окно «успешно пройден», это свидетельствует о том, что этап
соответствует ожидаемым показателям;
 сопутствующие дефекты (если имеются).
4.7 Среда тестирования
Верификационное тестирование может быть проведено с использованием

симулятора в виртуальной среде, на локальной рабочей станции или на системе для
ПЦР в реальном времени CFX Opus 96 Dx или системе для ПЦР в реальном
времени CFX Opus 384 Dx.
4.8 План усложнения тестирования
При усложнении, специалисты по обеспечению качества ПО выполняют

следующее тестирование:
 выполнение всех тестовых случаев, связанных с пожеланиями, реализованными
специально для каждого выпуска (это включает запуск комбинации
автоматизированных и ручных тестовых случаев);
 тестирование производительности;
 анализ руководства пользователя;
 тестирование установки;
 анализ меню «Помощь»;
 дополнительное тестирование последовательностей операций и
исследовательское тестирование по критически важным признакам на 3 версиях
операционной системы: английской, российской, китайской;
 стрессовое тестирование посредством запуска тестов при подключении к 4
системам CFX Opus Dx в течение продолжительного периода времени.
КОНФИДЕНЦИАЛЬНО Страница 10 из
11
4.9 Дефекты, обнаруженные во время тестирования
Дефекты, обнаруженные во время тестирования, заносят в систему Jira. Во время

разработки группа сортирует дефекты путем назначения приоритета (срочный,
высокий, нормальный, низкий или несущественный) и серьезности
(катастрофический, серьезный, нормальный, малый и тривиальный) на основании
степени вреда, наносимого функциональности, и влияния, оказываемого на
проектные исходные требования. Дефекты могут быть устранены во время текущей
итерации, внесены в журнал как дефекты подлежащие устранению во время
следующей итерации, отложены до будущего выпуска, отложены на
неопределенный срок или закрыты со статусом «неподлежащие устранению».
Устраненные дефекты верифицируют, отслеживают и закрывают в системе Jira.
Если при тестировании обнаруживают, что дефекты не устранены, их отмечают как
«ошибка верификации» и возвращают группе разработчиков.
Отложенные дефекты классифицируют по риску перед выпуском в соответствии с

документом «SOP NPD.ENG 3114 Сортировка дефектов и классификация рисков
программного обеспечения», чтобы гарантировать отсутствие влияния на
безопасность.
4.10 Критерии завершения верификации
Верификационное тестирование считается завершенным при удовлетворении

следующих условий:
 системное верификационное тестирование, проведенное группой специалистов

по клеточной и молекулярной биологии, продемонстрировало, что
биологические/химические испытания соответствуют SRS, где применимо;
 программное обеспечение является «завершенным по признакам»: все новые и
модифицированные признаки, включая установку программного обеспечения,
были реализованы и верификационное тестирование этих признаков завершено;
 все проектные спецификации программного обеспечения были протестированы
и прошли верификационное тестирование;
 все дефекты, идентифицированные при анализе рисков как нуждающиеся в
устранении (срочные), были устранены, и дефектов, которые необходимо
верифицировать, не осталось;
 все автоматизированные блоки и верификационные тесты запускаются без
ошибок, за исключением любых известных отложенных дефектов;
 все программное обеспечение, которое необходимо протестировать,
идентифицировано и доступно;
 отчет о верификационном тестировании завершен.
4.11 Отчет о результатах верификации
Отчет о результатах верификации создают в конце цикла разработки проекта

программного обеспечения, подводя итоги по результатам выполненных действий
по верификации.
11
4.12 Ссылки
IEC 62304, издание 1.1, 2015-06 Программное обеспечение для медицинских

устройств - процессы жизненного цикла программного обеспечения.
11

Отредактировано - 18676 - CFX Maestro Dx Verification Plan Rev A

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Отредактировано - 18676 - CFX Maestro Dx Verification Plan Rev A

Загружено:

Авторское право:

Доступные форматы

BIO-RAD LABORATORIES, LIFE SCIENCE GROUP

Проект: CFX Maestro Dx Номер документа: 18676

ПРЕДУПРЕЖДЕНИЕ: ИНФОРМАЦИЯ, СОДЕРЖАЩАЯСЯ В ДАННОМ ДОКУМЕНТЕ,

ВВЕДЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ

Программное обеспечение CFX Maestro Dx SE с системой для ПЦР в реальном времени

План верификации очерчивает действия, связанные только с верификацией

1. ВЕРИФИКАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1.1. Определение верификации

В процессе разработки программного обеспечения верификация и валидация

Понятие верификация программного обеспечения в данном документе имеет

Верификация программного обеспечения выполняется непрерывно и постепенно

1.2. Метод верификации программного обеспечения

Целью верификации программного обеспечения, проводимой относительно

Действия по верификации программного обеспечения включают:

 определение приемочных испытаний и критериев;

Для получения информации о функциях и обязанностях участников проектной группы

3. ОБЗОР ПРОЦЕССА ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3.1. Объекты, требующие верификации

Каждую новую или модифицированную проектную спецификацию программного

3.2. Метод верификации, основанный на оценке рисков

Все проектные спецификации программного обеспечения можно

 Спецификации не связанные с безопасностью – спецификации, не влияющие

4.2.1. Тестирование спецификаций, связанных с безопасностью

Все спецификации в программном обеспечении CFX Maestro Dx SE не

4.2.2. Тестирование спецификаций, не связанных с безопасностью

Спецификации, не связанные с безопасностью, проходят функциональное

3.3. Итеративный процесс верификации

Разработка программного обеспечения выполняется в рамках гибкого фреймворка

Регрессионный анализ используют для определения того, что:

 необходимо написать и выполнить новые тесты;

При каждом малом расширении ПО следуют следующему процессу:

 специалисты по обеспечению качества ПО / разработчики анализируют каждое

4.2.3. Деятельность группы разработчиков по верификации

Группа разработчиков программного обеспечения выполняет следующие

 анализ исходного кода программного обеспечения;

4.2.4. Действия по проверке обеспечения качества программного обеспечения

 по мере реализации пожеланий пишут тестовые случаи, и

Группа специалистов по обеспечению качества программного обеспечения

 полная автоматическая регрессия выполняется ежедневно на развернутой

Для того, чтобы убедиться, что программное обеспечение удовлетворяет

тестирование включает запуск тестовых случаев, специально нацеленных на

 написать, проанализировать и выполнить новые тестовые случаи;

Все тестирование выполняют на утвержденных системных конфигурациях.

4.4 Разработка автоматизированных функциональных тестов

Когда тест автоматизирован, его подвергают экспертному анализу, чтобы:

 оценить структуру, чистоту и выразительность кода;

Весь комплект автоматизированных тестов запускают на каждой ежедневной

4.5 Выполнение тестов

Когда разработка спецификации завершена, специалисты по обеспечению качества

4.6 Тестовый случай / детали выполнения

Ниже представлена информация, описывающая структуру тестового случая. Сюда входит:

4.7 Среда тестирования

Верификационное тестирование может быть проведено с использованием

4.8 План усложнения тестирования

При усложнении, специалисты по обеспечению качества ПО выполняют

4.9 Дефекты, обнаруженные во время тестирования

Дефекты, обнаруженные во время тестирования, заносят в систему Jira. Во время

Отложенные дефекты классифицируют по риску перед выпуском в соответствии с

4.10 Критерии завершения верификации

Верификационное тестирование считается завершенным при удовлетворении

 системное верификационное тестирование, проведенное группой специалистов

4.11 Отчет о результатах верификации

Отчет о результатах верификации создают в конце цикла разработки проекта