Site icon Qualibus

Validazione del software Qualibus

wp-admin
ci_cd_gitlab

È disponibile, su richiesta, una Linea Guida Qualibus, per orientare i responsabili del sistema a tenere sotto controllo questo aspetto che è obbligatorio per i Clienti con sistema di gestione certificato ISO 13485.
Di seguito si riporta una sintesi della Linea Guida.

1. SCOPO E CAMPO DI APPLICAZIONE

Indicare le modalità per la validazione e rivalidazione del Software Qualibus a cura di Nord Est Systems e del Cliente, al fine di assicurare che soddisfi le specifiche a seguito della prima installazione o l’upgrade ad una nuova release e risulti conforme:

2. RIFERIMENTI

3. DEFINIZIONI

GAMP 5: Good Automated Manufacturing Practices. Costituiscono l’insieme di ‘good practices’ definite dalla commissione tecnica COP (Community Of Practice) che fa capo alla Società Internazionale di Ingegneria Farmaceutica (ISPE). L’obiettivo della comunità è quello di promuovere la comprensione del regolamento e l’uso di sistemi automatizzati entro l’industria farmaceutica.
Validazione: l’attività di controllo che risponde alla domanda “stiamo realizzando il prodotto corretto?”, che confronta un risultato dello sviluppo, anche intermedio, con i requisiti iniziali del prodotto.
Verifica: l’attività di controllo che risponde alla domanda “stiamo realizzando correttamente il prodotto?”, che mira a scoprire i difetti introdotti durante un passo di lavorazione analizzando due prodotti intermedi successivi o controllando il corretto svolgimento di un’attività di sviluppo.
Test: una tecnica di controllo che ha l’obiettivo di rivelare eventuali malfunzionamenti analizzando il comportamento di un programma mentre è eseguito in un ambiente controllato (ambiente di test) e su insiemi predefiniti di dati di ingresso. In una differente accezione, con test si identifica il particolare insieme di dati e procedure usati per verificare un programma
Bug: indica la causa di un malfunzionamento in un sistema software; in italiano è spesso tradotto per assonanza con baco
Debugging: si intende propriamente la ricerca dei bug effettuata dinamicamente ispezionando lo stato del programma durante una sua esecuzione controllata; in senso più lato debugging è sinonimo di tutta l’attività di controllo del software. Con debugger si identifica uno strumento realizzato appositamente per supportare questo tipo di attività.
Regressione: la possibilità che un programma, in seguito a una modifica dovuta a un intervento di manutenzione o a un processo di sviluppo incrementale, peggiori le proprie funzionalità. Il confronto di versioni successive dello stesso programma prende il nome di test di regressione
Affidabilità: la caratteristica di qualità di un prodotto software relativa alla sua capacità di funzionare correttamente nel tempo. Lo standard ISO 9126-1 la prevede come una caratteristica di qualità primaria, a sua volta decomposta in maturità, tolleranza ai guasti, recuperabilità.
Funzionalità: una particolare funzione o caratteristica di un prodotto software che lo rende abile a soddisfare una parte dei requisiti. In una diversa accezione del termine, la funzionalità è la caratteristica di qualità di un prodotto software relativa alla sua capacità di soddisfare i requisiti.
Efficienza: la caratteristica di qualità legata alla capacità di un prodotto software di svolgere le proprie funzionalità con un consumo minimo di risorse di calcolo. In generale l’efficienza è considerata relativamente a una particolare risorsa: tempo macchina, occupazione di memoria, occupazione di disco. Lo standard ISO 9126 distingue a questo proposito come sotto caratteristiche dell’efficienza l’efficienza nel tempo e l’efficienza delle risorse
Usabilità: la caratteristica di qualità di un prodotto software relativa alla sua possibilità di essere impiegato produttivamente da una particolare utenza. Lo standard ISO 9126 prevede l’usabilità come caratteristica di qualità primaria, a sua volta decomposta in comprensibilità, apprendibilità, operabilità.
Portabilità: la caratteristica di qualità che indica la capacità di un prodotto software di essere trasportato da un ambiente a un altro. Si prende in considerazione il problema di convertire il software affinché funzioni su una piattaforma hardware, su un sistema operativo o, più in generale, in un ambiente operativo diverso da quello per cui è stato in origine progettato e realizzato.

