Использование надстройки Inquire при валидации электронных таблиц MS Excel

Данная заметка сделана в развитие переводной статьи по аспектам валидации электронных таблиц.

Говоря о валидации MS Excel не устаю вновь и вновь обращаться к документу EDQM, где показан практический пример по валидации, который является достаточно лаконичным и, вместе с тем, более предметным чем сотни страниц разного рода GAMP-руководств или руководств FDA в части валидации компьютеризированных систем. Более того, в который раз сошлюсь на перевод Антона Мымрикова этого документа, впрочем, не забывая о том, что там этот перевод выполнен для всего контекста компьютеризированных систем – MS Excel – это только частный случай и попутно, приложение 1 к основному документу.

Читати далі →

Поделитесь с коллегами:

Три аспекта валидации электронных таблиц

Валидация электронных таблиц

Валидация электронных таблиц Excel является неотъемлемым навыком специалиста по валидации и очень важно, чтобы они были валидированы также, как и все другие компоненты оборудования. На конференции IVT по вопросам валидации Рауль Сото (Raul Soto), магистр наук, делал доклад под названием «Статистические возможности MS Excel», во время которого привел такое сравнение: пояс Бэтмена имеет такое же отношение к борьбе с преступностью, как Excel к валидации. Оценив презентацию господина Сото и его амбициозную аналогию, редакторы IVT вдохновились написать эту статью, в которой рассмотрены три аспекта валидации электронных таблиц.

Читати далі →

Поделитесь с коллегами:

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

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

    1. Валидация компьютеризированных систем, строго говоря, уместна только тогда, когда та или иная система только разрабатывается. Лучший старт валидации – это на этапе разработки URS. В крайнем случае, на этапе, когда URS утверждена, и разработчик работает над её реализацией.
    2. Собственно практика тестирования в “обычном” ИТ – это уже очень давно не terra incognita – есть и стандарты этому посвященные – IEEE 829, ISO 25051, есть книги – да собственно курсов по QA IT валом и спрос на это сейчас, безотносительно фарма-отрасли, стабильно высок.

Читати далі →

Поделитесь с коллегами:

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

Правила виноделов

  1. Правило четырех исправлений
  2. Чем больше сделаешь сегодня, тем больше завтра исправлять
  3. Поторопишься, разгневаешь бога валидации
  4. Любое шевеление должно быть произведено таким образом дабы избежать шевелений в дальнейшем

Комментарий

  1. Любой документ при любом исходном состоянии должен быть переделан 4 раза. После четвертой правки мы либо приходим к исходной версии документа, либо получаем абсолютную ересь, которую читать не будет никто и никогда.
  2. Вытекает из первого пункта. Главное найти баланс. Чтобы с одной стороны все были уверены в том, что мы в поте лица трудимся с другой стороны избежать лишних шевелений.
  3. Иррациональный момент. Успешная валидация определяется сумой двух компонентов: Фактический валидационный статус объекта, отсутствие косяков у валидаторов. Если что либо делается впервые, либо не по стандарту, либо включает в себя наладочные работы, то вероятность успешной валидации зависит только от Него.
  4. Это с годами приходит. Забейте в youtube «Порожняк фитиль»

Читати далі →

Поделитесь с коллегами:

Облачные решения

Хотелось бы в режиме «фьюжн» обсудить возможность применения облачных решений в фармотрасли. Конечно, сейчас облака можно настроить самостоятельно и лично у меня есть опыт использования, например, GoogleDrive в качестве системы баг-трэкинга при тестировании нового ПО или Dropbox при необходимости работы с одним файлом-таблицей из разных точек доступа (с синхронизацией через клиент). Удобно, т.к. при запуске и тестировании нового ПО мы тщательно вместо обычных блокнотов, тетрадей, черновиков или в лучшем случае разрозненных файлов разных пользователей (потому как ПО мультипользовательское, стандартное с клиент-серверной архитектурой, тестовых сценариев одновременно реализуется множество) вписываем все баги в заранее разработанную форму, где багу присваивается номер, дается краткое и развёрнутое описание, приоритет.

Читати далі →

Поделитесь с коллегами: