柏
柏/ネタ帳/HighPriorityDefect/ノート
タイトル候補†
- An Empirical Study of Bug Priority Changes ~hogehoge
- Defect Priority Prediction Models: Can We Do Better?
- 優先度を付けるのは大変
- 依然として，ほとんどの不具合の優先度はデフォルト値のまま
- この優先度であっているかはわからない
支援対象†
ゴール†
- 優先度変更がなぜ起きるかを理解する
- 優先度の自動設定ができるようにする
- 本研究で大切なのは優先度の設定ではなく，優先度の変更
- プロジェクトのリソースや残り時間
スタンス†
David Loは，プロジェクトの傾向を見てる本研究は，プロジェクトの状況を見てる
Introduction†
近年のソフトウェア開発は大規模・複雑化しており，ソフトウェアテスト過程で大量の不具合が報告される．
報告された不具合は次のリリースに向けて修正を行うが，限られた期間と人員で全ての不具合を修正することは難しい．
多くのソフトウェア開発では，大量に存在する不具合のどれから修正するかを意味する優先度を設定する．
優先度の設定を行うには，すべての不具合内容を把握する必要があるため，多くの時間を要する．
そのため，不具合の優先度を予測するため研究が盛んに行われている．
しかしながら，その精度は40%程度と低く，特にP1は10%から30%と低く，ソフトウェアは１件の不具合でもシステムが停止することがあるため，P1値はより，正確に見積もる必要がある．
本研究では優先度が高い不具合票の検出精度の向上を狙う．
- プロジェクトにとって直さなくてはならないものはP2・P1
- P3は気が向けば直す？
- P4,P5はパッチが来れば見て，取り込む
つまり大事なのはP2・P1を検出すること
Background and Motivation†
Priority†
- 優先度は，開発者によって付けられ，開発者の不具合修正の大事さを示す
- 一方，深刻度は，ユーザーに付けられ，不具合がユーザーに与えるインパクトの大きさを示す
- 優先度をつける開発者は，具体的に，プロジェクトリード (Project Lead)または不具合の担当者がつける．
- 物事が処理される順序を反映する必要がある
- 優先順位は時間とともに変化する可能性がある
- 作業が始まった後にP1・P2ではないと判断されることが実際にある（例えば，当初の予想よりもはるかに多くの作業が必要なことが判明した場合など）
- コンポーネントにおける全ての不具合を調べ，そのマイルストーンごとのP1，P2を設定する必要がある
優先度の意味†
柏/ネタ帳/HighPriorityDefect/プロジェクトごとの優先度
Motivation†
多くの研究者はPriorityは意味ないという．ほんとうか？
一方，OSSプロジェクトではプライオリティの指標を掲げている．
Eclipseでは，ほげほげ，Webkitでは具体的な内容まで指している．
ここに矛盾が生じている．
ただ，この矛盾が生じている原因として，多くのBTSの優先度の初期値が普通だったことに起因すると考えられる．
これがバイアスとなり，結果を歪めているのではないか．
では，優先度が変更されたものだけではどうだろうか．
これが私達のモチベーションである．優先度の変更に着目した研究はまだない．
Related works†
多くの研究は，予測に関する研究で，不具合の優先度を分析する研究はない．ただし，一部の研究の副産物として優先度に触れられているものがある．以下ではそれを述べる．
Predictions†
柏/ネタ帳/HighPriorityDefect/関連研究
Remarks†
柏/ネタ帳/HighPriorityDefect/関連研究
事前調査†
PreRQ1：どのようなフローで優先度が変更されているか†
PreRQ2：開発者はいつ優先度を変更するか†
PreRQ3：優先度は守られているか（意味があるか）†
- 不具合の修正日数やリリースまでの修正完了率を比較
- 修正時間の分散もみるべき，P3なんかはバラツキがあるはず
研究設問†
RQ1: 優先度は何から何に変更されているのか†
- 事前優先度メトリクス
- ほとんどはP3から変更される
- 前の状態が影響を与えている
- %のフローも出すP3→P1→P2のとどまる率や変更率
RQ2：時期によって優先度の出やすさはあるか†
- 変更タイミングメトリクス
- 各月の優先度変更数を比較
- 累積も比較
- 変更する時期が関係する
時期によって変更されやすい優先度はあるのか†
- 変更されやすい優先度（元）
- 変更されやすい優先度（先）
RQ3：変更者によって付けやすさはあるか†
- 変更者メトリクス
- 人によって変更の傾向がある
- 優先度を変更する開発者に偏りがあるか
- ある場合，何が違うか
- 優先度設定が80%を占めるグループと20%を占めるグループで比較
- 50%，50%の方が良いか？
- その他の候補
- コンポーネントで最も活躍する開発者か
- ネットワーク図で関わりを表しても面白そう
RQ4：変更されることを予測できるか†
- リリース数ヶ月前の時点で，不具合が修正されていないもの，およびリリース前数ヶ月間で報告される不具合が優先度が何になるか予測する
Report†
- プロダクト
- コンポーネント
- 深刻度
- ◎変更前の優先度
- プラットフォーム
- OS
- summery+descriptionの文字数
- Description中の単語の情報利得が上からtopX
- 報告日時
- ◎報告日時からリリースまでの時間(リリース前数ヶ月以上なら一定値)
Reporter†
- Reporter名
- 報告者Rが報告した不具合数
- 報告者Rが報告する不具合の優先度の平均値・中央値
Changer†
- ◎プライオリティの変更者名
- ◎プライオリティ変更者の変更経験数（変更件数）
- ◎プライオリティ変更者の変更経験数（不具合件数）
- ◎プライオリティ変更者がつける優先度の平均値・中央値
Projectの傾向（例年）†
- 類似した不具合20件の優先度の平均値・中央値
- 類似した不具合10件の優先度の平均値・中央値
- 類似した不具合5件の優先度の平均値・中央値
- 類似した不具合3件の優先度の平均値・中央値
- 類似した不具合1件の優先度
- 優先度の平均値・中央値
- P1の割合
- P2の割合
- P3の割合
- P4の割合
- P5の割合
Projectの状況（変更の直前）†
- 7日以内の不具合報告の数
- 7日以内の不具合報告の数（同じ深刻度）
- 7日以内の不具合報告の数（同じもしくは大きい深刻度）
- 30日以内の不具合報告の数
- 30日以内の不具合報告の数（同じ深刻度）
- 30日以内の不具合報告の数（同じもしくは大きい深刻度）
- ◎P1の不具合数
- ◎P2の不具合数
- ◎P3の不具合数
- ◎P4の不具合数
- ◎P5の不具合数
Discussion†
優先度の変更†
P1から下げられる不具合とは†
- 最初にP1と報告者がつけ，下げた？
- コア開発者以外が高くつけ，下げた？
P5から上げられる不具合とは†
変更されないものも含めてやってみる†
優先度の変更間違い†
重要なのに優先度は低い†
マメな人†
- 人によって違うのではないか（マメな人とマメじゃない人）
全部の不具合が優先度を変更されていないのはめんどくさいから？†
- さっと直せるものは良いとして，リリース直前のものは，ちゃんとつけるべき
- でも，それが面倒くさいから，優先度をちゃんとつけてないのでは？
- 結局，リリースまでの時間を鑑みて，相対的に付けなければならないから，人間には容易ではない
優先度の変更を予測できるか†
ゴミを混ぜたときも予測できるか†
- 優先度が予測できるようになると，次のリリースまでにこのプロジェクトが直してくれるかがわかる [#v5b89c11]
- 優先度を予測できれば，パッチの採択を予測できるかも
- パッチの採択は，優先度とパッチの複雑度で決まる（Mozilla ではそうらしい）
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
