新しいプログラムの品質レベルを追跡するために、人々はどのような手法を推奨していますか? 「品質レベル」などの定義が不十分な用語を採用し、それを定量化してから予測する方法はありますか? 現在、バグ率と S カーブを使用していますが、品質レベルを評価、推定、予測する他の方法を探しています。
4 に答える
1
あなたのバグを数えることが、それと比較する何かなしで何をするのかわかりません。作成したソフトウェアが非常に難しく、エッジケースがたくさんある場合はどうなりますか？ある種の比較が必要です...
他の答えの1つが明らかにジョークコードであったとしても、レビューもおそらく良い考えです。バグが多すぎる場合は、より優れたエンジニアを雇うか、コードの記述を減らしてください。
編集：コメントを検討した後に追加...
すべてのバグは、ユニークなサッキースノーフレーク（サックフレーク？）のようなものです。それらは、顧客と開発者にさまざまなレベルの影響を及ぼします。私は少なくともこれを考慮に入れます。おそらく、重大度（修正に対する顧客のプッシュの尺度）とそれを修正するために費やしたエンジニアリング時間を追加すると、精度の向上に役立つ可能性があります。私の懸念は、ソフトウェアの開発に関しては、これはまだ「品質」の単純化を超えているということです。
悲しいことに、ソフトウェアの品質！=製品の品質。最近リリースされたFallout3というゲームは、たくさんの賞を獲得し、たくさんのお金を稼ぎました（少なくとも私は推測します）が、少なくともPCではバグの多いジャンクでもありました。
正しいことを追跡して最適化していることを確認してください。＃バグ対時間の追跡は、バグ数対時間の追跡にすぎません。これ以上読むには、ある程度の仮定が必要ですが、正しいか間違っているかは関係ありません。
あなたの目標は何ですか？バグはソフトウェア品質の一部にすぎません。継続したい場合は、ソフトウェアの保守性をサポートすることが重要です。多くの場合、バグ修正により、コーダーが急いで物事を行った場合、物事の保守が困難になる可能性があります。これにより、将来の修正と機能が難しくなり、修正によって新しいバグが追加される可能性があります。
于 2009-04-07T17:08:31.210 に答える
0
これは、どのような種類の比較をしようとしているかによって大きく異なります。1 つのプロジェクトを長期にわたって見ていて、チームが変わらない場合、バグ率は意味があるかもしれません。ただし、異なるプロジェクトや異なるチームを比較している場合、既知のバグの割合を実際に比較しているため、バグの発生率などを比較する方法はありません。あるチームは他のチームよりもバグを特定するのが得意で、バグの発生率が高く見えるかもしれませんが、実際にはソフトウェアの品質が優れているチームです。
于 2009-04-07T16:42:25.703 に答える
0
単体テストは行っていますか？単体テストのコード カバレッジは、品質の適切な尺度となります。
于 2009-04-07T17:20:23.613 に答える