Обзор проекта (DR/DQ)

На этапе Обзора (проверки) Проекта (DR/DQ - Design Review / Design Qualification) необходимо:

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

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

При проведении Проверки Спецификаций используется следующая процедура:

Модель документации: протокол – отчет
Проверка проводится путем последовательной проверки и заполнения контрольных пунктов с критериями приемлемости в протоколе на основании проверяемых спецификаций.
Все обнаруженные отклонения записываются в раздел протокола «Перечень (Журнал) Отклонений».
Заполненный протокол становится отчетом.
В случае, если отклонений не обнаружено, они устранены, или не являются GxP критичными, Проверка Спецификации считается проведенной успешно.

Спецификации

При движении сверху вниз от высокоуровневых к низкоуровневым спецификациям можно выделить следующие их виды:

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

Спецификация целей в общем случае более детальна и устанавливает, что именно и насколько хорошо должна делать система:

Спецификация целей соответствует уровню системного тестирования в V-модели.
Спецификация целей не только описывает возможности системы, но и задает качественные характеристики ее функционирования.
При разработке спецификации целей за основу берется спецификация требований / URS.
В ходе проверки спецификации целей, помимо прочего, проверяется правильность «трансляции» требований из спецификации требований / спецификации требований пользователя (URS - User Requirements Specification).

В ходе проверки спецификации целей в IT-индустрии принято выделять следующие аспекты:

Возможности (Facility)
Предельные объемы данных (Volume)
Устойчивость к нагрузке (Stress)
Удобство использования (Usability)
Безопасность (Security)
Производительность (Performance)
Использование памяти (Storage)
Конфигурация (Configuration)
Совместимость (Compatibility/Conversion)
Установка (Installation)
Надежность (Reliability)
Восстанавливаемость (Recovery)
Обслуживаемость (Serviceability/Maintenance)
Документированность (Documentation)
Процедуры (Procedure)

Функциональные спецификации дают точное описание способа представления программы пользователям:

Функциональные спецификации соответствуют уровню функционального тестирования в V-модели.
Функциональные спецификации должны содержать полный перечень/описание индивидуальных функций системы и соответствующие элементы пользовательского интерфейса (элементы ввода/вывода).
При разработке функциональных спецификаций за основу берутся спецификации целей и требований / URS.
В ходе проверки функциональных спецификаций, помимо прочего, проверяется правильность «трансляции» требований из спецификаций целей и требований / URS.

Специалисты Tarqvara Pharma Technologies имеют многолетний опыт проведения квалификационных, валидационных и приёмочных мероприятий в фармацевтической индустрии в соответствии с международными, европейскими и национальными нормативными требованиями и стандартами GMP/GxP.

см. также:
Квалификация / валидация / приёмка
Валидация компьютеризированных систем (CSV)
Приёмка (FAT/SAT)
Риск-ориентированный подход