タグ付けされた質問 「measurement」

コンテキスト：私は、すべてがMSショップのエンタープライズ開発者です。 コードやアプリケーションの保守性を客観的に測定するための良い方法を誰かがお勧めできますか？ なぜ保守性があるのか：バグとコードカバレッジの数のみを対象とするグループの "品質"メトリックにうんざりしています。特に保守性を測定していない場合は、どちらのメトリックも簡単にゲームできます。近視眼と締め切りは、実際に対処されない膨大な量の技術的負債をもたらします。 なぜ客観的に測定できるのか：私は大企業グループで働いています。客観的に測定できない場合は、人々に説明責任を負わせたり、それを改善することはできません。主観的な測定は、発生しないか、一貫して発生しません。 私はVS2010コードメトリックスを見ていますが、誰か他の推奨事項があるかどうか疑問に思っています。

23 c#  visual-studio-2010  metrics  maintainability  measurement 

1977年、Maurice Howard Halsteadは、ソフトウェアシステムの複雑さの尺度を導入しました。これには、プログラムの語彙、プログラムの長さ、音量、難易度、努力、モジュールの推定バグ数の測定が含まれます。ウィキペディアによると、難易度は、プログラムの読み取りまたは書き込み時のプログラムの理解の難易度に関連しており、努力は、アプリケーションのコーディングに要する時間（時間=（努力/ 18）秒）に変換できます。 データと計算がソフトウェア開発の何らかの側面に関係しない限り、測定は役に立ちません。ただし、特定の値以上の難易度が統計的に有意な欠陥の増加や、難易度とコードの読み取り時間の関係につながる傾向があることを示す作品は見つかりませんでした（Nの難易度は平均M時間を費やしますコードベースを理解する）または品質を決定するのに役立つ事実の後の時間を計算できることの分析（特に書く時間はすでに測定値として記録されているはずなので）特にHalsteadのバグ推定（Wikipediaには記載されていません）に興味があります-アプリケーションのバグの数はVolume / 3000またはEffort ^（2/3）/ 3000で推定できます。 私は2つのことを探しています： 誰もが実際のアプリケーションでHalsteadのソフトウェア複雑度測定を使用してソフトウェア品質を評価しましたか？もしそうなら、どのようにそれらを適用し、有用で、有効で、かつ/または信頼できる測定であることが判明しましたか？ ソフトウェアの品質に適用した場合のHalsteadの複雑さの測定の有効性（または無効性）を検討する調査、分析、またはケーススタディの形式で学術研究はありますか？ ソース行コード（SLOC）を使用してボリューム、難易度、努力、時間、バグのハルステッドメトリックに類似した何かを計算することを実証する調査、分析、またはケーススタディの形式の学術研究はありますか？Volumeは単にSLOCカウントに対応し、Difficultyは循環的複雑度（およびおそらく他の指標）に対応する可能性があると思われます。また、SLOCで努力、生産性、または時間を測定することは、誤解を招く可能性があることをよく知っています。

14 quality  metrics  measurement 

組織内にコードレビュープロセスを導入しましたが、うまく機能しているようです。しかし、時間の経過とともにプロセスの有効性を測定できるようにしたいと思います。つまり、コードがクリーンであるためにバグを見つけられないのですか、それとも人々がバグを拾っていないのでしょうか。 現在、効果的な完全自動化されたテストプロセスはありません。私たちは主に手動テストを採用しているため、この段階で見つかった欠陥に頼ってコードレビュープロセスが機能していることを確認することはできません。 誰もこの問題に出くわしたことがありますか、コードレビューの測定で何がうまくいくのかについて考えたことはありますか？

14 code-reviews  quality  metrics  measurement 

私は経営陣にリファクタリングへの努力を投資するよう説得するための議論を探しています。 Jiraを使用して作業を記録し、すべてのsvn-commitをjira呼び出しに関連付けます。 私のアイデアは次のことです。 実装が非常に悪いが頻繁に使用されるコードの領域を手動で見つけます。User-POVとDeveloper-POVの両方（バグ修正） JIRA-Issuesを含むsvn-commitsを取得します いくつかの基準（問題の種類、バージョン、優先順位など）に従って問題をフィルタリングします。 これらのバグに費やされた時間/努力を計算する リファクタリングの労力とリスクを推定する 数字を提示し、それを修正する努力を求めます。 これについてどう思いますか？そのような測定は有用であり、説得力があるでしょうか？長所と短所は何ですか？

