「組み込みソフトウェア開発におけるソースコード品質評価のススメPart2」

１．前回の振り返り

　前回は、組み込みソフトウェアの品質改善を続けていくために品質評価が重要な役割を担う点を紹介しました。
　そして、品質評価を実施する上での2つのハードルについても言及しました。
　1つ目のハードルは「どの成果物を評価すればよいかがわからない」という評価対象の問題です。この問題については「どのプロジェクトでも必ず存在する」、「定量的に評価できる」という理由から、ソースコードが品質評価の対象として最も適切だという考えを紹介しました。
　2つ目のハードルは「どのように評価すればよいかがわからない」という評価方法の問題です。 本稿では、この問題の解として、ソースコードの品質評価方法についてご紹介します。

２．ソースコードの定量化と品質評価

　ソースコードを評価対象として選択した理由の一つに「定量的に評価できる」点を挙げたように、物事を評価する際には定量的であることが望まれます。
　ソースコードは他の成果物に比べて定量化に適しており、定量化するためのツールや方法論なども数多く世に出回っています。
　そういったツールや方法論を使うことで、以下の図のようにソースコードから様々なメトリクス（指標）の測定値を得ることが可能です。

図 1 ソースコードから得られる様々なメトリクスと測定値の例

　では、メトリクスの測定値を得ることができれば、即座にソースコードの品質を評価できるかというと、そう簡単にはいきません。
　まず、メトリクスの測定値について、どの程度であれば良いのか、逆にどの程度であれば悪いのか、といった基準として「メトリクスの閾値」が必要になります。
　また、各種メトリクスについて、前回の記事で挙げたソフトウェアの様々な品質特性のうち、どの特性と関係するものなのかといった「品質特性とメトリクスの関係」を決める必要もあります。
　さらに、メトリクスごとに品質特性に対する影響度合いが異なると考えられますので、影響度合いの違いを表す「メトリクスの重み」を評価に反映できれば評価精度を高めることができそうです。
　以上から、ソースコードの品質を評価するには、定量化によって得られるメトリクスの測定値に加えて、「メトリクスの閾値」、「品質特性とメトリクスの関係」、「メトリクスの重み」といった情報が必要といえそうです。

図 ２ ソースコード品質評価に必要な情報の概念図

　このような品質評価に必要な情報そのものやそれを得るための手段について、筆者を含む社内の数名のメンバーと早稲田大学の鷲崎准教授の共同で、2005年以降研究を続けてきました。
　なお、共同研究で決定した内容を紹介する文では「私達」という主語を使用します。

３．メトリクスの閾値

　ソースコードのメトリクスから品質評価につなげるための第一歩として、メトリクスの測定値について良し悪しを判定するための基準、いわゆる閾値を得ることが必要です。
メトリクスの閾値を得るための従来のアプローチは、経験豊富なエンジニアの定性的な感覚に基づいて決めるというものでした。このようなアプローチにより、例えば「関数の経路複雑度」といったメトリクスでは、「10以下が望ましい」とか「20までなら大丈夫」などの提案がされてきました。
　このアプローチは直感的でわかりやすいものですが、個々人によって変わりうる感覚に基づいていることから、閾値の水準について誰もが納得のいく根拠を示しづらいというデメリットがあります。
　私達は、できるだけ客観的な評価を実現しようと考えていたため、このアプローチを諦め、別のアプローチを模索しました。
　 その結果、複数の測定データ（メトリクスの測定値群）を使用して統計的に閾値を導出するアプローチを採用しました。
　 最初の導出の際には、当社のお客様を中心に組み込みソフトウェア開発現場の協力を得て、80程度のプロジェクトの測定結果から得られた情報を使用しました。

　これらの情報から各メトリクス測定値の頻度分布を作成し、分析してみると、以下の図のように概ね4種類の形状に分類できることがわかりました。

図 ３ メトリクス測定値の頻度分布のパターン

　 　この中で、例えば頻度分布の形状が最小型になったメトリクス（「関数の経路複雑度」や「依存している他ファイルの数」など）は、値が少ないほど良いとされるものばかりであることがわかりました。
　他に、頻度分布の形状が閾値型になったメトリクス（「関数名の長さ」、「ファイルの物理行数」）は、値が少なすぎても多すぎても良くないものばかりであることがわかりました。
　このことから、頻度の多い測定値の周辺が最も望ましい水準であり、そこから離れるほど段階的に望ましくない水準になることがわかりました。
　以上を踏まえ、最小型は、測定値の下位10%点を100点の閾値、上位10%点を0点の閾値と定め、最大型は最小型の逆としました。閾値型については、最も頻度の高い値周辺10%を100点と定めました。警告型は、「NULLポインタアクセスになる文の数」など値が1つもないことが望まれるメトリクスが当てはまる型なので、測定値が0の場合のみ100点でそれ以外は0点という具合に閾値を定めました。
　このようにメトリクスの頻度分布の型に応じて、閾値の導出方法を決めておくことで、測定データから機械的に閾値を導出することが可能になりました。
　一例として、「関数の経路複雑度」について閾値を導出し、得点を求める場合の例を以下の図に示します。

図 ４ メトリクス測定値から得点化する例

４．品質特性とメトリクスの関係

　「信頼性」や「保守性」などの品質特性は、ソフトウェアやソースコードの品質の一側面を表す概念であり、そのままの形で評価することは困難です。
　そこでソースコードのメトリクスを活用しようということになるのですが、概念的な品質特性と定量的なメトリクスとの間にはギャップが大きく、そのまま関係付けるのは困難です。
　仮に無理やり関係付けをしたとしても、両者のギャップが大きい分、納得感の欠けるものになってしまうことでしょう。
　そこで私達は、品質特性とメトリクスのギャップを埋め、納得度の高い関係付けにする必要があると考え、GQMアプローチを採用しました
　GQMアプローチとは、達成したい目標（Goal）に対して、その達成に必要な項目を質問（Question）として洗い出し、最終的に測定可能なメトリクス（Metrics）に結びつける対応付けの手法のことをいいます。
　品質特性とメトリクスの関係付けにGQMアプローチを適用した例を以下の図に示します。

