2025年8月16日
今週の活動
- Orthogonal Defect Classification（ODC）の属性を整理
- ODC属性はOpener SectionとCloser Sectionに分類される
- Opener Section: 欠陥が発見された状況を記録する項目
- Closer Section: 欠陥の根本原因と修正内容を記録する項目
- Target: 修正された高レベルなエンティティ
- Defect Type: 具体的な修正内容の性質
- Assignment/Initialization
- Checking
- Algorithm/Method
- Function/Class/Object
- Timing/Serialization
- Interface/O-O Messages
- Relationship
- Qualifier: Defect Typeをさらに詳細に説明する属性
- Missing
- Incorrect
- Extraneous
- Age: 修正対象の変更履歴
- Base
- New
- Rewritten
- ReFixed
- Source: 欠陥が発生した段階
- Developed In-House
- Reused From Library
- Outsourced
- Ported
- ODCのOpener Sectionの属性は主にイシューのテキストから、Closer Sectionの属性は主にプルリクエストのテキストから分析できる
- 既存研究で作成された、テキスト分析を用いたODCのデータセットの問題点
- イシューのテキストからODC属性を決定している
- Opener Sectionの属性の教師データは信頼性が高いが、Closer Sectionの属性の教師データは信頼性が低くなってしまう
- バグの有無をコミット単位かつメソッド単位で予測するような場合、プルリクエストのテキストのみが使用できるのに対し、ODCのデータセットを学習した機械学習モデルはプルリクエストのテキストに対応していないため、予測精度が下がる可能性がある
得られた成果
- 既存のODCデータセットを活用してBugHunterデータセットに新たな特徴量を追加するのは難しい
- 実現できなくはないが、イシューのテキストを学習したモデルをプルリクエストのテキストを使用した分類に適用できるかどうかについて、一般化可能性が検証されていないため精度が下がる可能性があり、結果の考察も難しくなる
直面した課題
- BugHunterデータセットを分析すると、必然的にバグ混入コミットやバグ修正コミットを分析することになる
- コミットに関連付いているプルリクエストを収集することはできても、そのプルリクエストに関連付いている（と思われる）イシューを収集することはできない
- ODC属性のうち、Opener Sectionにある属性を算出するのを諦め、Closer Sectionにある属性に特化した分析に留めるべき
来週の計画
- イシューのテキストからODCデータセットを構築する研究を調べる
- その研究では、おそらくデータセットの構築前にODC属性の選定基準を定めており、データセットの構築後にODC属性ごとの信頼性について考察しているはず
- それらの情報をバグの特徴付けに役立てたい