埋め込まれたソフトウェア欠陥率

Question

ユニットテスト、コードレビュー、静的コード分析がなく、プロジェクトのコンパイルが約1500の警告を生成することを考えると、組み込みプロセッサ（DSP）用に記述されたC ++コードベースでどのような欠陥率が期待できますか。 5つの欠陥/100行のコードは合理的な見積もりですか？

Answer 1

この場合の推定値の妥当性に対する私の懐疑論にもかかわらず、私は関連する可能性のあるいくつかの統計を見つけました。

の この記事, 、著者は、で公開された「実証研究の大規模な研究」からの数字を引用しています ソフトウェア評価、ベンチマーク、およびベストプラクティス （ジョーンズ、2000）. 。で sie cmmレベル1, 、これはこのコードのレベルのように聞こえますが、あたり0.75の欠陥率を期待できます 関数ポイント. 。その方法を判断するために、お知らせします 関数ポイント そして、locはあなたのコードに関連するかもしれません - あなたはおそらく必要があります メトリックツール その分析を実行します。

コードのスティーブマッコネルが完了しました 研究を引用します 同じチームによって開発された11のプロジェクトのうち、コードレビューなしで5つ、コードレビューを含む6つのプロジェクト。非レビューされたコードの欠陥率は100 locあたり4.5で、レビューされた場合は0.82でした。そのため、他の情報がない場合、あなたの見積もりは公平に思えます。しかし、私はこのチームの間でプロ意識のレベルを想定しなければなりません（彼らが研究を実行する必要性を感じたという事実から）、そして少なくとも警告に出席しただろうということです。あなたの欠陥率はそうかもしれません はるかに高い.

警告についてのポイントは、一部は良性であり、一部はエラーであるということです（つまり、ソフトウェアの望ましくない動作につながります）。それらがすべて良性であると仮定してそれらを無視すると、エラーが導入されます。さらに、いくつかの意志 なる メンテナンス中のエラー他の条件が変更されたときには、すでに警告を受け入れることを選択している場合、そのようなエラーの導入に対する防御はありません。

Answer 2

あなたの質問は「5つの欠陥/100行のコードが合理的な見積もりですか？」です。その質問は答えるのが非常に困難であり、コードベースとコードの複雑さに大きく依存しています。

また、「コードベースにはおそらく多くのバグがあることを経営陣に示すために」というコメントで言及しました。それは素晴らしいことです、称賛。

経営陣の比ur的な目を開くために、少なくとも3つのアプローチを提案することをお勧めします。

• 特定のコンパイラ警告を取り、それらの一部が未定義 /悲惨な行動を引き起こす方法を示します。すべての警告が重いわけではありません。たとえば、初期化されていないポインターを使用している人がいる場合、それは純粋な金です。署名されていない16ビット値を無署名の8ビット値に詰め込んでいる人がいる場合、16ビット値が常に<= 255になることを示すことができます。
• 静的分析ツールを実行します。 PC-LINT （またはFlexLint）は安く、良い「Bang for the Buck」を提供します。コンパイラがしないものをほぼ確実にキャッチし、翻訳ユニット（2回以上のパスであってもすべてをまとめる）を介して走り、より微妙なバグを見つけることができます。繰り返しますが、これらのいくつかを適応として使用します。
• コードの複雑さ、バグの別のソースに関する他のメトリックを提供するツールを実行します。お勧めします M Squaredのリソース標準メトリック（RSM） これにより、期待できるよりも多くの情報とメトリック（コードの複雑さを含む）が提供されます。経営陣にそれを伝えるとき 50を超える複雑なスコアは「基本的には不可能」です そして、あなたは1つのルーチンに200のスコアを持っています、それはいくつかの目を開くはずです。

もう1つのポイント：グループにクリーンなコンパイルが必要で、クリーンリント出力も必要です。通常、これは良いコードを書くことによってのみ達成できますが、場合によっては、問題ではないもののためにツールを静めるためにコンパイラ /リントの警告を微調整する必要があります（賢明に使用）。

しかし、私がしたい重要なポイントはこれです： コンパイラと糸くずの警告に入って固定するときは、非常に注意してください. 。これは見事な目標ですが、動作コードを不注意に破ることも、「壊れた」コードで誤って機能した未定義の動作を明らかにすることもできます。はい、これは本当に起こります。だから注意深く踏みます。

最後に、既に堅実なテストセットがある場合、リファクタリング中に誤って何かを壊すかどうかを判断するのに役立ちます。

幸運を！

Answer 3

コードの品質をご覧ください。ソースに隠れている問題の量をすぐに示します。ソースが醜い場合、コードに多くのバグがあることを理解するのに長い時間がかかる場合。

一貫したスタイルを備えたよく構造化されたコードで、理解しやすい問題には少ない問題が含まれます。コードは、どれだけの労力と思考が入ったかを示しています。

私の推測では、ソースに多くの警告がコードに隠れている多くのバグがあることが含まれている場合です。

Answer 4

これは、誰がコードを書いたか（経験のレベル）、およびコードベースの大きさによっても依存します。

すべての警告をエラーとして扱います。

コードで静的分析ツールを実行すると、いくつのエラーが発生しますか？

編集

CCCCを実行し、McCabeの環状複雑さを確認します。コードがどれほど複雑になっているかを知る必要があります。

http://sourceforge.net/projects/cccc/

他の静的分析ツールを実行します。

Answer 5

欠陥の数の推定値を取得したい場合、統計的推定の通常の方法は、データをサブサンプリングすることです。ランダムに3つの中規模のサブルーチンを選択し、バグを注意深く確認します（コンパイラ警告を排除し、静的分析ツールを実行するなど）。ランダムに選択された合計100行のコードに3つのバグが見つかった場合、同様の密度のバグが残りのコードにあることは妥当と思われます。

ここで新しいバグを導入することについて言及した問題は重要な問題ですが、このテストを実行するために変更されたコードを生産ブランチに戻す必要はありません。サブルーチンを変更する前に、徹底的な一連の単体テストをお勧めし、すべてのコードをクリーンアップしてから、新しいコードを生産にリリースする前に非常に徹底的なシステムテストを行います。

Answer 6

ユニットテスト、コードレビュー、静的分析ツールの利点を実証したい場合は、パイロット研究を行うことをお勧めします。

いくつかのユニットテスト、コードレビューを実行し、コードの一部で静的分析ツールを実行します。これらの方法を使用して見つけたバグの数を管理します。うまくいけば、結果はそれ自体を物語っています。

Answer 7

次の記事には、静的分析が適用されている実際のプロジェクトに基づいたいくつかの数字があります。 http://www.stsc.hill.af.mil/crosstalk/2003/11/0311german.html

もちろん、異常がカウントされる基準は、結果に劇的に影響を与える可能性があり、表1に示す図の大きな変動につながる可能性があります。この表では、500の範囲（！）約10（自動生成）。