V&Vモジュール移行事例とフィールドマッピング

新しいV&Vモジュールへの移行の一環として、既存の検証データ（検証方法、コンポーネント検証方法、テスト手順を含む）を、更新されたV&Vモジュールのワークフローに移行する準備を進めています。

旧バージョンでは、V&Vモジュールに旧検証方法のフィールドと一致するフィールドを導入しました。顧客データ分析を活用して、一般的な使用事例を特定し、既存のデータを新しいモジュールに移行するための構造化された戦略を開発しました。

当社の移行計画は、7つのシナリオをカバーしています。

移行がお客様固有の要件に適合するよう、お客様からのフィードバックをお待ちしております。

ケース 1：「適用ブロック」フィールドへのコンポーネント検証方法

旧検証ワークフローでは、コンポーネントは、各要件に関連付けられた検証方法を通じて要件にリンクされていました。

新しい V&V モジュールでは、このプロセスが合理化されました。ユーザーは、"Applicable Blocks" 属性を使用して、コンポーネント/ブロックを要件に直接追加できるようになりました。移行中、旧ワークフローで検証方法にリンクされたコンポーネントは、対応する要件の "Applicable Blocks" 属性に自動的に転送されます。

ケース 2：要件検証方法（RVM）を「方法」フィールドに追加する

一部のユーザーは、 要件検証方法 （Requirement Verification Methods：RVM）を使用して、 コンポーネント検証方法 （Component Verification Method：CVM）や追加デー タ を追加 し た場合 と し ない場合で、 将来、 要件に対 し て意図 さ れ る 検証の種類を ラ ベル付け し てい ます。

こ の場合、 移行処理では、 RVM 名を コ ピー し て、 要件テーブルの新 し い フ ィ ール ド に転送 し ます。 “Methods”フィールドに転送します。

ケース 3: デフォルトの検証方法を VV の方法に変更する

旧検証システムでは、5つのデフォルト検証方法がある： Analysis, Review, Rules, Inspectionそして Tests.さらに、ユーザは Verification Methods Settings.

これらの検証方法は、Verifications and Validid (V&V)モジュール内の Methodsフィールドに移行される。

ケース 4：VV ルールへのルール検証方法

旧検証方法では、ユーザーは要件に検証方法を適用し、ブール式を定義することができました。 Rules型にブール式を定義することができます。 Close-Out Reference型にブール式を定義します。この式を使用して、要件値とシステム設計値を比較した。

新しい V&V モジュールでは、 こ のデー タ は直接、 要件モジ ュ ール内の V&V Rules属性に直接移行されます。

ケース 5：各テスト手順を新しい V&V アクティビティとして移行する

テスト手順とテスト実行を使用していたユーザーの場合、各テスト手順は、すべての手順、実行、および要件と コンポーネント/ブロックへのリンクを含む新しい V&V アクティビティとして移行されます。

下図を参照

ケース 6：同じファイルまたは分析をクローズアウト参照として持つCVMを持つRVMがコンパイルされ、新しいV&Vアクティビティとして移行されます。

同じ変動アクティビティにリンクされた複数のRVMを管理する場合、お客様は現在、関連する要件ごとに個別のRVMを作成する必要があり、多くの場合、それらのRVMにわたって同じファイルを添付し、同じ関連データを入力することを繰り返す必要があります。

これを効率化するために、移行プロセスでは、CVM のクローズアウト参照で、複数の要件にわたってクローズアウト参照として添付されているファイルまたは分析を識別します。これらは、単一の V&V アクティビティにグループ化される。関連するすべての要件とコンポーネント/ブロックは、検証・妥当性確認（V&V）項目として追加され、ファイルは統合されたV&V活動内に直接アップロードされます。これにより、関連データとファイルをより効率的かつ一元的に管理することができます。

ケース7：残りのRVM/CVMペアをアクティビティにグループ化する

最後のステップでは、残りのRVM/CVMペアをすべてアクティビティに統合します。アクティビティ名は、関連する検証手法に由来します。グループ化プロセスは以下のように動作します：

1. Manual Verification Method

   • のクローズアウト参照を持つ VM に対して、同じアクティビティが作成されます。 Manualのクローズアウト参照を持つ VM に対して、同じ名前 (Manual).

   • を共有するすべての RVM と CVM は、このアクティビティ内のアイテムとして表されます。 Manualは、このアクティビティ内のアイテムとして表されます。

2. File or Analysis Verification Method

   • クローズアウト参照が Fileまたは AnalysisRVMとCVMを含むが、ファイルまたは解析の添付がないもの：

     • という名前のアクティビティが作成されます。 Fileまたは Analysis.

     • このようなRVMとCVMはすべて、対応するアクティビティにアイテムとして含まれます。

3. Test Verification Method

   • のクローズアウト参照を持つVMの場合、RVMとCVMは存在するがテストはリンクされていない。 TestRVMとCVMは存在するが、テストはリンクされていない：

     • という名前でアクティビティが作成されます。 Test.

     • そのようなRVMとCVMはすべて、このアクティビティ内のアイテムとして追加されます。

4. RVMs Without CVMs

   • 関連するCVMを持たないRVMは、それぞれのアクティビティ内のアイテムとして新しいワークフローに表示されますが、リンクされたコンポーネント/ブロックはありません。

この構造化されたアプローチにより、すべての RVM と CVM が、それぞれの検証方法に沿った明確で管理しやすい方法で説明され、整理されます。

移行フィールドマッピング

テスト手順、RVM、CVM などの各オブジェクトには、重要な情報を含む追加のフィールドがあります。移行中、これらのフィールドは保持され、新しい V&V モジュールの対応するフィールドにマッピングされます。以下は、既存のフィールドがどのように移行されるかの概要です：

Edge Case:

タスク、ディスカッション、および CVM、RVM、テスト・ステップ、テスト実行、およびテスト手順 のサブスクリプションは、新しい V&V モジュールには移行されません。

検証方法ツリーの親子関係もエクスポートされません。