あなたが言う言葉でコードの品質を測定することが非常に簡単な仕事であり、メトリクスが正確であるなら、おそらくプロジェクトマネージャーはもう必要ないでしょう. さらに、良い管理者と悪い管理者の差は非常に小さくなります。そうではないため、ソフトウェアの品質を正確に把握することは簡単なことではありません。
質問は、異なる方法で定量化されているか、定量化に非常に主観的である複数の領域にまたがっているため、これらを共通のターゲットに対応するカテゴリにグループ化する必要があります。次に、各カテゴリに「重要性」要因を割り当て、そこからいくつかの指標を導き出すことができます。
たとえば、静的コード分析ツールを使用してコードの構文品質を測定し、そこからいくつかの指標を導き出すことができます。
バージョン管理システムと統合されたバグ追跡ツールを使用して、バグ/コード行からメトリックを導出することもできます。
コーディングプロセスの堅牢性、再利用、効率を測定するために、開発された機能ごとにデザインパターンの使用を評価できます(もちろん、それが理にかなっている場合)。これを達成するのに役立つツールはありませんが、ソフトウェアの成長を監視し、これらに数字を付ければ、プロジェクトがどのように進化しているか、正しい方向に進んでいるかどうかについてかなり良いアイデアを得ることができます. コード レビュー手順を導入すると、これらを追跡しやすくなり、開発プロセスの早い段階で対処できる可能性があります。これらに付ける数値は、適切な設計パターンを使用して実装された機能の割合である可能性があります。
メトリックは非常に抽象的で主観的なものになる可能性がありますが、それに時間を割いて常に改善しようとすれば、有益な情報を得ることができます。
ただし、ソフトウェア プロセスのメトリックについて注意すべき点がいくつかあります。
- うまくやらない限り、メトリクスは良いどころか悪いものになってしまう可能性があります。
- メトリクスをうまく行うのは難しい。
- メトリックを使用して個々のパフォーマンスを評価したり、ボーナス スキームを提供したりする場合は注意が必要です。これを行うと、誰もがシステムをごまかそうとするようになり、メトリックは無価値であることが証明されます。