Cas de migration du module V&V et correspondance des champs

Dans le cadre de la transition vers le nouveau module V&V, nous nous préparons à migrer vos données de vérification existantes — y compris les méthodes de vérification, les méthodes de vérification des composants et les procédures de test — vers le flux de travail mis à jour du module V&V.

Dans les versions précédentes, nous avons introduit dans le module V&V des champs alignés sur ceux de l’ancienne méthodologie de vérification. En nous appuyant sur l’analyse des données clients, nous avons identifié les cas d’usage les plus courants et élaboré une stratégie structurée pour migrer vos données existantes vers le nouveau module.

Notre plan de migration couvre sept scénarios distincts.

Nous attendons avec intérêt vos retours afin de nous assurer que la migration répond à vos exigences spécifiques.

Cas 1 : méthode de vérification des composants vers le champ « Applicable block »

Dans l’ancien flux de vérification, les composants étaient liés aux exigences via les méthodes de vérification associées à chaque exigence.

Dans le nouveau module V&V, ce processus a été simplifié. Les utilisateurs peuvent désormais ajouter directement des composants/blocs aux exigences à l’aide de l’attribut « Applicable Blocks ». Lors de la migration, tous les composants liés aux méthodes de vérification dans l’ancien flux seront automatiquement transférés vers l’attribut « Applicable Blocks » des exigences correspondantes.

Cas 2 : méthodes de vérification des exigences (RVM) vers le champ « Methods »

Certains clients ont utilisé les Requirement Verification Methods (RVM) pour étiqueter le type de vérification prévu pour une exigence à l’avenir, avec ou sans ajout d’une Component Verification Method (CVM) ou de données supplémentaires.

Dans ce cas, le processus de migration copiera les noms des RVM et les transférera vers le nouveau “Methods” dans le tableau des exigences.

Cas 3 : méthodes de vérification par défaut vers les méthodes VV

Dans l’ancien système de vérification, il existe cinq méthodes de vérification par défaut : Analysis, Review, Rules, Inspection et Tests. En outre, les utilisateurs avaient la possibilité d’ajouter des méthodes de vérification personnalisées via le Verification Methods Settings.

Ces méthodes de vérification seront migrées vers le champ Methods du module Verifications and Validations (V&V).
 

Cas 4 : méthode de vérification Rules vers les règles VV

Dans les anciennes méthodes de vérification, les utilisateurs pouvaient appliquer la méthode de vérification Rules à une exigence et définir une formule booléenne dans le type Close-Out Reference. Cette formule était utilisée pour comparer les valeurs de l’exigence aux valeurs de conception du système.

Dans le nouveau module V&V, ces données seront migrées directement vers l’attribut V&V Rules du module des exigences.

Cas 5 : chaque procédure de test est migrée comme une nouvelle activité V&V

Pour les utilisateurs qui utilisent les procédures de test et les exécutions de test, chaque procédure de test sera migrée comme une nouvelle activité V&V avec toutes les procédures, exécutions et liens vers les exigences et les composants/blocs.

Une illustration est présentée dans l’image ci-dessous

Cas 6 : les RVM avec des CVM ayant le même fichier ou la même analyse comme référence de clôture sont compilés et migrés comme une nouvelle activité V&V

Lors de la gestion de plusieurs RVM liés à la même activité de variation, les clients doivent actuellement créer des RVM distincts pour chaque exigence associée, ce qui les oblige souvent à joindre à plusieurs reprises le même fichier et à saisir les mêmes données associées dans ces RVM.

Pour simplifier cela, le processus de migration identifiera les fichiers ou analyses joints comme références de clôture dans les références de clôture des CVM sur plusieurs exigences. Ceux-ci seront regroupés dans une seule activité V&V. Toutes les exigences et tous les composants/blocs associés seront ajoutés comme éléments de Verification & Validation (V&V), et les fichiers seront téléversés directement dans l’activité V&V consolidée. Cela garantit une manière plus efficace et centralisée de gérer les données et fichiers associés.

Cas 7 : regroupement des paires RVM/CVM restantes en activités

La dernière étape consolide toutes les paires RVM/CVM restantes en activités, avec des noms d’activité dérivés des méthodes de vérification associées. Le processus de regroupement fonctionne comme suit :

1. Manual Verification Method

   • Pour les VM ayant une référence de clôture de Manual, une activité est créée en utilisant le même nom (Manual).

   • Tous les RVM et CVM partageant la méthode de vérification Manual sont représentés comme éléments dans cette activité.

2. File or Analysis Verification Method

   • Pour les VM ayant une référence de clôture de File ou Analysis qui incluent des RVM et des CVM mais sans pièce jointe de fichier ou d’analyse :

     • Une activité est créée avec le nom File ou Analysis.

     • Tous ces RVM et CVM sont inclus comme éléments dans l’activité correspondante.

3. Test Verification Method

   • Pour les VM ayant une référence de clôture de Test où des RVM et des CVM existent mais où aucun test n’est lié :

     • Une activité est créée avec le nom Test.

     • Tous ces RVM et CVM sont ajoutés comme éléments dans cette activité.

4. RVMs Without CVMs

   • Les RVM qui n’ont pas de CVM associés sont représentés dans le nouveau flux de travail comme des éléments au sein de leurs activités respectives, mais sans composant/bloc lié.

Cette approche structurée garantit que tous les RVM et CVM sont pris en compte et organisés de manière claire et gérable, en cohérence avec leurs méthodes de vérification.

Migrations : correspondance des champs

Chaque objet, tel que les procédures de test, les RVM ou les CVM, comprend des champs supplémentaires pouvant contenir des informations critiques. Lors de la migration, ces champs seront conservés et mappés vers leurs champs correspondants dans le nouveau module V&V. Vous trouverez ci-dessous un aperçu de la manière dont vos champs existants seront migrés :
 

Edge Case:

Les tâches, discussions et abonnements sur les CVM, RVM, étapes de test, exécutions de test et procédures de test ne seront pas migrés vers le nouveau module V&V.

Les relations parent-enfant dans l’arborescence des méthodes de vérification ne sont pas non plus exportées.