テクノロジー
技術レポート:アーカイブ
Category:カーエレクトロニクス
車載組込みソフトウェア開発のプロセス改善活動

近年、車載組込みソフトウェアは、高度な機能が求められている一方で品質要求も高まっている。そのような状況の中、ソフトウェアの品質を確保する手法として、AutomotiveSPICE(以下、A-SPICE)に沿った開発を実施することが自動車業界では主流となっている。当部では、A-SPICEギャップアセスメント(注1)を受診し、ソフトウェアテストにおいて、3段階あるテストフェーズの最終段階にテスト項目が集中し過ぎているとの指摘を受けた。そこで、各テストフェーズで行うべきテスト項目を定義し、網羅性の高いテストが実施できるようプロセス改善を実施した。
参考情報:
車載組込みソフトウェア開発のプロセス改善活動 1.まえがき 近年、車載組込みソフトウェアは、高度な機能が求められている一方で品質要求も高まっている。そのような状況の中、ソフトウェアの品質を確保する手法として、AutomotiveSPICE(以下、A-SPICE)に沿った開発を実施することが自動車業界では主流となっている。当部では、A-SPICEギャップアセスメント(注1)を受診し、ソフトウェアテストにおいて、3段階あるテストフェーズの最終段階にテスト項目が集中し過ぎているとの指摘を受けた。そこで、各テストフェーズで行うべきテスト項目を定義し、網羅性の高いテストが実施できるようプロセス改善を実施した。 2.当部のソフトウェア開発の特徴 2.1 システム構成当部では、すべてのビジネスユニットにおいて、規模の大小(約100~300KSLOC(Source Line of Code))はあるものの図1のような構成で動作するマイコンに組込むソフトウェアの開発を担当している。自動車メーカの要求に合わせた新規ハードウェアを直接制御するソフトウェアであり、開発要素の多いことが特徴である。図1.システム構成図①物理量(アナログ量)をA/D変換しデジタル値に変換②デジタル値から制御対象の制御量を算出③マイコンからの制御量を制御対象に出力④制御情報、故障診断結果などを他ECUと相互通信2.2 開発ライフサイクル当部では、ソフトウェア開発において、ソフトウェア設計領域~ソフトウェアテスト領域を担当している。図2にA-SPICEで定義されているソフトウェア開発ライフサイクルを示す。ソフトウェア設計領域とソフトウェアテスト領域で分業し、それぞれ成果物を遅滞なく伝達・共有し、イテレーティブに開発するスタイルである。図2.ソフトウェア開発ライフサイクル3.活動内容ソフトウェア適格性確認テストに、テスト項目が集中している要因を分析した結果、以下の課題があることが判明した。(1) ソフトウェアの繰り返し開発が多く、分業が進んだ結果、個別の作業レベルの伝達・情報共有は行われているが、本来行うべき全体でのテスト設計が十分できておらず、担当者のスキルに依存したテストになっている。(2) ソフトウェアテスト領域の各プロセスで行うべきテスト内容が、事前に定義されていないため、ソフトウェア設計領域とソフトウェアテスト領域のカバレッジが明確になっていない。この課題を解決するため、以下の対策を実施した。車載組込みソフトウェア開発のプロセス改善活動三田事業所 技術第2部本多 淳二(注1 ) 改善活動を具体的に始める前に、プロセスの強み、弱みを調査分析し、改善点を洗い出すために行う。17車載組込みソフトウェア開発のプロセス改善活動特集論文3.1 全体テスト計画書の策定全体テスト計画書を作成し、ソフトウェアテスト領域の各プロセスに割り振るテスト項目の基準を定めた。全体テスト計画書では、体制、スケジュール、役割、責任などとともに、各プロセスのテスト方針についても下記(1)~(3)に示す定義とした。図3にイメージ図を示す。図3.テスト工程ごとのテスト対象①ソフトウェアシステム ソフトウェア要件(機能・非機能)を実現するシステム②コンポーネント ソフトウェアシステムにおいて、分割した機能を実現するためのモジュールの集合体③モジュール ある機能もしくはその一部を実現するために互いに関連を持つユニットの集合体④ユニット モジュールを構成する最小単位(各関数)(1) ソフトウェアユニット検証の定義システムを構成する最小単位であるユニット(関数)に着目して行なう。ソフトウェアユニット検証の目的は、関数内のロジックやインタフェースと、その関数の外部仕様(機能、入力、出力、および外部への影響)との食い違いを見つけることである。(静的解析も含む)(2) ソフトウェア統合テストの定義ソフトウェア統合テストの目的は、ソフトウェアユニット検証の際にドライバ/スタブを用いて行なったコンポーネント間のインターフェーステストを、実際に統合されたコンポーネントを対象にして行なうことである。テスト項目としては、ソフトウェアユニット検証において使用したテスト項目のうち、コンポーネント間インタフェースに関するものを選んでテストを行う。また、複数コンポーネント間の動的な検証も行う。(3) ソフトウェア適格性確認テストの定義ソフトウェア適格性確認テストの目的は、ソフトウェアシステム全体として、要件定義書に記載された正常系機能のみならず異常状態においても正しく作動することを検証することである。3.2 機能展開図の作成機能展開図は、要求項目を要求仕様、詳細設計へと展開していく過程を一覧表にする設計部分と、各項目に対してテスト項目を対応づけていくテスト部分とで構成される。機能展開図は、それらを紐付けることで、要求から設計、テ図4.機能展開図の生成プロセスと各工程での成果物との関係18車載組込みソフトウェア開発のプロセス改善活動ストに至る一貫性とトレーサビリティを可視化・検証でき、下記(1)~(3)の利点がある。概念図を図4に示す。(1) 機能展開図を作成することは、一つ一つの設計項目を詳細化することに役立つ。また、レビュー効率を上げる役割も果たす。(2) 機能展開図の検討に要した時間は、設計と実装への要求事項を理解するための時間でもあり、結果的に設計と実装の作業効率化ができる。(3) テストケースを作成する前に、機能展開図上で個々のテストを分解・細分化することで、抜け・重複を防ぎ、要件に対するテストカバレッジの向上が図れる。また、効率的にテスト作業の見積りが行え、実行計画を立案できる。3.3 機能展開図の作成とテスト設計の実施今回、組込ソフトウェア開発のソフトウェア設計領域とソフトウェアテスト領域において、機能展開図の作成に取り組んだ。機能展開の実施例を図5に示す。(1) ソフトウェア設計領域の改善点ソフトウェア要求分析ではソフトウェア要件に対し、要件仕様記述手法であるUSDM(Universal SpecificationDescribing Manner)により仕様の整理を行った。また、機能単位に、ID番号を付与し、トレーサビリティがとれるようにした。なお、USDMは自然言語で記載される場合が多いが、必要に応じて、ブロック図、タイミングチャート図、状態遷移図を使用し、仕様を分かりやすく表現した。(2) ソフトウェアテスト領域の改善点ソフトウェアテスト領域のテスト設計段階では、機能展開図のテスト工程欄にテスト項目No.を記入する。テスト設計を終えた時点で、機能展開図の各項目ついて、漏れや重複がないことを確認した。図5.機能展開 実施例19車載組込みソフトウェア開発のプロセス改善活動4.活動の成果従来の方法は、ソフトウェアユニット検証~ソフトウェア統合&統合テストで実施すべきテストをソフトウェア適格性確認テストで実施していたが、今回は全体テスト設計書に基づきテストプロセス毎にテスト項目を分類した。これにより、ソフトウェア適格性確認テストでは、ソフトウェア要件のみ実施することになり、テスト件数は削減できた。ソフトウェア適格性確認テストに集中していたテストをソフトウェアユニット検証~ソフトウェア統合&統合テストに振り分けることにより、当該プロセスのテスト件数は増加した。しかし、これらの工程では、テストを自動化できるため、テスト工程全体での効率化を図ることができた。この実施例でのテスト項目数は全235件であり、ソフトウェアユニット検証:162件、ソフトウェア統合&統合テスト:57件、ソフトウェア適格性確認テスト:16件となった。5.今後の課題5.1 システム領域とソフトウェア設計領域の連携今回、取り組み対象ではなかったシステム領域からインプットされた仕様書をもとに機能展開図を作成する。また、テスト工程では、作成したソフトウェアテスト領域の全体テスト計画書を、システム領域テストのインプットとして活用していくよう対応部門に働きかける。特に、機能展開図を用いたテスト計画において、本来、システム領域テストで実施すべきテストをソフトウェア適格性確認テストで実施していることも判明した。システムテスト担当部門との調整を進めていく。5.2 テストの効率化全体テスト計画書を運用した結果、テスト項目数を適切に配分できた。今後はテスト工数等のデータを採取し、今回の改善が妥当であったか検証する。5.3 ソフトウェア要件が多い場合の機能展開図膨大な量のソフトウェア要件から機能分割、詳細化する際に、この機能展開図のみで網羅しハンドリングすることは困難である。ツール等を活用し要件を管理するなどの工夫が必要である。6.むすび本改善活動で全体テスト計画作成によるソフトウェアテスト領域のテスト内容明確化と、要求からテスト項目までをトレースできる機能展開図を作成し、テスト設計を行うことが出来た。今後も引き続きA-SPICEの要求事項と、業務効率を意識した改善活動を推進する所存である。最後に、本活動にあたり多くの助力をいただいた関係者各位に深く感謝申し上げる。参考文献および規格(1) VDA QMCワーキンググループ13/Autmotive SIG:AutomotiveSPICE プロセスアセスメントモデル/プロセス参照モデル、バージョン3.1(2017/11/1)(2) IEEE829 IEEE Standard for Software TestDocumentation(3) 独立行政法人 情報処理推進機構ソフトウェア・エンジニアリングセンター:改訂版組込みソフトウェア向け開発プロセスガイド、ESPR(Ver.2.0)(4) 一般社団法人 IT検証産業協会 29119研究会解説書WG:国際標準規格によるソフトウェアテスト解説、Ver.1.0(2015/7/10)執筆者紹介本多 淳二 ホンダ ジュンジ1989年入社。主に車載用ソフトウェアの業務改善に従事。現在、三田事業所技術第2部。20車載組込みソフトウェア開発のプロセス改善活動