現状のウォーターフォール型開発の問題点とシミュレータを活用した反復型開発によるソフト品質改善

最近では、「情報家電」「ユビキタスコンピューティング」をキーワードに、従来コンピュータに適用していた製品分野が、組み込み機器の適用分野に含まれるようになってきました。例えば、身近な携帯電話、普及期に入ったHDDビデオレコーダ、オフィス用の複合機など、この傾向を象徴しています。このように、最近では組み込み機器のほとんどが、その機能をソフトウエアで実装するようになっています。

市場での製品の評価は、このソフトウエアの機能性や使いやすさ、他社との差別化などがポイントになりつつあります。
このような多機能化極まる製品開発のために、ソフトウエア実装量は増加の一方であり、携帯電話などでは、開発者の全体の人数に占めるソフト開発者の割合が、80%とも言われています。

その反面、開発期間はと言うと、製品サイクルの短縮化や多様な顧客ニーズへの対応のために、製品開発スタートの時点から、製品仕様確定が遅れ気味となり、開発期間、品質評価の時間はますます短くなっています。その結果、市場での不具合、リコール、製品への信用失墜など、最悪のストーリーを辿ってしまう場合も少なくありません。
では、ソフト検証が不十分になってしまう原因について考えてみましょう。

現状のほとんどの開発現場では、試作ボードとICEを使用したソフトデバッグが行われています。この場合、十分なテストが行えない次のような問題があります。

・ハード試作が完成するまで、動作検証ができない。ハードの完成が遅れると、そのままソフト開発期間が短くなってしまう。
・実機では、複合条件や複雑なタイミングテストが難しく、網羅的なテストが行えない。
・初期の試作ハードにはバグがあり、動作不具合の原因の切り分けに時間が掛かる。

これらの問題の根源は、システム検証のベースを、開発の後半にならなければ完成しない試作ハードに依存しているためであり、ハードウエアを使用しない確実な検証環境が求められています。

現状のほとんどの開発現場でのテスト工程は、担当者による手作業で行われており、一回のテストに、多くの時間とコストがかかります。このため、テスト工程で不具合を発見した場合に、再テストは不具合箇所に限定して行われることが多く、関連した不具合を見落としてしまうケースが少なくありません。

これは、ソフトウエア改変の度に、全てのソフトをテストするには物理的な時間が不足しているためであり、手作業による手法では、事実上、これを解決する方法はありません。

試作ハードを使用したテストの場合、システム動作の評価は開発後半になります。このようなウォーターフォール型の開発プロセスでは、ソフトウエアアーキテクチャの問題など、開発早期で修正すべき問題点が後になって発見されることが多く、この「手戻り」を修正するためのコストが高くなります。

また、ソフトがシステム化された後になってからの修正は、その場しのぎの「パッチ」プログラムとなることが多く、ソフトウエアの保守性、信頼性を低くしてしまいます。

ソフト品質を上げるために、システムが完成する前の段階で出来るものに、「モジュール単体テスト」があります。これは、システムを構成する部品である関数やタスク等の単位で、網羅的な入出力テストを行うものです。これは「ホワイトボックステスト」と呼ばれており、ソースコード上の変数や引数に対して直接データを入力し、関数実行後に戻り値や変数を評価するものです。

この作業には、システム全体が動作している必要はなく、関数のみを実行できる環境があれば行うことができます。実機を使用する場合ならば、ツールベンダーの提供する各種「評価ボード」にICEを接続して、ソースコードデバッグできる環境が用意できれば実現します。「モジュール単体テスト」は、ソフト品質保証の原点であり、これが保証されていれば、システム動作に入ってからの不具合の切り分けなどが容易となり、ソフト品質の向上に確実につながります。

しかしながら、システムの関数の個数は膨大であり、この関数1つ1つに対してICEを使った手作業でテストを行うのでは、工数が膨大になります。

現状では、ソフト品質を非常にシビアに考える自動車関連業界での組み込みソフト開発では、工数をかけて手作業によるテストが行われています。この工数に対する問題が解決できれば、モジュール単体テストは、ソフト品質改善に非常に有効な手段となります。

モジュール単体テストには、マイコンシミュレータ（ISS）を使用したテスト環境が注目されています。モジュール単体テストは、システム全体が動作する必要はないため、ロジックの実行が可能なMPUコア部分のシミュレータ（ISS）があれば、容易に行うことができます。

