process - 最も有用なソフトウェア開発指標は何ですか?

Question

チームのソフトウェア開発プロセスを改善し、時間の見積もりを改善し、プロジェクトの実行中に対処する必要がある特殊なケースのバリエーションを検出するために使用できるメトリックを追跡したいと考えています。

各回答を 1 つの指標に限定し、その使用方法を説明し、良い回答に投票してください。

score 51 · Accepted Answer

51

_{(ソース: osnews.com )}

于 2009-03-20T08:04:55.337 に答える

score 12 · Accepted Answer

逆コードカバレッジ

テスト中に実行されなかったコードの割合を取得します。これは Shafa が言及したものと似ていますが、使い方が異なります。テスト中にコード行が実行された場合、それがテストされる可能性があることがわかります。しかし、コード行が実行されていない場合、それがテストされていないことは確かです。単体テストでこれらの領域を対象にすると、品質が向上し、カバーされたコードを監査するよりも時間がかかりません。理想的には両方を行うことができますが、それが実現することは決してありません.

score 11 · Accepted Answer

「チームのソフトウェア開発プロセスを改善する」: 欠陥の発見率と修正率

これは、コミットまたは検証された修正の数に対して提起された欠陥またはバグの数に関連しています。

これは非常に重要な指標の 1 つであると言わざるを得ません。

1. コードチャーン。毎日/毎週どのくらいのコードが変更されているか (これは、リリースに向けて安定させようとしている場合に重要です)、および、

2. 欠陥が修正よりも先に進んでいるか、またはその逆かを示します。これは、開発チームが QA/テスターによって提起された欠陥にどれだけうまく対応しているかを示しています。

修正率が低いということは、チームが他のこと (おそらく機能) に取り組んでいることを示しています。バグ数が多い場合は、開発者にいくつかの欠陥に対処してもらう必要があるかもしれません。
発見率が低いということは、ソリューションが素晴らしく、バグがほとんどないか、QA チームがブロックされているか、別のことに注力していることを示しています。

score 7 · Accepted Answer

見つけたバグのソースとタイプを追跡します。

バグソースは、バグが導入された開発段階を表します。(例: 仕様、設計、実装など)

バグの種類は、バグの広範なスタイルです。例えば。メモリ割り当て、不適切な条件。

これにより、開発のそのフェーズで従う手順を変更し、コーディングスタイルガイドを調整して、過剰に表現されたバグの種類を排除することができます。

score 7 · Accepted Answer

それに対して見積もりがあるタスクを実行するのにかかる時間を追跡します。彼らが十分に下回っていた場合は、その理由を質問してください。それらが十分に終わっている場合は、その理由を質問してください。

ネガティブなことにしないでください。タスクが吹き飛ばされたり、見積もりが大幅に下回ったりしても問題ありません。あなたの目標は、見積もりプロセスを継続的に改善することです。

score 7 · Accepted Answer

速度: 特定の単位時間あたりの機能の数。

機能をどのように定義するかはあなた次第ですが、それらはほぼ同じ大きさである必要があります。そうでない場合、速度はあまり役に立ちません。たとえば、ストーリーやユースケースによって機能を分類できます。これらは、すべてほぼ同じサイズになるように分割する必要があります。反復ごとに、いくつのストーリー (ユースケース) が実装 (完了) されたかを把握します。機能/反復の平均数がベロシティです。機能ユニットに基づいて速度がわかったら、それを使用して、機能に基づいて新しいプロジェクトを完了するのにかかる時間を見積もることができます。

[編集] または、機能ポイントやストーリーポイントなどの重みを複雑さの尺度として各ストーリーに割り当て、完成した各機能のポイントを合計して、ポイント/反復で速度を計算することもできます。

score 4 · Accepted Answer

ソースコード内のクローン (類似のコードスニペット) の数を追跡します。

クローンを見つけたらすぐにコードをリファクタリングして、クローンを取り除きます。

score 3 · Accepted Answer

関数の長さの平均、またはより良い感触を得るための関数の長さのヒストグラム。

関数が長くなればなるほど、その正しさは明らかではなくなります。コードに長い関数がたくさん含まれている場合、そこにいくつかのバグが隠れている可能性があります。

score 2 · Accepted Answer

http://cccc.sourceforge.net/

ファンインとファンアウトは私のお気に入りです。

ファンイン：このモジュールを使用/認識している他のモジュール/クラスの数

ファンアウト：このモジュールは他にいくつのモジュールを使用/認識していますか

score 2 · Accepted Answer

時間の見積もりを改善する

Joel Spolsky の Evidence-based Scheduling は、それ自体がメトリックではありませんが、まさにあなたが望むもののように思えます。http://www.joelonsoftware.com/items/2007/10/26.htmlを参照してください。

score 2 · Accepted Answer

ソースの一部がレビューを受けているかどうか、受けている場合はどのタイプかを追跡します。その後、レビューされたコードとレビューされていないコードで見つかったバグの数を追跡します。

これにより、見つかったバグに関して、コードレビュープロセスがどの程度効果的に機能しているかを判断できます。

score 2 · Accepted Answer

