チップおよび電子システムの設計チームは、テスト数の増加や回帰プロセスの自動化を超える問題に直面している。製品がソフトウェアへの依存度がより高いアーキテクチャへ移行し、ハードウェア、ソフトウェア、サブシステムが統合されるにつれて、検証の証拠は異なるツール、チーム、段階に分散している。一方で、要件や設定は変化し、知的財産は新たなコンテキストで再利用される。
この状況において、Jake WiltgenとMike Andrewsは、基本的な課題は単により多くの記録を作成することではなく、ライフサイクル全体を通じて意味とつながりを維持することだと考えている。Sponsor Blog形式で公開された本稿は、「検証スレッド」という概念を、要件、規格、検証活動、設定、結果を結び付ける体系化されたデジタル接続として提示している。
問題はデータ不足ではない
検証環境ではすでに、ログ、波形、信号、確認結果、カバレッジ指標、成功または失敗の結果が生成されている。しかし、テスト結果が成功したという事実だけでは、それがどの要件に対応したのか、どの設計リビジョン、テスト環境、設定が使用されたのか、またシナリオを支配した前提条件が何だったのかは説明できない。
カバレッジの数値についても同様である。カバレッジは活動や進捗を示すが、それだけで検証が十分であることを証明するものではない。要件や設定が変更されると、チームは影響を受けるテストや、過去の結果が依然として有効かどうかを把握するために、コンテキストを手作業で再構築しなければならない。
検証スレッドが加えるもの
著者らは、各検証イベントを回帰レポートの単なる1行ではなく、再利用可能なエンジニアリング証拠として扱うことを提案している。これには、活動を要件またはエンジニアリング上の意図に結び付けること、基準、設計リビジョン、実行環境、刺激、制約、関連する証拠を記録することが含まれる。
このつながりにより、チームは「テストを実施した」という表現から、より具体的な答えへ移行できる。すなわち、要件はどのように、どの条件の下で、どの証拠によって検証されたのか、そしてどのようなギャップが残っているのかを明らかにできる。また、ユニットを再利用したり派生設計を開発したりする際に、過去の結果の有効性を評価する助けにもなる。これにより、作業を無作為に繰り返したり、分析なしに除外したりすることを避けられる。
ツールの統合から意味の統一へ
本稿は、アプリケーションを接続したりファイルを交換したりするだけでは、真の検証スレッドを構築するには不十分だと強調している。ハードウェア検証、ソフトウェア検証、システムテスト、安全性分析、要件管理では、異なる抽象化と成功基準が使用される。
そのため、提案されるモデルには、異なる環境で生成された場合でも、要件、基準、設定、証拠オブジェクトを結び付ける共通の意味が必要になる。その結果は、欠落、重複、または古くなった証拠を特定し、要件の変更が関連するテストや結果に及ぼす影響を追跡できるエンジニアリング知識ネットワークに似たものとなる。
なぜこのニュースが重要なのか
この提案の重要性は、検証を後付けの文書化段階ではなく、継続的なエンジニアリングアーキテクチャの問題として再定義している点にある。異なるチーム、サプライヤー、地理的に離れた拠点に分散した開発では、暗黙知への依存が減少する。また、承認段階で遅延や曖昧さが発生した場合のコストが高まるため、証拠が完全で、説明に耐え得るものであることがより重要になる。
ただし、本稿は明確な制約も示している。ツールやデジタルスレッドによって、曖昧な要件、定義されていない基準、または一貫性のない方法で記録された証拠を解決することはできない。このアプローチを成功させるには、要件を検証可能な期待事項に分解し、基準を明示し、検証イベントを体系化された構造で記録する必要がある。
提示された事実に基づけば、実務上の主な価値は、新たなダッシュボードを追加することではなく、検証結果を理解し、再利用し、影響分析できるようにすることにある。一方、Questa One VeriThreaderというソリューションと、ホワイトペーパー「Rethinking Traceability for Modern Systems」への言及は広告記事の末尾に登場するものであり、この製品を評価したり他の代替製品と比較したりするのに十分な独立した詳細は含まれていない。