Loading article…
直交欠陥分類( ODC ) [ 1 ]は、ソフトウェア欠陥ストリーム内の意味情報をプロセスの測定値に変換します。[ 2 ]このアイデアは、1980 年代後半から 1990 年代初頭にIBM リサーチのRam Chillarege [ 3 ]によって開発されました。これにより、ソフトウェア開発およびテスト プロセスの分析に使用される新しい分析手法の開発につながりました。ODC は、プロセス モデル、言語、ドメインに依存しません。ODC のアプリケーションは、ウォーターフォール、スパイラル、ゲート、アジャイル[ 4 ] [ 5 ]開発プロセスなど、さまざまなプラットフォームと開発プロセスで、いくつかの企業によって報告されています。ODC の一般的なアプリケーションの 1 つは、ソフトウェアの根本原因分析です。
ODCは、その原著論文で提案されているように、開発プロセスに関する測定値を作成するための特定の属性値セットを備えています。よく知られている5つのカテゴリのうち、2つは欠陥タイプと欠陥トリガーです。欠陥タイプは、欠陥の結果としてコードに加えられた変更を捉えます。欠陥タイプには7つの値があり、それらの分布を通じて、プロセスにおける製品の進捗状況を測定することが経験的に確立されています。この概念は、欠陥タイプの分布の変化が開発プロセスモデルの関数であり、したがって、プロセスにおける製品の進捗状況を本質的に測定できるというものです。
同様に、欠陥トリガーはテストプロセスの測定を提供します。トリガーの概念は、ODC を通じてもたらされた重要な貢献であり、現在では技術および研究出版物でかなり広く使用されています。[ 6 ]ソフトウェアトリガーは、障害を顕在化させて障害を引き起こした力として定義されます。トリガーの全セットは、ODC ドキュメントで入手できます。
欠陥の種類とトリガーは、欠陥に関する多くの因果情報を提供します。標準的な ODC 実装で取得される欠陥からの追加情報には、「影響」、「ソース」、「経過時間」などがあります。ODC トレーニング コースでは、トレーニングを受けた個人は、タスクを遡及的に実行する場合、3 分未満で ODC を使用して欠陥を分類できると報告されています。[ 7 ]飛行中または処理中に実行する場合は、かかる時間ははるかに短くなります。ODC データは「何が起こっているか」に関するものであり、「なぜ」に関するものではないため、分類を根本原因分析と直接比較することはできません。ただし、根本原因分析はODC を使用して非常に一般的に実行されます。ODC データを調査する分析は、根本原因分析の最初のパスを実行するものであり、開発チームと結果について話し合うことで確認されます。このアプローチには、従来の方法と ODC 方法の間に 5 つの主な違いがあります。[ 8 ]
個々の欠陥分析は、ODC の応用例の 1 つにすぎません。ODC の本来の設計は、欠陥ストリームを内在的な測定値のソースとして使用して、ソフトウェア エンジニアリングの測定システムを作成することでした。したがって、属性は、単独で、または他の属性と組み合わせて、エンジニアリング プロセスの特定の側面に関する具体的な測定値を提供します。これらの測定値は、一般的な測定原理を念頭に置いて設計されているため、 1 つ以上の分析方法に使用できます。現在までに、さまざまな目的でこれらを適用した研究論文がいくつかあります。最近では、セキュリティ評価に使用される方法を評価するために ODC を使用し、ODC の範囲を拡大した研究論文があります。[ 9 ]