評価ボード+ICEを使用したテスト環境との大きな違いは、環境が全てソフトウエアであることです。Windowsのファイルシステム等を利用して、関数を評価するためのデータ入力や、関数実行後の戻り値、変数の評価を、シナリオとしてファイル化し、これをバッチ処理的に自動実行することで、手作業に比較して飛躍的に作業を効率化できます。ガイオでは、マイコンシミュレータ（ISS）を使用したモジュール単体テスト専用ツール「カバレッジマスターwinAMS」（下図参照）を提供していますが、多くのお客様よりご好評を頂いています。

試作ボードを使用したテストは、実機が動作するため、実時間上での検証になります。この実機環境では、時間的なイベントの組み合わせによる例外的な条件、複合的な条件を再現するのは、非常に困難です。このため、実機での検証は「正常系動作」の検証に偏りがちで、「異常系動作」の検証を網羅しきれず、潜在的な不具合を抱えたまま出荷される製品も少なくありません。

この様な、「異常系動作」に対する網羅テストを行える環境として、マイコンシミュレータ（ISS）が注目されています。マイコンシミュレータはWindows上で動作するソフトウエアであるため、周辺回路動作をソフトで記述した仮想ハードウエアを含めたシステム全体の「時間」を止めることができます。また、「時間のステップ実行」も可能です。

これにより、異常系動作を引き起こす複雑なイベントタイミングについても、自由にスケジューリング、シナリオ化できるため、網羅的なイベントタイミングテストが可能になります。

モジュール単体テストやシステム動作にシミュレータを導入することで、開発初期の段階にソフト検証の工程を前倒しすることができます。これにより、テスト結果をソフト設計にフィードバックして、また次の評価を行うような「反復型」開発が、開発早期の段階から可能となります。

その結果、仕様やソフトウエアのアーキテクチャに関わる問題点を早期の段階で検証できることになり、開発の工程に沿って、ソフト品質を保ちながらの開発が可能になってきます。

テスト結果のフィードバックが開発後半に偏ってしまうウォーターフォール型の開発を改善し、開発の大きな「手戻り」を無くすことができます。

ここまでは、現状の組み込みソフト開発工程に沿った問題点とその解決法を見てきましたが、ここからは、組み込みソフト開発の全体を見渡してソフト品質改善へのアプローチを考えてみます。

主に自動車関連の開発では「Ｖ字開発」と呼ばれる開発プロセスが用いられています。これは、システムに対する要求仕様を決める段階から、ソフトコーディング後の最終システムテストまでを段階に分け、各々の段階でテスト結果と要求仕様をつきあわせて検証するものです。

下図は自動車関連のECU（電子制御ユニット）を例に取った開発プロセスを示しています。一番下のコーディングの工程を折り返し点として、各段階でテスト結果と要求仕様をつきあわせて検証を行います。

ECU開発においては、図の丸印で示されるように、種々の開発ツールが使用されており、特に左側の仕様・システム設計のフェーズにおいては、UMLツール、MATLAB/Simulink（Mathworks社製）等のCASEツールを使用して、設計内容のシミュレーション、動作検証が行われています。このモデルがECUへのソフトウエア実装のための「仕様書」として使用さえる例もあり、MATLABモデルの入出力結果と、実際のソフトウエアを実装したECUの入出力結果が一致することを評価基準として使用しています。
V字型開発の最大の特徴は、開発途中に数多くの検証工程が設定されていることであり、その各々がソフト品質を高めるステップになっているのです。

今回は、ソフト品質を評価するためのテスト手法について考えましたが、皆様の開発では、いかがでしょうか？
ソフト品質を上げるためのアプローチとして、テストや検証の方法に着目するのは、どちらかと言うと従来の手法の延長線上にあるもので、大きなパラダイムシフトを起こす様なものではないかもしれません。また、ソフト品質を上げるのは、テストや検証だけではなく、例えばオブジェクト指向などのように、ソフトの設計方法そのものからのアプローチの方が効果が高いかもしれません。

しかしながら、特に、過去の開発資産を多数流用しながら、積み重ねの繰り返しになりがちな組み込みソフト開発では、結局、モジュール単体テストの様に、積み重ねたものを１つずつ検証することが求められてしまいます。このような現状では、テスト工程を効率的に行う手法を確立することが、ソフト品質を高めるための必須項目となります。