作島の履歴(No.43) - PukiWiki

[ トップ ] [ 新規 | 一覧 | 検索 | 最終更新 | ヘルプ ]

Memo†

Link†

作島/研究テーマ

Schedule†

	Mon	Tue	Wed	Thu	Fri
1
2			全体MT
3	ソフトウェア工学特論	3年演習	TKG班MT	マルチメディア	マルチメディア
4	ソフトウェア工学特論			3年演習
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)

TODO†

Erich Gamma は eclipseの創立者だからその人しか直せない場合がある(親密であるとは言えない)
データ分布がわからないと分析することができない
もともとある仮説を元に分析しているのでそれが当てはまっていなければその仮説が妥当ではなかったというだけ
- 全ての工程が違う開発者の場合の修正時間を短縮したい
  →親密度の高い人同士なら早いのではという仮説
  →親密度を割当率でやっていた
  →率ではなくて数でやったほうがいいのではないか．分布がわからない以上，議論ができない．
組織を削除する処理が雑→eclipseから割り当てられているメールアドレスならorgがつくから．
データ分布の８割を占めるのが上位10人だったのならわかるが。。
分布をみる前にパーセントを出しても意味がない

10/7†

ADVICE†

データ設計が8割
自分の見たいデータのみにすることがまず大事
- 自分が報告して自分で修正している人の割合を見るとがっかりするが自分が見たいデータではない
- 人が人に割り当てていることに着目するべきでBotが割り当てているのは自分がみたいデータではない
未加工のデータ知る

TODO†

一つのプロジェクトにのみ着目する
- [eclipse]
割当者が組織であるケースを削除
自分が自分に割り当てているケースを削除
結果を見る際に期待している結果とどの程度差異があるのか
- [求める結果を書く]
自分が扱っているデータがなにかをよく知る

DONE†

10/1†

DONE†

assignee_nameがunknownでもメールアドレスがわかっている場合は考慮するべきか．
プロジェクトごとの割当数