KLOCごとに欠陥を測定する方法
「コード1000行あたりのバグの数」という指標と、それが適切な数値になるかどうかについて、インターネットで読んでいます。
しかし、誰かがそのようなメトリックをどのように計算するのでしょうか？そこにバグがある理由は、誰もそれを発見していないからです。そしてテストでは、バグがなくなったことを示すことはできません。
「バグ」と「KLOC」という用語は明確に定義されていると考えるかもしれません。
私が考えられる1つの方法は、正式な方法を使用してソフトウェアが正しいことを証明し、途中で発生したバグの数を数えることです。ただし、これは大規模なコードベースでは現実的ではありません。
別の方法は、ベンダーが受け取った確認済みのバグレポートを重複なくカウントすることです。ただし、これは計算に多くの時間を必要とし、下限のみを与えます。また、より多くのユーザーがより多くのバグレポートを意味するため、広く使用されているソフトウェアに大きく偏っています。
コードチェッカー、静的分析なども考えられますが、すべてが見つかり、多くのノイズが発生するわけではありません。
「KLOCあたりの欠陥」を計算するか、少なくともバイアスをかけずに確実に推定できますか？
これらの数値を測定する一般的なアプローチは次のとおりです。
- 十分なカバレッジを備えたテスト計画を確立します。
- 正式なテスト計画（自動テストまたは手動テスト）を実行し、失敗したテストと、必要に応じて根本原因分析後に発行されたバグレポートを登録します。
- 図をソースコードから自動的に計算できるKLOCと比較します。
言うまでもなく、手動の「アドホック」テストアプローチを使用している場合、一貫したバグ番号は得られません。前述のように、多くのバグはすぐには発見されません。ただし、ユニットテスト、統合テスト、受け入れテストを含む正式なテスト計画は、より大きくミッションクリティカルなソフトウェアでは非常に一般的です。 [〜＃〜] tdd [〜＃〜] はテストをさらに強調し、約束された機能とコードが尊重するすべての不変条件をチェックおよび診断できる非常に詳細な単体テストを提供します。
また、統合のためにコードを送信する前に開発者が実行した予防テストの結果をカウントするかどうかという問題もあります。査読で発見された問題についても同じ質問です。
バグの定義も問題です。人々はこのWordを共通言語で使いすぎており、フロンティアは明確ではありません。それはコードが仕様に準拠していないことですか？それとも不明確な要件によって引き起こされる問題ですか？ここでは ISO 9126 のような正確な定義を持ついくつかの規格が本当に役立ちます。
最後に、KLOCは、支配的な言語が行指向（fortran、cobolなど）であったときに導入された概念です。だから、今日は本当に問題です、LOCには何を考慮すべきですか：空の行？コメント行？条件付きでコンパイルされた行？アクティブなライン、またはアクティブな命令？等...
このすべてが言われている、あなたはあなたの正確な定義と方法論に依存するだろうあなたの絶対的な数字にもちろん違いがあります。ただし、一貫性を保つと、絶対的な数値ではなく、これらのメトリックの進化を見ると興味深い事実が浮かび上がる可能性があります。
膨大な数のソフトウェアの統計を保持し、プロジェクトのメトリックの進化に基づいてバグ率を予測するために使用される予測モデルを開発した企業があります。その後、彼らはこの予測を市場に出すかどうかの意思決定に使用します（私は数年前にHPからの論文を読んだと思いますが、それを見つけることができませんでした）。このような予測にはもちろん統計値しかありません。一般的に意味があるという事実は、特定のプロジェクトがモデルと完全に矛盾する可能性があることを避けていません。
個人的には、これらの予測方法が、アジャイルとTDDの時代にまだ意味があるかどうかはわかりません。初期段階とその場でバグが防止されます。ただし、下請けプロジェクト（つまり、十分に指定された要件に従って構築されたソフトウェア）にこのような構造化メトリックを導入することで、一部の請負業者の信頼性の問題を迅速に制御および対処できるようになったことを認めなければなりません。