柏/ネタ帳/HighPriorityDefect の履歴(No.16)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 柏/ネタ帳/HighPriorityDefect へ行く。
  • 1 (2018-02-27 (火) 00:59:53)
  • 2 (2018-02-27 (火) 01:06:55)
  • 3 (2018-02-27 (火) 07:40:00)
  • 4 (2018-02-28 (水) 02:04:50)
  • 5 (2018-03-05 (月) 01:56:57)
  • 6 (2018-03-05 (月) 07:05:31)
  • 7 (2018-03-09 (金) 02:30:31)
  • 8 (2018-03-22 (木) 13:26:00)
  • 9 (2018-03-23 (金) 03:35:08)
  • 10 (2018-03-29 (木) 08:57:22)
  • 11 (2018-03-30 (金) 06:12:29)
  • 12 (2018-04-02 (月) 05:12:24)
  • 13 (2018-04-02 (月) 18:54:13)
  • 14 (2018-04-04 (水) 02:23:06)
  • 15 (2018-04-04 (水) 05:25:09)
  • 16 (2018-04-05 (木) 06:57:01)
  • 17 (2018-04-06 (金) 07:46:24)
  • 18 (2018-04-07 (土) 07:25:36)
  • 19 (2018-04-08 (日) 03:09:34)
  • 20 (2018-04-10 (火) 02:14:30)
  • 21 (2018-04-16 (月) 08:28:14)
  • 22 (2018-04-16 (月) 13:36:57)
  • 23 (2018-04-17 (火) 06:31:14)
  • 24 (2018-04-17 (火) 11:35:15)
  • 25 (2018-04-18 (水) 01:08:44)
  • 26 (2018-04-18 (水) 13:31:25)
  • 27 (2018-04-22 (日) 08:01:42)
  • 28 (2018-04-24 (火) 04:43:50)
  • 29 (2018-04-27 (金) 03:58:49)

---

柏
柏/ネタ帳/HighPriorityDefect/ノート

要約†

問題†

• 優先度を付けるのは大変
  • 依然として，ほとんどの不具合の優先度はデフォルト値のまま

ゴール†

• 優先度の自動設定ができるようにする
  • 優先度が意味があるものと証明すること
  • なぜ優先されるのかを明らかにする

着目†

• 本研究で大切なのは優先度の設定ではなく，優先度の変更

スタンス†

• David Loは，側を見てる
• 本研究は，中身を見てる

主張・帰着点†

hogehoge

Motivation†

背景†

近年のソフトウェア開発は大規模・複雑化しており，ソフトウェアテスト過程で大量の不具合が報告される．
報告された不具合は次のリリースに向けて修正を行うが，限られた期間と人員で全ての不具合を修正することは難しい．
多くのソフトウェア開発では，大量に存在する不具合のどれから修正するかを意味する優先度を設定する．
優先度の設定を行うには，すべての不具合内容を把握する必要があるため，多くの時間を要する．
そのため，不具合の優先度を予測するため研究が盛んに行われている．
しかしながら，その精度は40%程度と低く，特にP1は10%から30%と低く，ソフトウェアは１件の不具合でもシステムが停止することがあるため，P1値はより，正確に見積もる必要がある．
本研究では優先度が高い不具合票の検出精度の向上を狙う．

• プロジェクトにとって直さなくてはならないものはP2・P1
  • P3は気が向けば直す？
  • P4,P5はパッチが来れば見て，取り込む つまり大事なのはP2・P1を検出すること

Priority†

• 優先度は，開発者によって付けられ，開発者の不具合修正の大事さを示す
  • 一方，深刻度は，ユーザーに付けられ，不具合がユーザーに与えるインパクトの大きさを示す
  • 優先度をつける開発者は，具体的に，プロジェクトリード (Project Lead)または不具合の担当者がつける．
  • 物事が処理される順序を反映する必要がある
    • 優先順位は時間とともに変化する可能性がある
    • 作業が始まった後にP1・P2ではないと判断されることが実際にある（例えば，当初の予想よりもはるかに多くの作業が必要なことが判明した場合など）
  • コンポーネントにおける全ての不具合を調べ，そのマイルストーンごとのP1，P2を設定する必要がある

優先度の意味†

