2025年6月21日
今週の活動
- BugHunterデータセットに関する論文を読んだ
- 研究の目的
- 既存のバグ予測データセットの限界を克服し、より精度の高いバグ予測モデルを構築できるようにする新しいデータセットを開発すること
- 達成できたこと
- 従来のリリースバージョンごとに全てのソースコード要素の特性を収集する方法とは異なり、バグの存在を特定できる最も狭い期間において、同じソースコード要素のバグあり状態と修正済み状態を捉える新しいアプローチを確立
- バグの存在を特定できる最も狭い期間: バグが混入したコミットからバグが修正されたコミットまでの期間
- 15個のJavaプロジェクトを対象とし、3つのレベル（ファイル、クラス、メソッド）でのコード要素分析を行い、コードメトリクスとバグ情報を関連付けた
- 達成できなかったこと
- 複数のデータソースの使用
- 異なる言語を採用したプロジェクトの分析
- BugHunterデータセットはバグの混入から修正までの短期間の変化を捉えているため、コミット間の小さな変化がノイズになってしまう
得られた成果
- BugHunterデータセットはコミット単位でバグの因果関係を捉えられるため、バグの原因を詳細に分析できる
- しかし、依然としてスナップショット分析を行っており、データセットには変化量が含まれていない
- どうして変化量が含まれないのか？
- この研究では、バグを予測したい時点から未来の情報を使ってデータセットを構築しており、変化量を含めると汎用的な予測モデルを作成できないため
- この問題を解決すれば、変化量によるバグ予測精度向上が期待でき、バグ予測モデルをリアルタイムで活用できるようになるため、汎化性能も高くなる
直面した課題
- 新たな陰性データをどのように定義するか？
- BugHunterの場合:
- 陽性データ: バグ混入コミット
- 陰性データ: バグ修正コミット
- 新たな定義:
- 陽性データ: バグ混入コミット
- 陰性データ: バグ混入直前のコミット
- ただし、バグ混入直前のコミットが別のバグ混入コミットではないとは言い切れないため、それが異なるバグ混入コミットではないと仮定するためのフィルタリング条件が必要
- どれほど細かくフィルタリングしても偽陰性の割合は大きくなってしまう
- そもそも先行研究の結果から、汎化性能を上げると精度が大きく下がることが分かっている
- 先行研究の場合: F1スコアが最大で0.1低下
- 精度向上ではなく、改善に向けた迅速な情報提供を目標とすべき
来週の計画
- OpenStaticAnalyzerによるコードメトリクスの収集
- 先行研究で使用されていた静的解析ツール
- BugHunterデータセットの特徴量として採用されたコードメトリクスを計算できる
- 陰性データのフィルタリング条件を定義し、プログラムによる自動収集を行う