トレーサビリティおよび一貫性

トレーサビリティおよび一貫性は、Automotive SPICE 3.01 PAMにおいて、2つの別個の基本プラクティスで扱わ れる。トレーサビリティは、参照先または作業成果物間のリンクを指し、カバレッジ、影響分析、要件実装状況の 追跡等に役立てられる。対照的に、一貫性は内容および意味について扱う。

さらに、双方向トレーサビリティは、以下の間で明確に定義された。

 テストケースとテスト結果の間

 変更依頼と、この変更依頼によって影響を受ける作業成果物の間 双方向トレーサビリティおよび一貫性の概要を、次の図に示す。

図 D.4 — 双方向トレーサビリティおよび一貫性

D.5 「合意」および「要約と伝達」

「V」字モデルの左側の情報フローは、基本プラクティス「合意した〔作業成果物 X〕の伝達」を通じて保証される。こ こでいう用語「合意した」とは、作業成果物の内容の意図について影響を受ける関係者間で共通理解があること を意味する。

「V」字モデルの右側の情報フローは、基本プラクティス「結果の要約および伝達」を通じて保証される。ここでいう用 語「要約」とは、テスト実施結果の抽象的な情報が、すべての関係者に対して利用可能であることを指す。

これらの伝達を重視した基本プラクティスは、必ずしも正式な承認、確認、またはリリースを必要としないことに注意 する。むしろ、正式な承認、確認、またはリリースは能力レベル2 GP2.1.7の対象である。能力レベル1において、

伝達を重視した基本プラクティスは、作業成果物（またはその内容）が関係者に配布されることを意味する。

これらの概要を、次の図に示す。

図 D.5 — 合意、要約、および伝達

D.6 「評価」、「検証基準」、および「遵守の保証」

このセクションでは、検証、テスト、評価、および遵守における関係、相違点、および共通点について説明する。次 の図D.6で概要を記載する。

検証基準は、要件の遵守を保証するために、テストケースの作成または他の検証手段のインプットとして使用され る。検証基準は、システム要件分析プロセス（SYS.2）およびソフトウェア要件分析プロセス（SWE.1）でのみ 使用される。テストで網羅できない検証の側面は、検証プロセス（SUP.2）で扱われる。

ユニット検証のための基準は、ソースコードがソフトウェア詳細設計および非機能要件に遵守していることを保証する。

想定されるユニット検証可能なのための基準には、ユニットテストケース、ユニットテストデータ、カバレッジ目標、コー ディング標準、およびコーディングガイドラインを含む（例：MISRA）。ユニットテストにおいて、このような基準はユ

ニットテスト仕様書に定義しなければならない。このユニットテスト仕様書は、例えば自動化されたテストベンチのス クリプトとして実装してよい。

図 D.6 — 評価、検証基準、および遵守

システムおよびソフトウェアのアーキテクチャ、ならびにソフトウェア詳細設計に対する選択肢の評価は必要である。評 価は、定義した基準に従って実施しなければならない。このような評価基準には、モジュール性、信頼性、セキュリ ティ、および有用性といった品質特性、または「作成・購入・再利用」の分析結果が含まれる。アーキテクチャ／設 計の選定に対する論理的根拠を含む評価結果は、記録しなければならない。

アーキテクチャ設計の遵守とは、以下の間のインタフェースおよび関連相互作用が、アーキテクチャ設計により与えら れた仕様を満足していることを、明示した統合テストで証明できることを意味する。

 ソフトウェアユニット間

 ソフトウェアアイテム間

 システムアイテム間

D.7 「戦略」と「計画」と「戦略」の関係

用語「戦略」および「計画」は、Automotive SPICE 3.01 PAMの以下のプロセスで通常使用される。

 SYS.4 システム統合および統合テスト

 SYS.5 システム適格性確認テスト

 SWE.4 ソフトウェアユニット検証

 SWE.5 ソフトウェア統合および統合テスト

 SWE.6 ソフトウェア適格性確認テスト

 SUP.1 品質保証

 SUP.8 構成管理

 SUP.9 問題解決管理

 SUP.10 変更依頼管理

次の図は、これらのプロセスにおける戦略と計画の一般的な関係を示す。

図 D.7 — 戦略および計画