スクラムを使用している場合は、バックログ。各スプリント後のサイズはどれくらいですか? 一定の割合で縮小していますか？または、(a) 当初考えられていなかったことが原因でバックログに押し込まれている (「誰も考えていなかった監査レポートの別のユースケースが必要です。バックログに追加します。 ") または (b) 約束された機能の代わりに、作業を完了せず、日付を満たすためにバックログにプッシュします。

score 2 · Accepted Answer

2

コミットごとの失敗したテストまたは壊れたビルドの数。

于 2008-10-09T22:15:32.263 に答える

score 2 · Accepted Answer

Mary Poppendieckが推奨するシステムが特に気に入って使用しています。このシステムは、パッケージとして取得する必要がある 3 つの総合的な測定値に基づいています (したがって、3 つの回答を提供するつもりはありません)。

サイクルタイム
- 製品コンセプトから最初のリリースまで、または
- 機能リクエストから機能展開まで、または
- バグの発見から解決まで
ビジネスケースの実現 (これがなければ、他のすべては無関係です)
- 損益計算書または
- ROIまたは
- 投資の目的
顧客満足
- 例:ネットプロモータースコア

ユーザーに価値を迅速に提供するという究極の目標に向けて歩調を合わせているかどうかは、これ以上知る必要はありません。

score 2 · Accepted Answer

2

クラス間の相互依存。コードがどの程度緊密に結合されているか。

于 2008-10-09T23:36:03.880 に答える

score 1 · Accepted Answer

QAチームによってバグが報告されるたびに、その欠陥が開発者による単体テストから逃れた理由を分析します。

これを永続的な自己改善の練習と考えてください。

score 1 · Accepted Answer

チームのソフトウェア開発プロセスを改善する

メトリクスはチームのソフトウェア開発プロセスを改善するのに何の役にも立たないことを理解することが重要です。それらを使用できるのは、使用している特定のメトリックに関して、開発プロセスの改善に向けてどれだけ進んでいるかを測定することだけです. おそらく私はセマンティクスについて口論していますが、あなたがそれを表現している方法が、ほとんどの開発者がそれを嫌う理由です. メトリックを使用して結果を測定するのではなく、メトリックを使用して結果を推進しようとしているようです。

別の言い方をすれば、コードカバレッジが 100% でお粗末な単体テストと、すばらしい単体テストで 80% 未満のカバレッジのどちらがよいでしょうか?

あなたの答えは後者でなければなりません。完璧な世界を望み、両方を用意することもできますが、最初に単体テストに集中し、その時点でカバレッジがそこに到達するようにすることをお勧めします。

score 1 · Accepted Answer

前述の指標のほとんどは興味深いものですが、チームのパフォーマンスを向上させるのには役立ちません。問題は、開発フォーラムで管理に関する質問をすることです。

プロジェクトスケジュールレベルおよび個人レベルでの見積もり/対/実績 (Joel の証拠に基づく方法への前のリンクを参照)、リリース時に削除された欠陥の割合 (私のブログを参照: http://redrockresearch.org/? p=58 )、スコープクリープ/月、および全体的な生産性評価 (パトナムの生産性指数)。また、開発者の帯域幅は測定に適しています。

score 1 · Accepted Answer

QA におけるメトリクスの追跡は、かなり前から基本的な活動でした。しかし、多くの場合、開発チームは、これらの指標がビジネスのあらゆる側面にどの程度関連しているかを十分に検討していません。たとえば、欠陥率、有効性、テストの生産性、コードカバレッジなどの典型的な追跡指標は、通常、ソフトウェアの機能面の観点から評価されますが、ソフトウェアのビジネス面での重要性に注意を払う人はほとんどいません。

ソフトウェアのビジネス面に多くの価値を付加できるその他の指標もあります。これは、ソフトウェアの全体的な品質ビューを見るときに非常に重要です。これらは、大きく次のように分類できます。

ビジネスアナリスト、マーケティング担当者、営業担当者が把握したベータユーザーのニーズ
製品管理チームによって定義されたエンドユーザー要件
ピーク負荷時のソフトウェアの可用性と、エンタープライズ IT システムと統合するソフトウェアの機能を確保する
大量トランザクションのサポート
ソフトウェアが提供する業界に応じたセキュリティ面
競合製品と比較した必須機能とあれば便利な機能の可用性
そして、さらにいくつか…。

score 1 · Accepted Answer

1

類似行の数。（コードをコピー/貼り付け）

于 2008-10-09T22:14:09.083 に答える

score 1 · Accepted Answer

障害解決効率の指標が気に入っています。DRE は、見つかったすべての不具合に対する、ソフトウェアリリース前に解決された不具合の比率です。ソフトウェアを本番環境にリリースするたびに、この指標を追跡することをお勧めします。

score 0 · Accepted Answer

おそらく、CodeHealerをテストできます

CodeHealerは、ソースコードの詳細な分析を実行し、次の領域の問題を探します。

未使用または到達不能コード、識別子としてのディレクティブ名とキーワードの使用、より高いスコープで同じ名前の他のものを隠す識別子などの品質管理ルールを監査します。
初期化されていない、または参照されていない識別子、危険な型キャスト、自動型変換、未定義の関数の戻り値、未使用の割り当て値などの潜在的なエラーをチェックします。
メトリック 循環的複雑度、オブジェクト間の結合（データ抽象化結合）、コメント比率、クラス数、コード行などのコードプロパティの定量化。

score 0 · Accepted Answer

スクラムを使用している場合、毎日のスクラムがどのように行われたかを知りたいと思うでしょう。人々は、やり遂げると言ったことをやり遂げていますか?

個人的には苦手です。私は日常生活で慢性的に轢かれます。

score 0 · Accepted Answer

0

コードカバレッジ率

于 2008-10-09T22:12:32.440 に答える

score -1 · Accepted Answer

-1

ソース管理コミットのサイズと頻度。

于 2008-10-10T14:36:28.263 に答える

process - 最も有用なソフトウェア開発指標は何ですか?

26 に答える 26

Related

Reference