ソフトウェア測定法
ソフトウェア測定法（ソフトウェアそくていほう）またはソフトウェアメトリック（英: Software metric ）とは、ソフトウェアやその仕様の属性の尺度である。
定量的手法の威力は他の分野で証明されていたことから、計算機科学の分野でも同様の手法をソフトウェア開発に持ち込もうとする努力が続けられてきた。トム・デマルコは DeMarco, T. (1982) Controlling Software Projects: Management, Measurement & Estimation, Yourdon Press, New York, USA, p3 の中で「測定できないものは制御できない」と記している。
典型的なソフトウェア測定法
[編集]- 成長オーダー（アルゴリズム解析、O記法など参照）
- ソースコードの行数
- 循環的複雑度
- ファンクションポイント法
- ソースコードの行当たりのバグ数
- コード網羅率
- 顧客要求仕様の行数
- クラスおよびインタフェースの個数
- Robert Cecil Martin のソフトウェアパッケージ測定法
- 凝集度
- 結合度
限界
[編集]詳細設計に先駆けてプログラムの量の事前予測評価をしても、満足できるような結果を得るのは困難である。従って、ソフトウェア測定法の実用性は測定プロセスが安定する狭い領域に制限されている。
そのため、能力成熟度モデル統合や ISO 9000 のようなマネジメント方法論では、開発工程そのものを対象とした測定法（計量）により、開発工程の監視や制御を行えるようにする。
ソフトウェア開発工程に関する測定法の例:
- 一晩にビルドが失敗した回数
- 1人H（単位工数）当たりの作りこみバグ数
- 要求仕様への変更数
- 週単位にプロジェクトに投入できる予定工数（および実績工数）
- 最初の製品出荷以降のパッチリリース数
批判
[編集]ソフトウェア測定法には以下のような弱点や批判がある。
- プログラマの人間性を排除した管理
- 個人の能力を数値化し、それによって全てを判断するやり方は道義に反するとも言われている。管理者は最も才能のあるプログラマを一番難しい部分に割り当てる。つまり、その部分の作業が最も時間が長くかかり、バグも多くなることが予想されているからである。このため、さらに上の管理者は、そのプログラマの才能を低く判断してしまう可能性がある。
- 偏向
- 開発者はチームの能力を上司に対してよく見せようとする傾向があるため、結果として定量化に際して一種の偏向がかかる。例えば、コードの行数で能力を測ろうとした場合、プログラマは可能な限り行数が多くなるようにコードを書く可能性があり、コードを短縮できる方法を見つけたとしても採用しない可能性が出てくる。
- 不正確
- 意味があって、かつ正確な測定法は知られていない。コードの行数は正確に求められるが、問題の難しさの程度は正確に数値化できない。ファンクションポイントはコードや仕様の複雑さをより正確に測定する手法として開発されたが、うまく運用するには個人の判断が必要となる。推定方法が違えば、結果も異なってくるため、ファンクションポイントを万人が公平に利用するのは難しい。
- 計測性機能不全[1]
- 動機付けのある計画に文字通り盲従する事によって、その計画の実際の目標や意図とは正反対の結果を招来してしまうこと[1]。例えば、管理者が「単体テストではソースコード1000行あたり○○件の不具合を見つけること」のような目標を設定すると、不具合を作り込まない優秀な開発者ほど単体テストで目標件数を達成することが困難になってしまうため、開発者は意識的・無意識的にソフトウェアの品質を落とすことでこの問題を解決しようとする。
賭博型測定法
[編集]開発現場の経験から、測定法の設計によって測定対象となる人々の行動に一種の影響が出てくるとされている。よく言われるのは「測定したものしか得られない」（あるいは「何を望んでいるのかを忘れないように」）である。
よく知られている例はファンクションポイント法をソフトウェア開発工程の改善プロジェクトでの生産性の尺度に使った場合である。ファンクションポイント当たりのコストを低減する最も単純な方法は、ファンクションポイントをより細かくすることである。ファンクションポイントには標準といえる測定法がないため、測定法は一種の博打となる。つまりイカサマが行われる可能性が出てくる。時と共に恣意的にファンクションポイントを小さく分割していけば、測定された数値上は生産性が上がったかのように見せかけられる。
ある研究によれば、測定に際して目標を明確にして周知し、何をするのかを明確化すべきであるとしている。テスト駆動開発はこの考え方の一種の実践であり、開発者はテストを通ることを目的としてコードを書くことを求められる。それでもコードに誤りがある場合、それはテスト自体に誤りがあったということになる。測定法設計では、その賭博性を理解し、チームが正しい目標に向かって進むよう注意しなければならない。
均衡型測定法
[編集]「何を望んでいるのかを忘れないように」するためのひとつの手法は、複数の測定法で均衡をとるようにすることである。ソフトウェア開発プロジェクトでは、次のような観点でそれぞれ測定法を用意することが推奨される。
- スケジュール
- サイズ/複雑さ
- コスト
- 品質
これらの一部を強調しすぎると、チームの動機付けに不均衡が生じ、プロジェクトが機能障害に陥る可能性がある。
バランスト・スコアカードは、各種観点の複数の測定法を管理するための便利なツールとなる。
出典
[編集]参考文献
[編集]- DeMarco, Tom. Controlling Software Projects: Management, Measurement and Estimation. ISBN 0-13-171711-1
関連項目
[編集]外部リンク
[編集]- Ohloh 多数のオープンソースプロジェクトの定量的解析。公式ウェブサイト
- International Function Point Users Group（IFPUG）
- CyVis - フリーソフトウェアの複雑度可視化ツール（Java言語使用）
- SourceKibitzer.org 主なオープンソースプロジェクトの測定値に関するオンラインデータベース。週一回更新。