図 ５ GQMアプローチによる品質特性とメトリクスの関係（一部抜粋）

　ソースコード品質評価の場合は、各品質特性を評価することが目標（Goal）になります。
　図5では、例として「保守性を評価する」を目標に据えています。
　次にQuestionとして保守性を評価するために必要な質問項目を洗いだしています。
　Questionのレベルまで品質特性を細分化していれば、メトリクスとの関係付けが容易になり、かつ納得感の高いものになります。
　例えば「複雑な文になっていないか？」というQuestionに対して、ソースコードの複雑さに関するメトリクス（「関数の経路複雑度」や「関数内のネスト数」）を関係付けることは、保守性とメトリクスを直接関係付けることに比べて容易ですし、意味的に納得を得やすいのではないかと思います。
　私達は、ソースコードから評価可能だと考える5つの品質特性（「信頼性」、「効率性」、「保守性」、「移植性」、「再利用性」）について、このような関係付けを実施しました。

５．メトリクスの重み

　ここまででメトリクスの測定値に対する閾値を定め、メトリクスと品質特性を結びつけることができました。次に私達が考えたことは、メトリクスごとに品質特性に対する影響度合いが異なる点をどのようにして品質評価に反映させるか、ということです。
　まず、本当にメトリクスごとに品質特性に対する影響度合いが異なるのかどうかについて、具体例で考えてみます。例えば「NULLポインタアクセスになる文の数」と「不変条件になる条件式の数」は、両方とも信頼性に関わるメトリクスといえそうです。では、信頼性に対する影響度合いは異なるでしょうか？不具合への繋がりやすさを考えると、明らかに前者の方が信頼性に対する影響が大きいのではないでしょうか。また、後者はフローになにも影響を及ぼさないにも関わらず処理に一定の時間を要することから効率性に影響していると考えられますが、前者は効率性への影響はないと考えられ、信頼性の場合と比べ関係が逆転します。つまり、メトリクスによって品質特性に与える影響度合いは異なると考えられます。
　私達は、メトリクスの重要度に基づいて重みを設定し、個々のメトリクスの得点を上位のQuestionに反映させる際に重みを考慮することで、上記のような影響度の違いを正しく反映できると考えました。
　次に必要になるのが、重みの導出方法です。私達は、客観的な評価を実現するためには、閾値と同じように、統計的なアプローチで導出するのが良いと考えました。
　具体的には、複数の典型的なプロジェクト群を専門家による定性的な評価や現場エンジニアのアンケートによって、「良い群」と「悪い群」に分類し、両群の得点の差が大きくなるメトリクスほど重要、つまり品質特性に与える影響が強いメトリクスだと判定するアプローチを採用しました。このアプローチで2つのメトリクスの重要度を比較した例を以下の図に示します。

図 ６ 得点分布の違いによってメトリクスの重要度を比較した例

　この例では、「良い群」と「悪い群」の差をはっきりと表現できているメトリクスがM1であることが示されています。このような場合、M1には高い重みを、M2には低い重みを付与することになります。仮にM1とM2が同じQuestionに対応付けられ、M1の得点が50点、重みが1.0、M2の得点が100点、重みが0.1だとします。この場合、単純平均でQuestionの得点を求めると75点になるのに対して、重みを考慮した荷重平均をとった場合は50×1.0／1.1＋100×0.1／1.1＝54.5点となり、M1の重要性が正しく反映された結果になります。
　このようにメトリクスに重みを付与することは、評価の精度を高める上で非常に重要なポイントです。

６．品質評価方法の全体像

　本稿では、メトリクスの測定値からソースコードの品質評価を可能にするために必要な情報として「メトリクスの閾値」、「品質特性とメトリクスの関係」、「メトリクスの重み」があることを紹介しました。
　ソースコード品質評価方法の全体像をまとめると、以下の図のようになります。

図 ７ 品質評価方法の全体像

　本稿で紹介したソースコード品質評価方法は、ソースコードからメトリクスの測定値を得る「測定ツール」と測定データ資産があれば、実施可能です。ただし、それなりの人手と時間が必要になることは間違いありません。
　当社では、このソースコード品質評価方法を使ってC言語またはC++言語のソースコードを品質評価できるツール「Adqua」を条件付きではありますが無料で提供しています。このツールを使うことで、開発作業の中にソースコード品質評価を無理なく盛り込むことが期待できます。
　ここまで2回に渡って、ソフトウェア品質改善のために品質評価が重要である点とソースコード品質評価の具体的な方法についてご紹介しました。
　ソフトウェア品質の効率的な改善に向け、ソースコードの品質評価に目を向けていただくきっかけになれば幸いです。

 （参考文献）
・鷲崎弘宜、田邉浩之、小池利和、「ソース・コード静的検証によるソフトウェア品質評価の意義」、日経エレクトロニクス no.1022 2010 1-25、日経BP社、2010年
・鷲崎弘宜、波木理恵子、福岡呂之、原田陽子、渡辺博之、「プログラムソースコードのための実用的な品質評価枠組み」、情報処理学会論文誌Vol.48 No.8、2007年

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

• 「BSC（バランスト・スコアカード）を正しく理解する（３）」第２世代のBSC その２ 前の記事へ
• 「組み込みソフト開発現場でソフトウェア・プロダクトライン・エンジニアリングについて考えてみる（２）」 次の記事へ

『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。

• お問い合わせ