В первой части статьи мы рассмотрели вопросы нормативного регулирования и методологии валидации компьютеризированных систем, обозначили основные принципы валидации. Мы также привели основные трудности и ошибки, которые допускаются при создании таких систем. Во второй части мы рассмотрим особенности разработки и внедрения компьютеризированных систем с точки зрения процессов, ролей и требуемого документооборота.
Часть 1 «Валидация компьютеризированных систем» опубликована в журнале «Новости GMP» 3(17)/осень 2018
Жизненный цикл программного продукта и методологии разработки
Сердце любой компьютеризированной системы – это программный продукт, который необходимо внедрить для автоматизации одного, либо нескольких критичных бизнес-процессов. Любой программный продукт имеет свой жизненный цикл, состоящий из следующих стадий (см. рисунок 1):
- Формирование потребности. Запрос на ИТ решение
- Анализ требований. Оценка бизнес и регуляторных требований
- Проектирование. Формирование технического дизайна компонентов системы
- Разработка. Фактическая разработка решения согласно требованиям
- Тестирование. Проверка работоспособности функционала и его соответствия изначально заявленным требованиям
- Внедрение. Запуск системы в эксплуатацию
Следует отметить, что в приведенном выше перечне отсутствуют важные этапы непосредственной эксплуатации программного продукта и вывода его из эксплуатации. Данные вопросы находятся за рамками настоящей публикации.
При том, что этапы жизненного цикла программного продукта могут быть аналогичными, методологии разработки программного продукта могут концептуально отличаться друг от друга.
Под методологией мы будем понимать заранее определенную стратегию разработки программного продукта, которая:
- задает правила и последовательность взаимодействия проектной команды;
- учитывает риски;
- определена до старта проекта;
- соответствует возможностям команды;
- согласована участниками и спонсорами проекта.
Методологии к разработке и внедрению программного продукта сегодня принято условно делить на две большие категории (см. рисунок 2):
Каскадная (водопадная) методология – классическая методология предполагающая полное завершение предыдущего этапа до перехода к следующему.
Гибкая методология – довольно давно используемая в ИТ методология и сравнительно недавно активно внедряемая в другие сферы бизнеса, в том числе для проектов в фармсекторе. Особенность гибкой методологии заключается в итеративном подходе к разработке, позволяющем последовательно внедрять необходимый функционал в ходе многократно повторяющихся аналогичных этапов. Иными словами, если перед командой разработчиков стоит задача внедрить, условно, сто пользовательских требований, – данные требования разбиваются на приоритетные группы, после чего проектная команда завершает работу над первой приоритетной группой, потом переходит ко второй и т.д. Если результат работы по требованиям первого приоритет оказался неудовлетворительным, команда может решить продолжить работу с данным набором требований или изменить степень их приоритезации для перехода к следующей приоритетной группе. Данная методология становится все более интересной бизнесу, так как современный мир диктует необходимость быстро реагировать на изменения и гибко формировать потребности продукта в течение его жизненного цикла.
Приведем ниже сильные и слабые стороны для каждой из методологий.
Как видно из таблиц 1 и 2, обоснованность применения той или иной методологии индивидуально для каждого разрабатываемого программного продукта и зависит от многих факторов, таких как квалификация проектной команды и поставщика решения, детальности понимания бизнесом потребности, изменчивости бизнес процессов во времени, а также требуемой технической сложности будущего программного продукта. При разработке сложного программного продукта в условиях высокой неопределенности внутренних и внешних требований, использование каскадного подхода будет крайне проблематично. Например, могут измениться требования, приоритеты заказчика и к моменту, когда команда закончит этап проектирования, его нужно будет начинать сначала. Даже внедрение относительно небольшого изменения в функциональные требования на этапе тестирования также может обернуться достаточно большой проблемой, т.к. для этого может потребоваться остановка всего проекта. Гибкая методология позволяет «делить слона по частям», но при этом предъявляет высокие требования к руководителю проекта в плане организации работ, отслеживания прогресса и постановки приоритетов очередного цикла разработки.
Особенности документооборота
В таблице 3 перечислены основные документы, формируемые на каждом из этапов разработки ИТ-системы, используемой для GxP-целей. Следует иметь ввиду, что валидация компьютеризированных систем – это частный случай валидации. А значит, общие требования к проведению валидации применимы и к валидации компьютеризированных систем.
Рассмотрим подробнее предназначение каждого из документов, а также его логическое место в общей системе документооборота, формируемого в процессе разработки и валидации компьютеризированной GxP-системы.
Отчет о применимости регуляторных требований
Основополагающий документ, определяющий, каким именно регуляторным требованиям должен соответствовать программный продукт, в частности:
- Требованиям к безопасности программного продукта (IAPP)
- Требованиям по доступу из открытой сети Интернет
- Требованиям, связанным с хранением и обработкой персональных данных
- Требованиям, связанным с безопасностью пациентов
- Требования, связанным с наличием финансовых операций в системе
- Требованиям к хранению и обработке электронных записей и подписей
- Прочим регуляторным требованиям, которые могут быть применимы к разрабатываемому продукту, например, какие-либо специфические локальные требования
Именно анализ применимости нормативных требований дает ответ на вопрос, будет ли являться будущий продукт GxP или нет, а также уровень общего риска приложения с точки зрения безопасности пациентов: высокий, средний либо низкий. Ниже мы подробнее затронем вопрос оценки рисков.
Анализ применимости нормативных требований подготавливается на начальных этапах и используется в течение всего жизненного цикла продукта. В случае необходимости внесения изменений в продукт, в первую очередь должен быть обновлен именно анализ соответствия продукта регуляторным требованиям. Необходимость этого обусловлена тем, что любое изменение существующих требований, либо появление новых, может привести к изменениям в применимости регуляторных и нормативных требований, что нуждается в повторном анализе.
План выполнения нормативных требований
Еще один ключевой документ для GxP проекта (см. рисунок 3).
План выполнения нормативных требований определяет последовательность действий, необходимых для достижения соответствия продукта применимым регуляторным требованиям. На этом же этапе определяется детальный список документов и ответственные за их подготовку и согласование роли в проектной команде. Перечень должен включать в себя описанные в таблице 3 обязательные документы, а также любые дополнительные, если того требует специфика разрабатываемого продукта.
Документ используется только при реализации проекта и его целью является формирование необходимой и достаточной валидационной документации для будущего программного продукта.
Спецификация требований
Документ определяет, что собой будет представлять будущая ИС система. Спецификация требований содержит пользовательские требования, описывающие в формальном виде запрос бизнес-пользователей к системе, а также функциональные требования, отвечающие на вопрос, как то или иное пользовательское требование будет в системе.
Пример
В примере на рисунке 4 показано одно пользовательское требование системы работы и хранения данных по продажам продуктов компании (выделено голубым цветом) и его трансформация в функциональные требования (зеленым).
Кроме бизнес-требований, документ также содержит регуляторные требования, применимые к системе.
Важным критерием для утверждения спецификации требований является атомарность и потенциальная проверяемость требований на этапе тестирования. Т.е. каждое требование должно иметь уникальный идентификатор, который не меняется в течение всей жизни разрабатываемого продукта. Для каждого требования должна быть возможность создания пользовательского и/или системного теста, который подтвердит выполнение это го требования.
Данный документ является неотъемлемой частью программного продукта и должен содержать всегда актуальные требования к находящемуся в эксплуатации продукту. В случае необходимости дальнейшего развития и доработок продукта, спецификация требований должна быть обновлена.
Оценка GxP рисков
Анализ и управление рисками играют существенную роль при валидации программного продукта.
Ключевым документом на всем протяжении жизненного цикла продуктов является матрица рисков, которая позволяет адекватно структурированно оценить вероятность сбоев программного продукта и необходимый уровень тестирования.
Матрица рисков состоит из перечня GxP рисков, выявленных на основании требований к продукту. GxP риск включает в себя несколько составляющих:
- Общая степень риска программного продукта, которая была выявлена в ходе первичного анализа соответствия: высокий, средний, либо низкий
- Оценка надежности поставщика программного продукта, которая зависит от результата аудита поставщика
- Предметная оценка рисков для каждого пользовательского и функционального требования, которая формируется на основании следующих факторов (см. рисунок 5): описание отказа функциональности; потенциальная причина отказа; техническая вероятность отказа; важность требования с точки зрения бизнес-пользователя.
На основании проведенной оценки рисков определяется объем и типы необходимого тестирования разработанного, либо модифицированного приложения с целью раннего выявления и сдерживания рисков отказов. Кроме того фиксируется набор необходимых мероприятий и операционных процедур, которые будут разработаны для предотвращения и/или сдерживания каждого риска отказа.
Тестирование в GxP проектах
Тестирование IT-проектов давно уже не является чем-то уникальным и особенным. В GxP проекте предъявляются более жесткие требования к выполнению этого этапа. По итогам этапа оценки рисков проекта для каждого функционального требования необходимо определить тестовое покрытие или, иными словами, объем тестирования, в котором могут содержаться следующие виды тестов:
- Функциональный тест – проверка того, что функционал соответствует изначальным требованиям
- Граничный тест – проверка граничных условий, если функционал подразумевает ввод/вывод данных Негативное тестирование – проверка негативных сценариев, как система не должна работать, в соответствие с требованиями
- Тест интерфейса – проверка интерфейсов пользователя, если они имеются и к ним предъявлены требования
- Тест миграции данных – проверка миграции данных, если она присутствует в проекте
Для того чтобы понять, какое именно тестирование применить к тем или иным требованиям, необходима матрица оценки рисков. С помощью заранее установленных правил полностью исключается человеческий фактор при формировании тестового покрытия функциональности и объемы тестирования определяются исключительно степенью рисков конкретного требования и продукта в целом.
Пример
Правила определения объемов тестирования могут выглядеть, например, следующим образом:
Тестирование состоит из следующих этапов:
- Разработка и утверждение стратегии тестирования – формирование протокола тестирования
- Разработка тестовых сценариев для покрытия функциональных требований
- Разработка тестовых сценариев для приемо-сдаточных испытаний
- Непосредственное выполнение тестирования и выявление дефектов
- Подготовка финального отчета по тестированию
Разработанное тестовое покрытие должно быть актуально и доступно в течение всего жизненного цикла продукта. В случае доработок/изменения продукта, тестовое покрытие должно быть обновлено в соответствии с обновленными требованиями.
Матрица прослеживаемости
Данный документ определяет логическую взаимосвязь пользовательских и функциональных требований, тестов, подтверждающих выполнение указанных требований, а также указывает на операционные инструкции и процедуры, описывающие порядок работы с системой (см. рисунок 6):
- Пользовательских требований
- Функциональных требований
- Тестовое покрытие – набор пользовательских и функциональных тестов для конкретного требования
- Операционных процедур
Матрица прослеживаемости является неотъемлемой частью компьютеризированной системы в течение всего жизненного цикла и должна давать ответ на вопрос – как то или иное требование реализуется в программном продукте, какими тестами его проверить и какие операционные процедуры необходимы при эксплуатации.
Особое значение этот документ приобретает в случае анализа каких-либо дефектов, выявляемых в ходе тестирования, или на этапе эксплуатации программного продукта. Благодаря тому, что матрица прослеживаемости отражает логическую взаимосвязь всего документооборота, формируемого в ходе жизненного цикла программного продукта, можно оперативно установить каким образом было сформулировано то или иное требование, где оно зафиксировано и как на документальном уровне шло техническое воплощение требования в программном продукте.
Поддерживать матрицу прослеживаемости в актуальном состоянии без применения каких-либо средств автоматизации документооборота по мере наработки документов может быть весьма проблематичным делом. Поэтому в ряде организаций внедрен электронный документооборот, предполагающий автоматическую индексацию создаваемых документов в матрице прослеживаемости.
Отчет по валидации
Итоговый документ необходимый для запуска системы, подтверждающий, что в рамках проекта выполнены все активности, включенные в протокол тестирования. Система готова к эксплуатации только после подтверждения такого документа.
Проектная и продуктовая команда
Успех в реализации проекта по разработке и внедрению компьютеризированной системы во многом зависит от эффективной и слаженной работы проектной команды. При разработке, внедрении и эксплуатации ИТ-системы важно иметь четкое раз граничение ролей и обязанностей. Необходимо наличие следующих трех ролей в команде.
В таблице 4 представлены основные участники проектной команды, а также сотрудники, отвечающие за ее эксплуатацию.
На этапе инициации и выполнения проекта эти роли входят в проектную команду, кроме того в зависимости от выбранной методологии реализации проекта и требований, в проекте могут участвовать следующие роли:
- Руководитель проекта
- Команда разработки
- Команда тестирования
- Команда эксплуатации и сопровождения
- Группы экспертов по безопасности, электронным записям, приватности и т.д.
Заключение
Несмотря на успехи отечественной ИТ-индустрии в области программирования и автоматизации, формализация требований к различным этапам жизненного цикла программного продукта, документооборот в соответствии с GxP-требованиями остаются проблемной зоной. Вместе с тем существует достаточно большой объем нормативной документации, которая, на наш взгляд, может быть полезна разработчикам и специалистам в области обеспечения качества программных продуктов, желающих повысить уровень стандартизации своих рабочих процессов. Приведем несколько примеров:
Стандарты Ассоциации инженеров-электротехники и электроники (Institute of Electrical and Electronics Engineers, IEEE) https://www.ieee.org/standards/index.html
Сайт сообщества инженеров, посвященного компьтерным технологиям https://www.computer.org/web/guest/ Институт программной инженерии https://www.sei.cmu.edu/
Кроме того, рекомендуем обратить внимание на издание Американского Общества Качества (American Society for Quality), которое называется The Certifed Software Quality Engineer Handbook. Second edition, 2016.
Авторы материала: Михаил Хазанчук, эксперт по вопросам GMP/GDP;
Алексей Светлов, эксперт по информационным технологиям;
Михаил Чушков, эксперт по вопросам операционной логистики
Материал опубликован в журнале «Новости GMP» 1(18)/весна 2019