Automotive SPICE バージョン3.0の特徴

去る7月9日から11日にドイツ ベルリンにてVDA Automotive SYS Conferenceが開催されました。昨年の同カンファレンスにてAutomotive SPICE バージョン 3.0の概要が発表されておりましたが、今年のカンファレンスでは、来年の正式発行に向けて具体化された内容が発表されました。そこで今回は、Automotive SPICE の新バージョン3.0（以下、バージョン3.0）の特徴をご紹介していきたいと思います。

～エンジニアリング系プロセスの再構成～
再構成されたエンジニアリング系プロセスについてご紹介いたします。
バージョン3.0において、特徴的な変更点は、エンジニアリング系プロセスの全体構成の変更にあります。

従来のバージョン2.5では、ソフトウエア開発の視点を中心としたシステムエンジニアリング、ソフトウエアエンジニアリングに関するプロセスがENG.1からENG.10に割り当てられていました。
バージョン3.0では、この「ENG」をエンジニアリングの分野毎に分割し、システムエンジニアリングを「SYS」、ソフトウエアエンジニアリングを「SWE」としました。
ここまでの内容では、バージョン2.5と何も変わっていないように疑問を持たれる方もいらっしゃるかと思いますが、バージョン3.0では、システムアーキテクチャ設計の対象として、ソフトウエアエンジニアリング以外に電気電子系ハードウエアエンジニアリングと機構系ハードウエアエンジニアリングをプラグインすることができます。
バージョン3.0としては電気電子系ハードウエアエンジニアリングと機構系ハードウエアエンジニアリングは直接的に含まれませんが、必要に応じてこれらのモデルを組み合わせて使用することができるようになります。

さらに、バージョン3.0ではソフトウエアエンジニアリング系プロセスの構成も変更されます。
バージョン2.5では、ENG.5にソフトウエアアーキテクチャ設計とソフトウエア詳細設計の二つの設計が含まれていました。通常これらは開発を担う組織においては、別々のプロセスとして定義されることが多く、テストにおいてもソフトウエアアーキテクチャ設計に対してソフトウエア統合テスト（ENG.7）、ソフトウエア詳細設計に対してソフトウエアユニットテスト（ENG.6）と、いわゆるV字モデルの水平方向の対応関係にわかりにくさがありました。
それに対し、バージョン3.0ではSWE.2としてソフトウエアアーキテクチャ設計、SWE.3としてソフトウエア詳細設計とソフトウエアユニット構築（ハンドコーディングもしくは自動コード生成）を配置し、テストとしては、SWE.4にソフトウエアユニットテスト、SWE.5にソフトウエア統合と統合テスト、SWE.6にソフトウエア認定テストを配置されています。
このように、バージョン 3.0 では実際のプロセス定義との整合性が取りやすくなりました。

～トレーサビリティに関する変更～
Automotive SPICEバージョン（以下 Ver.）3.0におけるトレーサビリティに関する現Ver.2.5からの変更についてご紹介させていただきます。
エンジニアリング系プロセスの再構成というトピックに比べると、細かい変更が多数起きているため、大きく5つに分けてご説明いたします。

1つ目は、エンジニアリング系の全11 プロセスのうち、要件抽出(SYS.1)を除く10プロセスにおける、トレーサビリティに関するBPの変更です。
Ver.2.5では、トレーサビリティ関連のベースプラクティス（以下BP）は、必ず【一貫性（consistency）】というキーワードも含んでいました。Ver.3.0では【トレーサビリティ】と【一貫性】とを分離し、“双方向トレーサビリティの確立”と“一貫性の確証”という2つのBPに分けています。
本来トレーサビリティは一貫性を保証するためのものという前提で、Ver.2.5では1つのBPの中で両方の用語が使われていました。ところが、トレーサビリティが確立されているにもかかわらず、一貫性が実現されていない状況が多く見られ、BPの評定基準が曖昧になるという課題がありました。この課題を解決するために、Ver.3.0ではトレーサビリティを扱うBPと一貫性を扱うBPに分割し、それぞれの主旨を明確に表現することになりました。
トレーサビリティと一貫性の違いは、成果物間の内容を“考えて作り出す”という行為の有無にあります。有る場合は【一貫性】と【トレーサビリティ】の両方が要求されますが、無い場合は【トレーサビリティ】のみが要求されます。
「要件⇔設計」や「設計⇔テスト仕様」などには両方が要求される一方、「テスト仕様⇔テスト結果」などにはトレーサビリティのみが要求されます。

2つ目も、1つ目と同様に、エンジニアリング系の全11プロセスのうち、要件抽出(SYS.1)を除く10プロセスにおける変更です。変更点は、トレーサビリティの対応関係についてです。
Ver.2.5では、トレーサビリティの関係線の数だけBPがありました。例えばソフトウェア要件分析は、「システム要件⇔ソフトウエア要件」と「システムアーキテクチャ設計⇔ソフトウエア要件」の2つのBPを含んでいました。
Ver.3.0では関係線の数に関わらずBPは前述の通り“双方向トレーサビリティの確立”という単一のBPとなります。当該プロセスにおいて含むべき関係線については、BPの説明文中に定義しています（3つ目および4つ目の変更参照）。
システム要件分析(SYS.2)、システムアーキテクチャ設計(SYS.3)およびソフトウェアアーキテクチャ設計(SWE.2)の各プロセスは、1つの関係線があります。次に、ソフトウエア詳細設計およびソフトウエア構築(SWE.3)およびソフトウエアユニット検証(SWE.4)は3つ関係性があります。最後に、上記以外の5プロセスは2つを含んでいます。

