Automotive SPICE におけるプロセスの解釈について
（ソフトウェア統合および統合テスト）

今回の記事では、昨年11月号の「Automotive SPICEにおけるプロセスの解釈について（プロジェクト管理）」に続いて、Automotive SPICE PAM v3.1のソフトウェア統合および統合テストプロセスのアセスメントで弱みとなりやすい「ビッグバンテスト」について、その理由と解決策をご紹介します。

Automotive SPICEが期待するソフトウェア統合および統合テストプロセスの目的は２つ存在します。１つ目は「ソフトウェアアーキテクチャ設計でソフトウェアユニットの粒度まで詳細化した内容を基に、ソフトウェアユニットを実行可能なソフトウェアになるまでを統合すること」です。２つ目は「アーキテクチャ設計の設計内容に準拠していることを確実に確認すること」です。では、なぜ「ビッグバンテスト」がアセスメントで弱みとなりやすいのかを解説します。「ビッグバンテスト」では全てのソフトウェアユニットを一括で統合し、テストを行うため、ソフトウェアユニット間のインターフェースや統合した部品の動作を確認する際に他のソフトウェアユニットの影響を受けてしまいます。そのため、問題が発生した際は調査対象がソフトウェア全体となり、問題の原因が特定しづらくなります。その他にも、問題が発生しているにもかかわらず、偶然に設計通りに動作しているように見えることがあります。例えば、３つのソフトウェアユニットのソフトウェア統合テストを実施する際に、ソフトウェアユニットA-B間のインターフェースとソフトウェアユニットB-C間のインターフェースにそれぞれに問題があっても、２つ問題がお互いに打ち消しあってしまい、ビッグバンテストでは正しく動作しているように見えてしまうことがあります。

解決策としては当たり前だと思われるかもしれませんが、「インクリメンタルテスト（増加テスト）」を実施することです。「インクリメンタルテスト」は２つのソフトウェアユニットを統合し、テストを実施して、次のソフトウェアユニットを統合して、テストを実施する作業を繰り返す方法です。この方法により、インターフェースやシーケンスがソフトウェアアーキテクチャ設計の通りに動作していることを確実に確認することができます。特に製品の立ち上げ時などの大規模な開発の際は複数個所で問題が発生する可能性が高いため、「インクリメンタルテスト」を実施する必要があります。また、「インクリメンタルテスト」には上位エレメントから下位エレメントまでを順に統合する「トップダウンアプローチ」と下位エレメントから上位エレメントまでを順に統合する「ボトムアップアプローチ」があり、ソフトウェアの特性に合わせた方法を選定し、統合戦略として示す必要があります。

上記でご紹介した内容をすでに理解しているものの、「インクリメンタルテスト」は実施工数が多くかかるため、「ビッグバンテスト」を実施されている方も多くいるかと思います。私もエンジニアとして開発プロジェクトを実施していた時は、「インクリメンタルテスト」で実施すべきと理解しつつ、問題が発生しなければ工数を抑えられると考え、「ビッグバンテスト」を実施していました。しかし、担当していたソフトウェアのコード行数は数十万行あり、問題が発生する度に深夜まで残業をして、問題の原因を調査していました。特に納期前に問題が発生したときは大変だったことを今でも覚えています。問題が発生すること考えると、計画的に複数人で「インクリメンタルテスト」を実施する方が、結果的に効率が良く、納期にも間に合わせることができます。また、ソフトウェア統合作業やテスト作業の一部を自動化するなど開発環境を改善することで効率化することもできます。

今回の記事はソフトウェア統合および統合テストプロセスの一部分について、ご紹介させていただきました。今後もAutomotive SPICE PAMを解説する記事を発行させていただきますので、ご一読いただければ幸いです。また、弊社ではプロセス改善担当者様や管理者様、開発担当者様へ向けたAutomotive SPICEの概要や各プロセスを解説するトレーニングを実施しております。トレーニングでは今回の記事のようなアセスメントでよく見受けられる弱みなどを含めて解説いたします。詳細につきましては以下でご案内をしておりますので、興味がある方は是非ご受講をご検討頂ければと思います。

Automotive SPICE 3.1 プロセス基礎トレーニング
https://biz3.co.jp/publictraining_category/automotivespiceengineer

2023/1/17　中武 俊典