ソフトウェアメトリクス

読み：そふとうぇあめとりくす　／　英語表記：software metrics

ソフトウェアの規模、複雑さ、品質などを、定量的に測るための指標。ソースコードの行数やバグの数などから算出し、品質の管理や見積もりに使う。

イマシルちゃんの解説

「このプログラム、なんだか品質が悪そう……」って感覚で言われても、どこを直せばいいかわからないよね。

ソフトウェアメトリクスは、プログラムの「健康診断の数値」みたいなものなんだ。
「1,000行あたりにバグが何個あるか」「この関数はどれくらい複雑か」みたいに、数字で表すことで、
品質がいいのか悪いのか、客観的に話し合えるようになるんだよ！

ソフトウェアメトリクスは、ソフトウェアやその開発の過程の特性を、数値として測定するための尺度である。測定した値をもとに、品質の評価、問題のある箇所の特定、工数の見積もり、プロジェクトの進捗の管理などを行う。

メトリクス	内容
ソースコードの行数（LOC、KLOC）	規模を表す。KLOCは1,000行
ファンクションポイント	外部への入出力やファイルなどの機能の量から、規模を見積もる
サイクロマティック複雑度	プログラムの制御の流れの複雑さ（分岐の多さ）を表す
バグ密度	規模あたりのバグの数（例：1KLOCあたりのバグの件数）
テスト密度	規模あたりのテスト項目の数
コードカバレッジ	テストで実行された命令や分岐の割合

サイクロマティック複雑度（マッケーブの複雑度）は、プログラムの制御フローグラフから、次の式で求める。

複雑度 = 辺の数 − ノードの数 + 2

簡単には「分岐（if、ループの条件など）の数＋ 1」で求められる。値が大きいほど、テストすべき経路が多く、誤りが入りやすい。一般に、10を超えるような関数は、分割を検討する目安とされる。

状況	考えられること
バグ密度が基準より高い	品質が悪い可能性。設計やコーディングを見直す
バグ密度が基準より極端に低い	品質がよいとは限らない。テストが不十分でバグを見つけられていない可能性がある

バグ密度やテスト密度は、過去のプロジェクトの実績などから基準値を決め、その範囲に収まっているかを確認するのに使う。

バグの数とソースコードの規模などから、品質管理のためのメトリクスを算出するのは、メトリクスの計測ツール（コード解析ツールなど）の役割である。見つかったバグそのものの記録と、修正の計画や履歴を管理するのは、バグトラッキングシステムの役割である。