木村/Archive の編集

[[木村]]

*Index of Tables（Archive） [#m0a2c3ff]
#contents

**デバッグツールの時間短縮性の分析と評価指標の提案（ちょっと凍結） [#bbdf6a2d]
***To Do [#pefa2b3e]
-Fault Localizationツールのサーベイ
--Javaで公開・再現可能なもの
--&color(red){ツールのピックアップを進めているが，適切なツールを選べているか判断しづらい};
-デバッグツールの有効性に関連しそうなテーマをタイトルから抽出
--How helpful are automated debugging tools? [&attachref(p13-roessler.pdf);]
--An empirical study about the effectiveness of debugging when random test cases are used [&attachref(p452-265-ceccato.pdf);]
--Using automated program repair for evaluating the effectiveness of fault localization techniques [&attachref(p191-qi.pdf);]
--Does automated white-box test generation really help software testers? [&attachref(p291-fraser.pdf);]

***Done [#yf0e025f]
-ISSTA'11 に似たような研究論文を発見した
--調査の動機がほぼ同じ（デバックツールが実際にどのくらい役に立っているのか）
--明らかにしたいこと・貢献部分が自分のやりたいことと違う気がするのでおそらく大丈夫...~
参考程度には使えるかも
-同じ研究をしている論文がないか調査
--もしあれば，テーマを変える，もしくは違う観点で調査ができるか考える~
→ なさそうなので，研究の新奇性はあるはず
-引用できそうな論文
--''Evaluating the usefulness of IR-based fault localization techniques'' [&attachref(p1-wang.pdf);]
---Fault Localizationという技術は評価されにくい
---ユーザスタディがほとんどされていない
---ユーザスタディの環境設定の面で参考にできるかも
--''Practitioners' expectations on automated fault localization'' [&attachref(p165-kochhar.pdf);]
---実務者がFault Localizationに求めていること
---デバッグデータの可用性・スケーラビリティ・効率性など

**福井さんのお手伝い [#q97eacce]
***Memo [#oca0040e]
-PMFを用いる理由
--モデルをトレーニングさせた期間以降で新規タグが出現した場合に対応するためでは？
--新規タグが出現した場合の推定には，新規タグと新規タグとともにつけられているタグの行列よりPMFを使用するか，新規タグ以外で推定するか

***To Do [#x284d44c]
-%%ユーザの回答よりタグのスコアの重複具合を調査%%
-%%質問タグの一番左にあるタグ（質問のメインターゲットと仮定）を抽出し，全タグのどれだけの割合を占めているか%%
-タグの抽象度を上げてカテゴリを作り，カテゴリごとでPMFを使用し結合させた行列と丸ごとPMFを使用した行列の違いを分析
--ネットワーク分析を用いてコミュニティ検出を行い，コミュニティを1つのカテゴリと位置付けてみる．
--%%networkxにfind_clique()というコミュニティ検出メソッドが存在するのでそれを利用予定%%
-上記で抽出したクラスタごとにPMFを使った場合とクラスタ分けをせずにPMFを使った場合の比較
--知識の影響は隣接距離が１と仮定
--クラスタの中心は質問タグの一番タグ（最左タグ）で分類

***Done [#sc4eb4ae]
-重複スコアのデータ分析を実施
-重複スコアの考慮の仕方として，回答のスコアを質問に付随しているタグに''均等に分配する方法''を利用
-上記で示した方法でタグごとに加算したスコアを平均し，平均スコアを算出
-軽くタグごとに平均スコアのランキングを目視したが，重複スコアを考慮しなかった場合に比べ&color(red){変動している部分有り};

**sotorrentの構築 [#o9b2b2e6]
-接続のコンフィグは[[木村/Memo]]のPythonからMySQLへのアクセスにファイルを添付しているのでそれを参照してください
-Docker-MySQL 全テーブルのインポート完了　5/7 お疲れ様でしたm(_ _)m
-Docker-MySQL インデックス貼り付け　4/25[開始]　4/27[完了]
-Docker-MySQL メインテーブルのインポート　4/19[開始]　4/25[完了]
--&color(red){大量のフラグメンテーションが見られる};
--&color(red){前回のデータを大量削除したため};
-sshtunnelを用いたpythonでのMySQL接続に問題あり　4/19
--不具合の原因不明(サーバのファイアーウォールが原因？？)
-%%サーバMySQLへのインポート完了　4/18[確認]%%
-%%サーバのMySQLにインポート 順調　4/16[確認]%%
-%%Votesテーブルのインポートのみ　4/11[中断]%%
-%%メインテーブルのインポート　4/9[確認]%%

*デバッグツールの時間短縮性の分析と評価指標の提案 [#o1e9cbc2]
-人間と分類器の分析比較
--ツールが作業に与える時間短縮性はどの程度？~
~

#contents

**Background [#xc16f6d7]
-ソフトウェア開発において重要なプロセスのうちの一つがデバッグ
-デバッグは難しい上に時間もかなりかかる
-これまでデバッグの負担を軽減させるための技術・ツールはかなり研究されてきた
-しかし，これまでの研究はツールの性能を考慮したものしかなく，ツールが作業効率をどれだけ改善するのかを示したものがない
-ただ，ユーザスタディを行うために環境を用意することは大変であり，再現することはほぼ不可能

**Goal・Contribution [#vaed15e1]
-Bug Localizationの性能（メトリクス）と作業時間の関係を明らかにし，作業短縮の度合いに関する指標を示す
--ツールのユーザスタディを行わずに作業への影響度を示すことが可能になり，また開発者がツールの利用を考える際にツールの選択基準にもなり得る

**Approach [#zd820e3c]
-考えていること１
--エキスパートに協力してもらう
---メールでのアンケート調査？
--Bug Localizationが検出するバグの重要度を測る
---もしBug Localizationが重要度の高いバグを検出できていれば，有用なツールと言える
---そうでないなら，現場での使い所について考える必要がある
--Bug Localizationが検出するバグと人間が検出するバグの違いを分析
---違いがなければ，ツールの保証ができる？（人間以上に検出できるのであれば，さらに有用性が広がる）
---そうでないなら，現場での使い所について考える必要がある
~
-考えていること２
--エキスパートに協力してもらう
--Bug LocalizationのFalse Negative（見逃しバグ）の影響度
--Recallが高いBug LocalizationとPrecisionが高いBug Localization，どちらの方が効率よく作業できるのか
--Bug Reportから実際の修正期間が得られるはず
--3つを比較し分析
~
-考えていること３
--エキスパートに協力してもらう
--Bug Localizationのモデルコンセプトで種類分け
--種類別に作業効率の差異を分析

**Experiment [#ga36ca2a]
-知りたいこと
--MRRやMAPといったデバッグツールの性能指標と時間短縮性に相関はあるか？
--開発者のプログラミング従事年数と時間短縮性に相関があるか？
--プログラムのスケールと時間短縮性に相関はあるか？
--見逃しバグの影響度と時間短縮性に相関があるか？
---Bug Localizationが影響度の高いバグを特定できている場合とそうでない場合で時間短縮性に違いはあるか？
---設計のコンセプトが違うと特定するバグの種類に違いが出るのか？
---違いがあればBug Localizationの設計の改善が必要になる
--プログラミング言語によって時間短縮性に違いはあるか？
--ツールの使いやすさ（アンケート）と時間短縮性に相関はあるか？
---コンセプトごとで使いやすさにどの程度違いがあるか？
---最も良いコンセプトがわかるのでは？

**To do [#j38ca88b]
-類似テーマの論文サーベイ
--デバッグツールの有効性に関係しそうなタイトルから抽出
--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で公開されているものが好ましい（再現可能）

''[調査観点]''
--&color(red){検出したバグの重要度について議論しているのか？};
--&color(red){ユーザスタディを行なっている場合，どのような観点でモデルを評価しているか？};
--&color(red){モデル構築のコンセプトは，一体どのようなことに重きを置いているのか？};
--&color(red){Precision・Recall，どちらが重視されているか？};

**Done [#z5c0858c]
-類似テーマが存在するのかサーベイを実施
--ISSTA'11 に似たような研究論文を発見した
--[&attachref(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
---On the accuracy of spectrum-based fault localization [&attachref(On the accuracy of spectrum-based fault localization.pdf);]
---Check ’n’ Crash: Combining Static Checking and Testing [&attachref(Check ’n’ Crash.pdf);]
---（C/Java）Finding latent code errors via machine learning over program executions [&attachref(Finding latent code errors via machine learning over program executions.pdf);]
--Via author
---Velodrome: A Sound and complete dynamic atomicity checker for multithreaded programs [&attachref(Velodrome.pdf);]

**memo [#z9b1b459]
-再現可能なツール・技術のピックアップ
-とりあえずBug Localization関連の論文サーベイ
-必要なデータセットが収集可能か？
-427はやりすぎ
-言語ごとにツールが存在する
-ツール作成のベース概念が複数存在する
-ユーザスタディの実験環境や対象のデータセットについて考える
--デバッグを行うプログラムの規模，また埋め込むバグの影響度
--対象のエキスパート人数
-Spectrum-Based：ソースコードとテストスイートの組み合わせから位置特定
~
-伊原先生からの提案
--バグの検出と人員の関係からベストな開発体制を提案するモデルの構築（Optimization）
---（問題点）エキスパートのグループをどのようにして構成するのか？
--プログラムの規模，複雑度
--粒度を小さくするとバグ検出性能が向上する
--http://chakkrit.com/assets/papers/tantithamthavorn2014apres.pdf
--http://chakkrit.com/assets/papers/tantithamthavorn2018buglocalization.pdf

**reference [#aabff03a]
-[1]A Survey on Software Fault Localization  引用数：427  [&attachref(A Survey on Software Fault Localization.pdf);]
-[2]Practitioners' expectations on automated fault localization [&attachref(Practitioners' expectations on automated fault localization.pdf);]
--実務者がFault Localizationに求めていること（可用性・粒度・信頼性・スケーラビリティ・効率など）~
→　実務者が求めていることの1つに効率がある．今回は効率という観点から，Fault Localizationが作業時間をどれほど短縮させるのか調査をする．
-[3]Making numerical program analysis fast [&attachref();]
-[4]Evaluating the usefulness of IR-based fault localization techniques [&attachref();]
--現状，Fault Localizationのユーザスタディはほとんど行われていない
--ユーザスタディの実験環境の設定は参考にできるかも

タイムスタンプを変更しない

[[木村]]

*Index of Tables（Archive） [#m0a2c3ff]
#contents

*デバッグツールの時間短縮性の分析と評価指標の提案 [#o1e9cbc2]
-人間と分類器の分析比較
--ツールが作業に与える時間短縮性はどの程度？~
~

#contents

テキスト整形のルールを表示する