宮崎
Schedule†
| Mon | Tue | Wed | Thu | Fri |
| 1 | 全体MTG | | | | |
| 2 | | | | |
| 3 | | | | | Jedi MTG |
| 4 | | | | | |
| 5 | | | | | |
閾値の設定†
- 閾値と精度について相関分析を実施（スピアマンの順位相関係数）
- 支持度と精度（Precision,Recall,F_score）に正の相関あり，特にPrecisionの相関係数が高い
- 確信度は相関なし，類似度は負の相関が見られた
分類処理に関して†
- 問題点
- 現在はクラスごとにマッチした割合を用いている
- 現在で最も精度の良い閾値に設定すると，「セキュリティ以外」や「Secuirty-Other」は数件のルールになり，一個でもマッチしてしまうと割合が跳ね上がってしまう
- クラスごとに相関ルールマイニングを行っているため，仮に共通するルールが合った場合，同じ支持度，確信度となるとは限らない
- 全てのクラスでマッチ割合が0である場合は，「セキュリティ以外」に割り当てている
- 解決方法
- 支持度のみ，もしくは支持度と確信度をかけ合わせた値をルールの重みにして足し合わせる（クラス間で共通するルールは存在するが，ルールの分布は共通しないため足し合わせていいもの？）
- 支持度は，簡単に言うとルールが発生する頻度のことである
- 掛け合わせる場合は，例えば．クラスAのX→Yというルールの支持度0.2，確信度0.2であればp(X→Y)(A)=0.2*0.2=0.04，クラスBのX→Yというルールの支持度0.1，確信度0.5であればp(X→Y)(B)=0.1*0.5=0.05の重みをつける
- クラス間でルールの共通しているクラス数の逆数を重みとして採用する
- クラス分類に置いて全てのクラスに出現するルールはクラスの特徴を示すルールではないため重要ではなく，1つのルールにのみ出現するようなルールはクラスの特料を示すルールであり重要であると考えられる
- 例）1つのクラスにしか出現しないルールは1，5つのクラスにしか出現しないルールは1/5=0.2
フィードバック†
大ゼミ（6月1日）†
- 西村先生
- 要件定義書のデータ数的にWord2vecは適している？
- （少なすぎるんじゃない？単語数とか分析してみないと）
- 和田先生
- Word2Vecでベクトル表現してるから既に分類できている（クラスタリングの処理いらん）
- 日本語を対象にした理由は？英語のドキュメントを使って評価するのがスジ
- 学生
- 学習の爆発するからネガティブサンプリングとするといいよ（久保くん）
- 類義語をあらかじめ設定すれば？そんな類語語のパターンないやん
- 結局目視するんやんけ
8/3†
DONE†
- セキュリティ4項目(全6項目中目視で確認された項目) or セキュリティ以外で実験
- nltkが設定しているストップワードの除去が精度に悪影響を与えていた
- onlyやnoのような単語はIntegrityに重要なキーワード
- Precision,Recallはそれほど高くない
TODO†
- 作成した記述ルールの中身と誤分類の関係を分析
- 作成したルールの中に共通したルールはないか，共通したルールが悪影響を与えているのか
- 逆に判断のキーとなるルールはどういったルールか
- 見逃しを削減できるルールを作成するにはどうすればいいか考える
7/27†
DONE†
- 手法の実装
- 評価実験
- セキュリティのみで分類した場合
- 支持度0.10,確信度0.45の時，最も精度が良くてPrecision0.86,Recall0.73
- セキュリティ＋他のNFR
- 支持度0.1の時，計算が終了しない
- 支持度0.2以上の時，分類といえない精度
TODO†
- 背景にあった実験を行う
- セキュリティ or not
- セキュリティ詳細 or not
- クリーンな状態 ＆ セキュリティ or not の結果を用いて分類
- セキュリティ絞った背景を組み立てる
- まずセキュリティがどこにかかれているか
- 次に，セキュリティのどれかを分類
- NFR記述ルールの作成方法を変える
- NGDを使ってNFRに関連度が高い単語を含むルールのみを用いる
7/6†
DONE†
- 既存手法をセキュリティ小分類に適用
- CARsを用いた手法の改善
TODO†
6/29†
DONE†
- 実験
- NGDの計算に時間がかかっています，そろそろ終わりそう
- CAR（Class Association Rule Mining）について
- ソースを見つけました（Python,R）
- pythonの方で利用できないかテスト中
- 論文
- レビューお願いできず
- 文献追加のために論文読んでいました
TODO†
6/22†
DONE†
- データセットをISO25010のNFRに割り当て
- 実験について考える
TODO†
- 実験
- セキュリティ要件だけ分類
- セキュリティ or NFRで分類
- セキュリティ or NFR or FRで分類
- 月曜に2,3章をレビューしていただけますでしょうか
6/15†
DONE†
- 提案手法を実装
- 仮実験をしてみた
- 全部のデータを学習してテスト・あまり精度よくない
- tf-idfで単語の重み付けいる？
- Word2Vecのwikipediaデータ学習終わらず
- 論文かけるところから執筆
TODO†
- データセットをISO25010のNFRに割り当て直す
- 比較実験
6/7†
DONE†
- 大ゼミ発表
- Promise投稿を目指す
- Promiseデータセットの取得
- 既存手法（NGD）を適用中（単語の関連度計算に約1週間ほどかかりそう）
- Word2Vecの学習
- Promiseデータセットを学習してみたが，データ数が少ない or いらない単語を除去しきれていないためかあまり精度よくない
- 英語版Wikipediaを学習データに用いて学習中
TODO†
6/1†
DONE†
- セキュリティ8項目を対象に予備実験
- 大ゼミスライド作成
TODO†
まだ早い†
- 手動・自動コーパスの比較実験
- Precision,Recallで精度を比較
- 目視に使っていないドキュメントを対象
- NFRの粒度を変えて実験
- 大項目NFRは小項目コーパス全てを結合したコーパスを用いて分類
- 小項目は精度を平均して算出
5/18†
DONE†
- 手動コーパスを性能2個・セキュリティ5個作成
- 自動コーパスの方法を考えた（
進捗報告.key）＆実装をした
TODO†
- 手動コーパス実験
- 目視結果を学習とテストで半分ずつわける（ランダム）
- Precision,Recallを出してみる
まだ早い†
- 手動・自動コーパスの比較実験
- Precision,Recallで精度を比較
- 目視に使っていないドキュメントを対象
- NFRの粒度を変えて実験
- 大項目NFRは小項目コーパス全てを結合したコーパスを用いて分類
- 小項目は精度を平均して算出
5/11†
DONE†
TODO†
- 目視コーパスの作成・精度実験
- 目視コーパスができ次第，機械コーパスの作成
- まずは目視結果から自動でコーパスを作る
- 目視コーパスと自動コーパスの精度を比較
- よさげならばドキュメントから作ってみる
4/27†
DONE†
- 提案手法の仕様・仕様を満たすためのアプローチを考えた
- 既存手法のスクリプトのテスト
- Google Custom Search APIは費用と一日あたりのアクセス数の制限で実用的ではない（計算もえらくかかる）
- MediaWiki APIというWikipedia用のAPIがあるためこれで代用できそう？（無料かつアクセス数の制限なし）
TODO†
- 問題点考え直し
- 既存手法の Google Custom Search APIをMediaWiki APIに変更して実験
- NFRを3つの粒度にかえて精度の変動をみる
- 正解ラベル付けも行わないと
4/9†
DONE†
- 辞書作成方法を考えた
- 先行研究(NGDを用いた教師なしの手法)の実装
- 1．RFPの単語の類似度を計算する処理（完）
- 2．単語を類似度でクラスタリングする処理（完）
- 3．文を分類する処理（完）（4/10）
TODO†
- 手法練り直し
- まずは達成したい目標を決める
- 目標を達成するために必要なステップを考える
- そのステップを満たすために、適用するアルゴリズムを決める
- アルゴリズムありきの手法を考えるのではない
- 先行研究のテスト
- NGDの計算にGoogle APIを利用（一日のリクエスト数に限界があり，他のAPIを使うべき？）
4/2†
DONE†
- 目視したやつで、キーワード分布を調べる
- 非機能要件のカテゴリの特徴語が多い傾向にある
- が，ゴミも多い
- 先行研究のRFPを取得できるか調べる
- 論文で"the availability of requirements documentation and original developers."と書いていたが見つけることができなかった，論文にもリンクなし
- NGDで単語の類似度を計算する処理を実装
TODO†
- 辞書作成方法を考える
- 先行研究の実装
- 1．RFPの単語の類似度を計算する処理
- 2．単語を類似度でクラスタリングする処理
3/20†
DONE†
- 先行研究の問題点を考えろ、SRAのではなく
- 分類の粒度が大きい（セキュリティ・パフォーマンスなど）
- 辞書がドキュメント固有の辞書に限られている
- 各ドキュメント毎にキーワードをクラスタリングして辞書を作っている
- 実験方法
- Doc2vecでRFPを学習してクラスタリングしてみた
TODO†
- 目視したやつで、キーワード分布を調べる
- 先行研究のRFPを取得できるか調べる
3/13†
DONE†
- SRA進捗報告
- 特徴語の作成方法を考えた
- クラスタリングしたらいい、わけじゃない（結局目視いる）
- 少し実装中
TODO†
- 先行研究の問題点を考えろ、SRAのではなく
- まず、SRAの問題を解けるのか
- 分類の仕方を頑張る？
- 実験方法を考える
3/5†
DONE†
- RFP版word2vecの作成
- NFR記述文を特定するスクリプトを実装
- NFR記述文を取れるか予備実験
TODO†
- SRAの資料作成のやり直し（明日までに）
- 特徴語，形態素の組み合わせを考える
2/26†
DONE†
- RFP・要件定義書から必要な情報を取れるようにスクリプトを作成
- RFPをwordに変更で表やテキストのデータを取得可能
- wiki学習word2vec作成
- NFR記述文を特定するスクリプトを実装中
TODO†
- 福井とSRAの資料作成
- RFP版word2vecの作成
- NFR記述文を特定するスクリプトを実装
- 数種類のNFR記述文を取れるか実験
2/21†
DONE†
- pdfから情報を抽出する処理
- wordに変換すると表関係も抽出できそう
- wordから情報抽出するにはまだなんらかの処理が必要
- xml変換が一番できそうかも
- wiki学習word2vecの作成
- ローカルで実行するとメモリ不足で怒られる
- やっぱりブレインで実行する必要がある
TODO†
- pdfから情報を抽出する処理
- wiki学習word2vecの作成
2/14†
DONE†
- pdfファイルのテキスト変換スクリプトの実装
- 箇条書きは一文と分類
- 表の構造の取得はまだできていない
- brainの環境構築途中
TODO†
- brainの環境構築
- ドキュメントから文章を抽出する処理の実装
2/5†
DONE†
- 類似度の定義をした
- 今まである類似度
- 文字列の一致度
- 関連度（共起関係）
- 使用される文脈の一致度
- 「使用される文脈の一致度」に該当すると考えています
TODO†
1/29†
DONE†
- 自然言語処理とテキストマイニングの違い
- 自然言語処理：ドキュメントからテキストを分析可能な形にすること
- テキストマイニング：統計や機械学習などを用いてテキストから有益な情報・特徴を抽出する技術
- トピックモデルの勉強
TODO†
- テキストマイニングの手法のサーベイ
- 基礎中の基礎から最近の技術まで
- 自分が使う手法を選んだ理由を言えるように理解する
- 自分の思う「類似度」を定義
1/22†
DONE†
- word2vecを使って検出するツールの作成
- 類似した単語
- 類似した単語を含んだ文を抽出するとこまで作成
TODO†
- 自然言語処理とテキストマイニングの違いを理解する
- なんで使うのか言えるようにしろ
1/16†
DONE†
- 抽出方法について考えた
- 1．文章を形態素解析し，単語を原型に変換する
- 2．単語の一致で対象の文章を検索
- 以下の場合は直前の文章につなげる
- 文頭が接続詞の場合
- 文頭が"〜の場合，"
- 前の文に含まれている単語と同じ単語が含まれている場合
TODO†
1/9†
DONE†
- 自然言語処理，要件定義について勉強
- 契約の流れを勉強
- 基礎技術（形態素解析〜談話解析）に関して一通り本を読んだ
- 照応解析，談話解析は文章の前後関係を解析する
- 復習を兼ねて資料作成中
- 使えそうなテキストマイニングを考えた
- 情報抽出の手法を応用する？（固有表現等の抽出を文の抽出に応用）
TODO†
- 談話解析について詳しく調べる
- どうやって抽出するかをより具体的に考える
12/25†
DONE†
TODO†
- 自然言語処理，要件定義について本を読む
- 理解度を定着させるために簡単な資料を作成
- 形態素解析，構文解析，意味解析などの基礎技術をまず勉強
- 利用できそうなテキストマイニング技術の目星をつける
- 非機能要件の定義の難しさ，業務の契約についてを理解
12/18†
DONE†
TODO†
12/11†
DONE†
TODO†
- もう一回グレードの説明書を読め
- 読んでから話を作る
12/4†
DONE†
- 研究計画書を書いた（論理展開が破綻）
- 非機能要件に限定した話をできていない
- 定量評価を行う必要性を述べれていない
- 研究計画が見えてない
TODO†
- 研究計画をきちんと考える
- なぜ非機能要件を対象にするのか
- なぜ定量化する必要があるのか
- どうゆう手順で検出して評価するのか
11/27†
DONE†
TODO†
- 目視の追加
- 要件定義書から非機能要件の文章を判別（抽出）するスクリプトを書く
11/21†
DONE†
TODO†
11/13†
DONE†
TODO†
- 目視再開
- 性能性，セキュリティの項目について，要件定義書40件追加する
- 記述抽出に関して動詞と助動詞を分割しないようにする必要がある
- 例）「する」と「しない」では意味が異なるため評価に悪影響を与える
- 動詞，助動詞だけN-gramにしてBOW作成?
- word2vec・RNN？
10/30†
DONE†
- SRAとMTG
- まずはグレードを0，1で判断する
- レベル分けが簡単にできる項目はレベルわけを行う
- 仕様書をテキスト化するスクリプト
- コピペできない文字は文字コードが原因だと考えられる．
TODO†
10/16†
DONE†
TODO†
10/12†
DONE†
- 分類のための特徴量調査
- 多くの項目は記述があるかないかで判断していて，記述ありでも同じレベルに該当してしまう
- 運営時間など数値で表される項目は簡単にレベルわけできる．
- 調査カテゴリの追加
TODO†
- 分類のための特徴量調査
- 共通する単語，言い回し
- 同じ意味だが，異なる単語（「検査」と「監査」）
- 文献調査
10/4†
DONE†
- 分類スクリプトの作成
- 簡単なレベルわけならできる．（全く同じ記述も何個かあるからうまくいっている可能性もある）
TODO†
- 分類のための特徴量調査
- 共通する単語，言い回し
- 同じ意味だが，異なる単語（「検査」と「監査」）
- 文献調査
9/27†
DONE†
- 非機能要件の進捗報告資料の作成
- セキュリティ・性能性の各項目についてまとめた
- スライドの量が膨大になっているので簡単にできるところを抜いて，詰まっているところだけにする
- 目視再開
TODO†
- 報告資料の修正
- 解かなければならない問題し，学術的に何が新しいか役に立つかどうか考える
- 文献調査
9/12†
DONE†
TODO†
9/6†
DONE†
- 改めて考えたがいいものはでず
- なぜ，相関ルールマイニングなの？
- 共に変更されるという依存関係も重要だが，クラス，メソッド等のソースコード自体の依存関係も結果的には考慮すべきでは？
- 変更した行数，変更した記述（クラスに関する記述）によって，共に変更すべき部分も変わるのでは？
- 一個のファイルではなく，複数ファイルを推薦できない？
- 一個ファイルを取り除き修正もれとして扱って，推薦する実験をしている関係で無理なんだろう
TODO†
8/30†
DONE†
- History Miningのサーベイ
- 既存手法
- 相関ルールマイニングを用いて変更を予測
- 時間を考慮（最近の変更履歴からルールを作成）
- グレンジャー因果性の適用
- アイデア
- 過去の変更の目的に近いものから必要な変更を予測
- 今回の変更がバグ修正ならば，似た過去のバグを修正の変更を利用する
- 開発者の熟練度，担当でルールを作成
- 活動経験の長い開発者の変更履歴からルールを作成する
- モジュールAの変更予測を，モジュールAの担当開発者の変更履歴から行う
TODO†
8/23†
DONE†
TODO†
8/9†
DONE†
- 仕様書目視をまとめた
- 表記揺れ（ex. アクセス，接続）などが多いので量がいる
- グレードのレベル分け
- ログの取得，オンラインレスポンスの遵守率など簡単に分けられる
- 範囲設定，設定頻度などのレベル分けは難しい
- Dependency Analysisの論文読んでざっと理解
- オブジェクト指向特有の依存関係に対応できるようにした論文が多かった
- 依存関係グラフを可視化してプログラマの理解をサポートする論文
- クラスAを変更すると，依存関係あるクラスBとCも変更するか確認した方がいいって教えてくれる
- 出力
TODO†
- 仕様書
- 判断しやすいカテゴリの目視，性能要件から
- 仕様書の件数は2,30件を目処に
- 影響波及分析
- プログラムスライシング，動的解析の調査
- 余裕があればInformation Retrievalも
- 輪講，ICSE勉強会の資料作成
8/2†
DONE†
- 仕様書目視再開
- 運用・保守性に関する項目の目視を始めた
- ただ目視方法に問題あり
PLAN†
- 仕様書目視
- 1つの小項目（例．オンラインレスポンス遵守率）づつ片付けていく
- 8月中に影響波及分析サーベイ論文の内容を一通り読み，研究対象とする範囲を絞る
TODO†
- 仕様書
- 今まで目視した項目に関して，グレードのレベルと記述の関係を分類
- 影響波及分析サーベイ
- Call graphの中身の勉強
- Dependency Analysisの勉強・論文（他の手法と比べると多い）読む
7/26†
DONE†
- ジャーナル修正版投稿
- 影響波及分析のコールグラフの輪行資料作成
TODO†
7/12†
DONE†
TODO†
- ジャーナル第二版（金曜日まで）
- 非機能要件の再開
- 性能性・セキュリティ以外を目視して，学習できそうか判断する
- 輪講資料作成（影響波及分析）
- 計画書作成
7/5†
DONE†
TODO†
6/28†
DONE†
- ジャーナル修正（表記揺れは完了）
- 影響波及分析のサーベイ
- 工数見積もりの論文をかるく調べた
TODO†
- ジャーナル論文修正・回答文作成（来週月曜日まで）
- 追加サーベイ
- 大ゼミ資料作成
6/21†
DONE†
- テーマ考えた：長期貢献者の特徴分析
- コミット・プルリクのコメントのPoliteness値を分析して，無視されないコミット・プルリクを見つける
- プルリクに対するコメントはQtのレビューコメントと区選べて記述の仕方バラバラ
- 開発者が発信している表現と受け取った表現の差分をとコミュニティ維持度の分析
- 丁寧なコメントをしている開発者が雑なコメントを受け取ると悪い印象を受ける
- 一方，雑なコメントをしている開発者が丁寧なコメントを受け取る
- コミュニティ内で接した開発者による影響
- コアの中のコア開発者にレビューしてもらったらやる気が出るとか
TODO†
6/14†
DONE†
- SS発表
- レビューコメントのPoliteness値と長期貢献者/短期貢献者の比較
- 1年以上活動を行なっている開発者を長期貢献者と定義
- 中央値と平均値で両貢献者を比較
- 有意差出ず
- 輪行資料作成の際に思ったこと
- 論文：1回パッチを承諾された開発者がやめた理由をアンケート
- 周りの印象が障壁となっている場合は少ない
- 新しく貢献しようとした人の障壁ー＞レビュー，パッチ承諾プロセスに時間がかかりすぎ
- ↑の問題を解決した方が新人開発者の増加に繋がるのでは？
- 開発者の離脱を検知するために
- 離脱の予兆の単語，言い回しをあるか調査する
- 離脱検知のための辞書を作るべき
TODO†
5/31†
DONE†
- SSスライドの手直し
- レビューのゴミ除去のスクリプト書いた
TODO†
- 初練
- レビューのPoliteness値算出し直し．．．
5/24†
DONE†
- SSスライド作成
- SRA報告スライド作成
- 分析データ用のスクリプト作成
- まだPoliteness値の算出が3分の1終わってない
TODO†
5/17†
DONE†
- レビューコメントにPolitenessツール適用中
- SSコメント対応
TODO†
- 発表スライド作成
- 分析用のデータを生成するスクリプトを作成
- 川辺さんに報告するスライドを
5/10†
DONE†
- 伊原チームの論文を読んだ
- レビューコメントを用いた長期貢献者の予測
- データセット取得(Shaneらのデータセット)
- gerrit, review broadの勉強
TODO†
- 計画書出せ
- 今あるデータでやってみる
- SSコメント1,4対応
5/2†
DONE†
TODO†
4/26†
DONE†
- SS査読コメントへの対応をリストアップ
- 仕様書目視のやり直し
- Stackoverflowのダンプをダウンロード
TODO†
- SS査読コメントへの対応
- 仕様書目視の継続
- ラベルを貼りなさい
- 件数増やす
- 仕様書間で共通している部分を見つける
- 非機能要件グレードとずれているところを確認
- ダンプからデータを取得
Tools†
BookMark†
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
