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

@aleks79, вы как разработчик спрашиваете или как конечный пользователь?

конечный пользователь

@aleks79, если вы не разработчик ПО, не имеете достаточной квалификации и доступа к исходному коду, то вряд ли сможете провести такое тестирование. В приложении 11 ничего не сказано про исходный код, соответственно, это не входит в ваш объем работ по валидации. Это задача разработчика протестировать код и предоставить результаты тестирования вам. Вы, по сути, тестируете (валидируете) правильность работы ПО по функциям и процессам. Для этого у вас есть URS и FS.

@aleks79 добавлю чуть от себя к сообщению Антона. При самом правильном раскладе, у вас должен быть внутренний ИТ специалист, который знает язык программирования на котором написана система. Ну или передать это на аутсорсинг. По завершению пересмотра кода должен бить составлен такой документ как Code Review, с заключениям о качестве кода (соответствие устоявшимся правилам в языке программирования, спрятанный функции и бекдоры, возможными улучшениями и т.д.). Это требование есть в ГАМП5 (Appendix M4 3.6. (Custom SW), Appendix D4, 3.2).

Но это нужно далеко не всегда, зависит от системы и ее применения. 

Владимир описал идеальную ситуацию, которая на практике дорогая и сложнореализуемая. Если взять даже пару фреймворков того же PHP, то даже при знании языка сам стиль и правила написания структур для каждого фреймворка могут сильно отличаться. Сколько уйдет времени на то, чтобы у третьего специалиста разобраться с исходным кодом фирмы-поставщика. Пока он его будет пересматривать и анализировать, то исходный код может сильно измениться, особенно, если разработчик пользуется модными подходами типа Agile, Scrum и т. д. В итоге получите бесконечную карусель из проверки и разработки, а до валидации и внедрения так и не дойдете. А кто оценит компетенцию третьего специалиста, что он корректно оценит код фирмы-поставщика? 😉

Давайте смотреть реально на вещи. В руководстве PIC/S указано:

Documented source code with comments; explanation of function; in-data and expected out-data for each structured module. How modules influence each other. If program is purchased, how is access to source code guaranteed?

Исходя из этого я бы просто выбирал изначально нормального поставщика с налаженными процессами разработки и тестирования, запросил бы часть исходного кода (случайным образом для разных модулей) для проверки соблюдения заявленных процессов, примеры написания тестов и результаты всех выполненных тестов для всех функций и модулей.

Рекомендую задуматься над обязательным нормативным требованием - это квалификация поставщика, которую, наверное, делают только для поставщиков АФС и сырья, а для других систем, процессов и оборудования, почему-то забывают.

Антон, на самом деле, можно немножечко упростить процесс и сделать его вполне реализуемым:

У нас в компании применяется как оценка поставщиков так и пересмотр исходного кода для GxP критического кода (к счастью, таких примеров и проектов было плюс минус 12-15) и который будет делать что очень важное (то есть там где это было определенно на этапе планирования валидационной деятельности (наша любимая оценка рисков)).

Как это все работает и как упростить этот процесс: у нас есть средненькая по размерах ИТ команда, человек 30 в Украине и около 15-20 в разных странах. Когда команда сформировалась, на основании имеющихся компетенций ми сформировали приложения к СОПу по разработке систем, где перечислили свои требования к разработке как и веб сайтов кастомных так и систем, там же – и какие технологии должны бить использованы чтобы мы могли их развернуть и поддерживать (полностью основано на компетенции команды, а оно довольно большая). Дальше все работает следующим образом: Бизнес пишет ЮРС что он хочет, если такого решения нет на рынке, идем к разработчикам всяким разным, они получают от нас ЮРС и приложения с требованиями к разработке. Те из разработчиков, которые подтверждают готовность взяться за реализацию, проходят через процесс квалификации поставщика, как правило это запрос заполнить опросник и предоставить некоторые документы. Тот кто прошел квалификацию, получает аванс и начинает работать. Когда DEV среда готова и у нас есть код, начинаем смотреть что и как работает, делаем валидационные доки, а также, если ошибок в работе DEV среды не обнаружено, исходники идут на оценку кода к тому сотруднику ИТ, кто этот код может просмотреть. Когда Code Review готов и критических замечаний нет, ми начинаем развёртывание системы в QUAL среде со всей валидационной деятельностью IQ-SAT-UAT-TM-VR (FS, DS,CS – уже готовы на этот момент и предоставляются разработчиками). Ну а потом система попадает в PROD и пользователи получают доступ и начинают работать. Єто если в целом, в детали погружаться не буду (обучение, операционная поддержка, планирование и реализацыя проекта ....)

Как то так, вроде работает неплохо подход, несколько раз наши специалисты отдавали код на доработки. Аудиторы были удовлетворены таким подходом к кастомным системам.    

Это по богатому 🙂 Интересно, пересмотр кода ядра Windows или Linux вы тоже делаете? А кто оценивает компетенцию вашего специалиста, что он выявил все ошибки в коде и не пропустил какую-то уязвимость? Тут уже лучше многопрофильную группу тогда создавать из безопасников, программеров и т.д. Но конечно, это не отменяет внутренние требования конкретной частной фирмы, вы имеете право диктовать любые условия.

