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

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 柏/ネタ帳/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は10%から30%と低く，ソフトウェアは１件の不具合でもシステムが停止することがあるため，P1値はより，正確に見積もる必要がある．
本研究では優先度が高い不具合票の検出精度の向上を狙う．

優先度†

優先度とは†

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

優先度の意味†

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

関連研究†

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

研究設問†

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

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

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

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

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

• 優先度を変更する開発者に偏りがあるか
• コミッターか
• 議論に参加している開発者か
• その他の候補
  • コンポーネントで最も活躍する開発者か
  • ネットワーク図で関わりを表しても面白そう

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

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

不具合†

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

コード†

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

プロジェクト†

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

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

結果†

Eclipse†

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

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

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

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

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

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

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

Discussion†

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

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

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