Precedente :: Successivo |
Autore |
Messaggio |
ogelmaciste Nuova recluta del forum
Registrato: 16/03/11 17:27 Messaggi: 16 Residenza: Lombardia
|
Inviato: Ven Mar 18, 2011 10:12 am Oggetto: Validazione SW Open Source |
|
|
Ciao a tutti,
volevo confrontarmi con voi riguardo alla validazione di SW open Source, in particolare Subversion.
Qualcuno mi potrebbe dare qualche consiglio sui test case da effettuare.
Grazie |
|
Top |
|
|
|
|
QualitiAmo - Alberto Moderatore
Registrato: 10/11/09 11:26 Messaggi: 4567
|
|
Top |
|
|
QualitiAmo - Stefania Moderatore
Registrato: 16/09/07 18:37 Messaggi: 26589
|
|
Top |
|
|
ogelmaciste Nuova recluta del forum
Registrato: 16/03/11 17:27 Messaggi: 16 Residenza: Lombardia
|
Inviato: Lun Mar 21, 2011 11:15 am Oggetto: |
|
|
Non c'è problema mi rendo conto che l'argomento non sia dei più usuali..
A fronte di una richiesta di una casa farmaceutica(a seguito di un audit) c'è stato richiesto di validare il sistema Subversion.
Io in linee generali ho strutturato le attivitò come seguono:
-Validation Plan
-Documento di specifiche funzionali e di design
-Test Plan
-IQ
-OQ
-PQ
I test case che ho impostato vanno a verificare le funzionalità riportate nel documento di specifica..
I miei dubbi sono legati alla tipologia del SW, essendo un open source il codice sorgente è a disposizione di tutti in internet, secondo voi a senso effettuare la revisione del codice sorgente come una delle attività in fase di validazione?
Secondo me no.. |
|
Top |
|
|
2p71828 Qualità è precisione
Registrato: 31/10/08 17:43 Messaggi: 2750
|
Inviato: Lun Mar 21, 2011 1:09 pm Oggetto: |
|
|
ciao,
non sono un esperto di software , più che altro sono un utilizzatore che sfortunatamente ha un componente in gmp farmaceutico e quindi con il software in gamp.
per i fogli di excel ho trovato diversa letteratura per la validazione e i requisiti che essi devono dimostrare
per un software open source a naso vedrei:
le caratteristiche soddisfano le richieste gmp/gamp/fda? (esempio password, durata della password, sessione, log etc)
analisi del rischio sui bug rilevati in rete e suo aggiornamento
controllo e mantenimento della tracciabilità della versione (MD5) _________________ =fixed(exp(1);5)
sha-1=661bf49e78e9d958032859e811fa1ca27699207a |
|
Top |
|
|
filippo1974 Forumista di Qualità
Registrato: 19/10/10 12:39 Messaggi: 338 Residenza: North east of Italy
|
Inviato: Lun Mar 21, 2011 2:07 pm Oggetto: |
|
|
Eccolo qua...
mi sentivo fischiare un orecchio e ho pensato che qualcuno di qui mi cercasse hahahahahahaha
Dunque, validazione di SVN (acronimo di Subversion). Bella storia, SVN non è proprio un software da due soldi.
La "validazione" ha un significato ben preciso, e cioè consiste nella verifica che il prodotto (software o meno che sia) nel suo complesso soddisfi i requisiti espliciti e impliciti del cliente. In ciò si distingue dalla verifica, che è l'accertamento della rispondenza ai requisiti tecnici fissati per la sua realizzazione. Quindi, verificare vuol dire accertare che quanto realizzato sia conforme alla sua progettazione; validare vuol dire accertare che quanto realizzato faccia realmente quello che il cliente desidera.
Quindi, step 1: farsi un bell'elenco di quali siano i vostri requisiti e le vostre aspettative come utenti di SVN. Nel caso specifico, alcuni esempi frequenti di requisiti per un sistema di sviluppo concorrente (com'è appunto SVN) sono:
- Supportare il versionamento e il tracciamento non solo di codice sorgente, ma anche di materiale documentale.
- Offrire una gestione delle credenziali per controllare chi può fare cosa.
- Supportare l'assegnazione esclusiva di un file sorgente in modo da prevenire conflitti in caso di modifica concorrente di uno stesso sorgente da parte di due o più sviluppatori; oppure, fornire alert nel caso di commit concorrente da parte di due o più sviluppatori su file sorgente contenenti modifiche in conflitto tra loro.
... e molto altro.
Sulla base della lista dei requisiti vostri, lo step successivo è di dare a ciascun requisito una priorità. Requisiti di importanza più elevata dovranno essere validati da un numero maggiore di test case.
Ciascun test case sarà una "lista della spesa" che mostrerà qual'è lo scopo del test (quale funzione del prodotto, o più in generale quale attributo - robustezza, funzionalità, prestazioni, ecc.), quali i passi per condurre il test e quale risultato atteso.
Importantissimo: prevedere una congrua "dose" di test case "distruttivi", ovvero volti esplicitamente a valutare e validare la robustezza del prodotto intesa come capacità di recuperare un accettabile livello di funzionalità a seguito di eventi disastrosi (crash del server, errori di salvataggio informazioni, ecc.). Questi test case rispondono ad un requisito talmente implicito che nessuno lo cita mai, e cioè l'affidabilità del prodotto. Quindi: prevedere test case dove il server SVN viene deliberatamente messo off-line, magari durante un commit, e verificare eventuali corruzioni che possono essersi verificate; verificare se il prodotto supporta nativamente delle procedure di backup e disaster recovery, in caso contrario testare e documentare una procedura che consenta di ottenere una accettabile (per la vostra organizzazione) affidabilità dei dati. La procedura deve includere un backup completo e suo successivo ripristino, nonché un piano di rollback (cioè verificare se in caso di errore irreversibile durante un backup il sistema può comunque continuare a funzionare o, in caso contrario, cosa si deve fare per ripristinarne la funzionalità).
Ci sarebbe da dirne ancora un sacco, per ora mi fermo qui, spero di aver dato almeno un'idea generale.
Ciao
Filippo _________________ Filippo
Quality System Manager
"E' facile trovare le colpe. E' cercare di fare meglio che può essere difficile." - Plutarco |
|
Top |
|
|
ogelmaciste Nuova recluta del forum
Registrato: 16/03/11 17:27 Messaggi: 16 Residenza: Lombardia
|
Inviato: Lun Mar 21, 2011 4:03 pm Oggetto: |
|
|
Inizio a ringraziarvi per le risposte.
Proprio come mi avete suggerito ho proceduto..
L'unico punto non in accordo con Filippo è che il sistema essendo già istallato e funzionante in azienda(legacy system) non è stato oggetto di URS ma nelle Functional e Design Specifications sono state illustrate le funzionalità del sistema che poi saranno verificate in qualifica.
I test che ho predisposto sono stati:
IQ: -Verifica dell'ambiente di istallazione -Verifica della versione istallata-Verifica della documentazione tecnica(manuali-verifica presenza training operatori
OQ:Verifica degli accessi e permessi in Sub -Verifica delle Funzionalità del sistema(commit, merge...ecc)vs funzionalità descritte nelle FDS -Verifica delle tracciatura delle modifiche - Verifica dei dati a seguito di blac out -Verifica della struttura del repository- verifica accessi al repository
PQ: verifica della presenza di procedure per il mantenimento e l'uso del sistema(SOP Disaster, Back up, Sicurezza logica, CH...ecc..)
Trovo molto interessante ciò che mi ha consigliato 2p...analisi del rischio sui bug rilevati |
|
Top |
|
|
2p71828 Qualità è precisione
Registrato: 31/10/08 17:43 Messaggi: 2750
|
Inviato: Lun Mar 21, 2011 7:54 pm Oggetto: |
|
|
mi intrometto solo per capire qualcosa di un mondo che solo sfioro.
Pensavo che nel caso in cui SVN non facesse parte del pacchetto che vendo al cliente ma sia uno dei mezzi che utilizzo per produrre il software per il cliente (software quest'ultimo che necessita sì di IQ, OQ, e PQ per sua sfiga) dovessi limitarmi agli impatti che possa avere sul prodotto finito più che sulle sue reali prestazioni/caratteristiche ovvero fintanto che preserva l'integrità del codice durante lo sviluppo verso intrusioni di utenti non autorizzati, codice non validato nel repository di quello che ha già superato una fase di validazione etc) correre il rischio che in un crash del server perda l'ultima versione e debba ripartire dalla penultima è un problema interno che non dovrebbe inferire sulle prestazioni del prodotto finito.
Se invece affido/utilizzo SVN anche per la gestione dell'IQ/OQ/PQ del software "venduto" e la gestione del ciclo di vita (aggiornamenti negli anni) dello stesso, allora penserei come Filippo con una validazione più pesante.
Tuttavia essendo opensource pregi e difetti sono di pubblico dominio quindi parecchio lavoro dovrebbe essere già disponibile ed sia solo da verificare se rispondente alle richieste "anomale" del gamp/gmp _________________ =fixed(exp(1);5)
sha-1=661bf49e78e9d958032859e811fa1ca27699207a |
|
Top |
|
|
ogelmaciste Nuova recluta del forum
Registrato: 16/03/11 17:27 Messaggi: 16 Residenza: Lombardia
|
Inviato: Gio Mar 24, 2011 1:42 pm Oggetto: |
|
|
le GAMP 5 e il nuovo Annex 11 che entrerà tra poco in vigore si pone l'attenzione su 3 aspetti relativamente ai sistemi computerizzati: -salute del paziente - qualità del prodotto e integrità dei dati.
Ritengo che sia fondamentale quindi valutare e considerare l'integrità dei dati come un punto fondamentale, è quindi necessario considerare cosa avviene in caso di black out e avere procedure di back-up e disaster recovery.
Mi permetto di non essere d'accordo con quello che hai detto, perdere l'ultima versione è un grave danno, vorrebbe dire perdere una versione già rilasciata (e consegnata al cliente) perdendo la tracciabilità di questa con tutti i problemi che ne conseguono.
Ciao! |
|
Top |
|
|
2p71828 Qualità è precisione
Registrato: 31/10/08 17:43 Messaggi: 2750
|
Inviato: Gio Mar 24, 2011 5:52 pm Oggetto: |
|
|
ogelmaciste ha scritto: |
Mi permetto di non essere d'accordo con quello che hai detto, perdere l'ultima versione è un grave danno, vorrebbe dire perdere una versione già rilasciata (e consegnata al cliente) perdendo la tracciabilità di questa con tutti i problemi che ne conseguono. |
forse stiamo dicendo la stessa cosa. Se il programma è stato rilasciato al cliente sei nel caso che io prevedevo scrivendo "Se invece affido/utilizzo SVN anche per la gestione dell'IQ/OQ/PQ del software "venduto" e la gestione del ciclo di vita (aggiornamenti negli anni) dello stesso, allora penserei come Filippo con una validazione più pesante."
p.s.
svn mi ha incuriosito per cui stiamo valutando una sua possibile applicazione con Turtoise nella gestione della documentazione e nelle varie prove abbiamo riscontrato alcuni limiti: 1) turtoise permette la memorizzazione della password (cosa non ammessa dalla FDA) 2) alcuni tipi di file vengono visti come binari o mal gestiti (esempio fogli di calcolo) nel caso di contemporaneo utilizzo da parte di più utenti. _________________ =fixed(exp(1);5)
sha-1=661bf49e78e9d958032859e811fa1ca27699207a |
|
Top |
|
|
ogelmaciste Nuova recluta del forum
Registrato: 16/03/11 17:27 Messaggi: 16 Residenza: Lombardia
|
Inviato: Ven Mar 25, 2011 10:43 am Oggetto: |
|
|
In questo momento sto redigendo i test case e ancora non ho iniziato a testare!
Ti dirò |
|
Top |
|
|
ogelmaciste Nuova recluta del forum
Registrato: 16/03/11 17:27 Messaggi: 16 Residenza: Lombardia
|
Inviato: Mer Mar 30, 2011 3:05 pm Oggetto: |
|
|
Hai ragione c'è la cache di autenticazione..
Non è compliant al CFR 21 part 11..scriverò sul manuale di utilizzo di non memorizzare le credenziali...
Utilità= a zero.. |
|
Top |
|
|
2p71828 Qualità è precisione
Registrato: 31/10/08 17:43 Messaggi: 2750
|
Inviato: Mer Mar 30, 2011 5:43 pm Oggetto: |
|
|
se deciderò di adoperarlo penso che modificherò l'interfaccia: in GMP non mi ammetterebbero anche la sola possibilità di salvare la password _________________ =fixed(exp(1);5)
sha-1=661bf49e78e9d958032859e811fa1ca27699207a |
|
Top |
|
|
|