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

最近、マネージャーがバグの修正に非常に多くの時間を費やしていると発表しました。彼は私たちが常に完璧なコードを書くべきだと思っていると思います（もちろん、まだ不可能な締め切りに間に合います！）そして、新しいコードを書くのにバグ修正に費やす時間の業界平均は何だろうと思いました。 だから、新しいコード開発に対するバグ修正に時間を費やした指標はありますか？または、業界全体のバグ修正時間の実証分析はありますか？50％がバグの修正に費やしすぎていますか？20％または33％はどうですか？ 個人的な経験からの逸話的な証拠を受け入れることはうれしいです。それは、ここでパフォーマンスを比較できる統計の一部を形成するからです。

17 metrics 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 前日よりも生産性が高いまたは低いソフトウェアを開発していることをどのように追跡できますか？

16 productivity  metrics 

最近、私の仕事でパフォーマンスのレビューが出てきて、私は興味深い立場に置かれました。私たちのチームは多くのペアプログラミングを行っていますが、これはチームメンバー間のスキルの差を平均化する傾向があります（特にペアをローテーションすることを考慮して）。一般に、パフォーマンスレビューを行うときは、行った作業を振り返り、達成したことと、昇給やその他のメリットを交渉しようとする期待をどのように上回ったかを示します。 このような環境で個々のパフォーマンスをどのように実証（または測定）しますか？

15 pair-programming  metrics 

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 

Code Reviewでの質問のおかげで、下のコードのCyclomatic Complexityが正確に何であるかについて少し意見の相違（本質的に何かを学ぶ機会）になりました。 public static void main(String[] args) { try { thro(); thro(); thro(); thro(); thro(); thro(); thro(); } catch (NullPointerException e) { } } private static Random random = new Random(); public static void thro() throws NullPointerException { if (random.nextBoolean()) throw new NullPointerException(); System.out.println("No crash this time"); } Eclipseでこのコードを記述し、Eclipseメトリックプラグインを使用すると、メインメソッドのMcCabe …

12 metrics  cyclomatic-complexity 

同僚と出口インタビューを通じて、私は私の小さな会社で、私が他の仕事にいるときよりも3〜10倍多くのコードに対して「責任がある」と聞いています。私は自分のワークロードを他の分野と比較するために使用できる、ある種のあいまいなメトリックを探しています。 「コードの責任」とは、「コードベースのエリアXを知っているのは私だけ」という意味ではありません（悲しいことに、スタートアップ環境ではよく当てはまります）。むしろ、「code_base_size / number_of_developers」。 コードの行を数えるだけでなく、作業負荷をより正確に測定するために使用できるリソースはありますか？

12 metrics 

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

12 estimation  quality  metrics  measurement 

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

12 quality  metrics  measurement 

私は、QA組織としてのテスト効率の測定に関する経営陣との議論に参加しようとしています。この背後にある主な理由は、私たちのチームの半分が外注されており、私たちのビジネスは私たちがどれほど効果的/効率的であるかのいくつかのメトリックを提供したいので、私たちは請負業者のサービス契約と契約パラメータを交渉するための基礎データを持っている。 このテーマについて私が見つけた意見のほとんどは、開発者の効率性に関するものです。コードの行、配信されたストーリーポイント、導入された欠陥などです。 しかし、テスターはどうですか？テストは主に要件ベースで、手動、半自動、自動のテストが混在しています（すべてを自動化していないためではなく、テストシステムで自動化できないものがあるためです）。

11 testing  efficiency  qa  metrics 

会社のコスト削減目標のメトリックを生成しようとしています。これを行うには、ゼロから構築したり、COTSソリューションを購入したりするのではなく、オープンソースのWebアプリケーションを使用することで実現した節約を見積もります。プロセスの1つのステップは、アプリケーションを自分で開発するのにどれだけの費用がかかるかを見積もることです。残念ながら、完全な推定プロセスを経ずにこれを実行するための非常に簡単な方法に私は困惑しています。 私はソースコードを持っているので、それを書くのに必要な開発者の時間の非常に大まかな見積もりを与えることができるいくつかの経験則があると思うでしょう。残念ながら、トピックに関する私のWeb検索では、ほとんどの場合、コード行が生産性や品質の良い指標ではないという記事や意見が出されます。 これまでの私の最善の解決策は、開発者が1日に書き込むことができる行数を選択し、そこから開発者の時間数を計算することです。その方法を使用する場合、開発者の生産性の主張を裏付けるいくつかの（できれば研究に基づく）証拠を持ちたいです。 私が行っていることの1つは、最終的なメトリックを生成するために必要なのは、開発者の時間またはプロジェクトのコストの下限のみです。推定値が高ければ高いほど、メトリックは良くなりますが、数値を大きくするよりも推定手法の方が攻撃しにくいでしょう。 オープンソースプロジェクトの価値を推定するより良い方法はありますか？

