ソフトウェア測定法は、
ソフトウェアやその仕様に関する特性を定量化する手法です。これにより、
ソフトウェアの性能や品質を数値として評価できるようになります。
計算機科学の分野でも、他の分野での成功を受けて、こうした定量的方法が取り入れられ、
ソフトウェア開発の管理や改善に役立てられています。著名な
ソフトウェア開発者
トム・デマルコは、「測定できないものは制御できない」と述べており、効果的な測定が重要であることを示唆しています。
代表的な測定法
ソフトウェア測定法には、さまざまな手法があります。以下にいくつかの代表的な方法を挙げます。
- - 成長オーダー: アルゴリズム解析の一部。
- - Lines Of Code (LOC): コードの行数を基にした測定。
- - 循環的複雑度: プログラムの複雑さを定量化。
- - ファンクションポイント法: 仕様の機能を測る手法。
- - ソースコードの行当たりのバグ数: 未検出のバグの密度を測定。
- - コード網羅率: テストで網羅されるコードの割合。
- - 顧客要求仕様の行数: 仕様書の行数。
- - クラスおよびインタフェースの個数: ソフトウェア設計の要素を数える。
- - 凝集度と結合度: ソフトウェアの構造の品質を測る。
ただし、測定法の適用には限界があり、すべての状況で満足のいく結果を導くことは難しいとされています。そのため、
能力成熟度モデル統合や
ISO 9000などの管理手法が、開発プロセスそのものを対象にした測定法を用いて発展してきたのです。
開発工程における測定
ソフトウェア開発の過程で考慮すべき測定の例には、以下のようなものがあります。
- - ビルドの失敗回数
- - 単位工数あたりのバグ数
- - 要求仕様への変更回数
- - プロジェクトに投入される予定工数と実績工数
- - パッチリリースの回数
とはいえ、
ソフトウェア測定法にはいくつかの批判や弱点があります。たとえば、
プログラマーの個性を無視した管理が道義的な問題を引き起こすことがあります。結果として、管理者は特定の
プログラマーの実力を誤解しがちです。また、開発者はしばしば自らのチームを良く見せようとし、数値が操作される可能性もあります。そのため、測定は公平とは言えない場合があります。
さらに、測定法自体の不正確さや問題の複雑さを数値化する難しさも指摘されています。例えば、コードの行数は測定可能ですが、その問題の難易度を正確に定量化するのは難しいのです。このような測定法が
ソフトウェアの全体的な質を保証するものではないことを理解する必要があります。
均衡型測定法の提案
測定の目的を明確にし、適切な指標を選ぶことが重要です。均衡型測定法では、スケジュール、サイズ、コスト、品質の観点から複数の指標を設けることが推奨されます。このようにすることで、特定の測定にばかりフォーカスすることを防ぎ、プロジェクト全体のバランスを保つことができるのです。
バランスト・スコアカードといったツールが、各種の観点で測定法を管理する際に有益です。
ソフトウェア測定法は確実な解決策ではないものの、適切に活用することで、
ソフトウェア開発プロセスを最適化し、より高品質の製品開発を目指すことが可能です。