ソフトウェア品質の客観的指標
ソフトウェア製品で測定できる品質にはさまざまなタイプがあります。目的への適合性（例：最終用途）、保守性、効率。これらのいくつかは、やや主観的またはドメイン固有です（たとえば、優れたGUI設計原則は、文化によって異なるか、使用状況に依存する場合があります。軍事用か消費者用かを考えてください）。
私が興味を持っているのは、タイプのネットワーク（またはグラフ）に関連するより深い形式の品質とその相互関係、つまり、各タイプが何のタイプを参照しているか、適切に関連する相互接続の明確に識別可能なクラスターがあるかどうかです。階層型アーキテクチャ、または逆にタイプ参照の大きな「ボール」があります（「モノリシック」コード）。また、各タイプやメソッドのサイズ（たとえば、Javaバイトコードまたは.Net ILの量で測定））は、大規模で複雑なアルゴリズムがコードのモノリシックブロックとして実装されている場所を示す必要がありますより管理/保守可能なチャンクに分解される代わりに。
このようなアイデアに基づく分析では、少なくとも品質の代用となるメトリックを計算できる場合があります。高品質と低品質の間の正確なしきい値/決定点は、主観的なものだと私は疑います。保守性とは人間のプログラマによる保守性を意味し、したがって機能分解は人間の心の働きと互換性がなければなりません。そのため、考えられるすべてのシナリオで考えられるすべてのソフトウェアを超える、ソフトウェアの品質を数学的に純粋に定義できるかどうかは疑問です。
また、これが危険な考えであるかどうか、品質に対する客観的なプロキシが普及した場合、ビジネス上の圧力により、開発者は全体的な品質（プロキシによって測定されない品質の側面）を犠牲にしてこれらのメトリックを追求するようになります。
品質についてのもう1つの考え方は、エントロピーの観点からです。エントロピーは、システムが秩序だった状態から無秩序な状態に戻る傾向です。これまでに現実世界の中規模から大規模のソフトウェアプロジェクトに取り組んだことがある人なら、コードベースの品質が時間の経過とともに低下する傾向がある度合いを高く評価するでしょう。ビジネス上の圧力は一般に、新しい機能（アビオニクスソフトウェアなどの品質自体が主要なセールスポイントである場合を除く）に焦点を合わせた変更をもたらし、回帰の問題とそれがうまく適合しない「靴角」機能による品質の低下品質とメンテナンスの観点。それでは、ソフトウェアのエントロピーを測定できますか？もしそうなら、どうですか？
これは危険な考えです。品質の「客観的」プロキシは管理報酬に直接つながり、開発者は実際の品質を犠牲にしてこれらの指標を追求します。
これは意図しない結果の法則です。
品質は重要ですが、ソフトウェアの小さな側面の1つにすぎません。ソフトウェアが生み出す機能性と価値は、品質よりもはるかに重要です。
すべてのメトリックは、メトリックを最適化するアクティビティにつながります。そのため、実際には気に入らない結果になる可能性があります。
ソフトウェアは非常に複雑です。それがどれほど複雑であるかを理解することは困難です。
単体テストのコードカバレッジなどの「明白な」ものでさえ、時間を浪費する可能性があります。 100％に到達するには、テストされている簡単なコードよりも実際に複雑なテストを作成する必要がある場合があります。 100％のカバレッジに到達するには、許容できないコストがかかる場合があります。 [ささいな、小さく、めったに使用されないコードの代替は、検査による検査です。しかし、それは100％のメトリックゲームには適合しません。]
別の例は、循環的複雑度です。これは、コード品質の最良の尺度の1つです。しかし、それは、1つの大きな関数よりも読み取りが難しい（および維持するのが難しい）小さな関数を多数作成することで解決できます。あまり読みにくいかもしれないが、複雑さのしきい値は満たすことに同意するコードレビューに巻き込まれます。
また、これが危険な考えであるかどうか、品質に対する客観的なプロキシが普及した場合、ビジネス上の圧力により、開発者は全体的な品質（プロキシによって測定されない品質の側面）を犠牲にしてこれらのメトリックを追求するようになります。
ビンゴ、それについての「もし」はありません。これは「測定機能障害」と呼ばれ、何度も観察され、執筆されています ジョエルは2002年にそれについての記事を書きました ハーバード教授の本を参照しています。
これは、そのようなメトリックが役に立たないことを意味するのではなく、インセンティブまたはポリシーをそのようなプロキシ測定に明示的に基づいてはならないということだけです。品質を向上させたい場合は、非常に悪い値のプロキシメトリックが最初の開始点として適しています。ただし、すべてのメトリックが優れた値を持っているからといって、品質が良いと結論付けることはできません。
私が興味を持っているのは、タイプのネットワーク（またはグラフ）に関連するより深い形式の品質とその相互関係、つまり、各タイプが何のタイプを参照しているか、適切に関連する相互接続の明確に識別可能なクラスターがあるかどうかです。階層型アーキテクチャ、または逆にタイプ参照の大きな「ボール」があります（「モノリシック」コード）。
これはファンインとファンアウトのように聞こえます。ファンインは、特定のモジュールを呼び出すモジュールの数をカウントし、ファンアウトは、特定のモジュールによって呼び出されるモジュールの数をカウントします。使用する警告サインは、大規模なファンインと大規模なファンアウトを備えたモジュールです。これは、設計が不十分であり、リファクタリングまたは再設計の主要なターゲットを示している可能性があるためです。
また、各タイプやメソッドのサイズ（たとえば、Javaバイトコードまたは.Net ILの量で測定））は、大規模で複雑なアルゴリズムがコードのモノリシックブロックとして実装されている場所を示す必要がありますより管理/保守可能なチャンクに分解される代わりに。
簡単な測定は、コード行です。プロジェクト全体のコードの合計行と、モジュールごとのコード行（おそらく異なるサイズのモジュールを使用）に分解できます。これは、特定のモジュールを確認する必要があることを示す警告インジケータとして使用できます。 ソフトウェアの品質測定とメトリックに関する本 は、欠陥率とモジュールサイズの関係が曲線的であるといういくつかの作業について説明しており、KSLOCごとの平均欠陥には、 SLOC 175および350。
もう少し複雑なのは、システムのテスト容易性、理解可能性、および保守容易性を示すように設計された循環的複雑度です。循環的複雑度は、アプリケーションまたはモジュールを経由する独立したパスの数をカウントします。テストの数、したがってテストを作成して実行するために必要な作業は、循環的複雑度に強く関連しています。
高品質と低品質の間の正確なしきい値/決定点は、主観的なものだと私は疑います。保守性とは人間のプログラマによる保守性を意味し、したがって機能分解は人間の心の働きと互換性がなければなりません。
それが事実かどうかはわかりません。
たとえば、人間のワーキングメモリは7つのプラス/マイナス2のオブジェクトしか保持できないことを示唆する 研究がありました 。これは、おそらくファンインとファンアウトの測定に関心があります。モジュールで作業していて、それが7つ以上の他のモジュールに接続されている場合、これらのモジュールを正確に追跡することはできないでしょう。他のモジュールは私の頭の中にあります。
また、循環的複雑度などのメトリックに欠陥を関連付ける作業も行われています。システムの欠陥を最小限に抑えたいので、サイクロマティックの高度な複雑さによって特定されるように、より多くの労力テストまたはリファクタリングが必要なポイントを特定できます。
また、これが危険な考えであるかどうか、品質に対する客観的なプロキシが普及した場合、ビジネス上の圧力により、開発者は全体的な品質（プロキシによって測定されない品質の側面）を犠牲にしてこれらのメトリックを追求するようになります。
これは、測定またはメトリックの場合です。システムを理解し、情報に基づいた決定を行うために使用する必要があります。 「測定できないものは管理できない」という言葉が思い浮かびます。高品質のソフトウェアが必要な場合は、その品質を評価するためのいくつかの測定と測定基準が必要です。しかし、これには裏返しがあります。数字だけで管理することはできません。数字を使用して情報に基づいた決定を行うことができますが、数字がそう言っているからといって決定を下すことはできません。
関心のある多くの品質の指標またはプロキシがあります。
- コードの行
- ファンイン、ファンアウト
- コード1000行あたりのエラー率
- 循環的複雑度
- コードカバレッジ
- ディシジョンポイントカバレッジ
- メンテナンスアクティビティによって修正/導入されたエラーの比率
- 機能点分析
これらすべてのアイテムにいくつかの問題があります：
- 指標を最適化するために行われている作業-普遍的な傾向。チームまたは個人の評価または報酬の基礎としていずれかのメトリックが使用される場合、大幅に悪化します。
- コンテキストに依存しないメトリックは知りません。これは、時間の経過とともに、ショップ間では比較できないことを意味します。そのような比較から生じる測定基準は依然として価値があります-「私たちは今、1年前よりも正確にコードを作成していますか」。
これらの問題の総合的な影響は、これらのようなメトリックは、TQM、品質保証（制御ではない）、継続的な改善、カイザンなど、より広い文化の中でのみ価値がある可能性が高いということです。両方の文化の要素を定義する必要があります、それをどのように変更する必要があるか。これらの定義がある場合、これらのようなメトリックは、コードの品質、作業方法、生産性などの向上に役立つ不可欠なツールになります。このより広いコンテキストがないと、メトリックはメトリックを最適化する作業を生成します。生産性を向上させ、コストを削減するためのビーンカウンターのツールになります。そして、開発スタッフによるゲームの邪魔になるでしょう。
メトリックに夢中になることもあれば、最高の人材、ツール、エンジニアリングとQAのための慣行に夢中になることもあります。私は、「ランダムネスによってだまされている」を読んで、自動化を好むいくつかの偏執的なQAの天才が、数字を含む適切にフォーマットされたレポートの束よりもはるかに幸せだと思います。
メトリックにはこの根本的な問題があります。
提案されたメトリックのほとんどすべてが、実際のコードの現実の世界で、生のSLOC（コードのソース行）と強くまたは非常に強く相関していることが示されています。
これが、1970年代にハルステッドの指標を台無しにしたものです。 （偶然、ある日、1978年頃、私はハルステッドのメトリックスについての新しい博士号による講演に参加しました。そこで彼はこれを指摘しました。）
最近では、McCabeの循環的複雑度は未加工のSLOCと非常に強く相関していることが示され、調査を行った人は、McCabeの測定基準が何か有用なことを教えてくれるのかと大声で疑問に思いました。
私たちは何十年も前から、大きなプログラムは小さなプログラムよりも問題を抱えている可能性が高いことを知っていました。私たちは何十年も前から、大きなサブルーチンには小さなものよりもバグがある可能性が高いことを知っていました。これを伝えるために難解なメトリックが必要なのはなぜですか。テーブル全体に広がる4つのプリンターページを見ると十分説得力があるはずです。