組み込みプロセッサ (DSP) 用に作成された C++ コードベースで期待できる欠陥率は、単体テスト、コード レビュー、静的コード分析がなく、プロジェクトをコンパイルすると約 1500 の警告が生成されることを前提としています。コード 100 行あたり 5 つの欠陥というのは妥当な見積もりですか?
7 に答える
あなたの質問は、「5 つの欠陥/100 行のコードは妥当な見積もりですか?」です。その質問に答えるのは非常に難しく、コードベースとコードの複雑さに大きく依存しています。
また、コメントで「コードベースにおそらく多くのバグがあることを経営陣に示すため」と述べました-それは素晴らしいことです、称賛です。
経営陣の比喩的な目を開くために、少なくとも 3 つのアプローチをお勧めします。
- 特定のコンパイラ警告を取り上げ、それらのいくつかが未定義/悲惨な動作を引き起こす可能性があることを示します。すべての警告が重要になるわけではありません。たとえば、誰かが初期化されていないポインターを使用している場合、それは純金です。符号なし 16 ビット値を符号なし 8 ビット値に詰め込む人がいて、16 ビット値が常に <= 255 であることが示されている場合、それはあなたの主張をそれほど強くするのに役立ちません。
- 静的分析ツールを実行します。 PC-Lint (または Flexelint) は安価で、優れた「費用対効果」を提供します。ほぼ確実に、コンパイラーがキャッチできないものをキャッチし、翻訳単位全体で実行し (2 つ以上のパスであっても、すべてを一緒にリントします)、より微妙なバグを見つけることもできます。繰り返しますが、これらのいくつかを指標として使用してください。
- バグの別の原因であるコードの複雑さに関する他の指標を提供するツールを実行します。M Squared の Resource Standard Metrics (RSM)をお勧めします。これにより、期待以上の情報とメトリック (コードの複雑さを含む) が得られます。50 を超える複雑さのスコアは「基本的にテスト不可能」であると経営陣に伝え、1 つのルーチンで 200 のスコアを獲得した場合、いくつかの注意が必要です。
もう 1 つのポイント: グループ内でクリーンなコンパイルが必要であり、Lint 出力もクリーンにする必要があります。通常、これは適切なコードを記述することによってのみ達成できますが、コンパイラや lint の警告を微調整して、問題のないツールを静かにする必要がある場合があります (慎重に使用してください)。
しかし、私が言いたい重要な点は次のとおりです:コンパイラとリントの警告を修正するときは十分に注意してください。これは立派な目標ですが、誤って動作中のコードを壊したり、「壊れた」コードで誤って動作した未定義の動作を発見したりする可能性もあります。はい、これは実際に起こります。だから慎重に踏んでください。
最後に、しっかりとした一連のテストが既に実施されている場合は、リファクタリング中に誤って何かを壊してしまったかどうかを判断するのに役立ちます。
幸運を!
これは、誰がコードを書いたか (経験のレベル) と、コード ベースの大きさにも依存します。
すべての警告をエラーとして扱います。
コードに対して静的解析ツールを実行すると、どのくらいのエラーが発生しますか?
編集
cccc を実行し、mccabe の巡回複雑度を確認します。コードがどれほど複雑かがわかります。
http://sourceforge.net/projects/cccc/
他の静的分析ツールを実行します。
コードの品質を見てみましょう。ソースに隠れている問題の量がすぐにわかります。ソースが醜く、理解するのに長い時間がかかる場合、コードに多くのバグが存在します。
一貫したスタイルを持ち、理解しやすい構造化されたコードには、含まれる問題が少なくなります。コードは、それにどれだけの労力と思考が費やされたかを示しています。
私の推測では、ソースに多くの警告が含まれている場合、コードに多くのバグが隠れていることになります。
この場合の見積もりの妥当性については懐疑的ですが、関連する可能性のある統計をいくつか見つけました。
この記事では、著者は、Software Assessments, Benchmarks, and Best Practices (Jones、2000 年)に掲載された「大規模な実証研究」の数値を引用しています。このコードのレベルのように聞こえるSIE CMM レベル 1では、ファンクション ポイントあたり 0.75 の欠陥率が期待できます。関数ポイントと LOC がコード内でどのように関連するかを判断するのは、あなたに任せます。その分析を実行するには、おそらくメトリクス ツールが必要になるでしょう。
Code Complete の Steve McConnell は、同じチームによって開発された 11 のプロジェクト (コード レビューなしの 5 件、コード レビューありの 6 件)の研究を引用しています。レビューされていないコードの不良率は 100 LOC あたり 4.5 で、レビューされたコードでは 0.82 でした。そのため、他の情報がない場合、あなたの見積もりは公正に見えます。しかし、私はこのチームのプロフェッショナリズムのレベルを想定しなければなりません (彼らが調査を実施する必要性を感じていたという事実から)、そして彼らは少なくとも警告に注意を払っていたでしょう; 不良率がはるかに高くなる可能性があります。
警告についてのポイントは、いくつかは無害であり、いくつかはエラー (つまり、ソフトウェアの望ましくない動作につながる) であるということです。それらがすべて無害であると仮定してそれらを無視すると、エラーが発生します。さらに、他の条件が変化したときにメンテナンス中にエラーになるものもありますが、すでに警告を受け入れることを選択している場合は、そのようなエラーの導入に対する防御はありません.
欠陥の数を推定したい場合、統計的推定の通常の方法は、データをサブサンプリングすることです。中規模のサブルーチンをランダムに 3 つ選び、バグがないか注意深くチェックします (コンパイラの警告を取り除く、静的解析ツールを実行するなど)。無作為に選択された合計 100 行のコードに 3 つのバグが見つかった場合、コードの残りの部分にも同様の密度のバグがあると考えられます。
ここで言及されている新しいバグの導入の問題は重要な問題ですが、このテストを実行するために変更されたコードを運用ブランチにチェックインする必要はありません。サブルーチンを変更する前に一連の完全な単体テストを行い、すべてのコードをクリーンアップしてから、新しいコードを本番環境にリリースする前に非常に徹底的なシステム テストを行うことをお勧めします。
単体テスト、コード レビュー、静的分析ツールの利点を実証したい場合は、パイロット スタディを行うことをお勧めします。
いくつかの単体テスト、コード レビューを行い、コードの一部に対して静的分析ツールを実行します。これらの方法を使用して見つけたバグの数を経営陣に示してください。うまくいけば、結果はそれ自体を物語っています。
次の記事には、静的分析が適用された実際のプロジェクトに基づくいくつかの数値が含まれています。
もちろん、異常をカウントする基準は結果に劇的な影響を与える可能性があり、表 1 に示す数値に大きなばらつきが生じる可能性があります。この表では、C のコード 1,000 行あたりの異常の数は 500 (!)約 10 まで (自動生成)。