Документация по валидации порядок оформления пакета документов по валидации процесса
Обновлено: 30.06.2024
Перед отправкой данных на сервер важно убедиться, что все обязательные поля формы заполнены данными в корректном формате. Это называется валидацией на стороне клиента и помогает убедиться, что данные, введённые в каждый элемент формы, соответствуют требованиям. Данная статья проведёт вас через основные концепци и примеры валидации на стороне клиента.
| Начальные требования: | Владение компьютером, достаточное понимание HTML, CSS, и JavaScript. |
|---|---|
| Цель: | Понять, что такое валидация на стороне клиента, почему это важно и как применять различные техники для её реализации. |
Однако, не следует рассматривать валидацию на стороне клиента как достаточную меру безопасности! Любые данные, отправляемые через форму, необходимо дополнительно проверять на безопасность и на стороне сервера, поскольку валидацию на стороне клиента достаточно просто обойти и она может не остановить злоумышленников. Чтобы лучше понимать потенциальные угрозы, рекомендуем ознакомиться с разделом Безопасность вебсайтов; валидация на стороне сервера выходит за рамки этого модуля, но о ней следует помнить.
Что такое валидация формы?
- "Обязательное поле" (Вы не можете оставить поле пустым).
- "Пожалуйста, введите номер телефона в формате xxx-xxxx" (Чтобы данные считались корректными, их необходимо указать в определённом формате).
- "Пожалуйста, введите корректный email-адрес" (вы ввели данные в неправильном формате).
- "Длина пароля должна быть от 8 до 30 символов и включать одну заглавную букву, один символ, и одну цифру." (Требования к формату данных достаточно конкретные).
Это называется валидацией формы. По мере ввода, браузер и/или сервер проверяют данные, чтобы определить, соответствуют ли они требуемому формату. Валидация, выполняемая в браузере, называется валидацией на стороне клиента, а выполняемая на сервере — валидацией на стороне сервера. В этом разделе мы сосредоточимся на валидации, выполняемой на стороне клиента.
Мы хотим максимально упростить заполнение веб-форм. Тогда почему мы настаиваем валидации данных? На это есть три основные причины:
- Мы хотим получать правильные данные в правильном формате. Наши приложения не будут работать должным образом, если данные от пользователей хранятся в неправильном формате, некорректны сами по себе или вовсе пропущены.
- Мы хотим защитить данные пользователей. Принуждение пользователей вводить надёжные пароли облегчает защиту их аккаунтов.
- Мы хотим защитить себя. Существует множество способов, позволяющих злоумышленникам с помощью незащищённых форм навредить приложению (смотрите Безопасность вебсайтов).
Предупреждение:: Никогда не доверяйте данным, передаваемым на сервер клиентской программой. Даже если ваша форма правильно валидируется и не допустит введение потенциально вредоносных данных на стороне клиента, злоумышленники по-прежнему могут изменить сетевой запрос.
Типы валидации на стороне клиента
Существует два типа валидации на стороне клиента, с которыми вы столкнётесь в Интернете:
- Встроенная валидация форм использует функционал валидации HTML5, который мы неоднократно обсуждали в этом модуле. HTML5-валидация обычно не требует большого количества JavaScript-кода и демонстрирует лучшую производительность, но не настолько настраиваема, как валидация с помощью JavaScript.
- JavaScript-валидация кодируется с помощью JavaScript. Она полностью настраиваема, но требует программирования всей логики (или использования библиотеки).
Использование встроенной валидации форм
Одной из самых важных функций элементов форм HTML5 является способность валидировать бóльшую часть пользовательских данных без использования JavaScript. Это выполняется с помощью атрибутов валидации у элементов формы. Многие из них мы уже рассмотрели в этом курсе:
- required : Определяет, что для отправки формы данное поле предварительно должно быть заполнено.
- minlength и maxlength : Задаёт минимальную и максимальную длину текстовых данных (строк)
- min и max : Задаёт минимальное и максимальное значение для поля, расчитанного на числовой тип данных
- type : Определяет тип данных, на который рассчитано поле: число, email-адрес или какой-то другой предустановленный тип
- pattern : С помощью регулярного выражения, определяет шаблон, которому должны соответствовать вводимые данные.
Если данные, введённые в поле формы, соответствуют правилам перечисленных выше атрибутов, они считаются валидными, если нет — не валидными
Когда элемент валиден, справедливы следующие утверждения:
Когда элемент не валиден, справедливы следующие утверждения:
Примечание: Существует ошибки, которые не позволяют отправлять форму, в частности badInput , patternMismatch , rangeOverflow или rangeUnderflow , stepMismatch , tooLong или tooShort , typeMismatch , valueMissing , или customError .
Примеры встроенной валидации форм
В этом разделе мы протестируем некоторые из атрибутов, которые обсуждали выше.
Простой начальный файл
Давайте начнём с простого примера: поле, позволяющее указать своё предпочтение — банан или вишня. Этот пример включает обычное текстовое поле , связанный с ним элемент и кнопку отправки формы . Исходный код можно найти на GitHub по адресу fruit-start.html, а ниже приведён рабочий пример.
Для начала скопируйте файл fruit-start.html в новую папку на вашем жёстком диске.
Атрибут required
Добавьте к полю атрибут required , как показано ниже.
Обратите внимание на CSS, который включён в файл примера:
Данный CSS задаёт полю красную пунктирную рамку, когда оно не валидно, а когда валидно — сплошную чёрную. Мы также добавили фоновый градиент для обязательных не валидных полей. Проверьте новое поведение в примере ниже:
Примечание: Рабочий пример можно найти на GitHub по адресу fruit-validation.html (отдельно можно найти исходный код.)
Наличие атрибута required у любого элемента, который его поддерживает, означает, что элемент соответствует CSS-псевдоклассу :required , независимо от того, имеет он значение или нет. Если элемент не содержит значение, он будет соответствовать псевдоклассу :invalid .
Примечание: Для повышения удобства взаимодействия указывайте пользователям, какие поля являются обязательными. К тому же, этого требует руководство по обеспечению доступности WCAG. Требуйте обязательного ввода только тех данных, которые вам действительно нужны: например, так ли важно знать пол или должность пользователя?
Валидация с помощью регулярного выражения
Ещё одной полезной функцией валидации является атрибут pattern , который в виде значения принимает Регулярное выражение. Регулярное выражение (regex) — это шаблон, который может быть использован для сопоставления набора символов в текстовой строке, поэтому они идеально подходят для валидации формы и используются для множества других целей в JavaScript.
Регулярные выражения достаточно сложны и мы не подем подробно рассматривать эту тему в данной статье. Ниже приведены несколько примеров, чтобы дать вам представление о том, как они работают.
- a — Соответствует одному символу a (не b , не aa , и так далее).
- abc — Соответствует символу a , за которой следует b , за которой следует c .
- ab?c — Соответствует символу a , за которым опционально может следовать b , за которым следует c . ( ac или abc )
- ab*c — Соответствует символу a , за которым опционально может следовать любое количество символов b , за которыми следует c . ( ac , abc , abbbbbc , и так далее).
- a|b — Соответствует символу a или b .
- abc|xyz — Соответствует в точности abc или в точности xyz (но не abcxyz или a или y , и так далее).
Есть еще много возможностей, которые мы не упомянули. Полный список со множеством примеров можно найти в документации по Регулярным выражениям
Давайте рассмотрим пример. Добавьте в атрибут pattern следующий шаблон:
Это даёт нам следующее обновление — опробуйте его:
Примечание: Рабочий пример можно найти на GitHub по адресу fruit-pattern.html (исходный код.)
В этом примере элемент принимает одно из четырёх возможных значений: строку "banana", "Banana", "cherry", или "Cherry". Регулярные выражения чувствительны к регистру, но с помощью шаблона "Aa", вложенного в квадратные скобки, мы сделали поддержку написания слова как с большой, так и с маленькой буквы.
Подставьте в атрибут pattern приведённые выше примеры регулярных выражений, и посмотрите, как это повлияет на валидацию введённого в поле значения. Попробуйте написать свои шаблоны проверки и посмотрите, что получится. По возможности, делайте их связанными с фруктами, чтобы примеры имели смысл.
Если не пустое значение элемента не соответствует шаблону регулярного выражения, input будет соответствовать псевдоклассу :invalid .
Примечание: Некоторым типам элементов для валидации с помощью регулярного выражения не требуется атрибут pattern . Например, поле с типом email валидирует значение по шаблону одного email-адреса или, если присутствует атрибут multiple , шаблону списка email-адресов, разделённых запятыми.
Примечание: Элемент
(en-US) не поддерживает атрибут pattern .
Ограничение длины вводимых значений
Можно ограничить максимально допустимое количество символов для текстовых полей или
(en-US) используя атрибуты minlength и maxlength . Поле будет не валидным, если количество символов его содержимого будет меньше minlength или больше maxlength .
Зачастую браузеры не позволяют пользователям вводить в текстовое поле значение, длина которого превышает максимально допустимую. Можно существенно повысить удобство использования, если помимо ограничения в атрибуте maxlength добавить доступный индикатор, отображающий текущее и максимально допустимое количество символов, что даст пользователю возможность уместить содержимое в заданные рамки. Хорошим примером является окно написания твита в Twitter. Для реализации такого функционала можно использовать JavaScript, включая решения, использующие maxlength .
Ограничение допустимых значений
В полях, предназначеннх для ввода чисел (например, ), диапазон допустимых значений можно определить с помощью атрибутов min и max . Если поле содержит значение за пределами данного диапазона, оно будет не валидным.
Давайте рассмотрим другой пример. Создайте новую копию файла fruit-start.html.
Содержимое элемента замените на:
- Здесь мы в полю с типом text атрибутам minlength и maxlength , задали одинаковое значение 6, что соответствует количеству символов в словах banana и cherry.
- В поле с типом number атрибуту min мы задали значение 1, а атрибуту max значение 10. При вводе чисел за пределами данного диапазона, поле будет становиться не валидным; с помощью стрелок увеличения/уменьшения пользователи не смогут выйти за границы диапазона. Текущее поле не является обязательным для заполнения, поэтому даже после очистки будет оставаться валидным.
Примечание: Рабочий пример можно найти на GitHub по адресу fruit-length.html (исходный код.)
Примечание: (и другие типы, такие как range и date ) могут также принимать атрибут step , который задаёт шаг увеличения или уменьшения значения при использовании кнопок вверх и вниз. В примере выше мы явно не указывали атрибут step , поэтому он получает значение по умолчанию, равное 1 . Это значит, что дробные числа, такие как 3.2, будут не валидными.
Полный пример
Ниже представлен полный пример, демонстрирующий использование встроенного функционала валидации. Сначала немного HTML:
И немного CSS для стилизации HTML:
В статье Атрибуты валидации можно найти полный список атрибутов, которые можно использовать для ограничения допустимых значений ввода и типов полей input , которые их поддерживают.
Примечание: Рабочий пример можно найти на GitHub по адресу full-example.html (исходный код.)
Валидация форм с помощью JavaScript
Constraint Validation API
Большинство браузеров поддерживают Constraint Validation API, который состоит из набора свойств и методов, доступных на DOM-интерфейсах следующих элементов форм:
- HTMLButtonElement (представляет элемент )
- HTMLFieldSetElement (представляет элемент )
- HTMLInputElement (представляет элемент )
- HTMLOutputElement (представляет элемент )
- HTMLSelectElement (представляет элемент )
- HTMLTextAreaElement (представляет элемент
Для перечисленных выше элементов Constraint Validation API делает доступными следующие свойства.
Также для перечисленных выше элементов Constraint Validation API делает доступными следующие методы.
Начнём с простого HTML (Не стесняйтесь поместить это в пустой HTML-файл. Вы можете взять за основу свежую копию fruit-start.html, если хотите):
Добавьте на страницу следующий JavaScript:
Здесь мы сохраняем ссылку на поле email, а затем добавляем к нему обработчик события, который запускает код обработчика каждый раз, когда в поле меняется значение.
Если свойство validity.typeMismatch возвращает false , мы вызываем метод setCustomValidity() с пустой строкой. Это делает поле валидным, поэтому форма может быть успешно отправлена.
Попробовать пример можно ниже:
Примечание:: Данный пример можно найти на GitHub по адресу custom-error-message.html (отдельно можно найти исходный код.)
Более подробный пример
Теперь, когда мы разобрали простой пример, давайте посмотрим, как можно использовать данный API для создания более сложной валидацию.
Во-первых, HTML. Опять же, не стесняйтесь писать его вместе с нами:
Эта простая форма использует атрибут novalidate , который отключает автоматическую валидацию браузером; это позволяет нашему скрипту взять управление валидацией на себя. Однако, это не отменяет поддержку Constraint Validation API или псевдоклассов, таких как :valid или ему подобных. Это значит, что хотя браузер автоматически и не проверяет валидность формы перед отправкой данных, вы можете сделать это самостоятельно и соответствующим образом стилизовать форму.
Перейдём к базовому CSS, чтобы немного улучшить внешний вид формы и обеспечить визуальную обратную связь при введении не валидных данных:
Теперь давайте рассмотрим JavaScript, который реализует кастомную валидацию.
Комментарии объясняют логику хорошо, но кратко:
Примечание: Рабочий пример можно найти на GitHub по адресу detailed-custom-validation.html (отдельно можно найти исходный код.)
Constraint Validation API явяется мощным инструментом валидации форм, позволяющим получить контроль над пользовательским интерфейсом, существенно превосходящий возможности HTML и CSS.
Примечание: Для получения дополнительной информации смотрите руководства Constraint validation guide и Constraint Validation API.
Проверка форм без встроенного API
В некоторых случаях, например, при необходимости поддержки устаревших браузеров или кастомных элементов формы, вы не сможете или не захотите использовать Constraint Validation API. Вы по-прежнему сможете использовать JavaScript для валидации форм, но для этого всё нужно будет писать самостоятельно.
Для создания своего валидатора формы, задайте себе несколько вопросов:
- SmashingMagazine: Form-Field Validation: The Errors-Only Approach
- SmashingMagazine: Web Form Validation: Best Practices and Tutorials
- WebFX: 10 Tips for Optimizing Web Form Submission Usability
- A List Apart: Inline Validation in Web Forms
Пример без использования Constraint Validation API
Чтобы проиллюстрировать это дальше приводится упрощённая версия предыдущего примера, которая работает с устаревшими браузерами.
HTML почти тот такой же; мы только удалили функционал валидации HTML5.
CSS также не требует особых изменений; мы только заменили CSS-псевдокласс :invalid на реальный класс и не использовали селектор по атрибутам, так как он не работает в Internet Explorer 6.
Существенно изменился только JavaScript-код, который теперь должен выполнять гораздо больше работы.
Результат выглядит следующим образом:
Как вы можете видеть, сделать собственную валидацию не так уж и сложно. Сложность состоит лишь в том, чтобы сделать его кроссплатформенным и работающим с любой формой, которую можно создать. Для проверки формы доступно множество библиотек, например Validate.js.
Проверьте свои навыки!
Вы дошли до конца этой статьи, но можете ли вы вспомнить самую важную информацию? Вы можете найти дополнительные тесты, чтобы убедиться, что вы сохранили эту информацию, прежде чем двигаться дальше — Test your skills: Form validation.
Заключение
После того, как вы убедились, что форма заполнена правильно, ее можно отправлять. Дальше мы рассмотрим отправку данных формы.
В документации указано, что исследования по валидации процесса, должны способствовать надлежащей производственной практике; их следует проводить в соответствии с установленными методиками. Результаты и выводы должны быть запротоколированы. Если вводят новую производственную рецептуру или способ изготовления для многих лекарственных средства, то должны быть осуществлены действия, демонстрирующие их пригодность для серийного производства; должно быть доказано, что при использовании специфицированных веществ и оборудования установлен процесс позволяет постоянно получать продукцию требуемого качества. Существенные изменения производственного процесса с учетом любых изменений оборудования или веществ и материалов, которые могут повлиять на качество продукции и / или воспроизводимость процесса изготовления многих лекарственных средств, должны пройти схему валидации. Процессы и процедуры следует подвергать периодической критической ревалидации, чтобы гарантировать, что они остаются способными давать ожидаемые результаты.
Различают следующие виды валидации:
- Валидизация процесса
- Валидизация очистки, ревалидации
Валидация процесса - PV (process validation) - документированное подтверждение того, что процесс, который осуществляется в пределах установленных параметров, может проводиться эффективно с воспроизводимыми результатами и позволяет получить многие лекарственные средства, которые соответствует установленным требованиям и характеристикам качества. Валидацию аналитических методик следует рассматривать как разновидность валидации процесса (см. Валидация аналитических методик).
Валидация процесса может быть перспективной, сопутствующей и ретроспективной. Перспективная валидация (prospective validation) проводится до начала серийного производства продукции, предназначенной для продажи.
Сопутствующая валидация (concurrent validation) - в ходе серийного производства продукции, предназначенной для продажи. Ретроспективная валидация (retrospective validation) - Валидация процесса по многим лекарственным средствам, которые уже размещены на рынке, на основании собранных данных о производстве, испытаниях и контроле серий.
Валидация очистки (cleaning validation) - документированное подтверждение того, что утвержденная процедура очистки будет обеспечивать такую чистоту оборудования, которое необходимо для производства ЛП. Ревалидации (revalidation), или повторная валидация процесса, гарантирует, что изменения процесса / оборудования, внесенные в соответствии с процедурами контроля изменений, не оказали неблагоприятного влияния на характеристики процесса и качество препарата.
Она бывает двух типов: ревалидация после изменений и периодическая.
Согласно требованиям GMP производители должны определить, работа по схеме валидации необходима для подтверждения контроля критических аспектов конкретных операций. Критический процесс - это процесс, который может вызвать изменения качества фармацевтического препарата. Критическая стадия - это стадия процесса, влияющего на качество, эффективность или стабильность продукта. Критические стадии определяют на основании тщательного изучения процессов и операций.
Стадия процесса считается критической, если: это необратимый технологический процесс, в ходе которого формируются параметры качества продукта, неизменные со временем; происходит выделение загрязнения продукта (контаминанты) с целью обязательного очистки или стерилизации; возможна контаминация продукта вследствие воздействия окружающей среды или других факторов. Изменения, которые вносятся в технические средства, оборудование и процессы, которые могут повлиять на качество продукции, должны обязательно пройти форму валидации. Для определения объема проведения валидации следует использовать подход, основанный на оценке рисков. Документация по схеме валидации состоит из следующих частей. Ключевые элементы программы валидизации следует четко определить и задокументировать в основном плане схемы валидации. валидационные мастер-план (Validation Master Plan) - главный документ всей валидационной программы, который содержит сведения об объеме работ по валидации (финансы, время, персонал, оборудование), распределяет ответственность и полномочия, отмечает, объекты подлежат валидизации; определяет характер и масштабы испытаний каждого объекта, в общих чеиртах описывает протоколы и методики испытаний многих лекарственных средств, которые необходимо соблюдать при исполнении схемы валидации, описывает функциональные обязанности участников процесса валидизации, определяет обязанности по составлению отчетов и требования к документированию выполненной работы и исследования. В валидационных протоколах по отдельным операциям отмечают критические стадии конкретного процесса и критерии приемлемости, вид валидации, описание действий, количество производственных циклов, данные измерений. В валидационных отчетах по отдельным операциям делают ссылки на протоколы валидации. конкретного процесса, обобщают полученные результаты измерений, объясняют найдены отклонения, приводят рекомендации по их исправлению и улучшению. Сводный валидационные отчет содержит все данные, результаты и оценку всей программы и формы валидации, а также выводы и предложения по совершенствованию.
Результаты, как правило, предоставляют в виде визуализированных отчетов. После завершения схемы валидации или квалификации с удовлетворительными результатами следует оформить официальное письменное разрешение для перехода к следующей стадии квалификации. Согласно установки 42-01-2001 (п. 5.4.) Необходимо иметь письменные методики и протоколы выполненных действий или сделанных выводов с валидацией, принадлежащих к ним. Для важнейшего или критического оборудования следует вести журналы, при необходимости протоколируя в них все работы и форму валидации, калибровки, технического обслуживания, очистки и ремонта с указанием даты и лиц, выполнивших эти работы. В журналах в хронологическом порядке также следует регистрировать использования важнейшего или критического оборудования.
План валидации процессов производства многих лекарственных средств должен охватить все критические элементы производственного процесса от его разработки до окончательной валидации промышленного производства (для трех промышленных серий). Эту информацию следует включать в регистрационное досье, предоставляя результаты исследований по разработке, оценке и оптимизации процесса, полученные на лабораторных или опытно-промышленных сериях, с данными, полученными на промышленных сериях (при их наличии), или предоставить соответствующую схему валидации процесса, которая будет применена при форме валидации процесса производства промышленных серий многих лекарственных средств. Эта схема должна составлять часть регистрационного досье; в ней должны быть описаны официальные исследования, запланированные для серий промышленного масштаба (как правило, трех), которые следует проводить к выводу многих лекарственных средств на рынок. Связь между исследованиями по разработке и данными с валидацией технологического процесса прежде всего заключается в том, что критические характеристики многих лекарственных средств, которые определены на стадии разработки (степень растворения действующего вещества, содержание примесей и т.п.), следует использовать для установления и оценки критических параметров процесса производства многих лекарственных средств, которые необходимо проверять и которыми следует управлять с целью обеспечения воспроизводимости от серии к серии. Для определения этих критических параметров может понадобиться испытания процесса путем умышленных изменений для доказательства его устойчивости и определение границ допустимых отклонений. Такие параметры будут различными в зависимости от природы препарата, состав и предложенного типа производства.
Лабораторные серии производят на начальных этапах разработки и исследования; эти серии могут быть очень маленького размера (например., в 100-1000 раз меньше промышленные), их используют для многих целей, например. для разработки состава и выбора упаковки, для клинических и / или доклинических исследований. Опытно-промышленные серии могут использовать при разработке процесса или на этапе его оптимизации. Их размер должен составлять не менее 10% размера промышленной, то есть коэффициент умножения при масштабировании не должен превышать 10 Промышленные серии имеют размер, установленный для серий при полномасштабном производстве препаратов, находится на рынке. Данные этих серий не всегда могут быть в наличии в регистрации многих лекарственных средств. Если данные для промышленных серий отсутствуют или не предоставлены на момент подачи регистрационного досье, то можно использовать двухстадийный подход. На первом этапе следует тщательно оценить и охарактеризовать критические параметры процесса на лабораторных или опытно-промышленных сериях; после такой оценки следует разработать программу валидации на сериях промышленного масштаба. Для этой программы должна быть составлена схема валидации процесса. На втором этапе проводят валидацию процесса на промышленных сериях. Информация, полученная при этих исследованиях, после регистрации ЛП должна быть доступна для проверки контролирующим уполномоченным органом.
Схема валидации процесса в регистрационном досье должно содержать следующую информацию:
- краткое описание процесса с указанием критических стадий или критических параметров, которые необходимо контролировать в ходе валидации;
- спецификацию на готовую продукцию;
- подробные сведения о аналитические методы (ссылка на соответствующую часть регистрационного досье) контроль, предлагается в процессе производства, и критерии приемлемости;
- дополнительные испытания, которые должны быть проведены (с предлагаемыми критериями приемлемости и сведениями с валидацией аналитических методик, при необходимости);
- план отбора проб: где, когда и как отбирать пробы;
- подробные сведения о способах протоколирования и оценки результатов;
- график проведения.
Полезно знать
© VetConsult+, 2015. Все права защищены. Использование любых материалов, размещённых на сайте, разрешается при условии ссылки на ресурс. При копировании либо частичном использовании материалов со страниц сайта обязательно размещать прямую открытую для поисковых систем гиперссылку, расположенную в подзаголовке или в первом абзаце статьи.
- квалификация проекта (DQ): документальное подтверждение того, что проект производственных помещений, оборудования/ систем является пригодным для применения по назначению.
- квалификация монтажа (IQ): документальное подтверждение того, что монтаж помещений, оборудования/систем выполнен в соответствии с утвержденным проектом.
- квалификация функционирования (OQ): документальное подтверждение того, что помещения, системы и оборудование функционируют в соответствии со своим предназначением во всех предусмотренных режимах работы.
- квалификация эксплуатации(PQ): документальное подтверждение того, что помещения, системы и оборудование при совместном использовании работают эффективно и с воспроизводимыми показателями в соответствии с установленными требованиями и характеристиками процесса.
Валидация требует детальной подготовки и планирования различных этапов и стадий. Согласно требованиям GMP, производители должны определить, какая работа по валидации необходима для подтверждения контроля критических параметров процессов. Для определения области проведения и объема валидации следует использовать подход, основанный на оценке рисков. Всю деятельность по валидации исходит из Общей политики валидации производителя и оформляется документально.
- валидацию технологических процессов;
- валидацию процедур очистки;
- валидацию аналитических методов;
- валидацию контрольных испытаний в процессе производства;
- валидацию компьютеризированных систем и др.
- функционирует в пределах установленных параметров;
- обеспечивает эффективное производство продукции с воспроизводимыми результатами;
- соответствует предварительно заданным спецификациям и показателям качества.
- перспективная валидация (Prospective Validation) ;
- сопутствующая валидация (Concurrent Validation);
- ретроспективная валидация (Retrospective Validation);
- Повторная валидация (Ревалидация) (Re-validation).
Перспективная валидация (Prospective Validation) - валидация, выполняемая до начала серийного производства продукции, предназначенной для реализации. Перспективную валидацию рекомендуется выполнять для всех процессов, связанных с производством продукции.
Сопутствующая валидация (Сoncurrent Validation) - валидация, которая проводится в ходе серийного производства продукции, предназначенной для продажи.
Ретроспективная валидация (Retrospective Validation) - аттестация серийного процесса производства реализуемого продукта, основанная на полученных данных о производстве и контроле серий продукции.
Повторная валидация (ревалидация) (Re-validation) - повторение первичной валидации процесса для обеспечения гарантии того, что изменения в процессе (оборудовании), выполненные в соответствии с процедурой контроля изменений, не ухудшают характеристики процесса и качество продукции.
- в плановом порядке в сроки, устанавливаемые предприятием в Отчете о проведении валидации.
- в случаях изменения документации или условий производства, которые могут повлиять на качество продукта.
Объем валидационных работ определяется предприятием исходя из внесенных изменений. Результаты валидации процесса подлежат документальному оформлению.
- Валидационный мастер-план (Validation Master Plan - VMP);
- Валидационное досье (отдельно для каждого объекта):
- Спецификация требований пользователя (URS, User Requirement Specification);
- Протокол оценки рисков;
- Программа валидационных работ;
- Протокол/Отчет валидационных работ;
- Программа (плановой, внеплановой) ревалидации (повторной валидации).
![]()
По завершению всех этапов валидации составляется финальный отчет валидации, в котором, в случае успешного проведения процесса, будет указано, что процессы готовы к использованию и соответствует стандартам.
Таким образом, посредством валидации производитель получает документальное свидетельство того, что процессы (оборудование) соответствуют заданным требованиям, а это существенно снижает риск возникновения ошибок, затрат рабочего времени на их выявление и исправление, и внесение соответствующих изменений.
1.1. Настоящая инструкция определяет порядок действий для выбора, валидации и верификации методики выполнения измерений в испытательной лаборатории (центре) для решения конкретной задачи заказчика, который ее приобретает.
1.2. Инструкция предназначена для сотрудников испытательной лаборатории (центра).
2. Нормативные ссылки
2.1. ГОСТ ISO/IEC 17025-2019 "Общие требования к компетентности испытательных и калибровочных лабораторий";
2.2. ГОСТ 8.010-2013 "Государственная система обеспечения единства измерений (ГСИ). Методики выполнения измерений. Основные положения";
2.3. РМГ 76-2014 "ГСИ. Внутренний контроль качества результатов количественного химического анализа".
3. Определения
Методика выполнения измерений – установленная логическая последовательность операций и правил при измерении, выполнение которых обеспечивает получение результатов измерений в соответствии с принятым методом измерений.
Верификация методики – предоставление объективных свидетельств того, что данная методика соответствует установленным требованиям.
Валидация методики – верификация, при которой установленные требования связаны с предполагаемым использованием методики.
4. Сокращения и обозначения
ВЛКК – внутрилабораторный контроль качества
ИЛ – испытательная лаборатория
ИЛЦ – испытательный лабораторный центр
КХА – количественный химический анализ
МВИ – методика выполнения измерений
МСИ – межлабораторные сличительные испытания5. Процедура
5.1. Общие положения
5.1.1. Выбор МВИ необходим для получения качественного результата исследования, отвечающего потребности заказчика.
5.1.2. В ИЛ (ИЛЦ) для выполнения заявок пользуются аттестованными и стандартизированными МВИ. Сотрудники ИЛ (ИЛЦ) не разрабатывают (не валидируют) методики измерений.
5.1.3. МВИ, внедренные в ИЛ (ИЛЦ), тщательно подобраны для выполнения заявок заказчика, задач и функций ИЛ (ИЛЦ).
5.1.4. Методики и сопутствующие нормативные документы (инструкции, стандарты, руководства по эксплуатации и справочные данные), имеющие отношение к лабораторной деятельности, поддерживаются в актуальном состоянии и легко доступны для персонала ИЛ (ИЛЦ).
5.1.5. Внедрение МВИ подтверждается "Актом внедрения измерения" А-NN-ГГ или "Актом внедрения испытания" А-NN-ГГ.
5.1.6. За своевременное и качественное внедрение МВИ подразделения ИЛ (ИЛЦ) отвечает руководитель соответствующего подразделения ИЛ (ИЛЦ).
5.1.7. Верификацией методик измерений занимается исполнитель (сотрудник ИЛ (ИЛЦ)), уполномоченный руководителем подразделения ИЛ (ИЛЦ) на внедрение методики измерений в свою практику. В обязанности уполномоченного исполнителя входит сбор доказательств того, что методика измерений реализуется согласно установленным для нее требованиям.
5.1.8. В случае, когда заказчик не определяет МВИ, руководитель ИЛ (ИЛЦ) дает задание руководителю подразделения ИЛ (ИЛЦ) выбрать методику, отвечающую контролируемым требованиям, самостоятельно и информирует об этом заказчика. Задание оформляется в виде служебной записки или направления.
5.1.9. ИЛ (ИЛЦ) обеспечивает применение последней действующей редакции методики за исключением случаев нецелесообразности или невозможности.
5.2. Требования к выбору и внедрению МВИ
5.2.1. Доверие к выбранной МВИ выражается в виде определенных требований, которым должна соответствовать методика измерений.
5.2.2. Требования к выбору МВИ устанавливает заказчик в "Направлении в ИЛ (ИЛЦ)" Л-NN-ГГ и руководитель подразделения ИЛ (ИЛЦ) через рабочие характеристики методики, оформляя "Карточку требований МВИ" Л-NN-ГГ.
5.2.3. Перечень рабочих характеристик методики для оформления карточки требований МВИ:
- область применения;
- определяемые показатели;
- диапазон измерений;
- предел количественного определения;
- метрологические характеристики;
- показатели точности измерений (прецизионность и правильность)
- условия эксплуатации, ТО оборудования;
- расходные материалы;
- квалификация сотрудников;
- условия проведения измерений.
5.2.4. В зависимости от назначения и области применения методики могут устанавливаться требования ко всем или к некоторым рабочим характеристикам.
5.2.5. Если методика измерений предназначена для измерения величин (количественные измерения), то важными с точки зрения метрологии, являются именно показатели точности.
5.2.6. Если методика измерений используется при малых значениях измеряемой величины (например, определение микропримесей), то приоритетной характеристикой является предел обнаружения (подтверждение).
5.2.7. Для методик количественного измерения требуется оценить большее количество рабочих характеристик при меньшем объеме экспериментов.
5.2.8. Для методик качественного анализа, особенно в случае использования дихотомической шкалы (обнаружено/не обнаружено), требуется оценить меньшее количество рабочих характеристик при большем объеме экспериментов (поскольку получаемая информация менее информативна, чем результат измерения).
5.2.9. Выполнение требований к МВИ подтверждают исполнители (сотрудники ИЛ (ИЛЦ)) в ходе верификации методик измерений (внедрение МВИ) в подразделении ИЛ (ИЛЦ).
5.2.10. Верификация методик КХА и количественных измерений сводиться к подтверждению техническими записями исполнителя соответствия рабочих характеристик оборудования и окружающей среды установленным требованиям (показателям точности) МВИ ("Акт внедрения методики выполнения измерений" А-NN-ГГ).
5.2.11. Информация, полученная в подразделении ИЛ (ИЛЦ) при внедрении методики измерений, используется при контроле качества и оценивании неопределенности измерений.
5.2.12. Результаты исследований исполнителей при внедрении МВИ оценивает руководитель подразделения ИЛ (ИЛЦ). При соответствующем качестве результатов при внедрении МВИ составляется Акт внедрения методики выполнения измерений руководителем подразделения ИЛ (ИЛЦ) и утверждается руководителем ИЛ (ИЛЦ).
5.3. Проведение контроля качества результатов
5.3.1. Руководитель ИЛ (ИЛЦ) распоряжением назначает ответственных за контроль качества результатов в подразделениях ИЛ (ИЛЦ) из числа сотрудников, выбранных руководителями подразделений.
5.3.2. Проверку результатов исследований исполнителей, достигнутых во время лабораторной деятельности, выполняет ответственный за контроль качества результатов при выполнении плана ВЛКК.
5.3.3. Для подтверждения качества результатов измерений, произведенных по внедренным МВИ в области деятельности ИЛ (ИЛЦ), проводится предупредительный, внутренний и внешний контроль.
5.3.4. Предупредительный контроль выполняют в подразделении ИЛ (ИЛЦ) исполнители согласно "Перечню контролируемых условий" Л-NN-ГГ под контролем руководителей подразделений ИЛ (ИЛЦ).
5.3.5. Внутренний контроль (собственно ВЛКК) выполняют исполнители согласно "Плану ВЛКК измерений/испытаний" П-NN-ГГ. Внутренний контроль организует и проводит ответственный за контроль качества результатов, проверяет выполнение — руководитель подразделений ИЛ (ИЛЦ), контролирует – менеджер по качеству.
5.3.6. Ответственные за контроль качества результатов формируют в конце года План ВЛКК измерений/испытаний на следующий год и выполняют планирование, организацию и проведение внутрилабораторного контроля.
5.3.7. Ответственные за контроль качества результатов в лабораториях, выполняющих КХА и качественный анализ, контролируют качество результатов измерений и рассчитывают характеристику неопределенности МВИ, выполняя требования в части РМГ 76 из Приложений И, К, Л, Н.
5.3.8. Контроль качества результатов измерений включает оперативный и статистический контроль для количественных МВИ. Контроль качества результатов испытаний включает контроль условий проведения испытаний для качественных анализов (номинальные свойства анализируемых объектов), особенно где используется дихотомическая шкала (обнаружено/не обнаружено).
5.3.9. Внешний контроль выполняют исполнители согласно "Плану МСИ лаборатории" П-NN-ГГ под контролем руководителя подразделения ИЛ (ИЛЦ).
5.3.10. Руководители подразделений ИЛ (ИЛЦ) до 20 сентября текущего года определяют необходимые средства для проведения МСИ и составляют "План проведения МСИ ИЛ (ИЛЦ) на 20__ год" П-NN-ГГ на следующий год (заключают договоры с провайдерами).
5.4. Показатели результативности контроля качества результатов
5.4.1. В конце отчетного года до 20 декабря ответственные за контроль качества результатов лаборатории готовят документы для проверки менеджером по качеству и внутреннего аудита, подтверждающие выполнение Плана ВЛКК измерений/испытаний.
5.4.2. Ответственные за контроль качества результатов лаборатории составляют План ВЛКК измерений/испытаний на следующий год в двух экземплярах, согласовывают с менеджером по качеству, подписывают у руководителя подразделения ИЛ (ИЛЦ) и утверждают у руководителя ИЛ (ИЛЦ).
5.4.3. Утвержденный План ВЛКК измерений/испытаний хранится в местах, установленных Номенклатурой дел, у менеджера по качеству для контроля и у руководителей подразделений ИЛ (ИЛЦ) для проверки выполнения в течение года.
5.4.4. При успешном выполнении Перечня контролируемых условий, Плана ВЛКК измерений/испытаний, Плана МСИ лаборатории руководитель подразделения ИЛ (ИЛЦ) и ответственный за контроль качества упрощают контроль качества результатов анализа в Плане ВЛКК измерений/испытаний на следующий год.
5.4.5. В случае выявления нарушений требований МВИ при выполнении Перечня контролируемых условий, Плана ВЛКК измерений/испытаний, Плана МСИ лаборатории ответственный за контроль качества результатов информирует руководителя подразделения ИЛ (ИЛЦ), который предпринимает действия согласно процедуре "Корректирующие действия".
5.4.6. При выявлении и устранении несоответствия ответственный за контроль качества результатов и руководитель подразделения ИЛ (ИЛЦ) повышают контроль данного отклонения и контроль МВИ в течение следующего года в Плане ВЛКК измерений/испытаний.
5.4.7. Если в течение года несоответствие не повторилось, руководитель подразделения ИЛ (ИЛЦ) упрощает контроль результатов анализа или условий проверки данного МВИ, переводит фактор контроля в предупреждение согласно процедуре "Управление рисками" и, при необходимости, вводит в Перечень контролируемых условий.
СОДЕРЖАНИЕ
Определения
Верификация и валидация - это не одно и то же, хотя их часто путают. Бем лаконично выразил разницу как
- Проверка: правильно ли мы создаем продукт?
- Валидация: создаем ли мы правильный продукт?
Примечание. Проверка начинается перед проверкой, а затем они выполняются параллельно, пока не будет выпущен программный продукт.
Проверка программного обеспечения
Это означало бы проверить соответствие спецификациям, запустив программное обеспечение, но это невозможно (например, как кто-нибудь может узнать, правильно ли реализованы архитектура / дизайн / и т.д., при запуске программного обеспечения?). Только просмотрев связанные с ним артефакты, кто-то может сделать вывод, удовлетворены ли спецификации.
Проверка артефакта или спецификации
Выходные данные каждой стадии процесса разработки программного обеспечения также могут быть предметом проверки при проверке на соответствие входной спецификации (см. Определение CMMI ниже).
Примеры проверки артефактов:
- Соответствие проектной спецификации спецификации требований: правильно ли реализованы спецификации функциональных и нефункциональных требований в архитектурном проекте, детальном проекте и спецификациях логической модели базы данных?
- Об артефактах построения в соответствии со спецификацией проекта: правильно ли исходный код, пользовательские интерфейсы и физическая модель базы данных реализуют спецификацию проекта?
Проверка программного обеспечения
Валидация программного обеспечения проверяет, что программный продукт удовлетворяет или подходит для предполагаемого использования (проверка высокого уровня), т. Е. Программное обеспечение соответствует требованиям пользователя, а не как артефакты спецификации или как потребности тех, кто будет использовать программное обеспечение только; но, как потребности всех заинтересованных сторон (таких как пользователи, операторы, администраторы, менеджеры, инвесторы и т. д.). Существует два способа проверки программного обеспечения: внутренний и внешний. Во время внутренней проверки программного обеспечения предполагается, что цели заинтересованных сторон были правильно поняты и что они были точно и исчерпывающе выражены в артефактах требований. Если программное обеспечение соответствует спецификации требований, оно прошло внутреннюю валидацию. Внешняя проверка происходит, когда она выполняется путем опроса заинтересованных сторон, соответствует ли программное обеспечение их потребностям. Различные методологии разработки программного обеспечения требуют разных уровней участия и обратной связи со стороны пользователей и заинтересованных сторон; Итак, внешняя проверка может быть дискретным или непрерывным событием. Успешная окончательная внешняя проверка происходит, когда все заинтересованные стороны принимают программный продукт и заявляют, что он удовлетворяет их потребности. Такая окончательная внешняя проверка требует использования приемочного испытания, которое является динамическим .
Тем не менее, также можно выполнить внутренние статические тесты, чтобы выяснить, соответствует ли программное обеспечение спецификации требований, но это попадает в сферу статической проверки, поскольку программное обеспечение не работает.
Проверка артефакта или спецификации
Требования должны быть проверены до того, как программный продукт в целом будет готов (процесс каскадной разработки требует, чтобы они были полностью определены до начала проектирования; но итеративные процессы разработки не требуют этого и позволяют их непрерывное улучшение).
Примеры проверки артефактов:
Проверка и проверка
- Проверка программного обеспечения: процесс оценки программного обеспечения во время или в конце процесса разработки, чтобы определить, удовлетворяет ли оно указанным требованиям. [IEEE-STD-610]
- Проверка программного обеспечения: процесс оценки программного обеспечения для определения того, удовлетворяют ли продукты данной фазы разработки условиям, установленным в начале этой фазы. [IEEE-STD-610]
Валидацию в процессе разработки программного обеспечения можно рассматривать как форму валидации Спецификации требований пользователя; и что в конце процесса разработки это эквивалентно внутренней и / или внешней проверке программного обеспечения. Верификация с точки зрения CMMI, очевидно, носит артефактный характер.
В этой статье используется строгое или узкое определение верификации.
С точки зрения тестирования:
Связанные понятия
И верификация, и валидация связаны с концепциями качества и обеспечения качества программного обеспечения . Сами по себе проверка и валидация не гарантируют качества программного обеспечения; требуется планирование, отслеживаемость , управление конфигурацией и другие аспекты разработки программного обеспечения.
В сообществе моделирования и моделирования (M&S) определения верификации, валидации и аккредитации аналогичны:
- M&S Verification - это процесс определения того, что компьютерная модель , имитация или объединение моделей и реализаций имитаций и связанные с ними данные точно представляют концептуальное описание и спецификации разработчика.
- Проверка M&S - это процесс определения степени, в которой модель, имитация или объединение моделей и имитаций и связанных с ними данных являются точными представлениями реального мира с точки зрения предполагаемого использования.
- Аккредитация - это официальное свидетельство того, что модель или симуляция приемлемы для использования в определенных целях.
Определение валидации модели и модели фокусируется на точности, с которой модель модели и модели представляет предполагаемое использование в реальном мире. Определение степени точности модели и моделирования требуется, поскольку все модели и модели являются приближениями к реальности, и обычно очень важно определить, является ли степень приближения приемлемой для предполагаемого использования. Это контрастирует с проверкой программного обеспечения.
V&V методы
Формальный
В критически важных программных системах могут использоваться формальные методы для обеспечения правильной работы системы. Однако эти формальные методы могут оказаться дорогостоящими и составляют до 80 процентов от общей стоимости разработки программного обеспечения.
Независимый
Независимая проверка и проверка программного обеспечения (ISVV) нацелена на критически важные для безопасности программные системы и направлена на повышение качества программных продуктов, тем самым снижая риски и затраты на протяжении всего срока службы программного обеспечения. Целью ISVV является обеспечение уверенности в том, что программное обеспечение работает с заданным уровнем уверенности, в пределах его заданных параметров и определенных требований.
Действия ISVV выполняются независимыми инженерными группами, не участвующими в процессе разработки программного обеспечения, для оценки процессов и конечных продуктов. Независимость команды ISVV осуществляется на трех различных уровнях: финансовом, управленческом и техническом.
Результаты и выводы ISVV возвращаются командам разработчиков для исправления и улучшения.
История
ISVV является производным от применения IV&V (независимой проверки и валидации) к программному обеспечению. Раннее приложение ISVV (известное сегодня) восходит к началу 1970-х годов, когда армия США спонсировала первую значительную программу, связанную с IV&V для системы противоракетной обороны Safeguard . Другой пример - программа НАСА IV&V, созданная в 1993 году.
К концу 1970-х годов IV&V быстро стал популярным. Постоянное увеличение сложности, размера и важности программного обеспечения привело к увеличению спроса на IV&V, применяемые к программному обеспечению.
Между тем, IV&V (и ISVV для программных систем) консолидировались и теперь широко используются такими организациями, как Министерство обороны , FAA , NASA и ESA . IV&V упоминается в DO-178B , ISO / IEC 12207 и формализовано в IEEE 1012 .
В ЕКА
Первоначально в 2004–2005 годах европейский консорциум под руководством Европейского космического агентства в составе DNV , Critical Software SA , Terma и CODA SciSys plc создал первую версию руководства, посвященного ISVV, под названием «Руководство ESA по независимой проверке и проверке. "при поддержке других организаций. В этом руководстве описаны методологии, применимые ко всем этапам разработки программного обеспечения в том, что касается ISVV.
В 2008 году Европейское космическое агентство выпустило вторую версию, полученную от многих различных заинтересованных сторон European Space ISVV.
Методология
ISVV обычно состоит из пяти основных фаз, которые могут выполняться последовательно или как результат процесса адаптации.
Планирование
- Планирование деятельности ISVV
- Анализ критичности системы: идентификация критических компонентов с помощью набора действий RAMS ( соотношение цены и качества )
- Выбор подходящих методов и инструментов
Проверка требований
- Проверка на: полноту, правильность, тестируемость
Проверка дизайна
- Адекватность дизайна и соответствие требованиям к программному обеспечению и интерфейсам
- Внутренняя и внешняя согласованность
- Проверка выполнимости и обслуживание
Проверка кода
- Проверка на: полноту, правильность, непротиворечивость
- Анализ метрик кода
- Проверка соответствия стандартам кодирования
Проверка
- Выявление нестабильных компонентов / функций
- Валидация сосредоточена на обработке ошибок: дополнительная (не параллельная) проверка по отношению к той, которая выполняется командой разработчиков.
- Соответствие программным и системным требованиям
- Тестирование черного ящика и тестирование коробки Белые методы
- Методы, основанные на опыте
Нормативно-правовая база
Программное обеспечение часто должно соответствовать нормативным требованиям регулируемых отраслей, которые часто регулируются государственными учреждениями или промышленными административными органами. Например, FDA требует, чтобы версии программного обеспечения и исправления были проверены.
Читайте также: