Automoitve SPICE 3.0のご紹介

VDA（ドイツ自動車工業会）のワーキンググループAK13では、Automotive SPICEの新たなバージョンであるv3.0の策定作業が進められております。策定中の内容や現在の状況については、今年6月にドイツで開催されたAutomotive SYS Conference 2013でも紹介されておりますが、今回は、現在のバージョン（v2.5）からの主要な変更点をご紹介いたします。

現時点では、全体の半分くらいの策定が終わっておりますが、主要な変更点は次の2つに大別されます。①プロセス構造の変更②用語の変更と表現の明確化前者は、特にエンジニアリング領域におけるプロセスモデルと一般的な開発作業とのギャップを解消するための配慮がなされております。後者は、特に基本プラクティス（BP）の誤解釈による誤った実装を防止するための工夫と、1つのBPに複数の要件（意図）が入ることによる評定の曖昧さを解消する狙いがあります。

プロセス構造の変更では、エンジニアリングプロセスの改変と、プロセスの追加が行われています。従来のエンジニアリングプロセス群（ENG）は、システムとソフトウエアに分割され、それぞれSYSとSWEという略称に変更となります。

SYS.1 Requirement Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration & Integration Test
SYS.5 System Qualification

SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design & Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Integration & Integration Test
SWE.6 Software Qualification Testing

構造の変更では、「プラグイン」コンセプトという表現が使われています。つまり、開発の「V字」プロセスをドメイン毎に定義する（従来はENGの中にシステムとソフトウエアが混在していました）ことで、使用者の該当するドメインの開発プロセスをプラグインして使用するという意図があるようです。Automotive SPICEにおいては、SYS（システムエンジニアリング）とSWE（ソフトウエアエンジニアリング）ドメインのみを扱い、HWE(ハードウエアエンジニアリング)や、MEE(メカニカルエンジニアリング)は対象外にすると宣言されています。この変更に伴い、ソフトウエアエンジニアリングのV字プロセスは、従来のENG.5/6がSWE.2/3/4に分割され、設計に関するプロセスとテストに関するプロセスが左右対称のV字モデルになりました。構造の変更の2つ目の変更点として、新たに以下に示す12個のプロセスが追加されています。

ACQ.1 Acquisition Preparation
ACQ.2 Supplier Selection
ACQ.5 Customer Support

SUP.3 Validation
SUP.5 Audit
SUP.6 Product Evaluation

SPL.3 Product Acceptance Support

REU.1 Asset Management
REU.3 Domain Engineering

MAN.1 Organizational Alignment
MAN.2 Organizational Management
MAN.4 Quality Management

用語の変更と表現の明確化についてVDAの既発表資料に紹介されている例としては以下の4点が掲載されておりますが、これらの変更点について概要をご紹介いたします。
1) 「Traceability」と「Consistency」
2) 「Prioritize」、「Categorize」および「Map to future release」
3) 「Component」、「Element」、「Unit」および「Item」
4) 「Verification Criteria」と「Communicate requirements」

1)本来トレーサビリティ（Traceability）は、一貫性（Consistency）を保証するための道具という前提のもと、Automotive SPICE 2.5では、1つのBPの中で両方の用語が使われていました。ところが、トレーサビリティが確立されているにもかかわらず、一貫性が実現されていない状況が多く見られ、この場合のBPの評定基準が曖昧になるという課題がありました。本質論からすれば、評定基準は明確なはずですが、この問題を解決するために、AutomotiveSPICE 3.0では、トレーサビリティを扱うBPと一貫性を扱うBPに分割して、それぞれの主旨を明確に表現することになりました。

次に、2) Prioritize, Categorizeおよび Map to future release についてですが、優先順位付け（Prioritize）、分類（Categorize）および以後のリリースへのマッピング（Map to future release）という用語が、ENG.2/4/6で1つのBPの中で使われていました。このため、優先順位付けと分類が実施できていながら、リリースへのマッピングが不十分な場合に、その評定基準が曖昧となるケースがありました。また、優先順位付け、および分類という用語は、何に対して実施するかが不明確でした。これらの課題に対応するために、BPの構造要件（Structure Requirements）を実現するためにグルーピング、分類あるいは優先順位付けを行うという表現に変更し、さらにリリースへのマッピングを定義するBPを新設して独立させました。

3) Component、Element、Unit およびItemについては、コンポーネント（Component）やユニット（Unit）という用語が指す意味が組織によって異なることがあり、誤解釈を生むことがありました。AutomotiveSPICE 3.0では、プロセスの対象を示す用語の意味に一貫性を持たせるために、SYS1/2/3とSWE1/2の対象をエレメント、SWE3/4の対象はソフトウエアユニット、SWE5/6とSYS4/5の対象をアイテムと定義することになりました。

最後に、4) Verification CriteriaとCommunicate requirementsについてですが、ENG.3/5 で使用されている検証基準（Verification Criteria）という用語の解釈が不明確でした。また、ENG.2/3/4で使用されている、要件の情報伝達（Communicate requirements）という用語も対象や意味の解釈が不明確でした。これらを明確にするために、Automotive SPICE 3.0では、次の4つの表現に統一されています。

xxに対して評価する（Evaluate against…）
テスト基準を文書化する（Document test criteria）
テストする（Test）
xxと情報を交換し共通理解を図る（Agree on, and communicate x…）

簡単ではありますが、主要な変更点をご紹介いたしました。VDAのワーキンググループによると、現在の作業状況は、システムおよびソフトウエアプロセスの修正が半分くらい終了した状況です。また、リリースは、2015年を目指しているようです。新しい情報があれば、随時このメルマガの中でもご紹介する予定です。
(2013年08月号メルマガ抜粋)

※特に規定のない限り、下記住所の著作権帰属者からの書面による許可なく、当出版物のいかなる部分も、形式のいかんを問わず、一切の電子的あるいは機械的な方法のいずれによっても、複製、転載、流用することを禁ずる。

ビジネスキューブ・アンド・パートナーズ株式会社
東京都渋谷区広尾 1-13-1 フジキカイ広尾ビル 5F
TEL：03-5791-2121 / FAX：03-5791-2122 / E-mail：consulting@biz3.co.jp
URL：http://biz3.co.jp