柏/ネタ帳/HighPriorityDefect/プロジェクトごとの優先度

Motivation†

多くの研究者はPriorityは意味ないという．ほんとうか？
一方，OSSプロジェクトではプライオリティの指標を掲げている．
Eclipseでは，ほげほげ，Webkitでは具体的な内容まで指している．
ここに矛盾が生じている．
ただ，この矛盾が生じている原因として，多くのBTSの優先度の初期値が普通だったことに起因すると考えられる．
これがバイアスとなり，結果を歪めているのではないか．
では，優先度が変更されたものだけではどうだろうか．
これが私達のモチベーションである．優先度の変更に着目した研究はまだない．

Related works†

多くの研究は，予測に関する研究で，不具合の優先度を分析する研究はない．ただし，一部の研究の副産物として優先度に触れられているものがある．以下ではそれを述べる．

Predictions†

柏/ネタ帳/HighPriorityDefect/関連研究

Remarks†

柏/ネタ帳/HighPriorityDefect/関連研究

研究設問†

RQ1 : 優先度は何から何に変更されているのか†

ほとんどはP3から変更される

RQ2：優先度は誰が変更しているか（コアな開発者か）†

• 優先度を変更する開発者に偏りがあるか
• ある場合，何が違うか
  • 優先度設定が80%を占めるグループと20%を占めるグループで比較
  • 50%，50%の方が良いか？
    • コミッターの数
    • 議論に参加している開発者か
• その他の候補
  • コンポーネントで最も活躍する開発者か
  • ネットワーク図で関わりを表しても面白そう

RQ3 ：開発者はいつ優先度を変更するか†

• 各月の優先度変更数を比較

RQ4：優先度は守られているか（意味があるか）†

• 不具合の修正日数やリリースまでの修正完了率を比較
  • 修正時間の分散もみるべき，P3なんかはバラツキがあるはず

RQ5：なぜ変更されるのか（優先度をつける基準は何か）†

• 3つのディメンジョンにわけてサブRQを作成
  • 早く直さなくてはいけない理由を考える
    • 最終的に帰着させる論にもっていく必要がある
  • 優先度ごとに比較

不具合†

• 深刻度
  • プライオリティが変更される直前の時点で
• ある単語（セキュリティに関するワードなど）
• 他の不具合修正の阻害をしている（depend onの数）
• すべてのプラットフォーム（OS）に出現する
• プロダクト
• コンポーネント

コード†

• 修正したソースコードがコア部分（もしくはコア機能）

プロジェクト†

• 不具合の報告者が開発者
• とある開発者が関わっている
• たくさんの開発者が注目している(CCの数，コメントの数)
  • プライオリティが変更される直前の時点で
• 報告された日がリリースまでの時間が短い（微妙）

結果†

Eclipse†

RQ1 ：開発者はいつ優先度をつけるか†

• リリース前の3ヶ月間では変更回数が増える

RQ2：優先度は誰が付けているか（コアな開発者か）†

• 8割の優先度の変更は半分以下の開発者で行われている
• コアの定義が未定のため保留

RQ3：優先度は守られているか（意味があるか）†

• 修正日数は優先度が高いほど短い
• 修正完了率は優先度が高いほど高い

RQ4：優先度をつける基準は何か†

Discussion†

優先度の変更†

P1から下げられる不具合とは†

• 最初にP1と報告者がつけ，下げた？
• コア開発者以外が高くつけ，下げた？

P5から上げられる不具合とは†

優先度の変更間違い†

• P1なのにTrivialってどういうこと？

重要なのに優先度は低い†

全部の不具合が優先度を変更されていないのはめんどくさいから？†

• さっと直せるものは良いとして，リリース直前のものは，ちゃんとつけるべき
  • でも，それが面倒くさいから，優先度をちゃんとつけてないのでは？
  • 結局，リリースまでの時間を鑑みて，相対的に付けなければならないから，人間には容易ではない

展望†

• 優先度が予測できるようになると，次のリリースまでにこのプロジェクトが直してくれるかがわかる [#v5b89c11]
• 優先度を予測できれば，パッチの採択を予測できるかも
  • パッチの採択は，優先度とパッチの複雑度で決まる（Mozilla ではそうらしい）