研究発表会/2014年度の編集

[[研究発表会]]

*2014年度研究会 [#h6e5c033]
- 開催日：毎週水曜日13:10（３限）
- ルール
-- 持ち時間20分（発表12分，質疑8分）
-- 特別な事情長い限り原則，全員参加（３年生は任意で参加可）
-- 発表前日までに資料をアップすること（当日準備した質の悪いプレゼンを全員に共有させないで下さい．）
-- 急な予定が入った場合は，代わりの人を自分で探して下さい
-順番：M2→M1→B4
-発表者担当が司会兼議事録をする

**質疑の意味（なぜ発表者のために質問しなくてはいけないか？） [#j3fad181]
- 単純な質問（だただた分からなかったことを質問すること）の意義
-- 自分（発表者）の中では当たり前だと思っていることが，そうではない（論理の飛躍がある等）ということが分かる
-- 聞き手に何が伝わってないのかが理解できる（プレゼン方法の改善点が見つかる＝論文でも説明しておくべきことが分かる）
- 批判や代替案の提案（こういう方法があるんじゃない？／こうした方がいいんじゃないの？という類の質問）
-- 自分が考えていなかった視点で，アプローチや評価方法が存在することが分かる（考察や今後の課題として考えておかなければならないことが分かる）
-- もしかすると，自分が今までやっていた方法よりも良い方法があることが分かる

**2015年3月11日 [#e842e4b6]
-発表者：吉行
--発表タイトル：
--発表資料：(&attachref();)
-質疑応答
--優先度変更について
---後々，機能によって優先度が変わることもあのではないか？（大平）
---バグが特定することができたことが理由で，優先度が変更されることがある．（金城）
--バグ修正か機能追加かのリリースを区別する必要がある．（大平）
--最終的なゴールによって，プロジェクトの数を決めるべき．（大平）
--今後のコメントなどの活動内容を見て，今の現状の優先度ではいけないと教えてあげる．（大平）
--間にあわなかった不具合を見るために，ポストリリースを見ることも重要．（大平）
--優先度が低の不具合がなおしたせいで，優先度が高の不具合がリリースに間に合わなかったの？（優太）
---1人で行なっているわけではないので，必ずしも優先度が低の不具合がなおしたせいで，優先度が高の不具合が間に合わなくなることはない．

-発表者：松尾大典
--発表タイトル：
--発表資料：(&attachref();)
-質疑応答
**2015年3月11日 [#e842e4b6]
-発表者：松本
--発表タイトル：
--発表資料：（&attachref(小ゼミ_松本_20140311.pdf);）
-質疑応答
--途中から移って来た人、兼任してる人のコミッター昇格を見ては？(金城)
--不具合のパッチの投稿内容を見ては？セキュリティ関係とか(金城)
--どの指標使う？(山谷)
--コミッター昇格した後もデータとして使ってる？それって昇格率なん？(山谷)
--取るメトリクスによってデータ取得が変わる(山谷)
--これでいけるやろはあかん(大平)
--メトリクスを使う理由を仮説を立ててから(大平)
--High Impact Bugと連携(東)
-発表者：前田
--発表タイトル：
--発表資料：（&attachref(新研究テーマ(概要).pdf);）
-質疑応答
--質の高いアプリの定義はどこで定義されたやつ？(大平)
--「質の高い」ではなく「人気の高い」では？(大平)
--大量のアプリが存在は問題点じゃない(大平)
--問題点は人間側？アプリ側？(大平)
--余分な機能ついててもいいのでは？(山谷)
--大は小を兼ねる派の人もいることを言うべき(大平)
--なんでAndroidアプリ？(金城)
--無料アプリだけ？有料アプリは？(東)　
--API見てる研究もあるしソースコードにこだわる必要はない(大平)
--OSSに特化した解析とその他の解析(大平)

**2015年3月4日 [#e842e4b6]
-発表者：久木田
--発表タイトル：
--発表資料：（&attachref(kukita_2015-3-4.pptx);）
-質疑応答

--なぜリファクタリングなのか（大平）
---保守する上で重要，やるべき部分，やらなきゃいけない部分だと思っている（久木田）
---論文にはかけない，漠然としているから→リファクタリングにはならない（大平）

--クッキーは何すんの?（大平）
---リファクタリングするきっかけとなるメトリクスを調べる（久木田）
--リファクタリングすべき箇所が一定以上になれば，警鐘をならすのはどうか（柏）
--企業には，リファクタリング期間が存在する（大平）
--リファクタリングすることで得られるメリットは何か?（大平）

--評価方法がわからない（久木田）
---その後のバグ修正で評価（山谷）
---ブランチ開発しているプロジェクトを見ればいい，Apacheはマージしない．stable版と開発版でのバグの量を見る（大平）

-発表者：東
--発表タイトル：ライセンス特定ツールに追加すべきライセンスの抽出
--発表資料：（&attachref(東_小ゼミ_20150304_1.pptx);）
---図解で，具体的な例を示してほしい．
---各クラスタにおいて，抽出する際の基準となるライセンスを決めるべき？
---レーベンシュタイン距離で良いのか？
---bug of wordsのベクトルでレーベンシュタイン距離でもやってみるのは？
---データセットの使い道を明らかにするとジャーナルになるよ．
---真鍋先生の手法と比較してみるのは？

**2015年2月26日 [#e842e4b6]
-発表者：前田
--発表タイトル：
--発表資料：（&attachref();）

--質問
--ambariは何をするプロジェクトなのか？
--修正時間が短いと影響力が高いのか？
--Breakage Bug の詳細な分析をしてみては？
--こっち直せばこっちが壊れるといったやつを分析してみては？

-発表者：山谷
--発表タイトル：
--発表資料：（&attachref(yamatani_2015-2-26_1.pptx);）
--質問
--開発者でタイプ分けはどう？
--開発者が成長する過程でタイプがこういう風にかかわっていくからどうなるか？
--オープンソースのキャリアアップ(ソースコードのかきかた)
--開発者を固定するとプロダクトが進化するのが共進化？
--共進化とは人固定でプロダクト進化？それともプロダクト固定人進化？
--コミュニティのメトリクスとは？
--コミュニティの進化とは？
--アーティファクト　開発者　コミュニティ　の関係を分けたら？
--初めは4,5人続けてるのをみたほうがいい
--連続性はあまりない，時期に依存する

**2015年2月11日 [#e842e4b6]
-発表者：松本
--発表タイトル：
--発表資料：（&attachref(小ゼミ_松本_20140212_0.pdf);）

--質問
--ASFはSVNで開発しているけどGitの更新はいつするのか？
--レビューのみなし方法がよくわからない（前田）
--パッチ投稿してからのコメントがすべてレビューとなるのはおかしい（前田）
--コミッタ昇格後の活動の変化を示す図ってコミッタ後のパスがしめされているのか？（くっきー）
--通知される瞬間はわからないのか？（ひがし）
--コミッタの活動期間をみる（吉行）例：よろーっぱからはもういらんなど
--この研究の最終目標は？（まえだまえだ）
--もっとコミッタ増えてほしのは，プロジェクト側，コミッタになりたいのは開発者側
--HbaseとHiveは同じHadoopではないのか？（吉行）

-発表者：吉行
--発表タイトル：
--発表資料：（&attachref(小セ&#12441;ミ_吉行_20150212.pdf);）

--質問
--どのリリースを目標にしているのかどうやったらわかるのか？
--どうやってテストケース，テストファイルをみきわめるのか？
--優先度の自動設定を目標としているのに，修正時間を出しているのがわからない
--テストで発見したバグは報告されるのか？
--どうやって修正が間に合わないとかを判断しているのか？
--あきらめたやつはないのか？

**2015年2月4日 [#e842e4b6]
-発表者：柏
--発表タイトル：
--発表資料：

--質問
--実験の概要が実験の目的のあとにくるなんて（大平）
---アプローチでは？（山谷）
--評価項目　開発者の状況→タスク集中（大平）
--適性とプリファレンスが混在
--プリファレンスを結果に入れる
--LDAやSVMがいい理由を言ってない
--シミュレーションの設定（プリファレンスやコストの算出）が正しいことを示してから実験結果が目的を満たしているかを示す
---予備実験でプリファレンス等が妥当であると示す
--プリファレンスがいくら変わったら何が変わるのかが直感的じゃない
--CosTriageに修正時間の合計が負けててもいい理由を言ってない
---タスク集中を改善したっていう定義がない
--データセットを１年で区切るんじゃなくて，リリース毎とかにする
---次のリリースまでに終わるように調整する手法

** 2015月1月28日 [#e9eb3491]
-発表者：きんじょう
--発表タイトル
--発表資料（&attachref([1_28]Blocking Bugの原因理解に向けた特徴分析.pptx);）
--質問
--予定教えて(柏)
--例えば直した5行が近かったらそれを一つと考えるのはどうか(柏)
--1ブロックにつき１バグ表つくるのはどうか(柏)
--そもそもblockingbugって何で悪いん？(柏)
--どこからblockingbugが生まれるか,依存関係(先生)
--そもそもblocking状態になるには同時期に報告されてないとならない？(吉行)
--breakagebug、影響波及分析に近い感じする(柏)
--人数(マンパワー)かけるべき(柏)
--図描こうぜ(柏)
---はなからでかすぎるテーマですってゆう(先生)
--どういう世界かみせてよ(柏)

-発表者：前田
--発表タイトル
--発表資料（&attachref(High Impact Bugの特徴を明らかにするための目視による調査.pdf);）

--質問
--タイトルの「目視」がスライドに表現されていない（大平）
---「目視」いらないですね
--High Impactとは（柏）
---プロジェクトに大きな影響を与える
--プロダクトとプロセスになぜ分けたのか（柏）
---
--分類結果を出した方がいいんじゃないか（山谷）
---とりあえず主な6個のHigh Impact Bugをだせば？(吉行)
--図の結果に単位がない（山谷）
---
--1000件のうちどのくらいの数がHigh Impact Bugと言えるのか？
---camel 4割や，
--High Impact BugじゃないBugとは？（山谷）
---すぐ終わるBugはHigh Impact Bugでない（）
--High Impact BugじゃないBugってTrivialなBugとかですか（山谷）
--なぜ6個に分けたのか，なぜ修正時間で分析したのか・・・飛び飛びでつながりがわかりづらい（山谷）
--背景で例をいって欲しい．一つ一つの不具合を等しく扱っている例をだしてイメージを伝えるべし（山谷）
--コントリビューションは何か（柏）

** 2015月1月21日 [#e9eb3491]
-発表者：久木田
--発表タイトル
--発表資料（&attachref(小ゼミ_20150121_久木田_0.pdf);）
-質問．議論
--なぜ2回の検出ステップに分けるか?(金城)
---1回目，変化点外れ値の両方が検出される(久木田)
---2回目, 変化点と外れ値の分離し変化点を抽出(久木田)
--外れ値を外したのはなぜ？(吉行)
---僕が求めたい部分はプロジェクトの変わり目を知りたい(久木田)
---外れ値は一時的なものなので・・・(久木田)
--プロジェクトの変わり目とは？(吉行)
---プロジェクトの変化の例を知りたい(好行)
---外れ値かどうか結果論(柏)
---外れ値と変化点がちがうのはわかった(吉行)
---やはりなぜ外れ値を外すかが分からない，別々でみてみたら？
---本当に外れ値を外して良いか検証したほうがいい(柏)
--外れ値計算はどうしているのか?(柏)
---計算スライドを１枚いれたらどうや(吉行)
--ARモデルとは何ですか?(柏)
--確率モデルとは何ですか?(吉行)
--修正待ち不具合数が変化することとはどんなことを期待していますか?(大平)
---下がること？上がること？
---このメトリクスを使って観察した現象とは何ですか?
---下がることなのか，上がることなのか決めた方がよい 
--目的について(柏)
---検知手法なのか，異常の分析手法なのか?(柏)
---異常が決められないから異常の分析手法は無理(大平)
---意味のある変化点スコアをいう感じ(大平)
---今回トピック分析は補足(久木田のためにある)(大平)
---ICSEでは変化点とトピックの分布で説明できる(大平)
--なぜトピック分析を用いたのか？(柏)
---理由がないです(久木田)
--たいした結果がでない(大平)
---tf-idfとかやってみるとか
--トピック分析(吉行)
---donは赤いのはなぜ?
---doneだと思ったから(久木田)
---アルゴリズムみなおし
---ステミング
---stopwords
--基準値とは(大平)
-発表者：東
--発表タイトル
--発表資料（&attachref(東小ゼミ20150121.pptx);）
-質問・議論
--亜種ライセンスを特定することが目的？（金城）
---現状は正規表現だけでもとめることはできなく，もっと細かいルールを追加しないといけない
--Kmeans法のクラスタをどのように設定（柏）
---クラスタの数は大きすぎるといけない
--クラスタリングの結果の標準偏差は
---重心との距離という意味の標準偏差
--何故NINKAを使うのか
---現状一番制度が高いツールだから
--結果のライセンスの特徴はどういったことが書かれているのか
---どんな記述があるか書いてある
--目的から問題点のつながりがわからない
---問題を機械学習で解決できそうであるという必要がある
---すべての表記ゆれが機械学習できるわけではないので，類似度などを使おうと考えている
--最終的にファイルのライセンスを1，0で特定したいのか？
---ランダムフォレストによる特定を行う
--自動でライセンスを取ってくることができればいいな（山谷）
--何種類に分類するというところでKmeansを使うのか？
---現状わからなく，クラスタ数を増やして，良い値を見つけることが必要
--Kを増やせばいいのでは？
--Kmeansを使うとどれぐらいの精度で特定できているのか示せれば機械学習の有用性をいえる（大平）
--K=1から増やしていき一番適切なKの値を見つけるべき（大平）
--科学的な裏付けをとるための実験を今している
--パラメタを変えたりしながら結果を示すのが実験で，そこからどういったことが言えるのかが考察になる（大平）
--RQが重要なのはどういう理由
---手法を構築する上でRQでクラスタしたうえで，分析することが必要？まだわからない
---アプローチからRQに急につながるのは気持ち悪い
--サブゴールってなに（東）
---大きな目標があり，それを達成するために必要な小さな目標がサブゴール（吉行）

** 2015月1月14日 [#e9eb3491]
***発表者：松本 [#x5389791]
-OSSプロジェクトにおける開発者の活動量を用いたコミッター候補者予測
-発表資料（&attachref(小ゼミ_松本_20140113.pptx);）
-質問・議論
--松野くん
---モデルを作成するのか？
--片桐くん
---前の研究は何をしていたのか？
--松尾大くん
---具体的にどのような指標を使ってモデルを作成するのか？
--前田くん
---コミッターと非コミッターの違いは？
--柏さん
---何を予測するのか？
---コミッタ予測をして何がうれしいのか？
---コミッタの増減はどれくらいなのか？
---コミッタが増えると自分が担当しているコンポーネントをさわられるけど，それでいいのか？
--金城くん
---Apacheにしぼる必要があるのか？

***発表者：山谷 [#x5389791]
-ソフトウェア進化を分析するための遅延相関分析
-発表資料（&attachref(yamatani_2015-1-13.pptx);）
-質問・議論
--松尾大くん
---開発プロセスに変更が発生するのはなぜ？
--松野くん
---一つの目的変数と複数の説明変数で相関がとれないのか？
--片桐くん
---メトリクスを選ぶ指標は？
--柏さん
---相関わかって何がうれしい？

** 2015月1月7日 [#e9eb3491]
-発表者：柏
--OSS開発における不具合修正タスクの割当支援
---発表資料（&attachref(小ゼミ_柏_ver1.pdf);）

-発表者：吉行
--不具合修正プロセスにおける優先度と修正作業の関係理解のための分析
--発表資料（&attachref(小セ&#12441;ミ_吉行_20150107.pdf);）

** テンプレート [#k2568609]
-発表者：氏名
--発表タイトル
--発表資料（&attachref();）

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