Ранее на данном ресурсе неоднократно предпринимались попытки поговорить о валидации компьютеризированных систем, затрагивая как теорию, так и практику. Однако зачастую из фокуса рассмотрения авторов исчезало два простых обстоятельства:
- Валидация компьютеризированных систем, строго говоря, уместна только тогда, когда та или иная система только разрабатывается. Лучший старт валидации – это на этапе разработки URS. В крайнем случае, на этапе, когда URS утверждена, и разработчик работает над её реализацией.
- Собственно практика тестирования в “обычном” ИТ – это уже очень давно не terra incognita – есть и стандарты этому посвященные – IEEE 829, ISO 25051, есть книги – да собственно курсов по QA IT валом и спрос на это сейчас, безотносительно фарма-отрасли, стабильно высок.
По первой позиции. Не станем “строго сдвигать брови” аки суровый инспектор-буквоед, который привязан к тексту Приложения 11 GMP или опросникам PIC/S, и взглянем немного шире. Для чего, собственно говоря, вообще задумана автоматизация тех или иных бизнес-процессов? Как правило, для того, чтобы их ускорить и повысить их надежность, исключая человеческий фактор. Если мы “сообразили” даже какое-то простенькое приложение, что называется “на коленке” – какой побудительный мотив возникает сразу же? Правильно! Пощелкать самостоятельно, отработать различные сценарии. Тут уже нужен пример. Если мы разработали простенький калькуляционный лист MS Excel, позволяющий, например, оценить однородность массы таблеток, мы сначала сами заполним значение 20 масс, удостоверимся что ни одно индивидуальное значение не отклоняется от среднего более, чем удвоенный критерий (по фармакопеям, это, как правило, 5 % для масс свыше 250 мг, 7,5 % – в диапазоне от 80 до 250 мг и 10 % для масс менее 80 мг), и что выше критерия из всего массива данных не более двух значений индивидуальных масс. Мы “подбросим” соответствующие массивы данных для тестирования и интуитивно сделаем это раньше, чем отправим этот лист начальнику ОКК на рецензию. Ключевое слово “раньше”, т.е. до того, как этим листом воспользуются сотрудники и накосячат в результатах N-го числа испытаний. У тестирования приложений “по-позже” есть два полярных выхода: а) получить подтверждение, что разработка была правильной, но до этого ожидать, как на иголках, а так ли это на самом деле – тогда возникает вопрос, почему это не сделать сразу же, перед использованием, минуя интригующую стадию “прокатит/непрокатит”; б) получить результат неудовлетворительный – тогда помимо собственно исправления программы будет возникать, пожалуй, более важный вопрос – что делать с результатами использования “кривого продукта”?
Если система немного сложнее калькуляционного листа MS Excel, то нас интуитивный подход в тестировании уже не вполне выручит и мы обратимся к лучшим практикам, которые достаточно хорошо описаны. Но будем помнить главное – тестирование уместно только в момент разработки. Тестирование работающего программного продукта допустимо, но не уместно. Термин “тестирование” (именно о тестировании речь идет в многочисленных практиках разработки ПО) в данном случае можно смело приравнять для удобства к термину “валидация”. Если вы отдали продукт Заказчику “в продуктив” и там предполагаете ловить баги – вы слишком рискуете, современные практики разработки ИТ данный подход не считают приемлемым изначально. Нет, конечно, фаза опытно-промышленной эксплуатации имеет место быть – тот же SAPовский Roadmap (ASAP) включает её предпоследним этапом перед собственно GoLive. Но этому предшествуют фаза концептуального проектирования, функционального тестирования, интеграционного тестирования, когда о продуктивная эксплуатация систем исключена. На этих этапах отдельные сценарии могут многократно дорабатываться. Конечно же даже речи не идет о том, чтобы подобную систему сделать “прикидочно”, а потом “вылавливать” баги при работе с реальными данными.
Но SAP, это а) чрезмерно крупноуровневый продукт для начального рассмотрения; б) имеет свою методологию разработки и внедрения. По этой причине рассмотрим объект по проще, с тем чтобы проиллюстрировать какие основные подходы при разработке и тестировании могут быть задействованы с тем, чтобы не “сесть в лужу”.
Для этого приведу опыт по запуску LIMS на Access, когда 1 месяц ковырялись в тестовой среде, выполняя сквозной сценарий и затем 3 месяца – в продуктивной среде, отлавливая баги, значительная часть которых была связана с разношерстной ИТ-инфраструктурой. Прежде всего из-за того, что у ключевых пользователей были установлены различные ОС и версии MS Office.
Но прежде чем так поступить, хотим обратить внимание на “ИТ-фланг” в части тестирования ПО:
Просмотрите бегло на содержание курса по QA IT – для удобства, чтобы не скроллить первоисточник – приведу его тут:
В принципе тут мы обошлись без некоторых завершающих разделов, касающихся уже практики вэб-тестирования. Но и без этого представителю “фланга GMP” становится понятным, что угадываются знакомые подходы и понятия: “Quality Control”, “Quality Assurance”, “Requirements Specification”, “Traceability Matrix” etc.
Теперь вернемся к выше анонсированному примеру для LIMS. Выглядело это действо следующем образом. Мы имели на входе давно работающую систему, написанную в начале нулевых для лаборатории ОКК по учету лабораторных испытаний. Говоря укрупненно – обеспечивался весь цикл по анализу сырья с выдачей аналитического листа вплоть до выпуска готовой продукции с выдачей сертификата качества.
Затем было решено её доработать с учётом современных требований GxP к компьютеризированной системе – были добавлены журналы событий, разграничен доступ, оптимизированы некоторые формы и т.п.
Система представляла собой классическую клиент-серверную архитектуру:
Рис.1. Схема клиент-серверной архитектуры
Привязываясь к рис. 1, можем указать, что изменения коснулись пользовательского интерфейса и бизнес-логики. А вот база данных (БД) содержала все исторические данные с начала тех самых упомянутых выше нулевых и сразу же “соединить” их с непротестированной и усложненной бизнес-логикой было бы не комильфо. Хотя бы по причине того, что рабочую БД можно было сильно и необратимо “покоцать”.
Отсюда всплыло логичное решение скопировать наявную БД в отдельный сегмент VLAN (в принципе это может быть попросту отдельный тестовый ПК и/или отдельная папка в обычной локальной сети, без виртуализации). Таким образом, тестовые версии новых пользовательского интерфейса и бизнес-логики обращались к БД, имеющей реальные (правдоподобные) данные, но не имеющей реального значения 🙂
Как выяснилось – это традиционный подход в ИТ-тестировании при разработке ПО – даже есть специальный термин – sandbox (песочница). Там можно отрабатывать все ключевые сценарии, не опасаясь, что мы повредим рабочую БД.
Как было организовано тестирование. На отдельном ПК, который был выбран в качестве тестового Клиента (см. рис. 1), прогонялся сквозной сценарий – вот мы получили сырье, изменили его статус, получили аналитический лист, разрешили к использованию в производстве и т.д.
Что важно при этом – поочередно приглашался каждый ключевой специалист лаборатории, параллельно с выполнением сквозного сценария заполнялись бланки тестирования в sandbox. Причем состав участников для каждого шага был следующим: разработчик, инженер по валидации, специалист ОКК. Если фиксировались ошибки, то разработчик их себе записывал в специальную форму (бланк). Далее осуществлялась корректировка и определенный объем повторного тестирования (в данном случае оно называется регрессионным).
После успешного завершения тестирования в sandbox начальник ОКК вместе со свежеиспеченным тестовым сертификатом качества готового лекарственного средства подписывал также и разрешение на переход в продуктивную среду.
Это означало, как вы уже догадываетесь, подключение к реальной базе данных и прогону уже того же сквозного сценария в продуктивной среде. При этом никто не собирался удалять или модифицировать данные валидационных (тестовых) записей в отношении сырья и готовой продукции – напротив, они намеренно оставались “жить” в БД и специально назывались тестовыми, испытания в их отношении комментировали, как тестовые.
Конечно, на продуктивную среду мы уже выходили с серьезным запасом прочности, получив удовлетворительные результаты при тестировании в sandbox. Но, как я говорил выше, нюансы все-таки возникали и вот тут ключевая особенность именно ИТ – это обращение с ошибками (багами, bugs). Здесь особую роль играет то, как мы будем их собирать + как мы будем ими управлять.
Понятное дело, что тут форма (бланк), которую всякий раз заполнял разработчик при тестировании в sandbox – уже становится контрпродуктивной. Почему? Всё очень просто – помните состав участников в sandbox? Когда разработчик его заполняет, то рядом с ним сидят и инженер по валидации и ответственный специалист, например, микробиолог – они “соображают на троих” в хорошем смысле этого слова и исчерпывающе описывают то, с чем столкнулись и как это нужно исправить и фиксируют это в бланке.
Когда вы отпустили систему в “свободное плавание”, это означает что ежедневно с ней работают десятки сотрудников. Каждый охватывает малейшие нюансы и, несмотря на то, что система в целом не должна содержать чего-то критического, отчего она попросту завалилась бы с критическими ошибками и последствиями, тем не менее, у кого-то может поле не вписываться в разрешение экрана, у кого-то может не работать запрос или кнопка и т.п. Вы думаете всякий раз столкнувшийся с такой проблемой конечный пользователь будет исчерпывающе заполнять валидационный бланк отклонений? Если тот или иной специалист заметит какие-либо баги, то он либо запишет это на клочке бумаги, либо просто (в зависимости от степени критичности) может затаить невысказанную враждебность к разработчику. 🙂 Конечно, если баг критический, то специалист найдет возможность совершить эскалацию проблемы и в конечном итоге разработчик получит или e-mail или ему просто позвонят/напишут в “скайп”, причём обращение будет примерно вида “Шеф! Всё пропало, гипс снимают, клиент уезжает!”. (с) Т.е. суть возникшей проблемы останется за кадром. На самом деле толку от таких спонтанных всплесков неудовольствия немного.
И здесь нам ИТ-индустрия сильно подсобит – “все уже украдено до нас”. (с) То бишь изобретены системы баг-трэкинга. Т.е. автоматизированного сбора и управления багами. Собственно изобретено как само понятие/подход – что на самом деле на поверхности – так и предложены специализированные автоматизированные системы. Понятно, что выбор способа управлять багами (а вместе с ними – и всей разработкой) зависит от масштабов системы. Вряд ли для простенького приложения кто-то будет городить огород с освоением пусть интуитивно понятных, но тем не менее несколько громоздких RedMine или code.google. Но уже в нашем примере LIMS, где количество пользователей исчисляется несколькими десятками людей, это уже необходимо в том или ином варианте.
Вот форма такого баг-трэкинга на простейшем примере – созданная при помощи google-форм. А вот возможность взглянуть на его результаты. Понятное дело, что записи там сделаны “от фонаря”, но тут главное сама идея. Далее в гугл-таблице можно настроить дифференцированный доступ, чтобы разработчик не мог удалять баги, а только оставить ему поле для комментирования. Комментарии будут в духе “принято на сопровождение”, “исправлено в версии 1.ХХ” и т.п.
Ещё здорово добавлять к Вашим описаниям скрин-шоты – при современном развитии облачных ресурсов это не только не проблема, но даже делает процесс поиска и исправления багов намного удобнее. В частности Яндекс.Скриншоты вообще идеально заточены под поиск и сопровождение багов – см. пример.
В этом собственно и заключаются “10 шагов навстречу” от ИТ-специалистов к рядовым пользователям. Один раз людям покажите, как пользоваться современными сервисами, как правило, всем доступными и они с радостью подхватят ту методологию, которая работает и помогает им решать возникающие у них проблемы.
Резюмируя скажу, точнее, повторюсь, что при таком продуктивном тестировании основные баги были связаны именно с разношерстностью ИТ-инфраструктуры. У кого-то стояла WinXP SP2, у кого-то Win7, разные версии MS Word – отсюда и различные нестыковки. Это уже является управлением ИТ-инфраструктурой и собственно ОКК уже не касается. Как нетрудно догадаться – это проблема и в мире и в наших странах давно решена – вот две серии стандартов ISO 20k, ISO 27k.
В принципе если именно этот пример будет нуждаться в развитии/большей детализации, сможем углубиться, а сейчас для затравки темы в целом, перейдем к другим аспектам, чтобы не залипнуть на одном точечном примере.
***
Что важно для для т.н. Legacy System? Когда система давно используется, то, как правило, если в ходе валидации обнаружено ее концептуальное несоответствие требованиям GMP, то не факт что а) она подлежит доработке – с разработчиком “контакт” может быть потерян; б) таковая доработка нецелесообразна – часто проще сделать новую систему с нуля. Если нам все-таки повезло и давно используемая система пригодна – просто формально действуем в соответствии с п. 16.6 руководства PIC/S для Legacy System. Стараясь не перерасходовать валидационные ресурсы, т.к. ценности от такой запоздалой (ретроспективной) валидации не много. Точнее как, два несомненных плюса всё-таки есть:
Во-первых, вы получите, пусть и ретроспективно, URS (вообще говоря, это прямое требование п. 4.4 Приложения 11 GMP) – это позволит вообще понимать вам, для чего система задумывалась – может реально есть траблы с ее intended use (т.е. использованию по своему предназначению). В гипертрофированном варианте по мнению авторов абсолютно достаточно использовать приложение к Договору на разработку, где, как правило, указано что собой должна представлять система. Берем пример с бухгалтеров и финансистов – без согласованных Договоров не осуществляются платежи. В свою очередь в этих Договорах должен в том или ином варианте фигурировать предмет выполняемых работ, часто вынесенный в Приложения. Многие пользователи системы/валидаторы впервые узнают, для чего предназначалась система изначально и какой предусматривался ее основной функционал 🙂 При этом разработка ретроспективно отдельной URS часто нецелесообразна, если нет возможности или намерения вносить в систему изменения, планировать доработки.
Во-вторых, и это, пожалуй, самый важный аспект – необходимо создать актуализированное описание системы (п. 4.3 Приложения 11 GMP). Часто система внедрялась 10 лет назад, использовались WinXP, MS Office 2003 и т.п. С тех пор система многократно “допиливалась”, “живёт” на другой ИТ-инфраструктуре и т.п. Естественно описание в рамках исходного Договора и/или в Руководстве от разработчика, даже если оно было максимально детализированным, уже утратило свою актуальность.
Вот эти два вида деятельности полезны в рамках ретроспективной валидации КС (не путать с ретроспективной валидацией процесса, которая прямо запрещена с 2015-го в рамках Приложения 15 сGMP EU).
Даже если дорабатывать систему не нужно, во всяком случае, будет актуальная информация в ее отношении и ее можно будет поддерживать. А при последующей замене – будет на что опереться, при необходимости легче будет осуществить миграцию необходимых данных.
* * *
Если укрупненно говорить о GAMP 5 – то он состоит из следующих основных частей – общая часть (где в том числе и анализ рисков изложен) – много хороших картинок, но большей частью вода. А вот приложения уже несут в себе больше конкретики и структурированы следующем образом:
Группа Приложений O – Operation – т.е. Эксплуатация.
Кстати последняя группа наиболее многочисленная – предлагаю сравнить наименования ее приложений с наименованием пунктов Приложения 11 GMP фазы эксплуатации – все быстро встанет на свои места. А потом к этому добавим наименования некоторых пунктов стандартов ISO 20k & ISO 27k:
Operation Appendices GAMP5 | Annex 11 cGMP EU Operational phase | ISO 20000-1 (выборочно из ГОСТ Р ИСО/МЭК 20000-1-2013) | ISO 27001 (выборочно из перевода SITMA) |
O1 Handover | 5. Data | 8.1. Управление инцидентами и запросами на обслуживание | A.12.1.2 Управление изменениями |
O2 Establishing and Managing Support Services | 6. Accuracy Checks | 8.2 Управление проблемами | А.12.3 Резервное копирование |
O3 Performance Monitoring | 7. Data Storage | 9.1 Управление конфигурациями | А.12.4. Логи и мониторинг |
O4 Incident Management | 8. Printouts | 9.2. Управление изменениями | А.16 Управление инцидентами информационной безопасности |
O5 Corrective and Preventive Action | 9. Audit Trails | 9.3 Управление релизами и внедрением | |
O6 Operational Change and Configuration Management | 10. Change and Configuration Management | ||
O7 Repair Activity | 11. Periodic evaluation | ||
O8 Periodic Review | 12. Security | ||
O9 Backup and Restore | 13. Incident Management | ||
O10 Business Continuity Management | 14. Electronic Signature | ||
O11 Security Management | 15. Batch release | ||
O12 System Administration | 16. Business Continuity | ||
O13 Archiving and Retrieval | 17. Archiving |
Цветом специально выделены позиции, совпавшие практически буквально. Теперь становится понятным, откуда по сути списана большая часть требований Приложения 11 GMP. И если GAMP5 ещё можно считать некоей высокопарностью, то уж стандарты ISTM (ISO 20k) & ISMS (ISO 27k) – это давно уже реальность, внедренная в нашу жизнь практически повсеместно (интернет-банкинги, телекоммуникационные сервисы и т.п.). Например, головной стандарт по информационной безопасности (ISO 27001) в первой своей редакции увидел свет в 2005-м, а относительно недавно, в 2013-м вышла новая его редакция. В то время как GAMP5 (будучи сам 2008 г.р.) в своём Приложении О11 Security Management ссылается на его предтечу ISO 17799, который еще в 2005-м был заменен стандартом ISO 27002 (о том, как применять головной стандарт ISO 27001), а в 2013-м обновилась и сама редакция ISO 27002 вместе с головным стандартом серии. И если второе обновление GAMP5 не мог отследить физически (т.к. сам был издан ранее), то первые редакции ISO 27001 и 27002 были вполне в его временном интервале. Что называется, оцените инерционность и вторичность самого GAMP5. А самое главное, важно понимать, что тематика проработана задолго до GAMPa и куда основательнее, чем требует GMP.
Например, банковская деятельность подлежит обязательной сертификации на предмет соответствия требованиям стандартов серии ISO 27k. Соответственно инструментарий разработан очень хорошо. Аналогично можно отметить, что стандарты серии ISO 20k – это по сути рафинированный ITIL – в наше время столь популярная платформа как 1С уже имеет в своей линейке ITIL-продукты. Т.е. все требования вы в настоящее время можете выполнить автоматизировано. Хотя, признаюсь, мне неизвестны случаи, когда ИТ-отделы предприятий ведут, например, учет пользовательских ПК “пешком” – они либо не ведут его вовсе (есть ещё такие “колхозы”, где админы занимаются “подставкой табуреток под сервисы”), либо так или иначе автоматизируют свою работу. Список пользователей хотя бы через ActiveDirectory извлекается, равно как и полномочия нарезаются им аналогичным образом. Точно так же, если в природе доступны в т.ч. бесплатные инструменты мониторинга узлов сети (NMS – Network Monitoring Systems), Управления изменениями и инцидентами, то ни один ИТ-специалист не станет их игнорировать и вести учёт недовольных пользователей в MS Excel или в блокнотике. 🙂 Справедливым представляется утверждение, что если вы выполняете требования стандартов ISO 20k & ISO 27k, требования Приложения 11 GMP вы выполните автоматически, причем с большим запасом прочности.
* * *
Для последующего дополнения, чтобы не перегружать и без того насыщенную статью хотим проанонсировать продолжение данной статьи, очертив проблемные вопросы:
- GLP-регуляторы подошли к этому вопросу обстоятельнее, чем GMP выдав свое руководство.
- 21 CFR Part 11 – так всё-таки надо разобраться с вопросами:
а) обязательности 21 CFR Part 11 – формально в Annex 11 cGMP EU нет ни слова об этом американском нормативе, хотя интерпретация сообщества практиков GAMP содержит таковые ссылки,
б) “заколодованным кругом” в отношении определений ЭП и ЭЦП (electronic signature and digital signature) и их применения + юридической значимости.
А пока на этом всё, до новых встреч!
P.S.: часто от скептиков слышим, мол, находятся “бабули-аналитики”, которые не могут освоить эксплуатацию компьютеризированных систем (исполнители не обязаны понимать валидацию ни в целом, ни в частностях). Что можно сказать – тем хуже для “бабуль-аналитиков” – тренд, собственно, неизбежен. Приведу на этот счет цитату, которая содержится в преамбуле книги “Дао Тойота” (“Путь Тойота”): “вы можете не меняться – выживание не является обязанностью“.
Добавил в словарь немного терминологии по данной тематике. В частности термин legacy system и COTS.
И вот еще интересная статья по обслуживанию legacy-систем.
А вот живая иллюстрация на тему, как часто ведется разработка ПО.
Это старая аллегория. На самом деле нормальные разработчики так не делают.
В статье очень много полезной и интересной информации, за что огромный респект обоим авторам!
Но кроме первого вопроса с URS я что-то не уловил более глобальной проблематики статьи, в которою и прошу “ткнуть носом”.
Собственно URS или более привычный для нас термин “техническое задание” и является основой не только для разработки, но и для проведения тендера (хотя на тендер оно прилагается в более общем виде) и последующего подписания договора. Я не представлю, как без ТЗ (хотя бы сверстанного на коленке или оговоренного устно, если что-то совсем простое) можно внедрять, а тем более разрабатывать какую-либо систему. Это стандарт, без которого ни одна уважающая себя фирма не станет писать софт и выдвигаться на тендер, кроме случаев отката.
С моей точки зрения, URS актуальна для самописного софта или интегрируемого, то есть идущего в базовой комплектации и адаптируемого интегратором под нужды заказчика, и абсолютно бесполезна для софта, поставляемого “как есть”, например, MS Office, MS Windows (разве что вы не гигантская корпорация, которая делает отдельный заказ у Microsoft на доработку отдельной функции или пакета функций), тут скорее важнее СОПы, чем URS.
Отдельно спасибо за таблицу со сравнением стандартов и с нетерпением жду статей по проблемам, заявленным в конце данной статьи.
Более глобальная проблематика – мы внедрили систему, а теперь давай её валидировать – в корне неверный подход – валидация должна сопутствовать разработке/внедрению.
Теперь для меня посыл понятен. Он полностью отвечает логике внедрения и по сути так и должно быть, как описано в статье. Но, для систем на наших предприятиях, которые разрабатывали 10-15 лет назад, ни о какой валидации речи и не шло, тогда и понятия не имели об этом, да и указанные стандарты на то время также не были в обиходе или только осваивались. Вспомним когда интернет-банкинги пришли на Западе, не такие уж и большие периоды времени и по этим системам мы не так и отстаем от них.
Вопрос по старым системам – выкинуть их на свалку или пытаться описать по текущим требованиям и валидировать? На том же Западе часто используют старые системы до упора, пока переход на что-то новое не влечет за собой действительно существенные выгоды или просто диктуется устареванием оборудования и отсутствием замены. Видимо ВКС отчасти и задумывалась для таких систем.
Для давно используемых систем тоже описан подход в статье – подраздел “Что важно для для т.н. Legacy System?”. Тут уже тратить чрезмерные усилия не рекомендуется и пользу принесёт только формальное исполнение требований (п. 16.6 руководства PIC/S). Если система старая, но решает свои задачи и соответствует требованиям – вполне можно использовать её “до упора”.
Если есть критические несоответствия – например, для WMS можно отгружать сырье или готовую продукцию в статусе “карантин”, то её нужно или дорабатывать или немедленно выводить из эксплуатации – такой риск не приемлем. Аналогично, для различных систем мониторинга параметров – если у Вас есть возможность удалять/модифицировать архивные данные – аналогично – доработка или вывод из эксплуатации/замена.