Нет нет, таким никто не занимается, только кастомный софт, который создавался исключительно под конкретные требования, и только там где это действительно нужно, ресурсы просто так не используются,  даже человеческие, времени на это нет. Компетенция наших ИТ сотрудников подтверждена различными сертификатами: Cisco, Microsoft по различным отраслям и многолетним опытом. Поэтому и доверие к их мнению есть. 

В некоторых случаях, такая оценка помогала самим поставщикам сделать их продукт лучше. Не все конечно, есть и плохие примеры где система едва жива. К счастью, такие системы долго не живут. 

Догадываюсь, что содержать такую команду не дёшево, но если она есть значит в этом есть некий смысл.

Я о том что такие практики уже есть, и это не уникальный случай.

Я же к тому веду, что при содержании такой команды нет смысла в кастомных разработках на стороне и вычитывании чужого кода. Это двойная работа и затраты. Лучше тогда уже создавать внутренний продукт. Что-то тут не стыкуется, особенно в плане затрат. Либо кому-то выгодно...

И внутренние разработки, как вы сказали, есть. Экономически, отдавать на аутсортинг смысл есть, так как внутренние сотрудники заняты другим, а проекты нужно закрывать. Примером, если какое-то не большое решение будет создаваться месяц-два целой командой на стороне поставщика, то пересмотр кода потребует у одного-двух сотрудников гораздо меньше времени, плюс за это время они закроют десятки тикетов и других заданий. Плюс потом не нужно волноваться за поддержку решение. 

Тема многогранна, может лучше её переместить в другое место, а то далеко отошли от вопроса темы 🙂

Суммируя и возвращаясь к теме, можно сказать следующее: 

- есть возможность провести оценку исходного кода - делайте, лишним не будет если учесть количество кибер атак на фарм компании за последние годы.

- нет возможности- тестируем решения и в оценки поставщика говорим что поставщик надёжный, а в оценке рисков на систему что не такая она уж критична 🙂

Я бы делал как-то так 🙂

Не, не нужно. Пусть будет в этой ветке.

Как по мне странное решение. Тут как раз с поддержкой и будет потом проблема, если разработчик исчезнет или прекратит разработку по той или иной причине. В любом случае решение, за вами. Если решили так делать, значит посчитали, что вам так выгодно. Запретов то никаких нет в этом плане.

В оценке кода есть два аспекта:

1. Компетентность оценщика.

2. Если разработка уникальная, то код вам может никто не предоставить. Поскольку никакие соглашения о конфиденциальности не спасут от утечки.

Если разработчик закрывается, то поддержка переходит на другую компанию. К счастью, это сейчас не проблема, ИТ рынок очень и очень не слаб - компаний сейчас хватает и мы с некоторыми сотрудничаем. Дальше все зависит от контракта: или берём команду на проект, или на почасовку на доработки. Или заменям софт на новый продукт, которым уже будет покрывать требования (если на рынке уже есть, с такой ситуацией я сейчас кстати и работаю). 

Касательно права собственности, все также от контракта зависит, как договорились уже: или код после разработки переходит в интеллектуальную собственность компании, или же ми завязываемся на одном поставщика. Но данные в системе при любом контракте принадлежат нам и должны иметь возможность экспорта в определённом формате. 

Коллеги, вчера был на мероприятии, наверное, одном из самых респектабельных в бывшем СССР - https://xn--80aej0akkilk.xn--p1ai/ - были практически все представители бигфарма - Pfizer, Abbott - мега-крутые дистры (DHL, Kuehne+Nagel etc.). Вы понимаете, что уровень, который вы копнули, могут поддержать даже не все из них? 🙂 По простой причине - ROI 🙂 Если люди покупают решение "под ключ" - то это просто будет супербрендовый поставщик услуги и этим будет закрыт вопрос - такой поставщик будет "обстрелян" один раз - при аудите. А далее в код никто систематически, даже по диагонали лезть не будет.

Ближе всех из участников к этому была пара BIOCAD + SAP - я, конечно, не задал вопрос по коду - меня интересовали исполняемые модели BPMN 2.0. Узнал, что пока они ограничиваются аналитическими моделями EPC, но на новых проектах намереваются освоить исполняемые модели BPMN 2.0 и связанный с этим функционал. О коде в ABAP речи не шло, но могу попытаться спросить вдогонку.

До недавнего времени BIOCAD содержал микросервисы и полк собственных разработчиков.

Директор по качеству Johnson & Johnson, Михаил Хазанчук, говорил в контексте цифровой трансформации, что тренд идёт в сторону охвата всех уровней - операционного и транзакционного, поддержки планирования и принятия решений, стратегического анализа (с). При этом будут находить применение следующие технологии: искусственный интеллект, анализ больших данных, интернет вещей, машинное обучение, дополненная реальность, умные роботы (с). Это всё цитаты из статьи в GDP Review и доклада Михаила Хазанчука. 

