Software Engineering Evolution Program (SWEEP) では、サプライヤーを含めた日産全体のソフトウェア設計、コーディングおよびテストを含む、ソフトウェア開発プロセスの評価を行っています。2001 年まで、SWEEP では、単体テスト、統合テストまたはシステム テストにおいて、標準的な開発手法の観点から品質目標を設定していました。これらは、開発活動ごとに設定されているロバスト性の目標に照らしてチェックされていました。

菊池氏は次のように述べています。「日産とサプライヤーは完璧なソフトウェア ロバスト性を確保するために、テスト フェーズに多くの工数を費やしていました。」

その当時、ソフトウェア品質グループは、コーディングルールのチェックと、ソース コードの内部構造の検証を自動化する、2 つの静的解析ツールを使用していましたが、真のニーズは満たされていませんでした。菊池氏は次のように説明しています。「日産は、プログラム構造の複雑化やコーディング エラー、その他の問題によって引き起こされるソフトウェア バグという問題に直面していました。コーディングルール検証ツールや構造検証ツールで、問題の一部に対応することはできましたが、これらのツールではゼロ除算、オーバーフロー、範囲外の配列へのアクセスといったランタイムエラーを特定することはできませんでした。」

菊池氏はまず最初に、ルノー・日産アライアンス内部の同僚からPolyspace^® 製品について学び、Polyspace Bug Finder™ および Polyspace Code Prover™ のランタイムエラー検出機能を評価するベンチマーク テストを実施しました。「私たちは既に 2 つの静的解析ツールを使用していましたが、パイロット プロジェクトで Polyspace 製品を試すことしました。パイロットが成功するとすぐにPolyspace 製品を導入し、私たちがレビューする全てのソフトウェアに使用することにしました。サプライヤーはそれぞれ異なる開発環境、マイクロプロセッサ、クロスコンパイラを使って独自にソフトウェアを開発しているため、彼らのコードを迅速に解析する効率的なプロセスも構築しました。」

日産は、特定されたすべてのバグを重大さに応じてメジャー (即時に修正する必要あり)、ミディアム (今後のリリースで修正する) およびマイナーの3 つのレベルに分けることにしました。

菊池氏は、Polyspace 製品を使用して、他ツールで検証済みのコード内にランタイムエラーが存在するかチェックする際の制約と基準を構築しました。

菊池氏は次のように述べています。「Polyspace 製品は、どのコードを実行した時にランタイムエラーが発生しうるかを明らかにするだけでなく、実行条件に関係なく決してランタイムエラーが発生しないコードを特定することができます。しかもコーディング中、つまり単体テストの前に検証できるため、サプライヤーにとって非常に大きな価値があります。」

「私たちはサプライヤーに対してPolyspace 製品を開発環境で使用するよう強制することはありませんが、サプライヤーが組織的に活用することは大きなプラスであると考えています。コーディングの際にいつどのようにPolyspace 製品が使用されるかを知ることで、私たちはコードの信頼性について大きな自信を持つことができます。ソフトウェアのロバスト性と信頼性が最も効率的な方法で確保されていることの保証となるのです。」と菊池氏は結論付けます。