Memo†
Link†
作島/研究テーマ
時間割†
| Mon | Tue | Wed | Thu | Fri |
|---|
| 1 | | | | | |
|---|
| 2 | | | 全体MT | TKG班MT | |
|---|
| 3 | ソフトウェア工学特論 | 3年演習 | | マルチメディア | マルチメディア |
|---|
| 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†
11/ 26†
- 修正リーダー・修正時間に着目する
- 修正リーダー：コンポーネント単位の不具合において最も修正担当の割合が多い開発者
(関わっている年月が最も長い人物・両方でみてもいいかも)
- RQ2 : 修正リーダーは他の開発者よりも修正時間が短いのか
- 短い場合 -要因-
・ コンポーネントを熟知している (修正リーダーが創立者，関わっている年月が長い)
・ 修正リーダーのスキルが高い (修正パッチが再修正になることが少ない)
・ 重要度，優先度が高い修正依頼が多い(急かされている)
- 長い場合 -逆の要因-
・ 修正リーダーに修正困難な不具合が修正するため (Reopenedの不具合で評価)
・ 同時期に複数の修正依頼を抱えていることが多いため
- 有意差なし -どうして差がないのか-
・修正リーダーがリーダーではない(修正回数でリーダーを定義するのがよくない)
・修正リーダーのスキルが同程度 (修正パッチが再修正になる頻度)
11/ 20†
- 要因だけでは広義だから，「？？」の要因を調査するというふうに狭めて考える
- ストーリーがないといけない
- 有意差がでればOK，でなければダメ，という仮説ではいけない
11/ 14†
- スライドの流れ
OSS開発において日々多くの不具合報告がなされている．
利用するにあたって必要な箇所がいつ修正されるのかを知りたい
不具合修正の時間を予測する必要がある．
予測するツールがさまざまある
精度向上に関する研究が多くなされているがまだ不十分
精度向上を目指す→ 説明変数になる要因を探す．
- 修正時間はR≠T≠Fが最も時間がかかる要因は未解明
- 予測の精度は低い
11/ 5†
- モジュールごとに長がいるかもしれない
- 専門知識が必要でそれを修正できるひとが限られるからとか
- 修正時間が短い集合と長い集合から組み合わせを抽出する
- 最終的に比較するからこの集団を使う
- 中央値より短いか長いかで集団を区切る
- 状況を理解する必要がある．仮説を細かく考える必要がある．
- 修正時間が負の場合も削除する必要はない
- 他のデータが100日単位でずれていたりなど，見えていないデータもずれがある可能性がある
- 不適切なデータで見えている分を削除したくなるが他のデータは完全に正しいとは言えない
TODO†
- 研究発表のスライドを作る
- 短い集団と長い集団の取り方を修正する
- システマチックに仮説を立てる
10/ 31~†
REPORT†
TODO†
- 修正時間をプロットする
- 仮説と前処理がうまいこと噛み合ってない気もする
- 修正時間が短い場合と修正時間が長い集団を抽出して，そのなかで回数をみるとか
- 3543件→17件にしたが，削除した組み合わせと比較するしたい
- 17件の各修正時間(箱ひげ図)と削除した組み合わせの修正時間の平均を出す
10/ 23~†
- 割り当て者と修正者の関係のほかに，報告者と割り当て者の関係もみる
- 分布をみて明らかに割り当て回数が少ないのは重要なデータではないので削除する
→分布から見て100件以上でフィルタリングを行う，で良い．
- 自分以外の割り当ての多い開発者に注目する，という認識でOK
10/ 23†
TODO†
- 割り当て者の分布を算出する
- 全ての工程が違う開発者の場合の修正時間を短縮したい
→親密度の高い人同士なら早いのではという仮説
→親密度を割当率でやっていた
→率ではなくて数でやったほうがいいのではないか
DONE†
- 前処理
- assigner, assigneeの文字列に[ indox, eclipse, php, platform ] を含む列を除外
- 割り当て者の分布算出
- 結果
- eclipseプロジェクトにおける割り当て者：21323人，割り当て数：234960件
割り当ての80％を担当している割り当て者：1760人
報告.pdf
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の創立者だからその人しか直せない場合がある(親密であるとは言えない)
- データ分布がわからないと分析，議論できない
- 上位10人がデータ分布の８割を占めるなどの根拠がないといけない．
- もともとある仮説を元に分析しているのでそれが当てはまっていなければその仮説が妥当ではなかったというだけ
- 全ての工程が違う開発者の場合の修正時間を短縮したい
→親密度の高い人同士なら早いのではという仮説
→親密度を割当率でやっていた
→率ではなくて数でやったほうがいいのではないか．分布がわからない以上，議論ができない．
- 組織を削除する処理が雑
→eclipseから割り当てられているメールアドレスならorgがつくから．
10/7†
ADVICE†
- データ設計が8割
- 自分の見たいデータのみにすることがまず大事
- 自分が報告して自分で修正している人の割合を見るとがっかりするが自分が見たいデータではない
- 人が人に割り当てていることに着目するべきでBotが割り当てているのは自分がみたいデータではない
- 未加工のデータ知る
TODO†
- 一つのプロジェクトにのみ着目する
- 割当者が組織であるケースを削除
- 自分が自分に割り当てているケースを削除
- 結果を見る際に期待している結果とどの程度差異があるのか
- 自分が扱っているデータがなにかをよく知る
DONE†
10/1†
DONE†
- assignee_nameがunknownでもメールアドレスがわかっている場合は考慮するべきか．
- プロジェクトごとの割当数
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
