経験的測定基準に基づいて、ソフトウェアが良いか悪いかをどのようにして知るのですか？
現在、5か月前にコア開発を終えたが、依然として高いレベルの欠陥があるプロジェクトを検討するように求められています。修正された約10個の欠陥ごとに何が発生するか、少なくとも4個、場合によっては8個の欠陥を発生させます。
ベンダーでのコーディング慣行は貧弱で、これについては一般的な合意があると思います。しかし、ソフトウェアに構造的な問題があるのでしょうか。欠陥密度は有用な指標ですが、コアソフトウェアが適切に記述されていない場合は、ベンダーが行っていることのすべてが問題を変えています。
インフラストラクチャでは、何かが適切に構築されていない場合に、より明確になります。LOCごとの欠陥のほかに、ソフトウェアにどの測定を使用できますか？
製品は4か月間欠陥修正フェーズにありますが、重大な欠陥はまだ十分に解決されていません。新しい機能を挿入するのではなく、回帰の問題を修正するだけです。
これは、開発品質の問題を示しており、満足のいくものではありません。ただし、製品自体に根本的な欠陥がある場合、それは別の問題です。心配なのは、コアコードベースが不適切に記述され、ドキュメントが限られていることです。外部開発者が行っていることはすべて、問題をAからBにシフトすることです。内部開発チームが引き継ぐと、基本的にコードを機能させる。
それで、サードパーティから製品を受け入れ、それをサポートするように求められた場合、標準を定義するためにどのような受け入れ基準を使用しますか？
リード開発者にリリースごとのコードのピアレビューを行わせることに加えて、他に何ができるかわかりませんか？
あなたはしません。
ソフトウェアの品質を客観的に測定することは本当に難しい。解決策がないほど難しい。私は、この解決策がまったくあり得るかどうかという疑問に手を出すために、この回答を控えていますが、なぜそれを定義することが本当に難しいのかを簡単に指摘します。
現状維持による推論
キリアン・フォスが指摘したように、「良い」ソフトウェアの簡単な手段があれば、私たちはそれをすべて使用し、誰もがそれを要求するでしょう。
管理者が特定の指標を適用することを決定したプロジェクトがあります。うまくいったこともあれば、うまくいかなかったこともあります。有意な相関関係は知りません。特に重要なシステムソフトウェア（飛行機、自動車など）には、SWの品質を「保証」するための多くのメトリック要件があります。これらの要件が実際に高品質になることを示す研究はありません。反対。
カウンターインテリジェンスによる推論
また、すでにキリアンによってほのめかされており、より一般的には、「すべてのメトリックができるし、されるだろう」と表現されています。
メトリックを再生するとはどういう意味ですか？これは開発者にとって楽しいゲームです。メトリック値が本当に見栄えがよいことを確認しながら、本当にひどいことをします。
LOCごとに欠陥を測定するとします。どうやって演奏するの？簡単-コードを追加するだけです！ 100行を超える操作が行われず、突然LOCあたりの欠陥が少なくなるような愚かなコードを作成します。何よりも、実際にソフトウェアの品質をそのように低下させました。
ツールの欠点が悪用され、定義が最大限に引き伸ばされ、まったく新しい方法が発明されます。基本的に、開発者は本当に賢い人であり、チームで1人の開発者だけがメトリクスを楽しんでいる場合、メトリクスは疑わしいものになります。
これは、指標が常に悪いと言っているわけではありませんが、これらの指標に対するチームの態度は重要です。特に、これは、下請け業者とサードパーティベンダーの関係ではうまく機能しないことを意味します。
間違ったターゲティングによる推論
測定したいのはソフトウェアの品質です。測定するのは、1つ以上のメトリックです。
あなたが測定することとそれがあなたに言うだろうとあなたが信じるものとの間にはギャップがあります。このギャップはかなり巨大です。
それは私たちの周りのあらゆる種類のビジネスで常に起こります。 KPI（主要業績評価指標）に基づく決定を見たことがありますか？それはちょうど同じ問題です-あなたは会社にうまくやってもらいたいが、あなたは何か他のものを測定します。
定量化可能性による推論
メトリックを測定できます。それが、私たちがそれらにまったく対処する唯一の理由です。ただし、ソフトウェアの品質はこれらの測定可能なエンティティをはるかに超えており、定量化するのが非常に難しい多くのことが含まれています。ソースコードはどの程度読みやすいですか。デザインの拡張性はどの程度ですか？新しいチームメンバーがオンボーディングするのはどれくらい難しいですか？などなど.
メトリックのみでソフトウェアの品質を判断し、定量化できない品質の部分に目を向けると、確かにうまくいきません。
編集：
概要
上記はすべて、指標に基づいてソフトウェアの良し悪しを客観的に判断することに関するものです。つまり、メトリックを適用する必要があるかどうか、いつ適用するべきかについては何も言っていません。
実際、これは一方向の影響です。悪いメトリックは悪いコードを意味します。一方向性とは、不良コードが不良メトリックを保証するものではなく、良好メトリックが良好コードを保証するものではないことを意味します。一方、これはそれ自体、メトリックを適用してソフトウェアの一部を判断できることを意味します-この影響を念頭に置いてください。
ソフトウェアAを測定すると、測定基準が非常に悪くなります。次に、コードの品質が悪いことを確認できます。ソフトウェアBを測定し、測定基準に問題がなければ、コードの品質について何の手掛かりもありません。それが本当に「コードが良い=>メトリックが良い」であるときに「メトリックが良い=コードが良い」と考えることに騙されてはいけません。
本質的には、メトリックを使用して品質の問題を見つけることができますが、品質自体を見つけることはできません。
はい、メトリックをある程度調べれば、コードに品質の問題があることがわかります。
より具体的には、コードベースで複雑性分析ツールを実行すると、コードが良いか悪いかがわかります。
たとえば、 source monitor を実行できます。
これからわかることは、コードがどれほど複雑かということです。私が経験したすべての問題のあるシステムに悪い数字があったことをお話しします。許容限界をはるかに超える数十から数百のメソッドの複雑さ。ひどい数字。ひどい複雑さ、入れ子、深さなど。これは、多くの問題、一定の高い欠陥率、他の何かを壊すことなく変更を行うことが困難になるなどにつながります。
もう一つは欠陥です。やがてシステムは安定するはずです。理想的には、新しい欠陥はゼロに向かうか、少ない数に平坦化する必要があります。つまり、新しい欠陥と現在の欠陥は時間とともに減少するはずです。
プロットは次のようになります。
経時的な欠陥
それらが一定または増加し続ける場合、ソフトウェアは適切ではありません。あと4か月なので、あと数か月から1年は差し上げます。 6か月から1年後、継続的に欠陥が発生した場合、品質は良くありません。あなたのチームは別の 泥の玉 を開発しました。
次のテスト。持ってる？そうでない場合、品質が低下し、バグが増え、チャーンが増加します。それらがある場合、コードカバレッジなどのメトリックスは、カバーされているコードの量を把握するのに適していますが、品質を測定しません。優れたコードカバレッジ数を見てきましたが、実際のテストはくだらないものでした。彼らはシステムの動作や機能をテストしていませんでした。開発者は、管理のためのメトリック数を改善するためにそれらを書いていました。したがって、あなたはテストを受ける必要があり、それらは優れている必要があります。コードカバレッジ自体は、品質の指標ではありません。
コードレビュー、あなたはそれらを実行していますか？そうでない場合は、品質が低下します。これは、ジュニア開発者にとって特に重要です。アジャイルを行う場合は、「コードレビュー」というコードレビュータスクをストーリーに追加するだけです。管理者が番号を追跡する場合は、 Crucible のようなレビューを追跡するツールが必要になります。ここでは、コードレビュー番号またはメトリックは、プロセスの一部である必要があるという事実を除いて、それほど重要ではないと思います。すべてのチェックインにレビューが必要なわけではありません。しかし、レビューは、人々がホイールを再発明したり、他の人が理解および/または維持できないコードを記述していないことを確認するのに役立ちます。
最後に、コードを評価する必要があるだけで、それ以外の指標はありません。問題のあるすべてのコードプロジェクトには、次のような性質があります。
- 不十分なデータ構造。すべてが文字列であるか、XMLがあらゆる場所に渡され、あらゆる場所で解析されているか、神のオブジェクト、または不必要に複雑で汎用的なデータ構造であり、ドメインモデルはありません。
- 組織または構造の欠如、重要なプロジェクトには、ロジックを分離するいくつかの分割または階層化が必要です。 ここを見てください ...このタイプの編成または分離（どこにでもロジックが混在している）が表示されない場合、システムの保守と理解が難しくなります。
- 抽象化より。逆の場合もありますが、システムが抽象化されすぎています。すべてがインターフェースと抽象クラスである場合、または大量のクラス「ラッパー」タイプのクラスをナビゲートする必要がある場合、新しい開発者がオブジェクトの膨張をナビゲートできなくなるため、品質が低下します。
- コードがわかりにくい。熟練した開発者であり、理解しにくいコードを見ている場合、品質に問題があります。私の個人的な測定基準は、コードを見ていて、それを追うのが難しい、または私を馬鹿げていると感じた場合、またはロジックを理解するために多くの脳のサイクルを浪費しているように感じる場合、それは悪いコードです。熟練した開発者がフォローするのに苦労している場合は、新しい開発者にとってどのようなものになるか想像してみてください。彼らは問題を紹介します。
私のアドバイスは、コードの複雑さの分析を実行することです。結果を共有しないでください。代わりに、結果をフォローアップして、独立した調査を行い（コードを確認）、コードベースの全体的な状態を判断します。これから、アクションプランを作成し、コードの複雑な領域のいくつかを修正してください。
メトリックの悲しいことは、メトリックの結果の値を改善することになるかもしれませんが、それらによって測定されることが意図された品質ではないということです...
Visual Studioには、コンパイラの警告をエラーとして扱うための設定があります。現在、一部の人々は警告を理解しておらず、コードをコンパイルするために、単純なトリックを使用します（「pragma disable warning」または「new」キーワードを関数/プロパティに追加して、ベースの非仮想メンバーを非表示にしますクラス）。
ソースコードにアクセスできる場合は、静的コード分析を実行できます。 .Netプロジェクトの場合、たとえば、 FxCopまたはReSharper InspectCode。開発チームが正しく使用すると、ツールは品質の向上に役立ちます。しかし、もちろん、警告を理解せずに削除するための「修正」が可能です。
あなたは自動テスト/ UnitTestsを見ることができます：コードカバレッジはどれくらい良いですか？ただし、カバレッジだけでは、テストが実際にコードをチェックするのか、それとも1回だけ実行するのかはわかりません。
高品質を目指すことは態度であり、多くのツールとその測定基準でサポートできますが、開発者の態度がない測定基準は役に立ちません。
下、知る方法がありません。
元の質問の場合（哲学的答えの前）：製品は何をすることになっているのですか？欠陥数/密度で測定するだけでは不十分です。これがライブラリなのか、アプリケーションなのか、コードベースの大きさ、問題ドメインの大きさ、欠陥の重大度はわかりませんでした。たとえば、123の入力フォーマットの1つを処理しないことは、フォーマットが適切に処理されないことの重要性に応じて、ささいな欠陥またはショーストッパーになる可能性があります。そして、何よりも優れているのは高水準です。
この質問についての仮定：コードとソフトウェアには違いがあります。ソフトウェアは、クライアント/ユーザーが問題を解決するために使用するものとして定義しますが、コードはソフトウェアの構築材料です。
ソフトウェアは主観的にしか測定できません。つまり、ソフトウェアにとって重要な測定基準は、問題を解決するためにソフトウェアを使用するかどうかです。この測定基準は他者の行動に依存するため、主観的に異なります。注：一部の問題では、一部のソフトウェアが非常に役立つため、高品質（計算用のExcel）と見なされても、別の問題用の高品質ソフトウェア（MP3ファイルの再生用のExcel）ではないと見なされます。
コードは（通常）経験的メトリックで測定できます。しかし、解釈は品質の「はい/いいえ」ではなく、実際には「0からN」のスケールでもありません。指標は標準に対して測定します。したがって、メトリックは標準で定義された関心領域を見つけることができますが、関心領域が存在しないことは、これが高品質のコードであることを証明するものではありません。たとえば、有用なメトリック：コンパイルしますか？いいえ->品質ではありません。はい-> ???単体テストに合格していますか？番号？多分？ （なぜなら、ユニットテスト品質コードですか？）、はい-> ???。
したがって、Godelの不完全性証明が数学の公理について示したように（つまり、有限の公理のセットについて真または偽であると証明できない数学的ステートメントが存在する）、実際に「この品質である」と答えることはできないと思いますコード？'すべてのコードに対して。直観的には、品質に答えるためのソフトウェアメトリックと真または偽の可能性に答えるための数理公理との間にマッピングがおそらく存在します。
この主張をする別の方法は、自然言語に踏み込むことです。ウィリアムシェイクスピア、ルイスキャロル、マークトウェインはすべて成功した作家であり、作文の質の高さから多くの人々に愛されました。それでも、ランダムな12年生よりも一貫してそれらを評価する文法、語彙、スタイル、または音声のどの基準を適用できますか？そして、これら3つについていくつかの総合測度を作成することは可能かもしれませんが、それはジョンの書（KJV）、J.R.R。トールキン、ホーマー、セルバンテスなど？次に、バローズ、フォークナー、ヘミングウェイ、シルビアプラッツなどを投入します。メトリックは機能しません。
欠陥注入のようなメトリックを収集することに加えて、注意する必要がある1つのことは、欠陥の原因を解明することです。多くの場合、それは仕様に関連しています。
基本的に、仕様のエラー、仕様のあいまいさであり、インプラントが判断するか、実装のバグなのかです。
より定性的なアプローチは、ソフトウェアが有用かどうかを尋ねることです。よく見ると、どのソフトウェアにも欠陥が見つかる可能性があります。しかし、それがお金を稼ぐのに十分にうまく機能すれば、それはそれほど悪くないかもしれません。
私は彼らのプロセスを監査することで（そして逸脱を探すことで）これを測定します。
中央のソース管理、中央のビルドシステム、およびリリースされたブランチに統合する前にコードが確実にテストされるプロセスを提供するプロセスの証拠を探しています。
また、欠陥がリリースプロセスを通過した状況に応じて、プロセスがどのように変更されたかの証拠も探します。
彼らがこのレベルの監査に合格できない場合、彼らが一貫した信頼できるリリースを提供することを期待することはできません。
彼らがこの監査に合格し、プロセスを継続的に改善している場合、出力の一貫性は時間とともに改善する可能性があります。
これで問題が解決しない場合は、コードアーキテクチャに問題があり、現在のコードベースの拡張とテストに問題がある可能性があります。この場合、適切なオプションはありません。
完全に自動化された測定を探しているなら、私はこれらの人をお勧めします： Software Improvement Group
これは基本的に、ソースコードから自動的に抽出できるさまざまなメトリックの集合です（ユニットテストカバレッジ、関数サイズ、クラスの絡み合い、複製、LOCなど）。次に、これらの値は1〜5の星評価に変換されます。
彼らはまた、実際に読んでみる価値があるすべてのメトリックを説明するまともな本を持っています 'Building Maintainable software' 。