柏/卒論 の履歴(No.2)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 柏/卒論 へ行く。
  • 1 (2012-10-03 (水) 11:22:59)
  • 2 (2012-10-03 (水) 11:38:48)
  • 3 (2012-10-03 (水) 14:35:34)
  • 4 (2012-10-03 (水) 21:47:10)
  • 5 (2012-10-05 (金) 01:09:15)
  • 6 (2012-10-08 (月) 04:42:10)

Go on to Thesis_Slution_Kashiwa

卒研†

問題†

既存研究では不具合の依頼が一部の開発者に偏る

解決したいもの†

開発者への不具合の提供量

要因†

• 開発者
• 不具合

条件†

開発者†

• リソースは有限である
• 修正量に個人差がある
• コンポーネントごとに得意・不得意がある

不具合†

• 時系列に不具合が報告されていく
• 一目で修正の難しさがわからない

解決法†

整数計画法を使う†

目的関数：�瑤△襯灰鵐檗璽優鵐箸良垓餽腓紡个垢觸だ気慮�率の良さ×目的変数
目的変数：ある開発者があるコンポーネントを何個直すか
制約条件：ある開発者の可能修正量,あるコンポーネントの必要修正量（P1の個数など）
アルゴリズム：

1. 修正者がコンポーネントの修正にかかるコストを算出→目的関数
2. コンポーネントの必要修正量の算出→制約条件
3. 修正者の可能修正量の算出→制約条件
4. 制約条件の下に目的関数を最小にする目的変数を求める→答え
5. 開発者の過去の修正量を基に誰にどの不具合を割り当てるか決める
   例：
   目的関数：
   3xA1+2xA2+xA3+2xB1+3xB2+2xB3
   制約条件：
   xA1+xA2+xA3≦2
   xB1+xB2+xB3≦4
   xA1+xB1≧2
   xA1+xB1≧1
   x≧0かつ整数
   注意：xA1とは開発者Aがコンポーネント１を直す個数である

発展†

• Tossing Graphを用いる
• 多期間計画問題を用いる
• 不具合のsimilarity

Reference†

wiki†

FOSE2012_Kashiwa

Paper†