7

ソフトウェアの品質を測定するために使用されるメトリックの経験がある人がいるかどうか疑問に思っていました. コードの複雑さの指標があることは知っていますが、有効期間中の実際のパフォーマンスを測定する特定の方法があるかどうか疑問に思っています。実行時のパフォーマンスではなく、品質の尺度です。これらを収集するのに役立つ提案されたツールも大歓迎です。

これらの質問に答えるための測定値はありますか:

  • ソフトウェアの変更/強化がどれほど簡単か、堅牢性
  • それが十分に一般的/一般的なソフトウェアである場合、それはどの程度再利用可能ですか
  • コードに関連付けられた欠陥の数
  • これは再設計/再コーディングする必要がありますか
  • このコードはどのくらいの期間使用されていますか
  • 開発者は、コードがどのように設計および実装されているかを気に入っていますか?

これらのほとんどは、CM およびバグ報告ツールと密接に結び付ける必要があるようです。

4

7 に答える 7

1

あなたが言う言葉でコードの品質を測定することが非常に簡単な仕事であり、メトリクスが正確であるなら、おそらくプロジェクトマネージャーはもう必要ないでしょう. さらに、良い管理者と悪い管理者の差は非常に小さくなります。そうではないため、ソフトウェアの品質を正確に把握することは簡単なことではありません。

質問は、異なる方法で定量化されているか、定量化に非常に主観的である複数の領域にまたがっているため、これらを共通のターゲットに対応するカテゴリにグループ化する必要があります。次に、各カテゴリに「重要性」要因を割り当て、そこからいくつかの指標を導き出すことができます。

たとえば、静的コード分析ツールを使用してコードの構文品質を測定し、そこからいくつかの指標を導き出すことができます。

バージョン管理システムと統合されたバグ追跡ツールを使用して、バグ/コード行からメトリックを導出することもできます。

コーディングプロセスの堅牢性、再利用、効率を測定するために、開発された機能ごとにデザインパターンの使用を評価できます(もちろん、それが理にかなっている場合)。これを達成するのに役立つツールはありませんが、ソフトウェアの成長を監視し、これらに数字を付ければ、プロジェクトがどのように進化しているか、正しい方向に進んでいるかどうかについてかなり良いアイデアを得ることができます. コード レビュー手順を導入すると、これらを追跡しやすくなり、開発プロセスの早い段階で対処できる可能性があります。これらに付ける数値は、適切な設計パターンを使用して実装された機能の割合である可能性があります。

メトリックは非常に抽象的で主観的なものになる可能性がありますが、それに時間を割いて常に改善しようとすれば、有益な情報を得ることができます。

ただし、ソフトウェア プロセスのメトリックについて注意すべき点がいくつかあります。

  1. うまくやらない限り、メトリクスは良いどころか悪いものになってしまう可能性があります。
  2. メトリクスをうまく行うのは難しい。
  3. メトリックを使用して個々のパフォーマンスを評価したり、ボーナス スキームを提供したりする場合は注意が必要です。これを行うと、誰もがシステムをごまかそうとするようになり、メトリックは無価値であることが証明されます。
于 2009-06-29T22:59:22.520 に答える
0

サンプルプロットを含むソフトウェア品質のさまざまな側面について説明している次のページを確認することをお勧めします。測定に必要な品質特性の一部は、Sonarなどのツールを使用して導き出すことができます。次の側面のいくつかをどのようにモデル化するかを理解することは非常に重要です。

  1. 保守性:コードの変更/テストやコードの再利用がいかに簡単かについておっしゃいました。これらは、主要なソフトウェア品質特性であると考えられている保守性のテスト容易性と再利用性の側面に関連しています。したがって、保守性をテスト可能性(ユニットテストカバレッジ)と再利用可能性(コードの凝集性インデックス)の関数として測定できます。
  2. 欠陥:欠陥だけを測定するのは良い考えではないかもしれません。ただし、欠陥密度をモデル化できれば、良い画像が得られる可能性があります。
于 2013-02-14T18:57:31.640 に答える
0

より顧客に焦点を当てた指標は、ソフトウェア ベンダーがバグを修正して新機能を実装するのにかかる平均時間です。

バグ追跡ソフトウェアの作成日とクローズ情報に基づいて、非常に簡単に計算できます。

平均的なバグ修正/機能の実装時間が非常に長い場合、これはソフトウェアの品質が悪いことを示している可能性もあります。

于 2009-10-03T12:37:06.867 に答える
0

経済的な方法またはプログラマーの方法でそれを行うことができます。

経済的な方法の場合、コードの改善、バグの修正、新機能の追加などのコストを測定します。2 番目の方法を選択した場合は、プログラムで作業するスタッフの数と、平均的なバグを人間の時間で見つけて修正するのがどれほど簡単かを測定することをお勧めします。確かに、コストは市場の状況に依存し、人的時間は実際の人とそのスキルに依存するため、完璧ではありません。したがって、両方の方法を組み合わせた方がよいでしょう。

このようにして、コードの品質を測定するためのいくつかの手段を取得します。もちろん、プロジェクトのサイズやその他の要因を考慮に入れる必要がありますが、主なアイデアが明確であることを願っています。

于 2009-06-29T21:37:26.710 に答える
0

これについては、古い Joel on Software Discussion グループからの良いスレッドがあります。

于 2009-06-29T21:12:16.057 に答える
0

一部の SVN 統計プログラムは、送信ごとに変更された行の概要を提供することを知っています。バグ追跡システムがあり、バグを修正して機能を追加する人などは、バグが修正されたときにコミット番号を述べている場合、各バグ/新機能リクエストによって影響を受けた行数を計算できます。これにより、変更可能性の測定値が得られます。

次は、見つかったバグの数を数えて、コード行数との比率で設定するだけです。高品質のソフトウェアがコードラインごとに持つべきバグの数には、いくつかの値があります。

于 2009-06-29T21:14:50.687 に答える