HOME > Automotive SPICE 3.0について

Automotive SPICE 3.0について

2015年7月15日にAutomotive SPICE 3.0がリリースされました。
Automotive SPICEダウンロード先:
http://www.automotivespice.com/download/

プラグインコンセプトの導入

従来はソフトウェアエンジニアリングへブレイクダウンするためのシステムエンジニアリングとして解釈されがちであったシステムエンジニアリング系プロセスでしたが、3.0では、システムを構成するメカ、ハード(エレキ)、ソフトのすべてのドメインに対する上位概念としてのシステムエンジニアリングと位置づけられます。
3.0に掲載されるドメイン向けプロセスとしてはソフトウェアエンジニアリング系プロセスのみになりますが、今後は、現在策定が進んでいるメカ開発向けのプロセスやエレキ開発向けのプロセスを3.0に"プラグイン"してアセスメントを実施できるようになっています。

プラグインコンセプト

設計系プロセスとテスト系プロセスの1対1対応

従来のソフトウェア設計プロセス(ENG.5)は、ソフトウェアアーキテクチャ設計とソフトウェア詳細設計の両方を含んでいました。そのため、ENG.5はソフトウェア統合テスト(ENG.7)ともソフトウェアユニットテスト(ENG.6)とも関係を持っていました。
これに対し3.0では、ソフトウェアアーキテクチャ設計(SWE.2)とソフトウェア詳細設計(SWE.3)を分離し、ソフトウェアアーキテクチャ設計(SWE.2)vsソフトウェア統合と統合テスト(SWE.5)、ソフトウェア詳細設計(SWE.3)vsソフトウェアユニットテスト(SWE.4)を1対1に対応付けたことにより、すべてのエンジニアリング系プロセスで設計系プロセスとテスト系プロセスの1対1対応が取られました。

設計系プロセスとテスト系プロセスの1対1対応

用語の変更

他の規格に準拠する形でエレメント、コンポーネント、ユニット、アイテムという用語が再定義されました。
"V"の左側に当たる設計系プロセスでは、設計対象となる個々の塊をエレメントと呼び、それをブレイクダウンしながら設計を詳細化していきます。そして、ソフトウェアアーキテクチャ設計における最小単位のエレメントをコンポーネントと呼びます。さらにコンポーネントはユニットの集合体として形成されます。
"V"の右側に当たるテスト系プロセスでは、テスト対象となる個々の塊をアイテムと呼び、それを統合しながらテストを進めます。このアイテムは"V"の左側におけるエレメントと1対1もしくは多対多の関係を持ちます。

エレメント、コンポーネント、ユニット、アイテム

トレーサビリティと一貫性の概念の分離<

従来、設計系のプロセスにおいて、トレーサビリティと一貫性は同一の基本プラクティスに配置され、トレーサビリティは一貫性を保証するための手段と位置づけられていました。
3.0では、これらを別の基本プラクティスに分離し、以下の意味をより強調することになりました。

トレーサビリティ関係先の存在を保証する
一 貫 性内容や意味が正しく継承されていることを保証する

3.0では、さらにテストケースvsテスト結果、変更依頼vs対象成果物についても、双方向トレーサビリティを要求します。

双方向トレーサビリティと一貫性

合意、要約、伝達の概念の明確化

"V"の左側における設計系プロセスにおける"情報"には、成果物としての"伝達"と"合意"が求められます。ここでいう"合意"とは、成果物の内容(およびその意味)に対して利害関係者が同じ理解を示すことを意味します。
また、"V"の右側におけるテスト系プロセスにおける"情報"は、"要約"と"伝達"によって保証されることになります。ここでいう"要約"とは、利害関係者にとって理解可能(利用可能)なテスト結果としてまとまっていることを意味します。

合意、要約、伝達

評価、検証基準、遵守の保証の概念の明確化

3.0では、検証、評価、遵守といった概念が明確化されました。

検証基準
要求を遵守していることを保証するために、テストケースの作成や他の検証手段のインプットとして用いられる。
ユニット検証の基準
ソースコードが、詳細設計と非機能要求を遵守していることを保証するための基準。
(テストケース、テストデータ、テストカバレッジの目標値、コーディング標準、コーディングガイドなど)
評  価
評価は定義された規準に基づいて行われる必要があります。
評価基準には、モジュール性、信頼性、セキュリティ、ユーザビリティといった品質特性や、新規開発/再利用/購入を判断する分析結果も含まれます。
遵  守
例えばアーキテクチャ設計を遵守するという意味は、対応する統合テストが以下の内容に対して、インターフェースや相互作用を確認でき、これらがアーキテクチャ設計の仕様を満たすということです。
  • ・ソフトウェアユニット
  • ・ソフトウェアアイテム
  • ・システムアイテム
評価、検証基準、遵守の概念

戦略と計画の関係性

3.0のPAMにおいて、"戦略"と"計画"という用語は、以下のプロセスでよく用いられています。

SYS.4システム統合と統合テストSUP.1品質保証
SYS.5システム適格性確認テストSUP.8構成管理
SWE.4ソフトウェアユニット検証SUP.9問題解決管理
SWE.5ソフトウエア統合と統合テストSUP.10変更依頼管理
SWE.6ソフトウェア適格性確認テスト

以下の図は、これらのプロセスにおける一般的な"戦略"と"計画"の関係性を示しています。

戦略と計画
能力レベル 1
それぞれのプロセスにおいてプロセス固有の戦略の策定が求められます。
このプロセス固有の戦略は、プロセス固有の計画に該当します。
それぞれのプロセス固有の計画は、プロセス固有の作業成果物の特性を持ちます。
(例:テスト系プロセスにおけるテスト計画、構成管理プロセスにおける構成管理計画)。
能力レベル 2以上
それぞれのプロセス固有の計画は、全プロセス共通の一般的な計画として表現される作業成果物の特性に引き継がれます。これは、プロセス固有の計画にプロセス固有の特性と全プロセス共通の特性の両方が適用されるという意味です。
(例:プロジェクト計画書におけるテストの実施に関する記述)。
To TOP