TIPOLOGIE DI VALIDAZIONE

La Validazione dei Sistemi Software si compone di diverse tipologie di processi (task) che possono essere applicate, del tutto o in parte sulla base delle necessità di convalida e che coinvolgono ciascuna diversi elementi progettuali. I principali task che possono essere applicati in un processo di Validazione sono:

  1. Installation Qualification (IQ) che serve a verificare che l’applicazione sia stata installata correttamente e che tutta la documentazione necessaria (ad esempio manuali utente, istruzioni di lavoro, procedure di backup, ecc.) sia corretta e disponibile per gli utilizzatori
  2. Operational Qualification (OQ) che serve a verificare che tutti i requisiti funzionali e di sicurezza siano stati opportunamente verificati sulla base di quanto definito nelle Specifiche dei Requisiti Software / Funzionali. Tali verifiche possono includere test unitari e test di integrazione.
  3. Performance Qualification (PQ) che serve a verificare che il sistema software si comporti, in termini prestazionali, come previsto, è basata sulla Specifica dei Requisiti Utente e spesso richiede la compartecipazione da parte di utilizzatori qualificati (fase di beta test), i quali devono approvare che il sistema software si comporti come previsto dagli accordi contrattuali e dalle aspettative esplicite ed implicite (cioè quelle attese anche se non dichiarate) degli utilizzatori.
  4. Maintenance Qualification (MQ) che serve a valutare l’adeguatezza dei processi di manutenzione in atto per garantire la sistematica affidabilità dei Sistema software
  5. Component Qualification (CQ) che serve generalmente a qualificare eventuali applicazioni (o parti di applicazioni) software, da integrare nel Sistema Informatico, sia di acquisto, che sono definite COTS (Component Of The Shelf), sia di provenienza sconosciuta (SOUP)

4. Progetto qualibus

Ogni nuova release del software Qualibus viene tenuta sotto controllo grazie ad uno specifico progetto.
Il processo di verifica e validazione è applicato ad ogni release del software Qualibus ed è parte integrante del processo di progettazione e sviluppo che avviene con le modalità definite nella procedura interna del Sistema Qualità Nord Est Systems srl P 08 03, che prevede in particolare le attività di:

4.1 VERIFICHE DELLA PROGETTAZIONE

Il responsabile della progettazione e sviluppo software garantisce la corretta gestione dei test anche in linea con che quanto previsto dalla norma ISO IEC 9126-1.

4.1.1 TIPI DI TEST (TYPES OF TESTS)

I tipi di test, effettuati soprattutto in fase di validazione e rilascio della nuova release, riguardano i seguenti aspetti:
1) funzionalità
2) affidabilità
3) efficienza
4) usabilità
5) manutenibilità
6) portabilità.

4.1.2 TEST AUTOMATICI

Per accelerare le verifiche ed essere certi che tutti gli aspetti da analizzare siano effettivamente verificati si fa uso anche di specifici software che automatizzano i test per identificare:
a) Eventuali malfunzionamenti
b) Comportamenti non previsti
c) Regressioni (rispetto alle versioni precedenti)

4.1.3 TEST ESTESO IN NORD EST SYSTEMS

Nord Est Systems utilizza continuamente la versione in sviluppo di Qualibus ed in questo modo effettua un test esteso “in produzione” da parte di tutti gli utenti sotto il diretto controllo degli sviluppatori.
Il test si conclude quando:

4.1.4 TEST PRESSO CLIENTI (BETA TESTER)

Al termine del test interno in Nord Est Systems, viene installata la nuova release di Qualibus anche presso clienti “beta tester”, che hanno dato la propria disponibilità a testare il software sul proprio db per almeno quattro settimane prima del rilascio definitivo della Release ufficiale.
Il test continua fino a quando:

4.1.5 REGISTRAZIONI TEST

A seguito dei test effettuati è garantita la registrazione nei dati personalizzati degli eventi Qualibus Sviluppo e/o nel progetto Qualibus compilando le relative checklist.

4.2 VALIDAZIONE, RIVALIDAZIONE E RILASCIO DELLA NUOVA RELEASE

