Не является сервисом для создания и проведения компьютерного тестирования

Обновлено: 21.11.2024

Проверку компьютерной системы (CSV) часто называют проверкой программного обеспечения. Регулируемые компании выполняют проекты проверки, чтобы доказать, что их программное обеспечение или система работают так, как они должны работать, и не работают так, как не должны работать.

Есть несколько примеров того, почему важна проверка программного обеспечения. Посмотрите нашу библиотеку предупреждающих писем, чтобы найти более 200 причин для проверки вашего программного обеспечения или систем. Учащиеся нашего учебного лагеря по валидации компьютерных систем читают тематическое исследование о Therac-25, аппарате для лучевой терапии 1980-х годов. Из-за проблем с программированием машина могла назначать пациентам неправильное количество радиации (часто в виде огромной передозировки), что приводило к серьезным травмам и даже смерти. Если бы существовали стандарты проверки программного обеспечения, подобные случаи можно было бы выявить и устранить до начала лечения пациентов.

Проверка компьютерных систем — это серьезно, и FDA и другие регулирующие органы не относятся к этому легкомысленно.

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

«Подтверждение путем проверки и предоставления объективных доказательств того, что спецификации программного обеспечения соответствуют потребностям пользователей и предполагаемому использованию, и что конкретные требования, реализованные с помощью программного обеспечения, могут быть последовательно выполнены» — Общие принципы проверки программного обеспечения: окончательный вариант Руководство для промышленности и персонала FDA

Чтобы понять ключевые моменты, давайте разберем определение.

«Подтверждение экспертизой» — должны быть определены потребности пользователя и предполагаемое использование. Пользователь может быть пациентом, кем-то в больнице, лаборантом, инженером по контролю качества, производственником. Изучите программное обеспечение, чтобы убедиться, что оно работает в соответствии с требованиями и подходит для использования по назначению.
«предоставление объективных доказательств» — должны быть определены требования к программному обеспечению. Документируйте все действия по проверке и результаты тестирования.
"потребности пользователя и предполагаемое использование" – изучить программное обеспечение, чтобы убедиться, что оно соответствует потребностям пользователя и определенным требованиям. Сюда могут входить проверки проекта, проверки кода, тестирование и т. д. Определите, что пользователь должен делать с программным обеспечением и как он будет его использовать.
«конкретные требования, реализованные с помощью программного обеспечения» — подтверждение того, что требования могут быть последовательно выполнены (а не только в одной ситуации). Это может включать стресс-тестирование нескольких наборов данных, тестирование производительности со многими пользователями во многих местах, тестирование с использованием нескольких браузеров или веб-приложений, тестирование с нескольких устройств (и даже мобильных приложений) и т. д. использовать.
«постоянно выполняется» — необходимо иметь объективные доказательства этого подтверждения (для проверок). Документируйте все действия по валидации и результаты испытаний. Экспертиза должна подтвердить, что программное обеспечение будет работать во всех ожидаемых ситуациях.

Как выполнить проверку компьютерной системы с помощью классической «V-диаграммы»

Теперь, когда вы понимаете определение проверки компьютерной системы, мы можем обсудить один тип методологии, используемой для проектов проверки. Классическая «V-диаграмма» была популяризирована отраслевыми организациями, такими как ISPE, с помощью руководств GAMP.

Вот изображение модели:

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

Давайте разберем каждую часть поподробнее, начиная с планирования.

План проверки

План проверки определяет, что будет проверяться, и подход, который вы будете использовать. В нем также определяются роли и обязанности, а также самая важная часть — критерии приемки.

Спецификация требований пользователя (URS)

Спецификация требований пользователя описывает, что пользователю нужно от программного обеспечения и как он будет его использовать. Он также содержит любые критические ограничения, такие как правила, требования безопасности, эксплуатационные требования и т. д.

Например, вот список нескольких пользовательских требований, которые могут потребоваться для лабораторной системы.

Система должна отслеживать обучение лаборантов лабораторным методам/технике.
Система должна отслеживать образцы, поступающие в лабораторию.
Система должна автоматически назначать лаборантов для тестирования образцов в зависимости от их доступности и обучения.
Система должна отправлять в ERP образцы результатов тестирования "пройдено/не пройдено".
Система должна соответствовать 21 CFR 11

