Memo†
Link†
Sample†
Schedule†
Mon Tue Wed Thu Fri 1 2 全体MT 3 ソフトウェア工学特論 TKG班MT マルチメディア マルチメディア 4 ソフトウェア工学特論 5
考え方†
なぜその問題解決方法でいいのかという気持ちで読む．(仮説，アプローチ，話の落とし方)
怒りの気持ちを感じるためにはその分野のスタンダードを知っている必要がある．
多くのリソースをかければかけるだけいい結果になるなんてくだらない結果は求めてない 理想的な研究流れ
学部生：影響に関連する変数を明らかにする
院生：変数をアルゴリスムに乗せて精度を向上させる 研究テーマ†
概要
バグ修正の際のR≠T≠Fのパターン時，どんなバグかを考慮せずとも修正までにかかる時間が最も長い．
R≠T≠Fで他のパターンを凌ぐ良い結果の場合が存在する．
Bestと，Worstに関してなぜそのようになるのかを分析する．
R≠T≠Fパターンの結果が不安定な理由を解明する． 背景
不具合修正にかかる時間を予測したい．
不具合修正にかかる時間を最小にしたい． 問題点
最も実際の作業環境であると考えられるR≠T≠Fパターンの精度が不安定．
なぜ良い場合もあれば悪い場合があるかの理解がない．
どうしてそのような結果になるのかという原因に関する言及がない(先行研究)．
PlatformとJDTの2つのプロジェクトでしか行なっておらず，一般性が乏しい(先行研究)．
Eclipse Platform projects：統合開発環境(IDE)
Eclipse Java Development Tools projects：プラグイン．Javaソースコードのコンパイル，実行機能，コード補完，APIリファレンスの表示，リファクタリング，デバッグなどの機能の提供 貢献
実際の業務形態に対して直接的に貢献を及ぼすことができる．
コミュニティでの作業効率の向上． Meeting†
10/15†
assigner : 譲渡人(割り当てる人)
assignee : 譲り受け人(修正者) DONE†
前処理を丁寧にした
プロジェクトをeclipseに限定
Noneや空白を除外
メールアドレスに@がない，.orgがあるものを除外
割当者と修正者が同一人物であるものを除外 [求める結果]
上位割当者に割り当てられている修正者が共通して1人以上いる
明らかに割り当てられている割合が大きい開発者がいる [ぱっと見わかったこと]
10%以上割り当てられている開発者が3名
Erich Gamma(2)，Martin Aeschlimann(2)，Dirk Baeumer(1)
10名の内訳に多く存在する開発者
Erich Gamma(7)，Tod Creasey(6)，Olivier Thomann(5)，
Martin Aeschlimann(4),Dirk Baeumer(2) 10/7†
ADVICE†
データ設計が8割
自分の見たいデータのみにすることがまず大事
自分が報告して自分で修正している人の割合を見るとがっかりするが自分が見たいデータではない
人が人に割り当てていることに着目するべきでBotが割り当てているのは自分がみたいデータではない
未加工のデータ知る TODO†
一つのプロジェクトにのみ着目する
割当者が組織であるケースを削除
自分が自分に割り当てているケースを削除
結果を見る際に期待している結果とどの程度差異があるのか
自分が扱っているデータがなにかをよく知る DONE†
10/1†
DONE†
assignee_nameがunknownでもメールアドレスがわかっている場合は考慮するべきか．
プロジェクトごとの割当数の多い上位10名の開発者の内訳の上位10名を算出
['eclipse', 'mozilla', 'gcc', 'kde', 'httpd', 'webkit'] 9/24†
TODO†
パッと結果を出していかないと面白くない結果になったとき，どうしようもなくなる．
今週中に上位10名は行う． DONE†
PostgreSQLをJupyterNotebookで扱える環境を整えた．
割当10名が割り当てている人物が偏っているのか．
assigneeとして最もよく出現する人物を10名探す．(簡易のためとりあえず10名)
assigneeが割り当てている人物のそれぞれの割当率を算出する． 9/18†
TODO†
仮説を実際にデータで調査してみる
他のプロジェクトに参加しているかどうかをみるなら GitTorrent を使えばいい
仮説よりも，システマティックに考えられる仮説に変更することも大事
堀口くんに相談をしてみる
割り当て者が割り当てる開発者はさまざまだが，最も多くの割合でタスクを頼まれている開発者はなぜなのか．もいいかも すること†
各assignerが割り当てている開発者の上位10名を列挙
assignerを絞り込むためのフィルターもなにか設定する
割り当てられている上位開発者の割合算出 9/3†
TODO†
全ての工程を違う開発者で行って最高のパフォーマンスを出せた場合，どのような要因があったからなのか(仮説)
DONE†
先行研究の分析では
このパターンで修正が早いものと遅いものを比較した結果，
割り当て者はバグの再現方法と修正方法について，修正者は誰が適切かについて，議論している
割り当て前の議論を時間をかけずに適切に行うことでバグ修正時間は最適化できる 成功する場合に起きていると考えられる仮説
3者共通の関係性
信頼している→実績とか
他のプロジェクトに参加しているのか，何に参加しているのか， 3者のプロジェクトに参加した時期が近い Backyardが似ている コミュニケーションの取りやすさ（会話ができる）
開発以外での交流がある 割り当て者と修正者の関係性
この人！！って割り当てるか，適当に分散してタスクを割り当てているのか 修正者が抱えているタスクが少ない 修正者の活動率が高い 思ったこと
仮説を立てているうちに修正者が一番重要な位置にいる 8/20†
TODO†
SourceTree，Bitbucket，eclipseの使い方確認 分析するデータ(どのプロジェクトにおいてどんな成果物を見るのか)を決める
大平先生の論文ではPlatform，JDTのみしかやっていない←少ない
性質の違うプロジェクトを比較するのもあり DONE†
8/7†
誰から指示を出されるかでパフォーマンスが変化するのかに関する論文を読む．
分析
指示されてから修正完了するまでの修正時間，返答のときの文字数の違い，具体例を頻繁に記述しているか否かなどで評価する．
貢献者と採択者の組み合わせを調べる．
対処法
Aにはこのような話し方，手順を踏むと円滑に会話が進む，
目的
不具合修正などの予測に関する説明変数を提供する
社会的関係性によって修正者がタスクの優先度を決めると考えられるが，優先度を高くする関係性とはどのようなものなのか．相性など．
仮説-具体例を多く記述する管理者は割り当てたタスクを優先的に修正してもらいやすい
R≠T≠Fの場合の精度をもっとも向上させることができると社会的貢献は大きい→現実的なプロセスだから DONE†
The Impact of Bug Management Patterns on Bug Fixing: A Case Study of Eclipse Projects†
先行研究
バグ選別の自動化，重複バグの自動検出，バグ発生理由の理解 貢献
バグ管理システムにおいて，社会的および知識共有要因の重要性を強調．
研究者に対し，役割と個人を統合して考えることの重要性を示す． 目的
プロセスに関与する個人とバグ修正プロセスの効率に対する個人間の関係の影響を調査し， 結果
バグ報告者(R)，バグ割り当て(T)，修正者(F)
R=Tの場合，R≠Tよりも17-47%割り当てが早い
T=Fの場合，T≠Fよりも割り当ての時間が48-58%長い．修正までにかかる時間は半分．
全行程が異なる開発者で行われる場合は最悪のパフォーマンスになる． 所感・疑問
R≠T≠Fの時，バグコミュニケーションの数が多くなるほど修正時間が短くなるとあるがこれに関してもっと深く調査することは可能なのか．
純粋に会話数なのか，そのバグに至るまでの経緯の説明の有無，具体例の有無．これはコンポーネンツに含まれているのか．細分化するとか？ OSS開発における管理者と修正者の社会的関係を考慮した不具合修正時間予測†
仮説
タスクを割り当てる管理者によって優先順位を決めている
その優先順位によって修正までの時間が変わる
先行研究
粒度の大きい範囲でしか予測をすることができない
管理者と修正者の社会的関係が優先順位と修正時間に大きな影響を与えることが示唆されている．
問題点
大きい粒度の予測しかできない．
予測精度がまだまだ改善の余地あり． 目的
特定の管理者から割り当てられたタスクを他の管理者から割り当てられたタスクよりも優先して修正した割合を説明変数に追加(TaskPref)
上記の説明変数が予測精度の向上に寄与するかどうかを調査
結果
説明変数 TaskPref は，1日以内の修正予測に関して有用 所感・疑問
どのような関係性であれば ，TaskPrefの値が大きいのか．
1日という短い期間でTaskPrefは有効であるが，長い範囲での予測に関する説明変数はないのか．→ Patternsがそれに該当 7/31†
DONE†
sentiment analysis toolとpoliteness tool を要約
7/24†
TODO†
論文2本読む．
Sentiment and Politeness Analysis Tools on
Developer Discussions Are Unreliable, but so Are People
On Measuring Affects of GitHub Issues’ Commenters DONE†
気分は伝染し，パフォーマンスに影響を与える
感情分析の既存ツールを使用する際，ドメイン依存性がある
同じデータであっても感情分析ツールの結果は異なるそれぞれが異なる学習で構築されたモデルであるので，異なる結果になることはさして驚く内容ではない． ツールをドメイン特化にカスタマイズする
既存ツールをドメインごとにカスタマイズするとどのように影響を及ぼすのか．
どの程度データを増やせばその影響力を調べることができるのか．
データの過学習に関しての言及がいまいち広く使われている4つ(SentiStrength，NLTK，Stanford CoreNLP，AlchemyAPI)のSAツールの比較．
OSSからのコードレビューコメント用にカスタマイズされたSAツール，SentiCR を開発
SEデータについてSAツール：SentiStrength，SentiStrength-SE，Senti4SD，SentiCRの比較
既存の感情分析ツール，ポライトネスツールは正確に識別することができていない．
アンダーサンプリング，アンダーサンプリング&オーバーサンプリングの組み合わせが感情分析の分類性能をどのように改善するのか~→ 7/16†
TODO†
Big 5論文を読んでリスト化する
An Empirical Investigation of Personality Traits of Software Testers
What can OSS mailing lists tell us?
Politeness論文を読んでリスト化する（来週以降） DONE†
Tanjila Kanij，Robert Merkel，John Grundy
2015 IEEE/ACM 8th International Workshop
ソフトウェアテスターは他の開発者に比べ，誠実性が高いが理由は不明
by the MBTI as "logical and ingenious" はコードレビューのタスクが得意
extrovert personality traits(社交性) が effective exploratory testing と相関あり
by the MBTI as “sensing and judging” はsoftware testing が得意になるだろう
*ソフトウェアテスターに必要なスキルを "big five"の性格特性にマッピング． テスターには開放性と誠実性が大事
テストは退屈な作業．若手とベテランではソフトウェアテストに対するモチベーションが異なる．
ソフトウェアエンジニアに求められるスキルをMBTI性格タイプと関連づけ，ソフトウェアエンジニアのさまざまな役割に適した性格タイプを提案
by the MBTI as "thinking and judging"はソフトウェアエンジニアでは過剰に表現される
ソフトウェアテスターはcreative, accurate and strict な人が良い
ソフトウェアテスターは間違いを見つける好奇心を持っている悲観的な人が良い
ソフトウェアテスターにはcommunication skills, problem solving and team playing capability が大事，また creative and open to new challenges であるべき．
Peter C. Rigby，Ahmed E. Hassan
Fourth International Workshop on Mining Software Repositories (MSR'07)
OSS開発者の性格タイプはどのようなものか． 言葉や態度がプロジェクトnew,current,departで変化するのか．→Yes
リリース前後で word usage が違うのか→ LIWCでの有意性なし
特定のLIWC dimentions はbig fiveパーソナリティ指標と相関あり 5/22†
DONE†
4/23†
DONE†
Todo†
4/16†
DONE†
Todo†
研究テーマの背景，問題点，目的をスライドにまとめる．
以前紹介してもらった関連論文を読破する． 3/14†
Todo†
研究方針†
プロジェクトの中心人物数人に着目し，プロジェクト初期から末期までの会話データから人と人の打ち解け方やそのタイミングを分析する．
プロジェクトからデータを取るにはApacheが一番簡単．
Mozilla，Linuxやeclipseはデータを取ることが困難(時間的にも)
メイリスから取ってくるのがいいかも 話し合いの分析を行なった結果，話しやすい環境であれば的確な指示を出すことができて生産性が向上するまで出せたらいい感じ
ポライトネスが高いとバグの修正までの時間が長くなる
遠回しな言い回しをするから
ポライトネスとネットワークの次数の関係をみるといい感じかも(ほりほりと関連ありそう)
あるコミュニティに属する、ある条件を満たすユーザの時系列性格分析を行う
コミュニティを維持するために必要な条件要素を調査する
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
pattern_5.pdf
