Application note: validazione del software
Application note: validazione del software
Capita spesso che un laboratorio sottostante ispezioni secondo ISO / IEC 17025 : 2018-03 domandi un documento certificante la validazione del software acquistato, senza rendersi conto di fare una richiesta insensata…
Se andiamo a verificare la normativa, esistono due descrizioni che dobbiamo leggere bene: quella di verifica (3.8: verification) in cui si descrive come fornire evidenza oggettiva delle caratteristiche di un dato oggetto e quella di validazione (3.9: validation) in cui si va specificatamente a verificare che le specifiche di un dato oggetto siano adeguate all’uso definito.
Al paragrafo 7.11, poi, nell’ambito della gestione dei dati, si esplicita che laddove vi siano delle modifiche a software off-the-shelf, queste debbano essere autorizzate, documentate e validate prima dell’implementazione.
In Nota 2, infine, viene definitivamente chiarito che, in generale, il software commerciale off-the-shelf utilizzato nell’ambito del proprio fine deve considerarsi sufficientemente validato.
Se così non fosse, infatti, dovremmo andare a domandare a Microsoft® di validare il sistema operativo ogni volta che questo viene aggiornato(!) così come di validare Microsoft Excel o Microsoft Word prima di potere utilizzare codesti software su un PC aziendale! Nessuno ha mai pensato di farlo perché si tratta di software acquistati, proprio come i software forniti insieme alla strumentazione o anche – il ragionamento è identico – i firmware di data strumentazione! Qualcuno ha mai pensato di domandare la validazione del firmware di un multimetro? Eppure il suo utilizzo in laboratorio è molteplice!
Nota: è logico che qualsiasi software possa contenere dei bug. Microsoft® ci ha abituato agli aggiornamenti periodici che servono proprio per eliminare bug e migliorare le prestazioni. Ciò non toglie che il software sia validato e anche che un bug su un software da laboratorio off-the-shelf debba essere comunicato al produttore proprio per aiutare ad eliminare i bug.
Ricordiamo anche che occorrerebbe tenere, per ogni strumento, come da paragrafo 6.4.13 un certo numero di dati sulla scheda dello strumento:
- codici identificativi, includenti versione del firmware, software utilizzato e versione dello stesso
- nome del produttore, codice identificativo e numero di serie dello strumento
- evidenza della verifica relativa alla conformità dello strumento rispetto al fine per il quale è stato acquistato
- locazione dello strumento
- date di taratura, esiti di taratura, regolazioni eventuali, criteri di accettazione e data della taratura successiva
- documentazione dei materiali di riferimento, esiti, criteri di accettazione e dati rilevanti per il periodo di validità
- piano di manutenzione aggiornato
- dettagli riguardanti danni, malfunzionamenti, modifiche o riparazioni
Cosa succede se il software prevede che l'utente crei le normative di riferimento?
Come abbiamo già avuto modo di vedere, un software commerciale off-the-shelf non richiede validazioni da parte del produttore quanto invece una verifica da parte dell’acquirente che quanto comprato sia conforme a quanto necessario.
Questa osservazione vale vieppiù quando il software prevede già le normative cui fare riferimento: BAT-EMC propone già tutte queste normative ed altri software quali iso.control, autowave.control o net.control vantano librerie enormi costruite nel corso degli anni. Il costo di un software, infatti, non si misura tanto nello sviluppo dello stesso, quanto nella manutenzione che il produttore del software svolge continuativamente e nella continuità posta nella filosofia dello stesso.
Supponiamo infatti che uno debba utilizzare un software teoricamente completo ma in cui occorra creare le proprie curve o definire i propri limiti di emissioni: chi certifica il lavoro svolto dall’operatore? La famosa validazione di cui si scrive al par. 7.11!
Andiamo a prendere a riferimento il documento DT_02_DT di Accredia che è un’ottimo punto di partenza anche per chi non lavora in un laboratorio accreditato. Laddove al par. 7.4 di parla di “Collaudo del SW commerciale”, al par. 7.3 l’argomento è il “Collaudo e validazione del SW sviluppato”. A quest’ultimo paragrafo fanno poi seguito dei diagrammi di flusso di responsabilità di utente e sviluppatore (nel caso della creazione di una normativa su un software potrebbero essere la medesima persona, con doppia responsabilità!) ed un insieme di documenti da produrre.
Questo significa che un qualsiasi foglio Excel creato per la gestione di un processo di laboratorio così come una qualunque normativa creata sul software acquistato diventano parte di SW sviluppato e debbono seguire la trafila documentale apposita, ivi compresa la procedura di validazione.
Riassumendo, ricordiamo quindi i punti salienti che abbiamo potuto incontrare:
- Su un software acquistato non si richiede validazione. Occorre creare una scheda del software con determinati dati, ivi compresa la verifica di avere acquisito il software adeguato all’uso che si deve fare, ma non la validazione dello sviluppatore.
- Quanto vale per il software acquistato per sé, vale anche per il software acquistato insieme ad uno strumento e per il firmware.
- Su un componente progettato internamente, sia esso un foglio Excel per il calcolo di una potenza, sia esso uno scampolo di normativa, occorre sempre sviluppare la procedura che validi quanto svolto internamente e validare quindi quanto prodotto.
- A volte non si può evitare di sviluppare del software interno. Viste le informazioni che Accredia richiede vengano prodotte per essere certi del risultato, minore è l’intervento da parte del laboratorio e minore sarà il tempo passato su queste verifiche, importanti tanto quanto il calcolo delle incertezze di misura!