3つ目は、テスト関連の全5プロセスに関する変更です。
Ver.2.5では、V字モデルの左側の「要件」や「設計」と、右側の「テスト仕様」との間のトレーサビリティ（一貫性含む）のみを要求していました。Ver.3.0では右側の「テスト仕様」が、「テスト仕様に含まれる”テストケース”」に表現が変わり、更に「テストケース⇔テスト結果」のトレーサビリティも新たに要求しています。
ただし、ここで注意すべき点は「テストケース⇔テスト結果」ではトレーサビリティのみを要求している点です。これは前述の通り「考えて作り出す」という行為が無いためです。

4つ目は、ソフトウエアユニット検証プロセスに関する変更です。
Ver.2.5では、ユニットテスト仕様に対して「ユニット⇔ユニットテスト仕様」のトレーサビリティ（一貫性を含む）のみを要求していました。Ver.3.0ではこの「ユニット⇔ユニットテスト仕様」に加え、「ユニット⇔静的検証結果」、「ユニットテスト仕様⇔ユニットテスト結果」のトレーサビリティまでと、踏み込んだ内容を要求しています。

最後の5つ目は、変更依頼管理プロセスに関する変更です。Ver.2.5では、変更依頼管理プロセスにトレーサビリティに関する要求はありませんでした。Ver.3.0ではトレーサビリティに関するBPを明示的に要求しています。
これは変更依頼が発生した場合、変更依頼の内容と作業成果物の修正との間のトレーサビリティを管理すべきだという問題意識に端を発しています。ただし、ここで要求しているのはトレーサビリティのみで、一貫性までは要求していません。

以上がVer.3.0におけるトレーサビリティに関する変更ですが、Ver.2.5に対してトレーサビリティと一貫性に対する要求をより明確にした内容となっています。

～プロジェクト管理の変更点～
プロジェクト管理プロセスに焦点を当て、Automotive SPICE バージョン（以下Ver.）2.5からVer.3.0への変更点についてご紹介させていただきます。

今回の変更に至ったVer.2.5のプロジェクト管理プロセスにおける問題と、問題を解決するための課題とその変更点を見ていきましょう。

Ver.2.5では、基本プラクティス（以下、BP）のBP12において、プロジェクトの目標が達成されない場合は、計画からの逸脱を是正することが示されています。一方、その他のBPでは、計画や監視に関する活動が述べられていますが、計画からの逸脱を是正すること（原文では「制御」または「調整」と同意）は述べられていません。そのため、その他のBPでは、「制御」の活動がなかったとしても、計画や監視に関する活動が実施されていれば良いと評価される問題がありました。

この問題を解決するために、次の3つの課題が挙げられました。

①「プロセス目的」に、「計画」および「監視」の活動は含まれるが、「制御」の活動が含まれていない
②「調整」の活動が、BP12の中でしか表現されていない
③プロジェクト管理の様々な活動、作業成果物間の一貫性や同期が、BPに明確に表現されていない

これらの課題について、「プロセス目的」および「BP」に着目した変更が実施されています。

まず、「プロセス目的」の変更について、ご説明します。
Ver.3.0では、「プロセス目的」の本文が以下のように変更されています。「プロジェクト管理プロセスの目的は、プロジェクトの要件および制約内で、プロジェクトが製品および／またはサービスを生成するために必要な活動、タスク、およびリソースを識別し、確立し、計画し、連携し、監視し、制御することである。」
具体的には、「制御（control）」という言葉が追加されています。
Ver.2.5の「プロセス目的」の中では、「制御することである」という内容の定義がありません。「プロセス成果の 7」や「BP12：逸脱の是正」の中で間接的に定義されていました。一般的に、プロジェクト管理を実施する活動において、プロジェクトの活動内容を確立し、計画し、連携し、監視し、制御するということが一連の流れです。

今回、Ver.3.0では「プロセス目的」に「制御」という行為を入れることにより活動目的とプロジェクト活動の一連の流れを明確に定義しました。

次に、「BP」は以下の2点が変更されています

①Ver.2.5では「調整」に関する記述が、「BP12」でしか表現がされていませんでした。そのため、プロジェクト管理活動全般にわたって実施されるべき「調整」の活動の定義があいまいになっていました。その問題を解決するため、様々な側面（スケジュール、リソース、活動）に関する各BPの「計画」、「監視」と「調整」という活動の内容が明確に定義されました。具体的には、「BP12」が削除され、「調整」の観点がVer.2.5における「BP3,4,6,7」に追加されています。
②全ての側面を通じた一貫性を要求するための「BP」が新規に追加されます。これにより「プロジェクト管理の様々な活動、作業成果物間の一貫性や同期が、BPに明確に表現されていない」という課題が見直されています。

以上が、Ver.2.5のプロジェクト管理プロセスにおける問題と、問題を解決するための課題とその変更点です。

このほかにも、「Ver.2.5のBP5,8,9,10」、「（プロセス）成果」について内容の見直し案が示されていますので、詳細については次回以降のメールマガジンや弊社セミナー等にて引続きお伝えしていきます。
(2014年07月号、09月号、2015年01月号メルマガ抜粋)

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

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