Функциональные характеристики (FS)

Документ «Функциональная спецификация» описывает, как программное обеспечение должно работать и выглядеть, чтобы соответствовать потребностям пользователя. Документ может включать описание того, как должны выглядеть определенные экраны и отчеты, или описание данных, которые необходимо зафиксировать.

Функциональные требования также могут включать логику и расчеты, а также то, как они будут соответствовать нормативным требованиям. Например, в требованиях соответствия Части 11 может быть указано, как должны работать пароли или контрольный журнал.

Спецификации дизайна (DS)

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

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

Сборка системы

На этапе сборки системы вы разрабатываете или покупаете свое программное обеспечение, а затем настраиваете его в соответствии с предыдущими документами спецификации. Этот шаг включает модульное тестирование и интеграционное тестирование.

Квалификационные тесты установки (IQ)

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

Квалификационные тесты (OQ)

Операционное квалификационное тестирование часто называют функциональным тестированием или системным тестированием. Тесты OQ подтверждают, что все функциональные возможности, определенные в функциональной спецификации, присутствуют и работают правильно, а также отсутствие ошибок. Тесты OQ также могут включать подтверждение того, что любые элементы дизайна, не протестированные во время IQ, такие как конфигурация, работают, как указано.

Квалификационные тесты производительности (PQ)

Квалификационное тестирование производительности часто называют приемочным тестированием пользователей. Тестирование PQ подтверждает, что программное обеспечение будет отвечать потребностям пользователей и подходит для их предполагаемого использования, как определено в Спецификации требований пользователя. Тестирование может проводиться в соответствии с вариантами использования, СОП, пользовательскими сценариями и т. д. Для простого программного обеспечения, такого как отчеты или электронные таблицы, тестирование OQ и PQ часто сочетается.

Отчетность

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

Другая терминология проверки компьютерных систем

Проверка программного обеспечения

Управление по санитарному надзору за качеством пищевых продуктов и медикаментов заявляет, что:

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

Проверка подтверждает и проверяет задачи в процессе проверки. Он включает проверку и утверждение спецификаций (URS, FS, Designs), формальные обзоры проекта, просмотр кода, тестирование (IQ, OQ, PQ), матрицы трассировки (подтверждение всех URS, рассмотренных в FS и Design, подтверждение всех проверенных спецификаций), проверку. отчет (подтверждающий завершение всех действий по валидации, соответствие критериям приемлемости). Проверка также может включать в себя подтверждение учебных материалов, СОП для пользователей и технических специалистов, DRP и т. д.

Квалификация

Квалификация определяется IEEE следующим образом:

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

Квалификация — это формальное тестирование требований в URS, FS или проектном документе. Вы выполняете эти тесты на этапах IQ, OQ и PQ процесса проверки.

Чтобы объединить эти термины, давайте рассмотрим это на диаграмме отношений.

Итак, проверка компьютерной системы — это общее требование и процесс. Он состоит из множества действий по проверке, из которых формальное тестирование (IQ, OQ, PQ) по сравнению со спецификациями во многих компаниях называется «Квалификацией».

Я надеюсь, что этот пост пролил свет на то, как выполнять проверку компьютерной системы, чтобы вы могли применить эту методологию к своему следующему проекту проверки.

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

Получите помощь от экспертов. Наши опытные консультанты могут проверить ваше программное обеспечение или системы для вас.

Политика авторского права
Если не указано иное, Praxis Life Sciences, LLC является законным владельцем авторских прав на все (письменные, мультимедийные и графические) материалы на этом веб-сайте, и их нельзя использовать, перепечатывать, (частично) изменять или опубликованы без письменного согласия. Ссылка на Центр проверки должна присутствовать во всех копиях любых иллюстраций или контента, включая статьи и пресс-релизы.

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

Темы блога

Соответствие требованиям

Информация — это сила. Будьте в курсе последних тенденций соответствия, новых выводов FDA и отраслевых новостей. Будьте в курсе

Наши услуги по проверке

Наши аудиторские услуги

Подключить

