既存研究では不具合の依頼が一部の開発者に偏る
解決したいもの†
開発者への不具合の提供量
開発者†
- リソースは有限である
- 修正量に個人差がある
- コンポーネントごとに得意・不得意がある
不具合†
- 時系列に不具合が報告されていく
- 一目で修正の難しさがわからない
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がコンポーネント１を直す個数である
線形計画法は使わない理由†
線形計画法と整数計画法の違いは、変数が連続か整数かの違いで、線形計画法の方が解きやすい。しかし、線形計画法は連続量で近似しても一般性を失わない必要がある。今回のTask Allocationでは不具合の種類（コンポーネント）に対する修正する個数を目的変数としているため、少数を含むと、UIを1.7個割り当てててAntは1.29個割り当てるといったことも可能になり、不具合を少数個割り当てるのはおかしいため今回は整数計画問題とする。
- Tossing Graphを用いる
- 多期間計画問題を用いる
参考:FOSE2012_Kashiwa
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