13 svn  project-management  jira  measurement 

SLIMとソフトウェアの推定に関する職場でのトレーニングマニュアルからの引用を以下に示します。 また、努力と欠陥の間には相関関係があることに注意してください。つまり、特定のサイズのプロジェクトに割り当てられる人が多いほど、欠陥が多くなります。 労力は、プロジェクトの人時間（人年、人月）です。欠陥は、ライフサイクルの任意の時点で検出された欠陥の数です。サイズは、プロジェクトを構成するユースケース、機能ポイント、またはSLOCとして定義されます。 優れたプロセスと有能なエンジニアを想定すると、これは直感に反するように思われます。たとえば、より多くの人がいるということは、すべての成果物（要件の仕様、設計、コード、テスト）に注目することを意味します。より多くの目を持っていることは別として、私の直感は、適切な品質技術を利用するプロジェクトの努力と欠陥の間にはほとんど関係がないことを示唆しています。 欠陥と労力または欠陥とプロジェクトの人数との間の既知の関係を示唆する、Putnam Model（SLIMで使用される）に関するドキュメントを除いて、ドキュメントを見つけることができませんでした。これは既知の関係であり、「より多くの人=より多くの欠陥」という主張は有効ですか？

12 estimation  quality  metrics  measurement 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 ソフトウェア製品で測定できる品質には、目的への適合性（最終用途など）、保守性、効率など、さまざまな種類があります。これらのいくつかはやや主観的またはドメイン固有です（たとえば、優れたGUI設計原則は文化によって異なる場合や、使用状況に応じて、軍事的使用と消費者使用を考えます）。 私が興味を持っているのは、タイプのネットワーク（またはグラフ）に関連するより深い形式の品質とそれらの相互関係、つまり、各タイプが参照するタイプ、適切に関連する相互接続性の明確に識別可能なクラスターがあることです階層型アーキテクチャ、または逆に、型参照（「モノリシック」コード）の大きな「ボール」があります。また、各タイプおよび/またはメソッドのサイズ（たとえば、Javaバイトコードまたは.Net ILの量で測定）は、より複雑で管理しやすいものに分解される代わりに、大きな複雑なアルゴリズムがコードのモノリシックブロックとして実装されている場所を示す必要がありますチャンク。 このような考えに基づいた分析は、少なくとも品質の代用となる指標を計算できる可能性があります。高品質と低品質の間の正確なしきい値/決定点は主観的であると思われます。たとえば、保守性とは人間のプログラマーによる保守性を意味するため、機能の分解は人間の心の働きと互換性がなければなりません。そのため、考えられるすべてのシナリオで考えられるすべてのソフトウェアを超越する、数学的に純粋なソフトウェア品質の定義があるのではないかと思います。 また、品質の客観的なプロキシが普及すると、ビジネス上のプレッシャーにより、開発者は全体的な品質（プロキシで測定されない品質の側面）を犠牲にしてこれらのメトリックを追求することになるので、これは危険な考えかと思います。 品質に関する別の考え方は、エントロピーの観点からです。エントロピーは、システムが秩序状態から無秩序状態に戻る傾向です。中規模から大規模の実際のソフトウェアプロジェクトに携わったことのある人なら誰でも、コードベースの品質が時間とともに低下する傾向があることを理解するでしょう。一般に、ビジネス上のプレッシャーは、新しい機能に焦点を当てた変更（品質自体がアビオニクスソフトウェアなどの主なセールスポイントである場合を除く）、および回帰の問題と「適合」が合わない「シューホーン」機能性による品質の低下をもたらします品質とメンテナンスの観点。それでは、ソフトウェアのエントロピーを測定できますか？もしそうなら、どのように？

12 quality  metrics  measurement