4.2.1 GESTIONE EVENTO “VALIDAZIONE SOFTWARE QUALIBUS”

Dopo aver superato i test come indicato nel § 4.1:

  1. viene avviato un apposito evento “Validazione software Qualibus” da un modello opportunamente preconfigurato anche sulla base dei requisiti della norma ISO/TR 80002-2:2017
  2. registrato ed attuato quanto richiesto da Riferimenti, Dati personalizzati, disposizioni e comunicazioni
  3. se l’esito è positivo la nuova release viene messa a disposizione dei Clienti interessati ed in particolare a quelli con sistema certificato ISO 13485 che di conseguenza potranno aggiornare il proprio sistema
    La rivalidazione del software Qualibus avviene sistematicamente in occasione della emissione della successiva release ripercorrendo le stesse fasi sopra elencate al § 4.1.

La registrazione dei dati relativi alla validazione, rivalidazione e rilascio del software viene mantenuta anche nelle fasi con relative checklist del progetto Qualibus ed inoltre nell’evento “Validazione Software Qualibus”.

Seguendo le istruzioni indicate nel modello, le norme e istruzioni linkate nei documenti collegati, l’utente responsabile stabilisce i riferimenti da collegare ed il tipo di validazione da applicare (nel caso della rivalidazione è scelta la modalità di validazione “Completa” che prevede l’applicazione di tutte le tipologie di seguito indicate: IQ, OQ, PQ, MQ e CQ.)
Conseguentemente sono immessi e selezionati i dati personalizzati opportuni.
Per ciascuna tipologia di Validazione è predisposta una disposizione con relativa check list.

Nota: in alternativa alla Validazione completa, qualora il metodo proposto debba essere utilizzato dal cliente finale, è consigliata la Metodologia “Simultanea” che fa riferimento alle tipologie “Operational & Performance Qualification”

4.2.2 README QUALIBUS

Per ogni nuova release viene emesso un Readme che indica nel § “Validazione” almeno i seguenti dati:

  1. Riferimento alle procedure, Istruzioni e Protocolli applicabili
  2. Esito della Validazione / rivalidazione
  3. Indicazioni su come gestire al meglio la validazione dei processi configurati dal cliente

Nota: in questo modo il Cliente è sollecitato ad effettuare eventuali validazioni sui processi che lui stesso ha configurato, anche in autonomia, i cui componenti/moduli sono stati oggetto di sviluppo/modifica nella nuova release del software.

5 VALIDAZIONE E RIVALIDAZIONE PROCESSO SVILUPPATO DAL CLIENTE

5.1 PIANIFICAZIONE E SVILUPPO DI UN NUOVO PROCESSO

Quando risulti necessario configurare un nuovo processo in Qualibus, è consigliabile avviare un evento (tipicamente una Azione di Miglioramento) per pianificare e sviluppare in modo chiaro le varie fasi di analisi, configurazione, test e validazione.
Nell’evento utilizzato per tenere sotto controllo il nuovo processo configurato si deve fare particolare attenzione alla definizione delle modalità di verifica dell’efficacia (in pratica ai test) e alle modalità di validazione (in pratica i collaudi necessari a garantire il funzionamento del processo).

5.2 REGISTRAZIONE DELLA VALIDAZIONE E RIVALIDAZIONE

Per mantenere traccia della validazione e rivalidazione del processo, si consiglia l’uso dei seguenti metodi:
1) scadenzario Qualibus con una riga di programma di frequenza annuale e con una check list che permetta di registrare i test e validazioni effettuate
2) registrazione su evento “Validazione software Qualibus”

Nel primo caso potrebbe trattarsi di una riga di programma che ricordi all’esecutore l’impegno che comparirà sul proprio Calendar e che potrà essere chiuso mantenendo traccia sia delle singole righe di check list che della validazione e rivalidazione annuale del processo.

Nel secondo caso si potrà fare riferimento ad un evento classe “Validazione Software Qualibus” avviato in occasione di una nuova release del software oppure a seguito della introduzione di un nuovo processo configurato autonomamente dal Cliente, tipicamente duplicando quello precedente ed apportando le opportune modifiche/registrazioni.

Exit mobile version