Для программного обеспечения, используемого в рамках систем менеджмента качества медицинских изделий, должны быть предусмотрены соответствующие средства управления, обеспечивающие правильную работу на протяжении всего жизненного цикла программного обеспечения в системе менеджмента качества. Применение критического мышления и реализация выбранных действий по укреплению доверия приводят к созданию и поддержанию валидированного состояния (статуса валидации) программного обеспечения. На рисунке 1 приведено концептуальное представление типовых видов деятельности и соответствующего управления, которые являются частью жизненного цикла программного обеспечения в системе менеджмента качества с момента принятия решения об автоматизации процесса и до тех пор, пока программное обеспечение не устареет или больше не будет использоваться в рамках систем менеджмента качества медицинских изделий. На рисунке 1 изображена последовательная модель, в действительности же этот процесс носит цикличный характер, поскольку определяются элементы, идентифицируются риски и применяется подход на основе критического мышления.
При разработке программного обеспечения, используемого в рамках систем менеджмента качества медицинских изделий, одним из основных видов деятельности по укреплению доверия к функционированию программного обеспечения, выбираемой из набора инструментов, является выбор модели жизненного цикла разработки программного обеспечения. Выбранная модель уже должна содержать основанные на критическом мышлении действия, которые позволяют выбирать другие подходящие инструменты для использования на различных стадиях жизненного цикла. С целью обеспечения функционирования программного обеспечения в соответствии с его предусмотренным применением, результаты анализа и оценивания используются для выбора наиболее подходящего набора действий по укреплению доверия. Настоящий стандарт не подразумевает и не предписывает использование какой-либо конкретной модели разработки программного обеспечения. Однако для простоты остальная часть настоящего стандарта разъясняет концепцию критического мышления в контексте Каскадной модели разработки с использованием общих формулировок. Другие модели разработки программного обеспечения (например, итеративные, спиральные) также могут быть использованы при условии, что к ним применяются соответствующие инструменты и используется подход на основе критического мышления.
Рисунок 1 - Управление жизненным циклом программного обеспечения
При рассмотрении применения программного обеспечения в процессе следует идентифицировать факт его использования как части процесса системы качества посредством проведения анализа предусмотренного применения для рассматриваемого программного обеспечения. Если факт такого использования идентифицирован, то такое программное обеспечение должно быть валидировано на соответствие предусмотренному применению. Несмотря на то что настоящий стандарт описывает валидацию программного обеспечения, используемого в рамках систем качества медицинских изделий, такой же подход является хорошим примером для оценивания программного обеспечения на соответствие любым установленным требованиям. Самая важная часть валидации программного обеспечения - это разработка/закупка подходящего программного средства с целью использования его как инструмента для поддержания процессов, как предусмотрено изготовителем. Это подразумевает точное установление требований с целью оценивания того, подходит ли разработанное/закупаемое программное обеспечение для выполнения требований предусмотренного применения. Одинаково важны как технические требования, подходящие для верификации, так и технологические требования к процессу, подходящие для валидации. При рассмотрении вопроса о применении программного обеспечения в процессах следует учитывать, что программное обеспечение может взаимодействовать или иметь интерфейсы с другим программным обеспечением.
С целью сбора информации и принятия решений на стадии разработки жизненного цикла программного обеспечения в системе менеджмента качества выполняются задачи по менеджменту риска и планированию валидации в следующих четырех областях:
- уровень прилагаемых усилий, а также экспертиза документации и результатов работ и отчетных материалов;
- объем содержания результатов работ и отчетных материалов;
- выбор инструментов (из набора инструментов) и методов применения этих инструментов;
- уровень трудозатрат и усилий при применении этих инструментов.
Основными факторами, влияющими на принятие решений в этих четырех областях, являются риски, связанные с выполнением процесса, и риски, связанные с функционированием программного обеспечения. На принимаемые решения могут влиять и другие факторы (например, сложность программного обеспечения, сложность процесса, тип и происхождение программного обеспечения).
Процесс планирования проведения валидации состоит из двух отдельных составных частей. Первая часть включает в себя установление уровней тщательности в отношении документирования и проведения анализа полученных результатов. Решения в этой части главным образом определяются результатами анализа рисков процесса. Вторая часть включает в себя установление механизма выбора подходящих инструментов из набора инструментов для реализации тестирования и развертывания программного обеспечения. Выбор подходящих инструментов определяется главным образом посредством анализа риска программного обеспечения. Настоящий стандарт разбивает процесс планирования валидации на разные составные части, исходя из различий в деятельности, связанной с видом проводимого анализа риска. Тем не менее часто конкретные действия объединяются в одну деятельность, которая включает в себя различные аспекты анализа риска и вытекающие из него варианты продолжения проведения валидации.
На стадии разработки жизненного цикла программного обеспечения в системе менеджмента качества задачи менеджмента риска и планирования проведения валидации используются для установления соответствующего уровня трудозатрат и необходимости привлечения иных ресурсов, которые будут применены к программному обеспечению, а также для выбора и идентификации подходящих для применения инструментов по укреплению доверия. Использование такого подхода приводит как к выполнению поставленных задач по верификации, так и к реализации дополнительной деятельности, которая является основой для успешного установления валидированного состояния процесса применения программного обеспечения. Как только эта деятельность и задачи будут выполнены, инструменты и связанные с ними результаты вносятся в отчет по валидации программного обеспечения в качестве подтверждения заключения о том, что программное обеспечение является валидированным.
После развертывания программное обеспечение переходит в стадию своего жизненного цикла в системе менеджмента качества - обслуживание. На этой стадии программное обеспечение подвергается мониторингу, а также улучшается и обновляется в соответствии с потребностями бизнеса или изменением регулирующих требований. Деятельность по управлению изменениями на данной стадии основывается на тех же принципах, что и на стадии разработки жизненного цикла программного обеспечения. Однако изменения теперь оцениваются с точки зрения их влияния на предусмотренное применение, риск возникновения отказа, меры по управлению риском, которые применялись в ходе первоначальной разработки, а также на любые функциональные возможности самого программного обеспечения.
Стадия снятия с эксплуатации состоит из прекращения использования программного обеспечения посредством удаления процесса либо путем замены программного обеспечения, используемого для процесса.
На рисунке 1 показана основная деятельность по управлению жизненным циклом программного обеспечения в системе менеджмента качества. Прочие последовательности действий, не отраженные на рисунке 1, включают менеджмент проекта, разработку процессов, управление вендор-поставщиками (если применимо), а также другую деятельность в зависимости от рассматриваемого программного обеспечения.
Рисунок 2 отображает деятельность по управлению жизненным циклом программного обеспечения в системе менеджмента качества с учетом критического мышления и в контексте последовательности действий, не включенных в рисунок 1. Подход на основе критического мышления представлен на рисунке 2 в колонке "Итеративный анализ риска", а также в последовательности действий по валидации. Важно иметь четкие и документированные определения последовательности таких действий в рамках бизнес-модели организации с целью обеспечения правильного менеджмента программного обеспечения как с точки зрения бизнеса, так и с точки зрения регулирования.
Примечание - При использовании термина "разрабатывать" или "разработка" речь идет о разработке валидированного состояния программного обеспечения.
Рисунок 2 - Деятельность по управлению на основных стадиях жизненного цикла программного обеспечения
Стадии жизненного цикла программного обеспечения в системе менеджмента качества и блоки, расположенные в строке на рисунке 2, соответствуют той стадии жизненного цикла программного обеспечения в системе менеджмента качества, которая показана на общей блок-схеме на рисунке 1. Пунктирные линии показывают выходную информацию от одной деятельности, которая обеспечивает входные данные или помогает принимать решения при осуществлении другой деятельности. Диаграмма демонстрирует, что последовательность деятельности определяется наличием входной информации, необходимой для ее реализации. Важно отметить, что вся деятельность выполняется независимо от размера или сложности внедряемого программного обеспечения. Однако для более крупного или более сложного программного обеспечения такая деятельность, скорее всего, будет носить дискретный характер; для меньшего или более простого программного обеспечения некоторые виды деятельности будут объединены или выполняться одновременно.
Таким образом, подход на основе критического мышления устанавливает системный метод для идентификации и включения соответствующей деятельности или инструментов, обеспечивающих доверие к программному обеспечению, в различные последовательности действий для обоснования сделанного заключения о валидации программного обеспечения при выпуске, а также того, что статус валидации программного обеспечения будет поддерживаться до вывода его из эксплуатации.