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

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 柏/ネタ帳/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/ノート

ゴール†

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

背景†

• 不具合の優先度づけは大変
  • テストフェーズには大量の不具合が報告される
  • 報告される不具合はプロジェクトのコア開発者が不具合の内容を精査し，修正するかや優先度を決める
  • この精査は多くの時間を要する
  • リリースまでにプロジェクトの品質を上げるために，直すべき不具合を適切に把握・優先度は適切に設定し，リソースを上手く最大限活用して，優先すべき不具合を修正するべき
• 優先度の予測研究が行われている
  • 精度は40%程度と低い
  • 特にP1は低く，ソフトウェアは１件の不具合でもシステムが停止することがあるため，P1値はより，正確に見積もる必要がある

優先度†

優先度とは†

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

優先度の意味†

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

関連研究†

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

研究設問†

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

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

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

• 不具合の修正日数やリリースまでの修正完了率を比較

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

• 優先度を付ける開発者に偏りがあるか

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

• 優先度ごとに以下を比較
  • リリースまでの時間を比較
  • 修正したソースコードがコア部分
  • 深刻度
  • セキュリティに関するワードが含まれるか

RQ5：(RQ4)で違いがでた値は予測に使えるか†

結果†

Eclipse†

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

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

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

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

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

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

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

Discussion†

優先度が予測できるようになると，次のリリースまでにこのプロジェクトが直してくれるかがわかる†

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

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