柏
柏/ネタ帳/HighPriorityDefect/ノート
ゴール†
- 優先度の自動設定ができるようにする
- 優先度が意味があるものと証明すること
- なぜ優先されるのかを明らかにする
- 不具合の優先度づけは大変
- テストフェーズには大量の不具合が報告される
- 報告される不具合はプロジェクトのコア開発者が不具合の内容を精査し，修正するかや優先度を決める
- この精査は多くの時間を要する
- リリースまでにプロジェクトの品質を上げるために，直すべき不具合を適切に把握・優先度は適切に設定し，リソースを上手く最大限活用して，優先すべき不具合を修正するべき
- 優先度の予測研究が行われている
- 精度は40%程度と低い
- 特にP1は低く，ソフトウェアは１件の不具合でもシステムが停止することがあるため，P1値はより，正確に見積もる必要がある
優先度†
優先度とは†
- 優先度は，開発者によって付けられ，開発者の不具合修正の大事さを示す
- 一方，深刻度は，ユーザーに付けられ，不具合がユーザーに与えるインパクトの大きさを示す
- 優先度をつける開発者は，具体的に，プロジェクトリード (Project Lead)または不具合の担当者がつける．
- 物事が処理される順序を反映する必要がある
- 優先順位は時間とともに変化する可能性がある
- 作業が始まった後にP1・P2ではないと判断されることが実際にある（例えば，当初の予想よりもはるかに多くの作業が必要なことが判明した場合など）
- コンポーネントにおける全ての不具合を調べ，そのマイルストーンごとのP1，P2を設定する必要がある
優先度の意味†
柏/ネタ帳/HighPriorityDefect/プロジェクトごとの優先度
関連研究†
柏/ネタ帳/HighPriorityDefect/関連研究
研究設問†
RQ1 ：開発者はいつ優先度をつけるか†
RQ2：優先度は守られているか（意味があるか）†
RQ3：優先度は誰が付けているか（コアな開発者か）†
- 優先度を付ける開発者に偏りがあるか
- コミッターか
- 議論に参加している開発者か
- その他の候補
- コンポーネントで最も活躍する開発者か
- ネットワーク図で関わりを表しても面白そう
RQ4：なぜ優先されるのか（優先度をつける基準は何か）†
不具合†
- 深刻度
- ある単語（セキュリティに関するワードなど）
- 他の不具合修正の阻害をしている（depend onの数）
- すべてのプラットフォーム（OS）に出現する
- プロダクト
- コンポーネント
コード†
- 修正したソースコードがコア部分（もしくはコア機能）
プロジェクト†
- 不具合の報告者が開発者
- とある開発者が関わっている
- たくさんの開発者が注目している(CCの数，コメントの数)
- 報告された日がリリースまでの時間が短い（微妙）
RQ5：(RQ4)で違いがでた値は予測に使えるか†
Eclipse†
RQ1 ：開発者はいつ優先度をつけるか†
RQ2：優先度は誰が付けているか（コアな開発者か）†
- 8割の優先度の変更は半分以下の開発者で行われている
- コアの定義が未定のため保留
RQ3：優先度は守られているか（意味があるか）†
- 修正日数は優先度が高いほど短い
- 修正完了率は優先度が高いほど高い
RQ4：優先度をつける基準は何か†
Discussion†
優先度が予測できるようになると，次のリリースまでにこのプロジェクトが直してくれるかがわかる†
全部の不具合が優先度を変更されていないのはめんどくさいから？†
- さっと直せるものは良いとして，リリース直前のものは，ちゃんとつけるべき
- でも，それが面倒くさいから，優先度をちゃんとつけてないのでは？
- 結局，リリースまでの時間を鑑みて，相対的に付けなければならないから，人間には容易ではない
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
