柏/ネタ帳/HighImapctBug の履歴(No.11)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 柏/ネタ帳/HighImapctBug へ行く。
  • 1 (2017-04-29 (土) 05:55:37)
  • 2 (2017-05-02 (火) 05:34:30)
  • 3 (2017-05-02 (火) 07:04:28)
  • 4 (2017-05-09 (火) 08:55:39)
  • 5 (2017-05-10 (水) 04:24:16)
  • 6 (2017-05-10 (水) 07:13:45)
  • 7 (2017-05-17 (水) 06:22:34)
  • 8 (2017-05-24 (水) 22:24:24)
  • 9 (2017-07-24 (月) 12:53:22)
  • 10 (2017-10-25 (水) 02:08:02)
  • 11 (2017-11-01 (水) 12:45:00)

---

柏

Memo†

1. 目視・タグづけ
2. キーワード抽出・特徴抽出（優先度など）
3. データ規模拡大
4. 特徴抽出（変更部位なども含む）⇦これ大丈夫？
5. 予測（変更部位などは含まない．報告された時点でわかるもの）

定義†

ユーザー離れを起こす不具合
インパクト=ダメージ/コスト
経済効果的なところを参考にする (ドメイン大事)

Stage I†

不具合の目視4000件　2014/5--2015

Stage II†

High impact on XXXX
開発者へのアンケート 2017/5--2017/10

1. 分類（KJ法的な？）
   1. 原因と結果を明確に
   2. 開発者は原因を嫌がる？結果を嫌がる？

• アンケートの回答によって得られた結果を分類
  • 規格による分類
    • ISO/IEC 9126 [添付]
      ソフトウェア品質に関する分類（品質特性モデル）
      http://etc9.hatenablog.com/entry/20121129/1356526435

• IEEE std 10441044_2009.pdf
• IEEE std 1044.1

• Texの著者による分類ハ?ク?の種類.pdf
• 保守の観点による分類（吉行氏）
  • 適応保守 (adaptive maintenance)
    変化した又は変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の引渡し後の修正。
  • 是正保守 (corrective maintenance)
    発見された問題を訂正するために行うソフトウェア製品の引渡し後の受身の修正。いわゆるバグ修正。
  • 緊急保守 (emergency maintenance)
    是正保守実施までシステム運用を確保するための、計画外で行われる一時的な修正。
  • 完全化保守 (perfective maintenance)
    潜在的な欠陥が故障として現れる前に検出し訂正するために行う、引渡し後のソフトウェア製品の修正。
  • 予防保守 (preventive maintenance)
    引渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し、是正を行うための修正。

• Orthogonal Defect Classification
• ボーリス・バイザーの分類

• TODO

1. ミスラベルの論文を読む(DONE)
2. ISOの分類を調べる(DONE)
3. 不具合を読んでみる(5%)

• 調べてみたいこと
  • HIBは修正量が多いか
  • HIBは主要箇所か
  • HIBはユーザーに影響を与えるものか
  • 開発者がHIBと言ったものと類似するものを探し，他の人もそう感じるか

章立て†

バグは開発者に本当にインパクトを与えているのか（動機付けになっているか？）
2章：どんな種類か
3章：定量的に測る（どんなアクションか）
2章を元にサンプリングし，多くのバグで確認

1. 報告されてからアサインまでの時間
2. 報告されてから議論開始までの時間
3. 炎上指数など

良いフレーズ†

• Post-mortem analysis of bugs for understanding various characteristics of various bugs can have many benefits. It can provide knowledge for guiding the design of bug detection tools, triaging bug reports, locating likely bug locations, suggesting possible fixies, gauging testing and debugging costs, measuring software quality, and helping to monitor and manage development processes.
• To better understand the nature of bugs and potentially help to prevent, resolve, mitigate, or manage such bugs, this paper performs an exploratory study of real bugs.
• We believe our analysis of the bugs would provide guidance for preventing, detecting mitigating, resolving, and managing bugs in systems.

備考†

• 定性的なところをNIERに先に出す？
• サンプリングが妥当であるかを確認
• ドメインが違うことを証明

Stage III†

インパクトを数式化？

TODO†

1. アンケートの目視
2. まとめる