Свяжитесь с нами сегодня, чтобы обсудить, как мы можем помочь с вашим проектом проверки или аудитом FDA.

Разработка программного обеспечения — это набор действий в области информатики, посвященных процессу создания, проектирования, развертывания и поддержки программного обеспечения.

Программное обеспечение — это набор инструкций или программ, которые сообщают компьютеру, что делать. Он не зависит от аппаратного обеспечения и делает компьютеры программируемыми. Существует три основных типа:

Системное программное обеспечение для обеспечения основных функций, таких как операционные системы, управление дисками, утилиты, управление оборудованием и другие необходимые операции.

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

Возможный четвертый тип — это встроенное программное обеспечение. Программное обеспечение встроенных систем используется для управления машинами и устройствами, обычно не считающимися компьютерами, — телекоммуникационными сетями, автомобилями, промышленными роботами и многим другим. Эти устройства и их программное обеспечение могут быть подключены как часть Интернета вещей (IoT). 2

Разработкой программного обеспечения в основном занимаются программисты, инженеры-программисты и разработчики программного обеспечения. Эти роли взаимодействуют и пересекаются, а динамика между ними сильно различается в разных отделах разработки и сообществах.

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

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

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

Важным отличием разработки программного обеспечения на заказ от разработки коммерческого программного обеспечения является разработка программного обеспечения на заказ. Разработка программного обеспечения на заказ — это процесс проектирования, создания, развертывания и обслуживания программного обеспечения для определенного набора пользователей, функций или организаций. Напротив, готовое коммерческое программное обеспечение (COTS) разработано с учетом широкого набора требований, что позволяет его упаковывать, продавать и распространять на коммерческой основе.

Экспертные новости и советы для специалистов в области науки и технологий.

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

Рекомендации по проверке компьютерных систем

Проверка компьютерной системы (CSV) – это документированный процесс, который требуется регулирующим органам по всему миру для проверки того, что компьютеризированная система выполняет именно то, для чего она предназначена, согласованным и воспроизводимым образом. Этим регулирующим органам требуются процессы CSV для подтверждения точности и целостности данных в компьютеризированных системах, чтобы обеспечить безопасность и эффективность продукта. Например, в США FDA требует, чтобы фармацевтические компании выполняли CSV для систем, поддерживающих производство следующих продуктов:

Фармацевтика
Биопрепараты
Медицинские приборы
Кровь и компоненты крови
Продукты из клеток и тканей человека
Детские смеси

Проверка компьютерной системы требуется при настройке новой системы или внесении изменений в проверенную систему (обновления, исправления, расширения и т. д.).

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

Проверка компьютерной системы 101

Что касается валидации компьютерных систем, «компьютерная система» в лаборатории, регулируемой FDA, — это не просто компьютерное оборудование и программное обеспечение. Компьютерная система также может включать в себя любое оборудование и/или инструменты, подключенные к системе, а также пользователей, которые управляют системой и/или оборудованием с помощью стандартных операционных процедур (СОП) и руководств.

Проверка компьютерных систем помогает гарантировать, что как новые, так и существующие компьютерные системы последовательно выполняют свое предназначение и дают точные и надежные результаты, которые обеспечивают соблюдение нормативных требований, выполнение требований пользователей и способность обнаруживать недействительные и/или измененные записи. CSV использует как статическое, так и динамическое тестирование, которое проводится на протяжении всего жизненного цикла разработки программного обеспечения (SDLC) — от внедрения системы до вывода из эксплуатации.

Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США определяет валидацию программного обеспечения как «подтверждение путем проверки и предоставления объективных доказательств того, что спецификации программного обеспечения соответствуют потребностям пользователя и предполагаемому использованию, а также что определенные требования, реализованные с помощью программного обеспечения, могут быть последовательно выполнены». Компьютерные системы необходимо проверить, чтобы убедиться, что система будет работать во всех ситуациях. Кроме того, все действия по проверке и результаты испытаний должны быть задокументированы.

Все действия с CSV должны быть задокументированы следующим образом:

