7
経験的指標に基づいて、ソフトウェアが良いか悪いかをどのように知るのですか?
現在、5か月前にコア開発を終了したが、依然として高レベルの欠陥があるプロジェクトを検討するよう求められています。約10個の欠陥が修正されるごとに発生するのは、少なくとも4個、場合によっては8個の欠陥が発生することです。 ベンダーでのコーディング慣行は貧弱であり、これについては一般的な合意があると思います。しかし、ソフトウェアに構造的な問題があるかどうか疑問に思っていますか?欠陥密度は有用な尺度ですが、コアソフトウェアの作成が不適切な場合は、ベンダーが行っていることはすべて問題を解決することです。 インフラストラクチャでは、何かが不完全に構築されている場合、より明確に定義されていますが、LOCごとの欠陥のほかに、ソフトウェアにどのような測定値を使用できますか? この製品は4か月間欠陥修正フェーズにありますが、重大な欠陥はまだ十分に解決されていません。回帰の問題を修正するだけで、新しい機能を注入することはありません。 これは開発品質の問題を示しており、満足していません。ただし、製品自体に根本的な欠陥がある場合、それは別の問題です。懸念されているのは、コアコードベースの作成が不十分であり、ドキュメントが限られているため、外部の開発者はすべて、問題をAからBにシフトしているだけです。機能的にします。 サードパーティから製品を受け入れ、サポートを求められた場合、標準を定義するためにどの受け入れ基準を使用しますか? リード開発者にリリースごとのコードのピアレビューを行わせることに加えて、他に何ができるかわからない?