木村/Research Subject
デバッグツールの時間短縮性の分析と評価指標の提案†
Background†
- ソフトウェア開発において重要なプロセスのうちの一つがデバッグ
- デバッグは難しい上に時間もかなりかかる
- これまでデバッグの負担を軽減させるための技術・ツールはかなり研究されてきた
- しかし，これまでの研究はツールの性能を考慮したものしかなく，ツールが作業効率をどれだけ改善するのかを示したものがない
- ただ，ユーザスタディを行うために環境を用意することは大変であり，再現することはほぼ不可能
Goal・Contribution†
- Bug Localizationの性能（メトリクス）と作業時間の関係を明らかにし，作業短縮の度合いに関する指標を示す
- ツールのユーザスタディを行わずに作業への影響度を示すことが可能になり，また開発者がツールの利用を考える際にツールの選択基準にもなり得る
Approach†
- 考えていること１
- エキスパートに協力してもらう
- Bug Localizationが検出するバグの重要度を測る
- もしBug Localizationが重要度の高いバグを検出できていれば，有用なツールと言える
- そうでないなら，現場での使い所について考える必要がある
- Bug Localizationが検出するバグと人間が検出するバグの違いを分析
- 違いがなければ，ツールの保証ができる？（人間以上に検出できるのであれば，さらに有用性が広がる）
- そうでないなら，現場での使い所について考える必要がある
- 考えていること２
- エキスパートに協力してもらう
- Bug LocalizationのFalse Negative（見逃しバグ）の影響度
- Recallが高いBug LocalizationとPrecisionが高いBug Localization，どちらの方が効率よく作業できるのか
- Bug Reportから実際の修正期間が得られるはず
- 3つを比較し分析
- 考えていること３
- エキスパートに協力してもらう
- Bug Localizationのモデルコンセプトで種類分け
- 種類別に作業効率の差異を分析
Experiment†
- 知りたいこと
- MRRやMAPといったデバッグツールの性能指標と時間短縮性に相関はあるか？
- 開発者のプログラミング従事年数と時間短縮性に相関があるか？
- プログラムのスケールと時間短縮性に相関はあるか？
- 見逃しバグの影響度と時間短縮性に相関があるか？
- Bug Localizationが影響度の高いバグを特定できている場合とそうでない場合で時間短縮性に違いはあるか？
- 設計のコンセプトが違うと特定するバグの種類に違いが出るのか？
- 違いがあればBug Localizationの設計の改善が必要になる
- プログラミング言語によって時間短縮性に違いはあるか？
- ツールの使いやすさ（アンケート）と時間短縮性に相関はあるか？
- コンセプトごとで使いやすさにどの程度違いがあるか？
- 最も良いコンセプトがわかるのでは？
To do†
- 類似テーマの論文サーベイ
- デバッグツールの有効性に関係しそうなタイトルから抽出
- How helpful are automated debugging tools?
- An empirical study about the effectiveness of debugging when random test cases are used
- Evaluating the usefulness of IR-based fault localization techniques
- Using automated program repair for evaluating the effectiveness of fault localization techniques
- Practitioners' expectations on automated fault localization
- Does automated white-box test generation really help software testers?
- Bug Localization関連論文のサーベイ
（とりあえずICSEから拾ってみる）
- データセット，スクリプトがGithubで公開されているものが好ましい（再現可能）
[調査観点]
- 検出したバグの重要度について議論しているのか？
- ユーザスタディを行なっている場合，どのような観点でモデルを評価しているか？
- モデル構築のコンセプトは，一体どのようなことに重きを置いているのか？
- Precision・Recall，どちらが重視されているか？
Done†
- 類似テーマが存在するのかサーベイを実施
- ISSTA'11 に似たような研究論文を発見した
- [
parnin.orso.ISSTA11.pdf]
[要約]
- Eclipseのプラグインを用いて，Georgia Institute of Technology College of Computingに在籍する大学院生を対象にユーザスタディを実施した
- 使用したデバッグツールはTarantulaというアートデバッグツール
- Tarantulaを選んだ理由として，しっかりとした実証的評価がなされていること，開発者に使い方を教授しやすい
- エキスパートであったり，簡単なコードだと早く終わるが，その他はあまり有用ではない
- より開発者が使いやすいように人間の側面を考慮した研究を行い，デバッグツールの改善が必要
- 似たような観点で調査はしていたが，自分の考えていることと方向性が違うと感じたので問題なし！！
- 言語ごとにツールが分かれていることがわかった
- 開発においてメジャーなJavaのBug Localizationに絞って調査を実施する予定
- Fault Localizationのコンセプト種別
- Slice-Based（20%）
- Program Spectrum-Based（35%）
- Statistics-Based（7%）
- Program State-Based（7%）
- MachineLearning-Based（2%）
- Data Mining-Based（19%）
- Model-Based（1%）
- その他（9%）
- Fault Localization（Java）
- Openly accessible
- Via author
- Velodrome: A Sound and complete dynamic atomicity checker for multithreaded programs [Velodrome.pdf]
memo†
- 再現可能なツール・技術のピックアップ
- とりあえずBug Localization関連の論文サーベイ
- 必要なデータセットが収集可能か？
- 427はやりすぎ
- 言語ごとにツールが存在する
- ツール作成のベース概念が複数存在する
- ユーザスタディの実験環境や対象のデータセットについて考える
- デバッグを行うプログラムの規模，また埋め込むバグの影響度
- 対象のエキスパート人数
- Spectrum-Based：ソースコードとテストスイートの組み合わせから位置特定
- 伊原先生からの提案
reference†
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