Инвентаризация и оценка системы — определение систем, которые необходимо проверить
Спецификации требований пользователя — четкое определение того, что должна делать система, а также эксплуатационные (нормативные) ограничения.
Спецификации функциональных требований — четко определяет, как система будет выглядеть и функционировать, чтобы пользователь мог выполнить требования пользователя.
План проверки (VP) — определяет цели проверки и подход к поддержанию статуса проверки.
Оценка рисков проверки — анализ сценариев сбоев для определения объема усилий по проверке
Матрица прослеживаемости валидации — перекрестная ссылка между пользовательскими и функциональными требованиями и подтверждение того, что все было протестировано
Квалификация сети и инфраструктуры — документация, показывающая, что аппаратное/программное обеспечение сети и инфраструктуры, поддерживающее проверяемую прикладную систему, установлено правильно и работает должным образом.
Сценарии и результаты квалификации установки (IQ) — тестовые примеры для проверки правильности установки системы в пользовательской среде
Сценарии и результаты операционной квалификации (OQ) — тестовые примеры для проверки того, что система делает то, для чего она предназначена в пользовательской среде
Сценарии и результаты квалификации производительности (PQ) — тестовые примеры для проверки того, что Система делает то, для чего она предназначена, с обученными людьми, которые следуют СОП в производственной среде даже в наихудших условиях.
Отчет о проверке — обзор всех действий и документов в соответствии с планом проверки.
Документация о выпуске системы — документы о том, что действия по проверке завершены и система доступна для использования по назначению.

Рекомендации по проверке компьютерных систем

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

Выполните CSV с учетом рисков. Для выполнения CSV требуется много времени и ИТ-ресурсов, поэтому разумно следовать гибкому подходу GAMP 5, который использует оценку системы на основе рисков для определения необходимых тестовых случаев и оптимального уровня тестирования для каждого из них. Усилия CSV должны быть сосредоточены на том, что практично и достижимо для критических элементов системы, влияющих на обеспечение качества и соответствие нормативным требованиям. Преимущества такого подхода к CSV, основанного на оценке рисков, включают снижение затрат, бизнес-рисков и продолжительность проверки.

Создайте хороший план проверки. Как и в любом техническом начинании, процессы CSV должны руководствоваться хорошим планом, который создается до начала проекта. Этот план определит цели валидации, подход к поддержанию статуса валидации для всего SDLC и будет соответствовать всем нормативным политикам и передовым отраслевым практикам (например, GAMP 5). План проверки будет создан людьми, которые хорошо разбираются в задействованных технологиях (т. е. в информационных системах, инструментах, устройствах и т. д.) и служат для сведения к минимуму влияния проекта на повседневные лабораторные процессы.

План проверки должен содержать следующее:

Объем проекта — описывает части системы, которые будут проверены, а также результаты/документацию по проекту. Мероприятия по проверке применяются только к тем аспектам системы, которые будут использоваться компанией.
Подход к тестированию – определяет типы данных, которые будут использоваться для тестирования, а также типы сценариев, которые будут тестироваться.
Команда тестирования и обязанности. Список членов группы проверки, а также их роли и обязанности в процессе проверки.
Критерии приемлемости. Определяет требования, которые должны быть выполнены, прежде чем система будет считаться пригодной для использования в регулируемой деятельности.

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

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

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

Аудит сторонних поставщиков. В дополнение к выполнению CSV на внутренних системах компания, регулируемая FDA, должна быть готова к аудиту сторонних поставщиков услуг (например, CRO), а также поставщиков критически важных приложений и облачных услуг (SaaS). Производитель продукта, регулируемого FDA, несет полную ответственность за целостность данных, которые подтверждают эффективность и безопасность продукта, поэтому, если используются сторонние поставщики или поставщики услуг, производитель должен предпринять соответствующие шаги для обеспечения их работы. по стандартам, которые выдержали бы проверку FDA.

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

Заключение

Эффективная проверка компьютеризированных систем с учетом рисков – важная часть обеспечения соответствия нормативным требованиям и качества продукции в современных лабораториях. Неэффективные или неэффективные процессы CSV не позволяют реализовать проекты вовремя и в рамках бюджета, а также могут привести к действиям регулирующих органов.Что касается FDA, например, действия регулирующих органов из-за несоблюдения надлежащих требований CSV могут иметь юридические и финансовые последствия для организации.

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

Читайте также: