AutoODC: Automated generation of orthogonal defect classifications
アブストラクト
- ソフトウェア欠陥の分類と分析において最も影響力のあるフレームワークであるOrthogonal Defect Classification（ODC）は、システム開発と保守に貴重なフィードバックを提供
- 既存のODC分類は人的リソースを必要とし、ODCとシステムドメインの両方に関する専門家の知識が必要
- この論文では、ODC分類を教師ありテキスト分類問題として捉え、自動化する手法であるAutoODCを紹介
- 標準的な機械学習フレームワークをこのタスクに単に適用するのではなく、新しい関連性アノテーションフレームワークを提案することで、専門家のODC経験とドメイン知識を学習プロセスに統合し、より優れたODC分類システムの構築を目指す
- この論文では、ナイーブベイズとサポートベクターマシンを用いてAutoODCを学習し、ソーシャルネットワークドメインの産業欠陥レポートと、オープンソースシステムであるFileZillaの欠陥追跡ツールから抽出した大規模な欠陥リストの両方で評価
- 産業欠陥レポートではナイーブベイズで82.9%、サポートベクターマシンで80.7%の精度を達成
- オープンソース欠陥リストではナイーブベイズで77.5%、サポートベクターマシンで75.2%の精度を達成
はじめに
- 欠陥データの体系的な分類と分析は、原因分析と統計的品質管理の溝を埋め、システム開発や保守に貴重なフィードバックを提供するとともに、システムとソフトウェアの品質を保証し、改善するのに役立つ
- 体系的な欠陥分類に基づく分析結果により、システム欠陥の主な影響の種類を理解し、焦点を絞った問題解決と品質改善のために特定の問題領域を正確に特定できる
- ODCはIBMで開発された、ソフトウェア欠陥の分類と分析のためのフレームワーク
- ODCは問題領域を特定し、ソフトウェア製品の品質を改善するために、様々な種類の組織で使用されている
- 既存の欠陥分類手法とそのプロセスは人的資源を集中的に必要とし、ドメイン専門家は過去のプロジェクトとODC分類の両方に関する高度な知識を求められる
- 既存手法では、アナリストが各欠陥の説明をODC分類として分類する必要がある
- AutoODCは、特定のソフトウェアドメインにおける欠陥の概要と説明を含む既存の欠陥リポジトリから、ODC欠陥分類を自動的に生成するために開発された
- ほとんどの場合、欠陥データはシステムの開発・運用・保守中にユーザーや開発者によって報告され、欠陥リポジトリに保存される
- これらの欠陥リポジトリは、多くの場合、バグレポート、バグトラッカー、イシューリストと呼ばれる
- ソフトウェア・システムの欠陥分類における課題を克服するために、欠陥レポートからODCを自動生成する手法であるAutoODCを開発した
- ODCの分類問題を教師ありテキスト分類問題として捉え、欠陥レポート内の欠陥記録を機械学習技術を用いて自動分類する分類器を学習することを目標とする
- レポート内のすべての単語から学習すると学習プロセスにノイズが入り込み、分類システムの性能が低下
- そこで、人間がレポート内の単語やフレーズを特定のカテゴリーに分類し、それを注釈として利用
- さらに、ODC分類に関連しないテキストを削除するためのテキスト分析も追加
- これにより、分類器の相対エラーが14〜29%削減された
- AutoODCを2つの異なる欠陥データセットに適用した
- 1つはP社の産業欠陥レポートに含まれる403件の欠陥記録
- もう1つはオープンソースシステムであるFileZillaの公開されている欠陥追跡システム（イシューリスト）から報告された1,250件の欠陥記録
- 両方のデータセットを用いた実験では、「impact」属性について、AutoODCと手動ODC分類のパフォーマンスを比較した
- 各欠陥タイプにおけるパフォーマンスを測定するために、再現率と適合率という2つの一般的な指標を使用
- ナイーブベイズとサポートベクターマシンを使用して、2つのデータセット（403件の欠陥レコードを含むものと1,250 件の欠陥レコードを含むもの）でAutoODCを評価
- データセットはサイズが異なるだけでなく、クラス分布の点でも異なり、大きいデータセットの方が小さいデータセットよりもクラス分布が均衡している
- AutoODCは、手動による欠陥分類を評価基準として使用した場合、小規模データセットで80.7〜82.9%、大規模データセットで75.2%〜77.5%の正解率の分類結果を生成した
- これらの結果は、データセットの基礎となるクラス分布が偏っているか比較的均衡が取れているかに関係なく、AutoODCが堅牢なパフォーマンスを提供することを示している
動機付けの例
- 欠陥レポートやイシューリストの主な特徴
- ID、概要、説明、優先度、重大度、ステータスなどの一連のフィールドが含まれる場合がある
- ただし、ODC分類は主に概要と説明に依存する
- AutoODCの利点
- 関連性アノテーションを用いて自動欠陥分類の精度を向上させられること
- 関連性アノテーションとは、ODCの専門アナリストが欠陥記録のODC分類を決定する際に頼りにするテキスト領域（通常は単語やフレーズ）
- 関連性アノテーションが分類精度向上に役立つ可能性を理解するための例
- 例1
- ODCのimpact属性のうち、Requirementsカテゴリーは現在の製品やリリースの要件として認識、理解、優先順位付けされていない機能に関する顧客の期待を示す
- 一方、ODCのimpact属性のうち、Capabilityカテゴリーは顧客が他のカテゴリーのいずれにも影響を受けない場合に、ソフトウェアが意図された機能を実行し、既知の要件を満たす能力を定義する
- Requirementsカテゴリーに属するレポートでは、would beというフレーズが使われる可能性が高く、これは現在システムに欠けている望ましい要件を示している
- しかし、欠陥データセットは通常、クラス分布が偏っており、欠陥レコードの約70%がCapabilityカテゴリーに属している
- この不均衡なクラス分布により、機械学習アルゴリズムは、提示された証拠がそのデータを他のカテゴリーに割り当てるのに不十分な場合、この最も頻度の高いカテゴリーに文書を割り当てる傾向がある
- この例では、would beというフレーズは有用な証拠であるが、欠陥の説明が長いため、この証拠の影響力が弱まり、このレポートが誤分類される可能性がある
- 一方、would beを関連性アノテーションとして使用することで、その重要性が強調され、機械学習アルゴリズムがこの証拠に焦点を当てる可能性が高まる
- 例2
- installという単語があることは、その欠陥がinstallabilityというカテゴリーに属する可能性が高いことの強力な証拠だが、実際にはReliabilityカテゴリーに属する
- Installabilityは顧客がソフトウェアを準備して使用できる場所に配置できる能力と定義されており、ユーザビリティーは含まれない
- Reliabilityは予期しない中断なしに意図された機能を一貫して実行するソフトウェアの能力と定義されており、abendやwaitなどの重大な中断は常にReliabilityと見なされる
関連研究
ODC欠陥分類
- 当初の欠陥分類手法は、欠陥が発見されるたびに開発者がODC分類法に直接分類し、さらなる欠陥分析を行うというものだった
- 他には、既存の欠陥リポジトリに基づいてODC分類を実行する研究もある
- いずれも人間のアナリストが各欠陥の説明をを理解した上でODC分類法に分類する必要がある
ODCベースの欠陥分析
- 欠陥がODC分類法に分類された後、統計分析を実行して残っている欠陥の数を推定することでソフトウェア製品の信頼性を予測し、ソフトウェアプロセスの改善におけるリスクを特定する研究がある
- IBMはコードメトリクスからODC属性を自動で算出する特許を2008年に取得
- テキストとコードの両方の特徴を活用し、特定の欠陥をType属性の3つのスーパーカテゴリーに分類する研究がある
手法
概要
- 欠陥の「概要」と「説明」が含まれる半構造化データを受け取り、サポートベクターマシンとナイーブベイズを使用してODC分類を行い、分類と分類の信頼度を出力
- 基本的な欠陥分類システムは、（1）欠陥レポートの前処理、（2）ODC分類の学習、（3）分類という3つのステップで開発される
- 本研究で導入するアノテーション関連性フレームワークは、関連性アノテーションを4つの方法で活用することで、基本分類システムを拡張
- 具体的には、（1）分類器の学習用疑似インスタンスの生成、（2）追加の特徴の生成、（3）ドメイン知識の追加、（4）談話分析の実行である
基本的な欠陥分類システム
- ステップ1: 欠陥レポートの前処理
- 各欠陥レポートにはテキストによる「説明」とオプションの「概要」が含まれる
- 各欠陥レコードをトークン化し、WordNet語彙知識ベースに付属するステマーを用いて各単語の語幹を抽出
- 各欠陥レコードを2値ベクトルとして表す
- 各要素はトレーニングセットに出現する個別の単語に対応
- 具体的には、要素がレコードに出現する単語に対応する場合、その値は1になり、そうでない場合、値は0になる
- 言い換えると、ベクトルは対応するレコードに単語が存在するかどうかを示す
- 予備実験でストップワードを削除すると結果がわずかに悪化したため、ベクトルからストップワードを削除しなかった
- ベクトルにはクラス値も関連付けられている
- これは、対応するレコードにアナリストが割り当てたODCカテゴリーである
- 最後に、ベクトルに1が多数含まれる可能性のある長い欠陥レコードが学習プロセスに悪い影響を与えないように、各ベクトルを正規化し、各特徴の値を定数で除算して2ノルムで測定された結果のベクトルの長さが1になるようにする
- ステップ2: ODC分類の学習
- 2値ベクトルで構成される前処理済みのトレーニングセットが完成した後は、機械学習アルゴリズムを適用して未知のレコードを定義ズムの欠陥カテゴリーのいずれかに分類できる分類器を学習する
- 実験では、分類器の基盤となる学習アルゴリズムとして、サポートベクターマシンとナイーブベイズを使用している
- 実験では、各クラスに対して1つの分類器を訓練する。one-versus-others訓練スキームを採用
- 例えば、欠陥記録がReliabilityに属するかどうかを判断する分類器を1つ訓練し、記録がUsabilityに属するかどうかを判断する別の分類器を訓練する
- 各分類器は正確に1つのODCクラスを表し、訓練する分類器の数は欠陥クラスの数に等しい
- 各分類器を訓練するための訓練セットを用意する際は、各訓練インスタンスのクラス値を変更し、訓練インスタンスがそのクラスに属する場合は1を割り当て、そうでない場合は-1を割り当てる
- ステップ3: 分類
- トレーニング後は、得られた分類器を適用してテストセット内の各欠陥レコードを分類できる
- テストインスタンスはトレーニングインスタンスと同じ方法で作成される
- 具体的には、分類する欠陥レコード（テストインスタンス）が与えられ、得られた分類器をそれぞれ個別に適用してインスタンスを分類する
- 各分類器は実数値を返し、値が大きいほど、インスタンスが特定のクラスに属する信頼度が高くなる
- 結果として、全ての分類器によって返された値のセットの中で最も大きい値を返したクラスが欠陥レコードに割り当てられる
関連性アノテーションの活用
- トレーニングセット内の欠陥レコードのみに関連性アノテーションが含まれており、テストセット内のレコードには含まれていない
- 基本的な欠陥分類システムに対して4つの拡張を行った
- 拡張1: 疑似インスタンスの生成
- 少ない訓練データから関連性アノテーションを活用して追加の学習インスタンスを生成
- サポートベクターマシン向けの手法
- 元のインスタンスから関連語句を1つずつ除去して疑似インスタンスを生成
- 信頼度が元のインスタンス > 疑似インスタンスとなるような制約をサポートベクターマシンに追加
- 汎用手法
- 関連性アノテーションのみから擬似インスタンスを生成
- 重要な特徴を凝縮したデータで学習を促進
- 拡張2: 追加機能の生成
- 関連性アノテーションによって生成される特徴量の一部は「I would like to repair」のように多くの単語で構成されるため、テストセットに全く現れない可能性がある
- これにより、関連性アノテーションの特徴量の有用性が下がる
- データのスパース性に対処するために、関連性アノテーションの特徴量を直接使用する代わりに、それぞれの特徴量から生成できる全てのバイグラム（長さが2の連続する単語）を生成し、それらを追加の特徴量として使用する
- 例えば、「I would like to repair」からバイグラムを生成すると、「I would」、「would like」、「like to」、「to repair」という追加の特徴量を得られる
- 拡張3: ドメイン知識の活用
- データのスパース性の問題を、同義の関連性アノテーションをグループ化することで解決
- 全訓練データから関連性アノテーションを抽出
- 人間が同義語をグループ分け
- 各クラスターに一意のIDを割り当てる
- 個別の語ではなく、クラスターIDを特徴量として使用
- 拡張4: 浅い談話分析を用いた関連性の低い資料の特定
- 関連性アノテーションが文脈や状況を説明する文章の中に表れると誤分類の原因となる
- 例1: 「タイムアウトが検出されると…」 -> 「タイムアウト」でReliabilityの欠陥であると誤判定
- 例2: 「インストール後…」 -> 「インストール」でInstallabilityの欠陥であると誤判定
- 例3: 「表示される前に…」 -> 「表示」でUsabilityの欠陥であると誤判定
- 浅い談話分析を使用して以下の処理を実現
- 談話接続詞（if、before、afterなど）を検出
- これらの接続詞が導入するテキストセグメントを削除
- これにより、分類に無関係な文脈情報を事前に除去
評価
- RQ1: 4つの拡張機能を含む注釈関連性フレームワークは、基本的な欠陥分類システムと比較してODC分類をどの程度改善し、全ての拡張機能が性能向上に貢献するのか？
- RQ2: 注釈関連性フレームワークは、基本的な欠陥分類システムと比較して分類エラーをどの程度削減できるのか？
- RQ3: 関連性アノテーション以外の欠陥レコード部分は、全体的な分類性能にどの程度貢献しているのか？
- RQ4: 注釈関連性フレームワークの有効性は、少量のトレーニングデータでも維持されるのか？
- RQ5: AutoODCの分る精度をさらに向上させるための改善点は何か？
- RQ6: AutoODCは労力削減のアナリストの信頼性向上の観点から、どの程度費用対効果が高いのか？
実験の準備
データセット
- 使用したデータセット
- P社のデータ: 産業会社のソーシャルネットワークプロジェクトから403件の欠陥記録を得た
- FileZillaのデータ: オープンソースシステムの3つのサブシステムから1,250件の欠陥記録をランダムに選んだ
- アノテーション作業
- 2名の専門アナリストが独立して欠陥記録を分類
- P社のデータ: 初期合意率90%
- FileZillaのデータ: 初期合意率92%
- 分類の不一致については相互検証と話し合いで解決
評価指標
評価方法
- 5分割交差検証を採用
- 各データセットを5つの均等サイズのサブセット（フォールド）に単ダムに分割
- 毎回1フォールドをテスト用、残り4フォールドをトレーニング用として使用
- 5回の実験結果を平均して最終的なパフォーマンスを算出
基本システムと注釈関連フレームワークに関する実験結果（RQ1）
基本的な欠陥分類システム
- 基本システムの構成
- 各レコードを1,089個の固有語による2値ベクトルで表現
- サポートベクターマシン: 75:25で訓練データを分割し、最適なCパラメーターを選択した後に、全データを用いて再度訓練
- ナイーブベイズ: Wekaの実装を使用
- 基本システムの性能
- P社のデータ: ナイーブベイズで正解率79.7%、サポートベクターマシンで正解率74.2%
- FileZillaのデータ: ナイーブベイズで正解率68.2%、サポートベクターマシンで正解率71.2%
基本システムへの4つの拡張の有効性
- P社のデータ: 個別拡張機能の追加では統計的に有意な改善が見られなかった
- FileZillaのデータ: ナイーブベイズでは全ての拡張機能で有意な改善が見られた
基本システムと完全システムの違い（RQ2）
- 基本システムと完全システム（4つの拡張機能を全て適用したシステム）の分類エラーの違いを明らかにするために、混同行列と統計的有意性検定を実施
- 各カテゴリーについて、両システム間のFスコアの差が統計的に有意かどうかをt検定で判定
- P社のデータにおける改善効果
- ナイーブベイズ: 1つのカテゴリーで有意な改善を確認
- サポートベクターマシン：2つのカテゴリーで有意な改善を確認
- FileZillaのデータにおける改善効果
- ナイーブベイズ: 7つのカテゴリーで有意な改善を確認
- サポートベクターマシン: 2つのカテゴリーで有意な改善を確認
関連性アノテーションの価値（RQ3）
- 関連性アノテーションの価値を検証するために、2つの疑問を調査
- 関連性アノテーションを除いた残りの部分だけで学習できるか？
- 訓練データセットの各欠陥記録から関連性アノテーションの単語を全て削除
- 残りの部分でバイナリ特徴ベクトルを生成し、分類器を学習
- 1つのケースを除き、統計的有意性はなかった
- 関連性アノテーションがあれば、機械学習なしでも良い精度を達成できるか？
- 機械学習を使わずに分類
- P社のデータにおいて、両方の分類器で有意な差が得られた
学習曲線（RQ4）
- 少量の訓練データでも注釈関連フレームワークがODC分類を改善できるかを検証するために、異なる訓練データ量での学習曲線を分析
- 注釈関連フレームワークは、訓練データが少量の場合でもAutoODCを効果的に改善でき、データ量に関係なく一貫した性能向上を提供
エラー分析（RQ5）
- AutoODCの精度向上と将来の拡張機能の特定のために、分類器でご分類された欠陥の分布と根本原因を分析
- タイプ1エラー: 曖昧な特徴による誤分類
- 別の欠陥クラスの用語と重複する用語がテキストに含まれていたことで、曖昧な特徴ベクトルが生成されていた
- タイプ2エラー: 異なるクラスの関連性アノテーションの混入
- 本来のクラス以外の欠陥クラスの関連性アノテーションが含まれる
労力の節約と信頼性の構築（RQ6）
労力
- P社のデータ: 手動分類の場合は18時間、注釈関連フレームワークの場合は最大11時間
- FileZillaのデータセット: 手動分類の場合は40時間、注釈関連フレームワークの場合は最大28時間
信頼の構築
- AutoODCは人手によるODC生成を代替するものではなく、補完するもの
考察
- AutoODCの限界
- ODCのImpact属性のみを評価対象としたこと
- 結果の一般化可能性
- P社とFileZillaのデータで得られた適合率、再現率、Fスコア、カテゴリーごとのデータの分布は、他のデータセットには必ずしも適用できない
結論と今後の課題
他のソフトウェアエンジニアリングタスクへの一般化可能性
- 注釈関連フレームワークはODC以外のテキスト分類問題にも適用できる
今後の課題
- 機械学習アルゴリズムやテキストマッチング手法を改良
- 異なる特徴表現が分類精度に与える影響を比較
- ODCのTrigger属性における談話接続詞の効果を調査
引用情報
- 著者: LiGuo Huang, Vincent Ng, Isaac Persing, Mingrui Chen, Zeheng Li, Ruili Geng, Jeff Tian
- タイトル: AutoODC: Automated generation of orthogonal defect classifications
- 雑誌 / 会議名: Automated Software Engineering
- 巻号: vol. 22
- ページ: pp. 3-46
- 出版日: June 2014
- DOI: https://doi.org/10.1007/s10515-014-0155-1