Schedule†
| Mon | Tue | Wed | Thu | Fri |
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | TKG班MTG
(13:10-14:40) | 全体MTG(輪講)
(13:10-14:40) | |
| 4 | | | | | 応用解析 |
| 5 | | | | | |
Index of Tables†
Progress†
人と分類器の比較分析（学士論文テーマ）†
- ユーザスタディの実施
- 大平研・伊原研の学生に研究協力してもらう（10人以上の協力を集う）
- 非機能要件の説明・ラベリングチュートリアル
- 非機能要件のラベルリング作業
- 調べる予定のこと
- 分類器で分類したものと人の手作業で分類されたものの違いはあるか？
- 品質特性ごとにラベリングされたもののバラツキはどのようなものか？
- バラツキが多い品質特性は曖昧度が高い
- 学習させる際に考慮すべき事柄が見つかるかも？
To Do†
- データセットのPDFをエクセルに変換する
- （問題点）Googleドキュメントによるテキスト変換はページ上限が存在する可能性があり，下部のページが見切れている
- （対処案）PDFからテキスト，そしてエクセルに変換の一連の処理をPythonで全て行う予定
- 非機能要件の目視（データ集め）
- エクセル変換したデータセットで不必要なテキストを削り，データを成形する
- 被験者を募る
- 背景部分の引用論文をサーベイ
- 大東さんが使用していた分類閾値が適切なのかどうか調査を行う
- 辞書の不要な単語を削る
- 削った場合とそのままの場合の違いを分析し削った場合の精度が高いのであればデータを増やさない
- 変わらない，もしくはそのままの方が高い場合はデータ件数を増やす
- 精度が高かった時のトレーニングデータ（辞書）の単語を目視し特徴となっている単語を調査する
- 精度が低かった時のトレーニングデータ（辞書）の単語を目視し不要な単語を調査する
- 形態素解析のパッケージをMeCabからnagisaに変えることで精度が変わる
- Mecab，nagisaそれぞれの形態素解析の結果を分析
Done†
- 実験で使う要件文のセレクト
- pythonで要件文のPDFをエクセルに変換するスクリプトを作成した
- 表内のテキストのみ正常に変換できない
- PDFをテキスト変換した際に不具合がある
- 要件文のデータセット３件用意した
- 非機能要件分類器の実装
- 前処理部分（クリーニング・形態素解析[nagisa]・正規化）
- 前処理部分を適応させて分類を実行できるように連結
- tfidfから得られた単語の重要度を用いて，使用する単語の取捨選択機能を実装
- トレーニングデータの割合と制度の比較を実施
- 全体的に右肩上がりのためデータ件数はかなり増やす必要があると思われる
- 品詞の制限ありと無しでは制限なしの方が制度が良い（機能適合性に関しては）
デバッグツールの時間短縮性の分析と評価指標の提案（修士論文テーマ）†
To Do†
- Fault Localizationツールのサーベイ
- Javaで公開・再現可能なもの
- ツールのピックアップを進めているが，適切なツールを選べているか判断しづらい
- デバッグツールの有効性に関連しそうなテーマをタイトルから抽出
- How helpful are automated debugging tools? [
p13-roessler.pdf]
- An empirical study about the effectiveness of debugging when random test cases are used [p452-265-ceccato.pdf]
- Using automated program repair for evaluating the effectiveness of fault localization techniques [p191-qi.pdf]
- Does automated white-box test generation really help software testers? [p291-fraser.pdf]
Done†
- ISSTA'11 に似たような研究論文を発見した
- 調査の動機がほぼ同じ（デバックツールが実際にどのくらい役に立っているのか）
- 明らかにしたいこと・貢献部分が自分のやりたいことと違う気がするのでおそらく大丈夫...
参考程度には使えるかも
- 同じ研究をしている論文がないか調査
- もしあれば，テーマを変える，もしくは違う観点で調査ができるか考える
→ なさそうなので，研究の新奇性はあるはず
- 引用できそうな論文
- Evaluating the usefulness of IR-based fault localization techniques [p1-wang.pdf]
- Fault Localizationという技術は評価されにくい
- ユーザスタディがほとんどされていない
- ユーザスタディの環境設定の面で参考にできるかも
- Practitioners' expectations on automated fault localization [p165-kochhar.pdf]
- 実務者がFault Localizationに求めていること
- デバッグデータの可用性・スケーラビリティ・効率性など
福井さんのお手伝い†
Memo†
- PMFを用いる理由
- モデルをトレーニングさせた期間以降で新規タグが出現した場合に対応するためでは？
- 新規タグが出現した場合の推定には，新規タグと新規タグとともにつけられているタグの行列よりPMFを使用するか，新規タグ以外で推定するか
To Do†
ユーザの回答よりタグのスコアの重複具合を調査質問タグの一番左にあるタグ（質問のメインターゲットと仮定）を抽出し，全タグのどれだけの割合を占めているか- タグの抽象度を上げてカテゴリを作り，カテゴリごとでPMFを使用し結合させた行列と丸ごとPMFを使用した行列の違いを分析
- ネットワーク分析を用いてコミュニティ検出を行い，コミュニティを1つのカテゴリと位置付けてみる．
networkxにfind_clique()というコミュニティ検出メソッドが存在するのでそれを利用予定
- 上記で抽出したクラスタごとにPMFを使った場合とクラスタ分けをせずにPMFを使った場合の比較
- 知識の影響は隣接距離が１と仮定
- クラスタの中心は質問タグの一番タグ（最左タグ）で分類
Done†
- 重複スコアのデータ分析を実施
- 重複スコアの考慮の仕方として，回答のスコアを質問に付随しているタグに均等に分配する方法を利用
- 上記で示した方法でタグごとに加算したスコアを平均し，平均スコアを算出
- 軽くタグごとに平均スコアのランキングを目視したが，重複スコアを考慮しなかった場合に比べ変動している部分有り
sotorrentの構築†
- 接続のコンフィグは木村/MemoのPythonからMySQLへのアクセスにファイルを添付しているのでそれを参照してください
- Docker-MySQL 全テーブルのインポート完了 5/7 お疲れ様でしたm(_ _)m
- Docker-MySQL インデックス貼り付け 4/25[開始] 4/27[完了]
- Docker-MySQL メインテーブルのインポート 4/19[開始] 4/25[完了]
- 大量のフラグメンテーションが見られる
- 前回のデータを大量削除したため
- sshtunnelを用いたpythonでのMySQL接続に問題あり 4/19
- 不具合の原因不明(サーバのファイアーウォールが原因？？)
サーバMySQLへのインポート完了 4/18[確認]サーバのMySQLにインポート 順調 4/16[確認]Votesテーブルのインポートのみ 4/11[中断]メインテーブルのインポート 4/9[確認]
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
