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

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 柏/卒論 へ行く。
  • 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)

---

卒研†

問題†

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

解決したいもの†

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

要因†

• 開発者
• 不具合

条件†

開発者†

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

不具合†

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

解決法†

整数計画法を使う†

目的関数：�瑤△襯灰鵐檗璽優鵐箸良垓餽腓紡个垢觸だ気慮�率の良さ×目的変数
目的変数：ある開発者があるコンポーネントを何個直すか
制約条件：ある開発者の可能修正量,あるコンポーネントの必要修正量（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がコンポーネント１を直す個数である

keyword†

時系列・機械学習・計画問題・ナップサック

評価†

現実のタスク割り当てvs柏アルゴリズム

新規性†

過去には不具合の修正の推奨システムはあるが、現実的に考えれば不可能である量が推奨されている。そこで、開発者の処理能力をナップサック問題としてとらえることにより、推奨システムをより現実的なものにする。

発展†

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

解決法†

Go on to Thesis_Slution_Kashiwa

Reference†

wiki†

FOSE2012_Kashiwa

Paper†