直交欠陥分類

直交欠陥分類（ODC）^[1]は、ソフトウェア欠陥ストリーム内の意味情報をプロセスの測定値に変換します。^[2]このアイデアは、1980年代後半から1990年代前半にIBM ResearchのRam Chillarege ^[3]によって開発されました。これにより、ソフトウェア開発とテストプロセス分析に使用される新しい分析手法が開発されました。ODCはプロセスモデル、言語、ドメインに依存しません。ODCのアプリケーションは、ウォーターフォール、スパイラル、ゲート、アジャイル^{[4] [5]}開発プロセスに至るまで、さまざまなプラットフォームと開発プロセスでいくつかの企業によって報告されています。ODCの一般的なアプリケーションの1つは、ソフトウェアの根本原因分析です。

ODC は、根本原因分析にかかる時間を 10 倍以上短縮することが知られています。このメリットは、根本原因分析に対する異なるアプローチから主に生まれます。ODC データは迅速に生成され (欠陥ごとに数時間かかるのに対し、数分で生成されます)、分析結果が原因と結果の分析に使用されます。これにより、分析の負担が、純粋に人間による方法から、よりデータ集約的な方法に移行します。^[6]

元の論文で提案された ODC には、開発プロセスの測定を作成する特定の属性値セットがあります。 5 つのよく知られているカテゴリのうち 2 つは、欠陥タイプと欠陥トリガーです。 欠陥タイプは、欠陥の結果としてコードに加えられた変更をキャプチャします。 欠陥タイプには 7 つの値があり、その分布を通じてプロセス全体にわたる製品の測定を提供するために経験的に確立されています。 概念は、欠陥タイプの分布の変化は開発プロセス モデルの関数であり、したがってプロセス全体にわたる製品の進捗の本質的な測定を提供するというものです。

欠陥トリガーも同様に、テストプロセスの測定を提供します。トリガーの概念は、ODC を通じてもたらされた重要な貢献であり、現在では技術および研究出版物でかなり広く使用されています。^[7]ソフトウェアトリガーは、障害を表面化させて障害を引き起こす力として定義されます。トリガーの完全なセットは、ODC ドキュメントで入手できます。

欠陥の種類とトリガーは、欠陥に関する大量の原因情報を提供します。標準の ODC 実装でキャプチャされる欠陥の追加情報には、「影響」、「ソース」、および「経過時間」が含まれます。ODC トレーニング コースでは、トレーニングを受けた個人は、遡及的にタスクを実行するときに 3 分未満で ODC を介して欠陥を分類できると報告されています。^[8]飛行中またはプロセス中に行う場合、かかる時間ははるかに短くなります。分類は、ODC データが「なぜ」ではなく「何であるか」に関するものであるため、根本原因分析と直接比較することはできません。ただし、根本原因分析は、ODC を使用して非常に一般的に実行されます。ODC データを調査する分析は、根本原因分析の最初のパスを実行し、開発チームと結果を話し合うことで確認されます。このアプローチには、従来の方法と ODC 方法の間に 5 つの主な違いがあります。^[9]

根本原因分析は、ODC の応用例の 1 つにすぎません。ODC の元々の設計は、欠陥ストリームを固有の測定ソースとして使用してソフトウェア エンジニアリングの測定システムを作成することでした。したがって、属性は、単独でも、他の属性と組み合わせても、エンジニアリング プロセスの特定の側面に関する特定の測定を提供します。これらの測定は、一般的な測定原理を念頭に置いて設計されているため、1 つまたは複数の分析方法に使用できます。現在までに、いくつかの研究論文で、さまざまな目的でこれらが適用されています。最近では、ODC を使用してセキュリティ評価に使用される方法を評価し、ODC の範囲を拡大した研究論文があります。^[10]

• IBM リサーチ: 直交欠陥分類
• チラレッジ株式会社: 直交欠陥分類