For FOSE2012†
既存研究では不具合の依頼が一部の開発者に偏る
解決したいもの†
開発者への不具合の提供量
開発者†
- リソースは有限である
- 修正量に個人差がある
- コンポーネントごとに得意・不得意がある
不具合†
- 時系列に不具合が報告されていく
- 一目で修正の難しさがわからない
note†
一般のプロジェクトでWPを単位にしたTaskAllocation（線形計画法）との違い
- WPが単位なので、複数の開発者を割り当てることができる。
- 不具合と違い、ほとんどのWPは開発者が割り当てられる。
アイデア†
ナップサック問題を使う†
目的関数：重要度
目的変数：0・1(不具合を修正するかしないか)
制約条件：修正予測時間に基づいて、ある一定期間における予測修正量＜開発者の修正可能量
アルゴリズム：
- 修正可能な修正者をリストアップ
- 修正予測時間を算出→Cost
- 不具合の重要度を算出→Value
- ナップサック適用(１つ選ぶ)
- 不具合がまだあるなら１に戻る
- 開発者に不具合割当
整数計画法を使う†
目的関数：�凜灰好函潴榲�変数
目的変数：ある開発者があるコンポーネントを何個直すか
制約条件：ある開発者の可能修正量,あるコンポーネントの必要修正量（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がコンポーネント１を直す個数である
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
