*卒研 [#u5ecb226]
**問題 [#p034d151]
既存研究では不具合の依頼が一部の開発者に偏る
**解決したいもの [#t5ea0e07]
開発者への不具合の提供量
**要因 [#j4e054ad]
-開発者
-不具合
**条件 [#fb021b3a]
***開発者 [#d190f311]
-リソースは有限である
-修正量に個人差がある
-コンポーネントごとに得意・不得意がある
***不具合 [#ucd23a49]
-時系列に不具合が報告されていく
-一目で修正の難しさがわからない
**解決法 [#se1496cf]
***整数計画法を使う [#h057ee4f]
目的関数：�瑤△襯灰鵐檗璽優鵐箸良垓餽腓紡个垢觸だ気慮�率の良さ×目的変数~
目的変数：ある開発者があるコンポーネントを何個直すか~
制約条件：ある開発者の可能修正量,あるコンポーネントの必要修正量（P1の個数など）~
アルゴリズム：~
+修正者がコンポーネントの修正にかかるコストを算出→目的関数
+コンポーネントの必要修正量の算出→制約条件
+修正者の可能修正量の算出→制約条件
+制約条件の下に目的関数を最小にする目的変数を求める→答え
+開発者の過去の修正量を基に誰にどの不具合を割り当てるか決める
~
例：~
目的関数：~
3xA1+2xA2+xA3+2xB1+3xB2+2xB3~
制約条件：~
xA1+xA2+xA3≦2~
xB1+xB2+xB3≦4~
xA1+xB1≧2~
xA1+xB1≧1~
x≧0かつ整数~
注意：xA1とは開発者Aがコンポーネント１を直す個数である
**keyword [#k7d29716]
時系列・機械学習・計画問題・ナップサック
**評価 [#a7e714de]
現実のタスク割り当てvs柏アルゴリズム
**新規性 [#ab139a63]
過去には不具合の修正の推奨システムはあるが、現実的に考えれば不可能である量が推奨されている。開発者の処理能力・得手不得手を考慮し，整数計画問題としてとらえることにより、推奨システムをより現実的なものにする。
**整数計画問題を選択した理由 [#k8c3acb6]
整数計画問題を扱うことにより，開発者ごとに割り当てる不具合の上限を設定できる．
また，既存研究ではGreedy法や遺伝的アルゴリズムを使っているが，条件として一人につき１つの不具合だけを修正するという前提で行っている．しかし，整数計画法を用いればある期間内に１人につき複数の不具合を割り当てることができ，より自然となる．
**発展 [#x34a7f10]
-Tossing Graphを用いる
-多期間計画問題を用いる
-不具合のsimilarity
**解決法 [#l07f5705]
Go on to [[柏/卒論/詳細]]
**Reference [#be01de8a]
***wiki [#tb916626]
[[FOSE2012_Kashiwa]]
***Paper [#h6552dda]
|CENTER:|CENTER:|CENTER:|c
|''Title'' |''Author''|''Conference'' |h
|Optimized Assignment Of Developers For Fixing Bugs|Md.Mainur Rahman|ICSM2009|
|Who Should Fix This Bug?|John Anvik|ICSE 2006|
|Improving Bug Triage with Bug Tossing Graphs|Gaeul Jeong|ESEC/FSE'09|
|Fine-grained Incremental Learning and Multi-feature Tossing Graphs...|Bhattacharya|ICSM 2010|
back to [[柏]]
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
