おおさわ/修士論文
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
]
開始行:
[[おおさわ]]
* 修士論文 [#ad6e2f38]
#contents
* 章構成 [#t7289b3d]
- はじめに
-- 研究の背景
--- OSSが流行っている
--- OSSに関わる人も多くなってきている
--- 不具合修正にも多くの時間が費やされている
--- Bug Triage(不具合の判定,修正担当者の決定)はman power...
-- 目的
--- 修正時間を短くすること(大目的)
--- assign の方法を分析する(中目的)
--- best effort になっていないか?
--- どんなパターンが効率的か?
-- 論文の構成
- OSSにおける不具合修正に関して
-- 不具合修正の手順
--- 不具合修正がどのようなプロセスで行われるのか
--- どういった人が絡んでくるのか
-- Reporter、Assignor と Resolver の関係(type分け)
--- 特にAssignee(Assign To)に着目した理由
--- Reporter、Assignor と Resolver の関係について
--- type1:A(a)→A
--- type2:A(a)→B
--- type3:A(B)→B
--- type4:A(B)→C
- 分析方法
-- データの取得、整形
--- BTSからのデータ取得
- ケーススタディ
-- 対象プロジェクト
--- 対象とした不具合報告(Resolution:fixed -> なんらかの...
-- 基本統計量
--- プロジェクト毎の開発者,Assignorの分布
--- タイプ毎の修正時間について(タイプ間の差)
- 考察
- 関連研究 z:Zimmermann s:Sunghum Kim
-- 不具合報告に関する研究
--- what makes a good bug report ? (z)
--- quality of of bug reports in eclipse (z)
--- extracting structural information from bug reports (z...
--- towards the next generation of bug tracking systems (z)
--- modeling bug report quality
--- duplicate bug reports considered harmful ... really (...
--- information needs in bug reports: improving cooperati...
--- a linguistic analysis of how people describe software...
--- do stack traces help developers fix bug ?
-- 修正時間予測に関する研究
--- how long will it take to fix this bug ? (z)
--- predicting eclipse bug lifetimes
-- OSS開発における人的に関する研究
--- latent social structure in open source project
--- who should fix this bug ?
--- automatic bug triage using text categorization
--- improving bug triage with bug tossing graph (z,s)
- 結論
- 謝辞
- 参考文献
* 対象プロジェクト [#o70e3afb]
- Eclipse
- Mozilla
- Apache
- OpenOffice
- LinuxKernel
* 参考文献 [#z818aacb]
* スケジュール [#xc1cec79]
- 章構成作成
-- 〜12月3日
- 第一段階分析完了
-- 〜12/10
- 原稿執筆
* 年末報告会の質疑応答から [#ddb1db17]
** 研究内容について [#u91a6588]
- プライオリティで分けた方が良い
-- 優先度と高いのと低いのが一緒なのはおかしい(低いのだけ...
- 会社の仕事でやっている人もいるので,それを考慮すべき
-- Eclipse:IBM,Linux:RedHat
- 誰からAssignされたかが重要ではないのか
- プロジェクトを増やすより,特定のプロジェクトで深く分析...
-- Eclipseに着目してみるとか
- 予備分析は分析の1つとして言っても構わないのではないか
-- RQ1としてしまっても問題ないと思う
-- 他のRQが予備分析をやった上で立ててるのなら今のままで良...
- A-B-A型を考慮すべき
-- 考慮しないならその理由をちゃんとすべき
-- 頼まれているという観点から考慮すべきてはないか
** 発表について [#sea27696]
- 全体にまとまりがない
-- どこを重点的に言いたいのかをはっきりさせる
-- 『オリジナルな部分はここです』とはっきり言う
- トリアージの用法はそれであってるのか
* めも [#k6e2fb1f]
#comment
終了行:
[[おおさわ]]
* 修士論文 [#ad6e2f38]
#contents
* 章構成 [#t7289b3d]
- はじめに
-- 研究の背景
--- OSSが流行っている
--- OSSに関わる人も多くなってきている
--- 不具合修正にも多くの時間が費やされている
--- Bug Triage(不具合の判定,修正担当者の決定)はman power...
-- 目的
--- 修正時間を短くすること(大目的)
--- assign の方法を分析する(中目的)
--- best effort になっていないか?
--- どんなパターンが効率的か?
-- 論文の構成
- OSSにおける不具合修正に関して
-- 不具合修正の手順
--- 不具合修正がどのようなプロセスで行われるのか
--- どういった人が絡んでくるのか
-- Reporter、Assignor と Resolver の関係(type分け)
--- 特にAssignee(Assign To)に着目した理由
--- Reporter、Assignor と Resolver の関係について
--- type1:A(a)→A
--- type2:A(a)→B
--- type3:A(B)→B
--- type4:A(B)→C
- 分析方法
-- データの取得、整形
--- BTSからのデータ取得
- ケーススタディ
-- 対象プロジェクト
--- 対象とした不具合報告(Resolution:fixed -> なんらかの...
-- 基本統計量
--- プロジェクト毎の開発者,Assignorの分布
--- タイプ毎の修正時間について(タイプ間の差)
- 考察
- 関連研究 z:Zimmermann s:Sunghum Kim
-- 不具合報告に関する研究
--- what makes a good bug report ? (z)
--- quality of of bug reports in eclipse (z)
--- extracting structural information from bug reports (z...
--- towards the next generation of bug tracking systems (z)
--- modeling bug report quality
--- duplicate bug reports considered harmful ... really (...
--- information needs in bug reports: improving cooperati...
--- a linguistic analysis of how people describe software...
--- do stack traces help developers fix bug ?
-- 修正時間予測に関する研究
--- how long will it take to fix this bug ? (z)
--- predicting eclipse bug lifetimes
-- OSS開発における人的に関する研究
--- latent social structure in open source project
--- who should fix this bug ?
--- automatic bug triage using text categorization
--- improving bug triage with bug tossing graph (z,s)
- 結論
- 謝辞
- 参考文献
* 対象プロジェクト [#o70e3afb]
- Eclipse
- Mozilla
- Apache
- OpenOffice
- LinuxKernel
* 参考文献 [#z818aacb]
* スケジュール [#xc1cec79]
- 章構成作成
-- 〜12月3日
- 第一段階分析完了
-- 〜12/10
- 原稿執筆
* 年末報告会の質疑応答から [#ddb1db17]
** 研究内容について [#u91a6588]
- プライオリティで分けた方が良い
-- 優先度と高いのと低いのが一緒なのはおかしい(低いのだけ...
- 会社の仕事でやっている人もいるので,それを考慮すべき
-- Eclipse:IBM,Linux:RedHat
- 誰からAssignされたかが重要ではないのか
- プロジェクトを増やすより,特定のプロジェクトで深く分析...
-- Eclipseに着目してみるとか
- 予備分析は分析の1つとして言っても構わないのではないか
-- RQ1としてしまっても問題ないと思う
-- 他のRQが予備分析をやった上で立ててるのなら今のままで良...
- A-B-A型を考慮すべき
-- 考慮しないならその理由をちゃんとすべき
-- 頼まれているという観点から考慮すべきてはないか
** 発表について [#sea27696]
- 全体にまとまりがない
-- どこを重点的に言いたいのかをはっきりさせる
-- 『オリジナルな部分はここです』とはっきり言う
- トリアージの用法はそれであってるのか
* めも [#k6e2fb1f]
#comment
ページ名: