![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
#author("2018-10-19T02:26:46+09:00","","") #author("2018-10-22T10:16:14+09:00","","") [[柏/ネタ帳/HighPriorityDefect]] *Priority [#k03fbb00] **予測 [#t8d3aa26] ***Predicting Priority of Reported Bugs by Multi-Factor Analysis [#ecba4a4b] -著者 --Yuan Tian, David Lo, and Chengnian Sun -会議 --ICSM13 -概要 --報告者，プロダクト，類似不具合などから取ったメトリクスからプライオリティを予測 ---報告者：過去にどれだけ報告したかや，普段よく付ける優先度の値 ---プロダクト：P１，P2，P3の割合など ---類似不具合：BM25F(cos類似度を応用)を利用して，類似した不具合をもとめ，その優先度の平均値など -結果 --F値の平均は30%程度．P3だけ85% ---⇐P3ばっかり予測してたら，そら当たるのでは？ --一番目に効くのは，プロダクトにおけるP1とかの割合 ---⇐もはや予測していない？あたっているものは偶然に近い ---ちなみに，２番目に効くのは，そのコンポーネントにおけるP1の割合 ***Bug Prioritization to Facilitate Bug Report Triage [#e28cd473] -著者 --Jaweria Kanwal and Onaiza Maqbool -誌名 --JOURNAL OF COMPUTER SCIENCE AND TECHNOLOGY -概要 --不具合の優先度を予測した初のジャーナル --カテゴリカルデータとテキストデータを用いる（アルゴリズムにはSVMとNBを利用） ---カテゴリカル・データには，生データと予測したデータ（開発者と修正時間）を用いる --Recall/Precision以外にNFNとNFPという指標を提案 --NFNとNFPは優先度を低く見積もった場合ペナルティを与える考え方 -結果 --精度はDavid Loの論文より良い？（F値は書かれていないが計算すると0.41ぐらい） --予測したデータを用いるほうが精度が良くなる *** [#v1d0ea36] **分析 [#odb2ebc8] ***hoge [#cebeac03] -著者 -誌名 -概要 -結果 *Severity [#rc6dc724] **予測 [#va9c2c1a] ***Automated Severity Assessment of Software Defect Reports [#qa26162f] -著者 --Tim Menzies and Andrian Marcus -誌名 --ICSM08 -概要 -テキストデータを用いて深刻度を予測 --ストップワード除去，ステミング，tf-idf上位100ワード以外除去，情報利得によるフィルタリングで次元圧縮 --Ripper（決定木の一種）を用いて予測 -結果 -f１値の平均は0.5 --Severity1では，0.71 --Severity2では，0.31 --Severity3では，0.86 --Severity4では，0.14 ***hoge [#nc054940] -著者 -誌名 -概要 -結果 **分析 [#va3d68ce] ***hoge [#z202826b] -著者 -誌名 -概要 -結果 *Others [#ad7f3e2f] **Fixing-time [#xc9a8f69] ***Studying the Fix-Time for Bugs in Large Open Source Projects [#z202826b] -著者 --Lionel Marks, Yung Zou, Ahmed E. Hassan -誌名 --PROMISE'11 -概要 -修正時間を３つのディメンジョンから分析 --バグが含まれている場所 --報告者 --不具合報告内容 -結果 --Firefoxで修正時間で関係あるものは以下の通り +++不具合報告の年度 +++プロダクト名 +++不具合報告の週 +++コンポーネント --Eclipseで修正時間で関係あるものは以下の通り +++深刻度 +++CCの数 +++プロダクトの平均修正時間 --なお，優先度は修正時間と関係ない！ **Re-assignments [#se4aa160] ***An Empirical Study of Bug Report Field Rassignment [#z202826b] -著者 --Xin Xia, David Lo, Ming Wen, Emad Shihab, and Bo Zhou -誌名 --CSMR-WCRE 2014 -概要 --不具合のフィールドのRe-assignmentを調査 -結果 --PriorityとSeverityも頻繁にリアサイメントされる ---特にPrirorityはユーザーが設定するSeverityに基づくから，頻繁に変更されやすい --ガイドラインにPriorityとSeverityの付け方が記載されているが，いつもその通りに付けれるとは限らない ---Netbeans の不具合報告68956では，ガイドラインではPriorityとSeverityが共に普通として設定すべきだが，このアプリケーションによってなにかが壊されるのであれば，それはPriorityとSeverityを高いにすべき *Concept Drift [#hfb1beae] **Fault prone (Module level) [#g09e2932] ***Tracking Concept Drift of Software Projects Using Defect Prediction Quality [#l89adbfe] *バグ予測 [#zd99b9d2] **Concept Drift [#hfb1beae] ***Module level [#e557b5e9] -タイトル --Tracking Concept Drift of Software Projects Using Defect Prediction Quality [#l89adbfe] -著者 --Jayalath Ekanayake, Jonas Tappolet, Harald C. Gall, and Abraham Bernstein -誌名 --MSR09 -概要 --xx --プロジェクトが月日とともに変化していくのに対して，bug predictionへの影響はあるかを調べる --1ヶ月や２ヶ月のデータで予測モデルを構築 -結果 --xx --安定期とドリフト期がある --ヒートマップの赤いところが三角形になっている --オーサーの人数が精度を減少させる **Fault prone (Commit level) [#p9b9189f] ***Are Fix-Inducing Changes a Moving Target? [#f84ffb48] ***コミットレベル [#pd5ff395] -タイトル --Are Fix-Inducing Changes a Moving Target? [#f84ffb48] -著者 --Shane McIntosh and Yasutaka Kamei -誌名 --TSE18 -内容 -概要 --問題点 ---過去に発生するイベントのデータが将来に発生するイベントのデータと同じという仮定でMSRツールが使われていること --結果 ---xx **予測 [#c74f5058] -タイトル --Predicting Fault Incidence Using Software Change History -著者 --T.L. Graves, A.F. Karr, J.S. Marron, and H. Siy -誌名 --TSE00 -概要 --They show that process metrics are better defect features than product metrics like McCabe’s cyclomatic complexity.