11 open-source  estimation  metrics 

ソフトウェアの「データ衛生」インデックスがあるべきか-プログラムがどれだけクリーンであるかを示すために？未使用の一時ファイル、レジストリエントリ、環境変数などを作成しない たとえば、Windowsのユーザーフォルダーを見ると、アプリケーションで使用されるあらゆる種類のワークスペースファイルが表示されます。 たとえば、これにより、何をバックアップする必要があり、何をマシン生成として破棄できるかを知ることが難しくなります。

11 environment  metrics  data  application-design 

結合と凝集に関するc2wikiページから： 凝集度（モジュール内の相互依存性）強度/レベル名：（悪いものから良いものへ、高い凝集性が良い） 偶然の凝集度：（最悪）モジュール要素は無関係 論理的凝集度：要素は、外部モジュールから選択されたものと同様のアクティビティを実行します。つまり、実行する操作を選択するフラグによって実行されます（CommandObjectも参照）。つまり、関数の本体は1つの巨大なif-else / switch on operationフラグです 一時的な結束：実行される一般的な時間のみに関連する操作（すなわち、initialization（）またはFatalErrorShutdown？（）） 手続き的結束：それぞれが異なるデータにある、異なるが順次のアクティビティに関与する要素（通常、線形シーケンス境界に沿って複数のモジュールに簡単に分割できます） コミュニケーションの結束：同じデータまたは入力を必要とする以外は無関係な操作 シーケンシャル凝集：重要な順序での同じデータの操作。1つの関数の出力が次の関数に入力される（パイプライン） 情報のまとまり：モジュールはいくつかのアクションを実行します。各アクションには独自のエントリポイントがあり、アクションごとに独立したコードがあり、すべて同じデータ構造で実行されます。基本的に、抽象データ型の実装。つまり、sales_region_tableとその演算子の構造を定義します。init_table（）、update_table（）、print_table（） 機能的結束：すべての要素が1つの明確に定義されたタスク、つまり1つの操作を実行する関数get_engine_temperature（）、add_sales_tax（）に貢献します （強調鉱山）。 私は論理的な結束の定義を完全に理解していません。私の質問は： 論理的な結束とは何ですか？ なぜそんなにひどいラップ（2番目に悪い凝集力）になるのですか？

10 code-quality  metrics  cohesion 

チームプロジェクトについて外部のアドバイスを求めている開発者に出会いました。企業の幹部、プロジェクトマネージャー、開発者向けに、メトリックを自動的に計算し、反復ごとにグラフ化できる巨大なソフトウェアスイートを開発していることがわかりました。 コンピューターサイエンスのバックグラウンドを持つ学生として、メトリックスとその重要性についてほとんど知りませんが、私の質問は次のとおりです。 ほとんどの企業には何らかの方法がありますか、意味のあるメトリックを測定するために、エレガントなプログラムである必要はありませんか？ プロジェクトの範囲と見積もりを絞り込むのに役立つ単一または組み合わせのメトリックはどれですか？ 指標を分析する人として、どのくらいの頻度で指標に基づいて決定を下しますか？IE。毎週失敗したテストは劇的に増加していますか？ 調査指標の導入により、プロジェクトの理解が深まったと思いますか？ なぜだかわかりませんが、開発者プロジェクトに興味をそそられました。yの場合

9 project-management  metrics 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 4年前休業。 もうすぐ卒業するつもりで、ずっと考えていました。私は自分の自由時間に作成したいくつかの本当に小さなプロジェクト/スクリプト（〜100〜200 LOC）を持ち、それらをGithubに持っています。それらが将来の雇用主に提示されるのに十分な「価値がある」かどうか疑問に思っていましたか？または、大きなもの（〜1000 LOC）のみを含める必要がありますか？

8 interview  metrics