作成日 2009/10/25
最終更新日 2009/10/25
ソフトウェアメトリクスを意識する
このページではソフトウェアメトリクスについて説明します。
ソフトウェアメトリクスって何かだって？
早い話、プログラムの品質を測定することです。
で、このページではその「ソフトウェアメトリクス」とはどういうもので、より良いプログラムを作るのにどういいのか説明します。
…。
上記だけの説明だとオブジェクト指向との関係ないと思うかもしれませんが、決してそんなことはないです。
あれ？
「ソフトウェアメトリクス」の言葉の定義をe-WordsやWikipediaから引用しようと思ったのだけど、載ってない…。
仕方ないので、他のHPを参考にして説明しますと、「ソフトウェアの品質測定」です。
で、何に使うのかですが、ソフトウェアの品質（特に保守性（※１））を測定するためです。
え、これじゃあ説明になってないって？
ということで、なぜ、品質を測定するのか（したいのか）を説明します。
会社がソフトウェアを作るとき、納期、コスト、品質などをバランスよくコントロール必要があるわけです。
品質が悪いと、納期、コストに影響してきてしまいます。
具体的には、
品質-保守性の解析性と変更性が悪い
↓
解析性が悪いのでバグの調査に時間がかかる。場合によっては調査漏れが発生する
（納期に悪影響を及ぼす。また、時間がかかる=人件費がかかるだからコストにも悪影響を及ぼす。）
↓
変更性も悪いので、バグ改修に時間がかかったり、新たなバグを発生させてしまう。
なんてことがあるかも。
それから、ソフトウェアを納品した後、保守していくんだけど、このときの大変になりますよ。
具体的には上と同じなので改めて説明しませんが…。
そうそう、ソフトウェアは開発よりも保守の方にコストがかかるらしいです。品質が悪いと無駄にお金を払い続けることになりえます。
-----
※１：ソフトウェアの品質はISO/IEC9126(JIS X
0129)に規定されていて、下記の6つの品質特性と21つの品質副特性があります。
・機能性（合目的性、正確性、相互運用性、標準適合性、セキュリティ）
・信頼性（成熟性、障害許容性、回復性）
・使用性（理解性、習得性、運用性）
・効率性（時間効率性、資源効率性）
・保守性（解析性、変更性、安定性、試験性）
・移植性（環境適応性、設置性、規格適合性、置換性）
（参考文献：情報処理教科書 プロジェクトマネージャ 2006年度版 ISBN4-7981-1090-6
397ページ）
ソフトウェアメトリクスで測定する品質は6つあるう品質特性のうちの主に保守性です。
代表的なソフトウェアメトリクスを紹介します。
■行数
メソッド、もしくはクラスの行数が多いということは、理解するのに時間がかかるのだから当然解析性が悪いということになる。
行数が多い場合は、他のメトリクス（複雑度や凝集度）も悪い可能性があると思う。
■コメント率
メソッド、もしくはクラスのコメント率の低いと、当然、理解しにくい（解析性が悪い）可能性がある。
ただ、コメントは書けば良いものではなく、書く内容によっても品質が変わってくるのだけれでも、そこまでは測定ツールでは見てくれない。
メソッドのヘッダコメントなら、以下を書くと良いと思うが、ツールではそこまでは見てくれない。
・関数の概要、詳細（内部でif分岐しているならすべてがわかる位の記述レベル（かなり細かい記述レベルです））
・引数の説明
・戻り値の説明
・エラー時の挙動
・さらに、関数の設計にあたり、何故そうしたかという理由やサンプルコードがあると非常に良い
※最低でも、JavaのAPIドキュメントレベルまで書いておけばよいと思います。
■メソッドの複雑度
メソッド内にどれくらい分岐があるかです。
分岐（例えばIF文）がたくさんあると、それだけテストケースを増やす必要があるので、試験性に関連します。
■凝集度
非常に重要です。
凝集度についての詳細は「オブジェクト指向とモジュールの凝集度、モジュールの結合度 の 1.モジュールの凝集度とは」を見てください。
簡単に説明しますと、クラスのメソッドや属性間の関連性です。強いほど良いです。解析性に関係すると思います。
■結合度
個人的には、一番重要です。
結合度についての詳細は「オブジェクト指向とモジュールの凝集度、モジュールの結合度 の 2.モジュールの結合度とは」を見てください。
クラス間の関連の強さで弱い方が良いです。クラス間の関連性が強い場合、解析性、変更性、試験性がとにかく悪化します。
計算式が Coupling (computer science) - Wikipedia, the free
encyclopedia （英語のページです） に載っていますので、知りたい人は見てみてください。
他にもありますが、まあ、こんなところで。
ここまで、説明すると、
「プログラムを作った後にソフトウェアメトリクスを測定して、悪いところを修正する」
のがソフトウェアメトリクスの正しい使い方…のように思える。
個人的な意見で悪いのですが、現時点（2009/10/25）ではそれは違うと思います（VBAの場合です。Javaの場合は上記の考え方でよいと思います）。
■理由
まず、ソフトウェアメトリクスを測定できるツールがあまりない。少なくともJavaやC/C++に対応しているものはあるかもしれないけど、ExcelVBAに対応しているものはどうなのか？測定できないということはソフトウェアメトリクスは使えないのか？
次に、仮に測定できたとして、悪いところをどうやって直すかだ。
「おいおい、何馬鹿なこと言っているんだ。」と思うかもしれないが、プログラムを直すのは簡単だけど、納期、コスト、品質などを意識してプログラムを直すのは非常に難しい場合がほとんどだ。特に修正範囲が膨大である場合、リファクタリングツールがないと対応が厄介な場合が多い（リファクタリングツールがあっても厄介な場合も多々ある）。でも、Java(というかEclipse)には結構高機能なリファクタリングツールがあるけど、Visual
Basic
Editorにはたいしたリファクタリングツールなんて付属していない。
ということは、仮にソフトウェアメトリクスを測定したとしても現実には「あ、ここは悪いのか」で終わる（修正はできない）ことになる。まあ、次にプログラムを作る際の参考にはなるが、いまあるプログラムの修正は難しい。（コメント率は直せるけどさ…、ほかは難しいと思う。）
■じゃあ、もっといい使い方は？
ソフトウェアメトリクスを設計時から意識することですよ。
とくに結合度、凝集度は（クラスをまたがる修正は特に手間がかかるため）。
このページを作成するのに参考にしたページです。
このページの利用によって発生した、いかなる損害について、このホームページの作成者は責任を負いません。
このページの間違いや嘘を見つけた方、このページに書いて欲しい情報がある方は
メールをお願いします。
Microsoft 、Windows 、Visual Basic および Excel は米国Microsoft
Corporationの米国およびその他の国における登録商標または商標です。
ここではExcel® をエクセル、Visual Basic® for
Applications をVBAと表記する場合があります。
Mac 、Mac OS 、Mac OS X は米国Apple
Computer,Inc.の登録商標または商標です。
Sun、Sun Microsystems、サンのロゴマーク、Java、及び、Sun/Solaris/Java に関連するすべての商標およびロゴマークは米国 Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
WikipediaR は Wikimedia Foundation, Inc. の米国およびその他の国における登録商標です。
その他、社名および商品名、システム名称などは、一般に各社の商標または登録商標です。
このホームページの作成者はこれらの会社とはいっさい関係がありません。
