Casi di migrazione del modulo V&V e mappatura dei campi

Nell’ambito della transizione al nuovo modulo V&V, ci stiamo preparando a migrare i dati di verifica esistenti, inclusi metodi di verifica, metodi di verifica dei componenti e procedure di test, nel flusso di lavoro aggiornato del modulo V&V.

Nelle versioni precedenti, abbiamo introdotto nel modulo V&V campi allineati a quelli della vecchia metodologia di verifica. Sfruttando l’analisi dei dati dei clienti, abbiamo identificato i casi d’uso più comuni e sviluppato una strategia strutturata per migrare i dati esistenti al nuovo modulo.

Il nostro piano di migrazione copre sette scenari distinti.

Attendiamo con interesse il vostro feedback per assicurarci che la migrazione soddisfi i vostri requisiti specifici.

Caso 1: Metodo di verifica del componente nel campo “Applicable block”

Nel vecchio flusso di lavoro di verifica, i componenti erano collegati ai requisiti tramite i metodi di verifica associati a ciascun requisito.

Nel nuovo modulo V&V, questo processo è stato semplificato. Gli utenti possono ora aggiungere direttamente componenti/Block ai requisiti utilizzando l’attributo “Applicable Blocks”. Durante la migrazione, tutti i componenti collegati ai metodi di verifica nel vecchio flusso di lavoro verranno trasferiti automaticamente all’attributo “Applicable Blocks” dei requisiti corrispondenti.

Caso 2: Requirement Verification Methods (RVM) nel campo “Methods”

Alcuni clienti hanno utilizzato i Requirement Verification Methods (RVM) per etichettare il tipo di verifica previsto per un requisito in futuro, con o senza l’aggiunta di un Component Verification Method (CVM) o di dati aggiuntivi.

In questo caso, il processo di migrazione copierà i nomi degli RVM e li trasferirà nel nuovo campo “Methods” nella tabella dei requisiti.

Caso 3: Metodi di verifica predefiniti in VV Methods

Nel vecchio sistema di verifica sono presenti cinque metodi di verifica predefiniti: Analysis, Review, Rules, Inspection e Tests. Inoltre, gli utenti avevano la possibilità di aggiungere metodi di verifica personalizzati tramite Verification Methods Settings.

Questi metodi di verifica verranno migrati nel campo Methods all’interno del modulo Verifications and Validations (V&V).
 

Caso 4: Rules Verification Method in VV Rules

Nei vecchi metodi di verifica, gli utenti potevano applicare il metodo di verifica Rules a un requisito e definire una formula booleana nel tipo Close-Out Reference. Questa formula veniva utilizzata per confrontare i valori del requisito con i valori di progettazione del sistema.

Nel nuovo modulo V&V, questi dati verranno migrati direttamente nell’attributo V&V Rules all’interno del modulo dei requisiti.

Caso 5: Ogni procedura di test viene migrata come una nuova attività V&V

Per gli utenti che hanno utilizzato procedure di test e test run, ogni procedura di test verrà migrata come una nuova attività V&V con tutte le procedure, le esecuzioni e i collegamenti a requisiti e componenti/block.

Un’illustrazione è mostrata nell’immagine seguente

Caso 6: Gli RVM con CVM che hanno lo stesso file o la stessa analisi come riferimento di chiusura vengono raggruppati e migrati come una nuova attività V&V

Quando si gestiscono più RVM collegati alla stessa attività di variazione, i clienti attualmente devono creare RVM separati per ciascun requisito correlato, spesso dovendo allegare ripetutamente lo stesso file e inserire gli stessi dati associati in tali RVM.

Per semplificare questo processo, la migrazione identificherà i file o le analisi allegati come riferimenti di chiusura nei riferimenti di chiusura dei CVM su più requisiti. Questi verranno raggruppati in un’unica attività V&V. Tutti i requisiti e i componenti/block correlati verranno aggiunti come elementi di Verification & Validation (V&V), e i file verranno caricati direttamente all’interno dell’attività V&V consolidata. Questo garantisce un modo più efficiente e centralizzato di gestire dati e file correlati.

Caso 7: Raggruppamento delle coppie RVM/CVM rimanenti in attività

L’ultimo passaggio consolida tutte le restanti coppie RVM/CVM in attività, con nomi delle attività derivati dai metodi di verifica associati. Il processo di raggruppamento funziona come segue:

1. Manual Verification Method

   • Per i VM con un riferimento di chiusura di Manual, viene creata un’attività con lo stesso nome (Manual).

   • Tutti gli RVM e i CVM che condividono il metodo di verifica Manual sono rappresentati come elementi all’interno di questa attività.

2. File or Analysis Verification Method

   • Per i VM con un riferimento di chiusura di File o Analysis che includono RVM e CVM ma non hanno un allegato di file o analisi:

     • Viene creata un’attività con il nome File o Analysis.

     • Tutti questi RVM e CVM sono inclusi come elementi nell’attività corrispondente.

3. Test Verification Method

   • Per i VM con un riferimento di chiusura di Test in cui esistono RVM e CVM ma non è collegato alcun test:

     • Viene creata un’attività con il nome Test.

     • Tutti questi RVM e CVM vengono aggiunti come elementi all’interno di questa attività.

4. RVMs Without CVMs

   • Gli RVM che non hanno CVM associati sono rappresentati nel nuovo flusso di lavoro come elementi all’interno delle rispettive attività, ma senza un componente/block collegato.

Questo approccio strutturato garantisce che tutti gli RVM e i CVM siano presi in considerazione e organizzati in modo chiaro e gestibile, in linea con i rispettivi metodi di verifica.

Migrazioni: mappatura dei campi

Ogni oggetto, come procedure di test, RVM o CVM, include campi aggiuntivi che possono contenere informazioni critiche. Durante la migrazione, questi campi verranno preservati e mappati ai campi corrispondenti nel nuovo modulo V&V. Di seguito è riportata una panoramica di come verranno migrati i campi esistenti:
 

Edge Case:

Attività, discussioni e sottoscrizioni su CVM, RVM, fasi di test, esecuzioni di test e procedure di test non verranno migrate nel nuovo modulo V&V.

Anche le relazioni padre-figlio nell'albero dei metodi di verifica non vengono esportate.