Si ringrazia l'Ing. Marta Barberis, Site Manager CSV di Adeodata srl, per la consulenza e il materiale fornito.
Nel mondo informatico si sta sempre più sviluppando un nuovo approccio allo sviluppo dei software che ha le sue basi nel Manifesto for Agile Software Development ed ha la finalità di fornire al cliente un software funzionante e di qualità in modo tempestivo.
Il metodo Agile antepone il buon funzionamento del software alla produzione di documentazione esaustiva e promuove la collaborazione e il dialogo continuo e costante tra cliente e implementatore/fornitore del software.
Il metodo Agile introduce particolari benefici nei contesti in cui non è possibile individuare a priori tutte le specifiche (tecniche, implementative dello sviluppo, funzionali, user requirements) di progetto e nei casi in cui i flussi di processo non sono adeguatamente strutturati. Si contrappone quindi al modello a cascata, proponendo un approccio meno strutturato ma che consente una consegna rapida e graduale del software al cliente.
I 12 principi del manifesto
LA METODOLOGIA SCRUM
I 12 principi possono essere declinati con varie metodologie, la più diffusa è la metodologia SCRUM.
Il metodo Agile-SCRUM riduce il rischio di fallimento globale del progetto attraverso il miglioramento continuo del software e parziali rilasci.
Il software viene sviluppato tramite cicli di sviluppo brevi chiamati sprint. Ogni sprint è un progetto a sé stante che deve comunque contenere tutto ciò che è necessario per rilasciare delle funzionalità nel software: pianificazione, analisi dei requisiti progettazione, implementazione, test e documentazione.
Il risultato di ogni sprint può non esaudire completamente l’obiettivo globale del progetto, ma è nel susseguirsi degli sprint che il software prende forma avvicinandosi sempre più, o addirittura superando, le aspettative del cliente.
I software impiegati in ambito farmaceutico e sviluppati con l’approccio Agile sono poco adatti alla convalida secondo il classico modello a V proposto dalle GAMP5.
Modello di convalida a V
LE CRITICITÀ
Le principali obiezioni derivano dalle seguenti criticità:
- gli user requirements non sono adeguatamente dettagliati nelle fasi iniziali del progetto;
- le specifiche di implementazione e di sviluppo non sono presenti nelle fasi iniziali del progetto;
- il rilascio delle funzionalità del sistema (o del progetto) è frastagliato e distribuito nel tempo;
- la pianificazione delle attività/fasi di progetto, non essendo fattibile definire dei milestone di deliverables a priori, diventa incerta;
- è richiesto un impegno costante e continuo del team di progetto (committenti, sviluppatori e società di convalida devono lavorare insieme costantemente per tutta la durata del progetto).
GLI APPROCCI ALLA CONVALIDA
Per convalidare quindi i software sviluppati con questo metodo occorre sviluppare delle metodologie di validazione anch’esse “Agile”.
In quest’ottica si propongono due approcci:
- un approccio “convalida Agile pura”
- un approccio “convalida Agile ibrida”
L’approccio di convalida Agile pura ben si presta ai progetti di convalida di software in ambito farmaceutico (ma anche medical device) per la gestione dei change di sistema, per la convalida e mantenimento dei sistemi SaaS (in cloud), nei progetti in cui si prevedono più go-live di processi o di moduli del software.
L’approccio di convalida Agile ibrida (più simile al metodo tradizionale suggerito dalle GAMP5) è applicabile nei progetti di implementazione del software in cui si prevede un susseguirsi di sprint ma il passaggio in produzione (go-live) del sistema è unico (convalida iniziale del software, upgrade del software, ..).
Il punto nodale per entrambi i casi sta nella definizione iniziale dei pacchetti di rilascio del software (sprint unico o insieme di sprint) e nell’approcciare ogni rilascio come se fosse la conclusione di un prototipo da convalidare.
I pacchetti di rilascio sono da intendersi come degli insiemi di sprint (oppure uno sprint unico se comprende implementazioni critiche e significative) che vengono opportunamente raggruppati tra loro in base a necessità/priorità di utilizzo del sistema da parte dal cliente, oppure in base a processi, oppure ancora in base ad argomentazioni/moduli del sistema.
E’ di rilevante importanza quindi definire preventivamente il contenuto dei pacchetti perché questo permette di: iniziare ad ipotizzare un programma di implementazione e convalida, identificare l’approccio di convalida più opportuno e, soprattutto, analizzare preventivamente l’impatto che ogni singolo pacchetto rilasciato può avere su parti del sistema già implementate e convalidate, prevedendo fin da subito la necessità delle verifiche di non regressione.
LA CONVALIDA AGILE PURA
L’approccio “Convalida Agile pura” prevede:
- un Validation Plan unico definito all’inizio del progetto dove viene descritta la strategia Agile pura.
- Un documento di User Requirements, Risk Analysis e Traceability Matrix dove è definito l’intended use del sistema che man mano si incrementa e/o aggiorna ad ogni rilascio di pacchetto del software.
- Un protocollo di IQ unico (se necessario) con lo scopo di registrare le componenti hardware e software di base e di effettuare le verifiche di data integrity.
- Un protocollo di IOQ per ogni sprint-pacchetto di rilascio contenete i test per registrare la baseline del sistema, i test di verifica e di sfida relativi alle funzioni rilasciate; all’occorrenza il protocollo deve contenere anche eventuali test di non regressione su funzionalità già verificate in sprint precedenti.
- Un protocollo di PQ per ogni pacchetto rilasciato con test di verifica dei flussi specifici da individuare di volta in volta in base all’ambito dello sprint (oltre ai tipici test di verifica di procedure, addestramento, …).
- un Validation Report che man mano si incrementa e/o aggiorna ad ogni rilascio di pacchetto del software.
Approccio Agile puro alla convalida
LA CONVALIDA AGILE IBRIDA
L’approccio “Convalida Agile ibrida” prevede:
- un Validation Plan unico definito all’inizio del progetto dove viene descritta la strategia Agile ibrida.
- Un documento di User Requirements, Risk Analysis e Traceability Matrix che descrive l’intended use del sistema, inizialmente definito ad alto livello e dettagliato e aggiornato ad ogni rilascio di pacchetto del software, per arrivare alla versione finale all’ultimo sprint.
- Un protocollo di IQ unico (se necessario) con lo scopo di registrare le componenti hardware e software di base e di effettuare le verifiche di data integrity.
- Un protocollo di IOQ unico contenete i test per registrare la baseline del sistema, i test di verifica e di sfida relativi alle funzioni rilasciate in tutti gli sprint.
- Il protocollo di IOQ è inizializzato al primo sprint, incrementato nei test che contiene e nelle relative esecuzioni ad ogni sprint successivo, per arrivare alla versione finale all’ultimo pacchetto rilasciato.
- Un protocollo di PQ unico contenente la verifica dei flussi di processo applicabili al contesto finalizzati a verificare il comportamento del sistema integralmente (oltre ai tipici test di verifica di procedure, addestramento, …).
- Un Validation Report unico a chiusura del processo di convalida.
Approccio Agile ibrido alla convalida
I VANTAGGI
Dunque, l’approccio Agile nell’implementazione di un software unito all’approccio agile della convalida (mandatoria nell’ambito farmaceutico) permette alle aziende committenti di:
- iniziare ad utilizzare il sistema in tempi brevi grazie alla pianificazione dei pacchetti di rilascio;
- avere una documentazione di convalida (URS, RA, TM) sempre aggiornata;
- apprendere dei criteri di valutazione del rischio riproducibili ad ogni rilascio;
- testare i pacchetti di rilascio prima della formalizzazione della documentazione di convalida attraverso l’esecuzione informale (dry run) dei protocolli di IOQ;
- migliorare le performance attese dal software;
- accrescere il livello di confidenza di chi è deputato in azienda a gestire il software e mantenerlo nello stato convalidato attraverso la costante collaborazione tra fornitore del software e società di convalida.
In conclusione, la convalida di un software sviluppato con la metodologia Agile è possibile e vantaggiosa perché, nelle aziende che decidono di utilizzarla, apre nuove opportunità di miglioramento delle competenze di gestione e di controllo del software attraverso strumenti/processi sostenibili e facilmente fruibili.
Articolo a cura di Giulia Colombo, Communication & Events Specialist di Quality Systems
Scopri i nostri servizi di convalida di sistemi computerizzati
Leggi altre GMP NEWS di Quality Systems