К чему нас приведёт ROI vs risk assessment? Реально ли будет делать source code review для всех подобных решений?

Даже в 1С в СППР встраиваются элементы автоматизации тестирования - та же Vanessa Automation - это тестовый скрипт, который может быть запущен хоть 10 тысяч раз. Лучше пусть она "пересмотрит" не столько код, сколько в целом поведение системы и рапортует об этом. 

От себя добавлю - появление low code систем - та же российская ELMA, международные Bisagi (я на самом деле очень поверхностно касался этой темы) - вообще сильно снизит потребность в кодерах.

Поэтому на мой взгляд (опять-таки, очень поверхностный) - эта деятельность (source code review) хороша в теории, но малоповоротлива на практике. Допускаю, что сочетания высококлассных спецов Cisco и просмотр ими кода поможет сделать кастомные решения лучше (а упомянутые спецы закроют другие тикеты). Но я думаю система, при которой у меня одни спецы закрывают тикеты, а вторые - сосредоточены на коде целиком (внешние или внутренние разработчики, которым сообщены требования по надлежащей практике) - может сработать несколько эффективнее. Сейчас нахожусь в системе координат, когда для системы ERP есть внутренние разработчики и за ними "присматривает" Vanessa, а тикеты зарывает другой отдел через HelpDesk. 

Какое решение лучше - наверное то, которое стоит на пересечении кривых ROI vs risk assessment. Понимаю, что для каждой компании эта точка определеяется индивидально и может быть "плавающей" 🙂

Вчера на упомянутом предприятии при запредельной концентрации владельцев крупного бизнеса (в т.ч. и прежде всего транснационального) этот вопрос стал в полный рост, оттеняя теоретическую академичность 🙂

P.S.: для 90 % игроков фармрынка бывшего СССР это вообще абстракция, причем регуляторно допустимая - нет в GMP упоминания о code review. Ну а кто дорос до SAP, кодить кому попало ему не доверит. Если доверит - то недолго (потому что или утонет сам, или погонит "бракоделов" на ранней фазе проекта, в идеале на аудите). Скажем так - имел опыт общения (в режиме телеконференций), примерно представляю какие требования есть у вышеупомянутых представителей бигфарма. Без определенного набора регалий и компетенций вы даже не сядете за стол переговоров с ними. До кода речь вообще не дойдёт 🙂 А если дойдёт, то в вас будут 10 раз уверены до того, чтобы не ходить за вами с "веником и совком" на 10 000 транзакций. По перечиcленным категориям от Михаила Хазанчука и той же Vanessa собственно  GAMP 5 (2008 г.р.) уже устарел безнадежно, хотя методологически он выверен, на верхнем уровне. Но хочется верить, что будут современные дополнения GAMP 5 хотя бы в виде GPG, отражающие современны реалии - всё к тому идёт (AI etc.). Но пока даже GAMP GPG RDI 2020 предлагает business process mapping делать ... в MS Visio 🙂 В современном мире BI это всё равно, что предложить документ набирать на печатной машинке, а чертежи рисовать на кульмане. Обсудим это на другом мероприятии с не менее мощным составом участников: https://conference.ispe.ru/

Кстати, изменения в SAP идут немножко другим маршрутом: там, где есть кодинг, изменения из среды в среду переносит другой специалист,  не тот который делал изменения. Он должен пересмотреть код, проверить работоспособность и перенести в QUAL или отправить на доработку. 

SAP это чистое страдание для ИТ и команды поддержки SAP, изменения не успевают внедрять как уже свежие прилетают 🙂 А толковых людей не сискать на открытые вакансии. 

Но на него можно очень хорошо натравить процессы RPA, которые очень сильно экономят человеческие ресурсы.

Касательно трудозатрат на оценку кода, наверно выпало из контекста, такой роботы очень и очень не много. Такие решения это где-то до 3% во всем портфеле комп. систем, активности в большинстве случаев одноразовые при внедрении. Лишь где-то половина из них меняются или дорабатываются.

Возможно поэтому, этот процесс никого не напрягает и все видят в нем плюс, особенно безопасники ? 

Владимир, помимо того, что я рад Вас приветствовать, добавлю, что переход к исполняемым моделям BPMN 2.0 в случае SAP в теории должен снять нагрузку по изменениям - бизнес-аналитики поменяли модель - автоматически изменился код. Это в теории и только если что-то меняется именно на уровне бизнес-модели. Если нужно лезть ручками в код, то, наверное, бенефитов не будет. Как это будет на практике, опыта нет пока не только у меня, но и у известных мне представителей биг-фарма. Есть только намерения это попробовать. Вероятно кто-то уже попробовал это в США или ЕС, надо гуглить опыт.

Опубликовано: @volodymyrkoval

Такие решения это где-то до 3% во всем портфеле комп. систем, активности в большинстве случаев одноразовые при внедрении. Лишь где-то половина из них меняются или дорабатываются.

Ну при таком объеме это немного. Конечно же такой пересмотр это похвально, но при больших объемах это уже теряет всякий смысл, потому что проще эту работу выполнить своими силами, как привел пример Александр с БИОКАД.