作島 の履歴(No.72)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 作島 へ行く。
  • 1 (2019-03-07 (木) 07:51:48)
  • 2 (2019-03-17 (日) 07:14:58)
  • 3 (2019-04-11 (木) 04:18:51)
  • 4 (2019-04-16 (火) 07:05:51)
  • 5 (2019-04-18 (木) 07:35:51)
  • 6 (2019-04-24 (水) 05:16:23)
  • 7 (2019-04-25 (木) 06:45:53)
  • 8 (2019-04-29 (月) 08:13:40)
  • 9 (2019-05-15 (水) 03:04:04)
  • 10 (2019-05-22 (水) 05:17:54)
  • 11 (2019-06-12 (水) 05:03:06)
  • 12 (2019-07-16 (火) 01:02:57)
  • 13 (2019-07-19 (金) 05:19:40)
  • 14 (2019-07-20 (土) 06:45:05)
  • 15 (2019-07-24 (水) 04:26:44)
  • 16 (2019-07-24 (水) 05:23:37)
  • 17 (2019-07-28 (日) 10:24:02)
  • 18 (2019-07-30 (火) 07:54:33)
  • 19 (2019-07-31 (水) 03:03:53)
  • 20 (2019-07-31 (水) 08:35:34)
  • 21 (2019-08-01 (木) 06:29:55)
  • 22 (2019-08-04 (日) 07:36:36)
  • 23 (2019-08-04 (日) 13:24:26)
  • 24 (2019-08-05 (月) 06:56:14)
  • 25 (2019-08-07 (水) 07:21:44)
  • 26 (2019-08-15 (木) 07:55:28)
  • 27 (2019-08-19 (月) 09:40:10)
  • 28 (2019-08-20 (火) 08:08:19)
  • 29 (2019-08-21 (水) 05:21:59)
  • 30 (2019-09-03 (火) 04:34:32)
  • 31 (2019-09-05 (木) 07:43:19)
  • 32 (2019-09-10 (火) 07:10:17)
  • 33 (2019-09-18 (水) 05:37:18)
  • 34 (2019-09-24 (火) 04:21:20)
  • 35 (2019-09-27 (金) 03:17:50)
  • 36 (2019-09-29 (日) 09:20:57)
  • 37 (2019-09-29 (日) 16:10:41)
  • 38 (2019-10-02 (水) 07:17:25)
  • 39 (2019-10-05 (土) 08:14:03)
  • 40 (2019-10-07 (月) 02:43:35)
  • 41 (2019-10-13 (日) 10:20:26)
  • 42 (2019-10-14 (月) 09:03:02)
  • 43 (2019-10-15 (火) 03:06:45)
  • 44 (2019-10-16 (水) 06:31:51)
  • 45 (2019-10-18 (金) 07:45:33)
  • 46 (2019-10-23 (水) 00:41:24)
  • 47 (2019-10-23 (水) 07:40:42)
  • 48 (2019-10-29 (火) 23:28:40)
  • 49 (2019-10-30 (水) 15:39:27)
  • 50 (2019-10-31 (木) 01:53:02)
  • 51 (2019-11-04 (月) 00:10:38)
  • 52 (2019-11-05 (火) 08:13:36)
  • 53 (2019-11-06 (水) 04:04:02)
  • 54 (2019-11-10 (日) 08:25:06)
  • 55 (2019-11-26 (火) 06:14:22)
  • 56 (2019-11-26 (火) 08:30:22)
  • 57 (2019-12-03 (火) 08:04:06)
  • 58 (2019-12-05 (木) 05:49:11)
  • 59 (2019-12-06 (金) 00:23:08)
  • 60 (2019-12-06 (金) 05:33:09)
  • 61 (2019-12-11 (水) 09:05:34)
  • 62 (2019-12-12 (木) 02:29:33)
  • 63 (2019-12-16 (月) 05:47:08)
  • 64 (2019-12-21 (土) 04:53:43)
  • 65 (2019-12-22 (日) 08:36:54)
  • 66 (2019-12-24 (火) 02:43:52)
  • 67 (2020-01-15 (水) 02:03:25)
  • 68 (2020-01-23 (木) 02:33:46)
  • 69 (2020-02-24 (月) 07:07:48)
  • 70 (2020-03-16 (月) 06:22:08)
  • 71 (2020-04-09 (木) 11:30:35)
  • 72 (2020-10-05 (月) 16:24:13)

---

Memo†

• 研究テンプレート
  
  • https://docs.google.com/spreadsheets/d/1yvgRGxTOrHRpvd1xt3etVEwwVunkwxjAt0t8HjttxW0/edit?usp=sharing
    
• 論文検索；ACM
  • https://dl.acm.org/

Link†

• 作島/task/task_01
• 作島/task/task_02
• 作島/メモ
• 作島/研究テーマ
• 作島/考え
• 作島/輪講

作島/研究テーマ

時間割†

Meeting†

4/ 16†

DONE†

TODO†

4/9†

DONE†

• Continue Deployment の紹介論文を読んだ

TODO†

論文を読むよりも，まず用語をおさえる．

• 体系的に学習するために本を購入し，スライドにまとめる

2/26 テーマ練り会†

• management規格が存在するのでどのリスクをマネージメントしたいのかをそれをみて考えて絞り込む
  • PMBOK，SWBOK，KPIなど
• プロジェクトや開発者にかかっている負荷を可視化できる指標を提案する

• デスマーチ（death march）
  システム開発現場の過酷な労働環境を表す言葉．
  人員不足，短すぎる開発期間，予算不足，ユーザからの過剰な要求などの悪条件が重なり，開発チームが過度のオーバーワークや疲弊状態に陥った状態

2/21†

卒論の修正内容の確認

• 研究の根拠はなになのか．
  • 報告回数，スタックトレース，共同回数で開発者群を分割しているがそれが適切だと考える理由が記載されていない
  • 多くの要因が考えられる中，その3つを選択しなぜそれが妥当であるのかの説明がない

1/ 23†

考察を思案中

• JDTとPlatformを比較する必要はない
• あるコンポーネントでは修正時間が関わっているかも
  • 一つのコンポーネントが足を引っ張っていてコンポーネント数が多いPlatformは影響が薄いが，JDTには影響が大きいかも
  • まずJDTの各コンポーネントにおいて修正時間を算出してみるといいかも

1/ 15†

• パターン4の箱ひげ図の上と下が含まれる結果になる要因を明らかにできたらOK
• 縦軸を対数変換するとクラスタリングがいい感じになると思う
• 関わった回数が多い集団と少ない集団の代表者を見つけて，修正時間，重要度の推移を考察する
• 重要度や優先順位などは手動で行うため，分析に有用かどうかがわからん
• コンポーネントごとに分析するといいかも(UIとかは簡単な修正な感じがするが)

12/ 26†

• 調査結果を出す
• x軸割り当て時間，y軸修正時間のグラフ出す
• モチベーションがなにかを明確にする

DONE†

• 2章レビュー提出 (12/23)
• 研究のモチベーション
  • 不具合パターンで他の開発者に修正を依頼する際に障壁となる要因を明らかにしたい．

先行研究のデータ(2007年1月→2009年12月)で出た結果を自分が使っているデータ(2001年10月→2017年12月)で再現できるのかを確認．

• 前処理
  • 再割当なし
  • reopenなし
  • FIXEDのみ限定
  • 修正時間を assigned_date → fixed_date から assigned_date → modified_date までへと変更
    
  • assigned_dateとmodified_dateが全く同じ時間であるときは適切に記入できていないとみなし削除
    fixed_dateは，よくわからない． modified_dateは，最終ラベルが貼られたときの時間を指す．

上記でやる場合，再割当も再修正もないため，割り当てられてから最終変更点までの時間を修正時間と考えることができる．

RQ1 : 先行研究の不具合管理パターンのデータ割合や修正時間が，調査範囲を広げるとどうなるのか．(先行研究の再現)
RQ2: 分担解決型において修正時間に影響を与える要因を調査する．

RQ1より分担解決型のみではなく，修正委託型にも同様の結果が見られるのでこの両者についてRQ2で分析を行う．

RQ2:いままで管理者と修正者が関わった回数が修正時間に影響を与えるのか
　　　分担解決型，修正委託型，その両者

12/ 17†

TODO†

• 卒論2,3章書く．
• 共同開発実績の回数のデータを出す．
• スタックトレースとかを抽出するスクリプトを作る．

DONE†

• 卒論2,3章を書き，レビューをしてもらった(次回締め切り 12/23)
• RQ1-1の結果を出した．

12/ 12†

ストーリー†

先行研究で不具合管理パターンが修正時間に影響を与えていることが明らかになるが原因については触れられていない

先行研究でパターン4にて修正時間が長い集団と短い集団が存在することがわかった

パターン4にて修正時間が長い集団を短い集団にしたい

先行研究で触れられていない + 修正時間を短くしたい
→　パターン4にて修正時間が短い要因 or 長い要因を見つけることで実現

不具合修正を短くするためには効率的な不具合管理プロセスが必要

効率的な不具合管理プロセス：報告者が不具合の詳細を管理者に報告することができる + 不具合報告に基づいて適任の開発者に割り当てることができている

パターン4のみ上記の2つの要素が関わっている．
・パターン1,2：報告不要
・パターン1,3：割り当て不要

上記の2つがパターン4の修正時間に大きく関わっているのでは？？(仮説)
・報告に慣れている必要がある，報告で詳細を伝えることができる
・適切に割り当てるためには管理者が修正者のことを熟知している必要がある

報告の慣れ → 報告回数
報告で詳細を伝えられている → 報告の際に，再現方法，スタックトレース，テストケースがしっかり記載されている
修正者を熟知しているか→ いままでプロジェクト内で関わった回数

RQ1 : 報告者が適切に報告できているかどうか(What makes a good bug report? ではCUEZILLAを使用していたが。。 )
・1-1：報告回数が多い開発者は少ない開発者よりも修正時間が短いか
・1-2：再現方法，スタックトレース，テストケースの記載の有無
RQ2 : 管理者が修正者のことを熟知しているかどうか

パターン4の修正時間が短い集団と長い集団で比較

不具合の概要を伝えられているか否かをなにで評価するか†

• 再現方法の記載の有無
• 報告回数 ( 報告に慣れているかどうか )
• スタックトレース( エラーが発生した時に表示される内容 )の有無( キーワード検索 )
• テストケースの有無 ( コードの有無 → 目視 )
• スクリーンショットの有無 ( 添付画像の有無で取得 → 目視 )
• 文字数

親密度を他の言葉で†

• 協調作業
• 共同作業実績

12/ 6†

DONE†

• 研究ストーリーを考えた．

TODO†

• 親密度がなぜでてくるのかが書けていない．
  

4つのパターンで不具合管理プロセスが運用されていて，全てのパターンで効率的に運用されることが期待されている．
プロセスを円滑に進めるためには，主に2つが重要である．
1つ目は，RT間では適切な不具合報告がなされているかどうかである．

2つ目は，TF間では当該不具合の修正に適切な修正者に割り当てられているのかである．
適切な修正者に割り当てるためには割当者が修正者のことを熟知していることが必要である．そのため熟知しているかどうかをいままでの開発プロセスにおいて共同作業をした回数を評価の指標として使用する．

• 親密度の言い方を変えたほうがいい．
• なにに注目すれば報告者が不具合の概要を適切に伝えられるのかを決める．
  • what makes a good bug report?
  • 報告者：報告回数25回以上，修正担当記録なしのエンドユーザ
  • 修正者：修正回数50以上

• 適切な報告されていないが，割当者と修正者間で親密度が高い時，修正時間が短くなるのではないか＜伝わってこない報告なのに修正時間が短くなるなんて論理的におかしくない？？

ストーリー†

不具合管理プロセスにはR=T=F，R=T≠F，R≠T=F，R≠T≠Fの4つのパターンがあり，それぞれパターン1，パターン2，パターン3，パターン4と呼称する．
上記のパターンが不具合修正時間に影響を与えることが先行研究で示されており，パターン4が他のパターンよりも修正時間が長い結果になっていた．
しかし，修正時間が最も長いパターン4に他のパターンと同程度の修正時間が短い集団が存在していた．
そこでパターン4で2つの集団が存在する理由があり，その理由を解明することで不具合管理プロセスをより効率化できると考えた．

本研究は，パターン4において修正時間が長い集団の修正時間を短くすることを目指す．
修正時間を短くするためには円滑な不具合管理プロセスが必要であり、それを実現するための必要な要因を調査する．
パターン4の修正時間に関わる要因を調査することで一つあたりの修正時間を削減し，より多くの不具合を修正することを可能とする．

パターン1,2は発見した不具合を報告する必要がない．そのため報告が適切に行われているかが関係していない．
パターン1,3は報告された修正を他の開発者に割り当てることが行われない．そのため割り当てが適切に行われているかが修正時間に影響がない．
パターン4において報告が適切に行われているか、と適切な割り当てができているかの2つの要因が修正時間に関わっている．

RT間においては適切に不具合の概要が伝わっているのかが大切
→概要を正確に伝えるためには報告するべき箇所を理解している必要がある
→報告するべき点を理解するには多くの報告を経験する必要がある
→報告に慣れている開発者が報告した場合と慣れていない開発者が報告した場合とで差があるのではないか
→報告回数に注目

TF間においては適切な修正者に割り当てることができてるかが大切→TF間の開発者間の関係性に注目

• 親密度
  • 割り当て者と修正者の親密度が高い場合，短い場合よりも修正時間が短い。
  • 互いを熟知している間柄であれば修正時間が短くなる

• 報告者の練度
  • 報告者として報告回数が多いほど、修正時間が短い
  • 報告することに慣れており，修正者がスムーズに修正することができる

• 報告者の練度とTF間の親密度の関係
  • 報告者が報告慣れしていなくても，親密度が高ければ修正時間が短いのでは？
  • 親密度が高くなくても，報告者が報告慣れしていれば修正時間が短いのでは？

FOSE†

• 修正者がどの行を変更しているのかがわかれば，作った人が修正しているなどがわかって面白い研究に繋がりそう
• 報告者に関して
  • 報告者がエンドユーザなのか，開発者なのかで差
  • 報告者が報告慣れしている場合とそうでないの差
  • 親密度で差を図る際に，親密度は高くないが報告者が報告慣れしているので実際は早くいっているケースがあるのではないか
• OSSではわからないが，業務の際に締め切りを早めに設ける人とそうでない人がいて，それが関係しているかもね
• 報告とか割り当ての際のテンプレを作るといいのかもしれない
• 同時期に抱えてるタスクが関係している
  • 修正者が抱えているタスクが多い
  • 普段は割り当て，修正者を自身で行なっているが，抱えているタスクが多く修正を他人に任しているケースは修正するまでの時間がかかっているのではないか．
• 考えられることが多くて目的を見失いやすそう

11/ 26†

• パターン4のみにしかいえない特徴に注目
• リーダーはすべてのパターンに言えるから論理的に矛盾している

親密度†

• 割当者と修正者とのペアの回数が多い
  • 多い場合と短い場合で比較
  • いろんなコンポーネントを担当するが遅い
  • 1つのコンポーネントしか担当しないが短い
• Aが見つけてAが割り当てるという場合と
  誰かわからない人からの報告を割り当てる場合とは違う．

リーダー†

• 修正リーダー・修正時間に着目する
• 修正リーダー：コンポーネント単位の不具合において最も修正担当の割合が多い開発者
  (関わっている年月が最も長い人物・両方でみてもいいかも)

• RQ1 : 修正リーダーの割合は？
  • 各リーダーが全体の何割を占めているのかを知るため

• RQ2 : 修正リーダーは他の開発者よりも修正時間が短いのか
  • 短い場合 -要因-
    ・ コンポーネントを熟知している (修正リーダーが創立者，関わっている年月が長い)
    ・ 修正リーダーのスキルが高い (修正パッチが再修正になることが少ない)
    ・ 重要度，優先度が高い修正依頼が多い(急かされている)
    

• 長い場合 -逆の要因-
  ・ 修正リーダーに修正困難な不具合が修正するため (Reopenedの不具合で評価)
  ・ 同時期に複数の修正依頼を抱えていることが多いため
  

• 有意差なし -どうして差がないのか-
  ・修正リーダーがリーダーではない(修正回数でリーダーを定義するのがよくない)
  ・修正リーダーのスキルが同程度 (修正パッチが再修正になる頻度)
  

11/ 20†

• 要因だけでは広義だから，「？？」の要因を調査するというふうに狭めて考える
• ストーリーがないといけない
  • 有意差がでればOK，でなければダメ，という仮説ではいけない

11/ 14†

• スライドの流れ
  OSS開発において日々多くの不具合報告がなされている．
  利用するにあたって必要な箇所がいつ修正されるのかを知りたい
  不具合修正の時間を予測する必要がある．
  予測するツールがさまざまある
  精度向上に関する研究が多くなされているがまだ不十分
  精度向上を目指す→ 説明変数になる要因を探す．
  

• 修正時間はR≠T≠Fが最も時間がかかる要因は未解明
• 予測の精度は低い

11/ 5†

• モジュールごとに長がいるかもしれない
  • 専門知識が必要でそれを修正できるひとが限られるからとか

• 修正時間が短い集合と長い集合から組み合わせを抽出する
  • 最終的に比較するからこの集団を使う
  • 中央値より短いか長いかで集団を区切る

• 状況を理解する必要がある．仮説を細かく考える必要がある．
  • 研究発表のスライドを作る

• 修正時間が負の場合も削除する必要はない
  • 他のデータが100日単位でずれていたりなど，見えていないデータもずれがある可能性がある
  • 不適切なデータで見えている分を削除したくなるが他のデータは完全に正しいとは言えない

TODO†

• 研究発表のスライドを作る
• 短い集団と長い集団の取り方を修正する
• システマチックに仮説を立てる

10/ 31~†

REPORT†

• 進捗報告.key
• 進捗報告.pdf

TODO†

• 修正時間をプロットする
• 仮説と前処理がうまいこと噛み合ってない気もする
  • 修正時間が短い場合と修正時間が長い集団を抽出して，そのなかで回数をみるとか
• 3543件→17件にしたが，削除した組み合わせと比較するしたい
  • 17件の各修正時間(箱ひげ図)と削除した組み合わせの修正時間の平均を出す

10/ 23~†

• 割り当て者と修正者の関係のほかに，報告者と割り当て者の関係もみる
• 分布をみて明らかに割り当て回数が少ないのは重要なデータではないので削除する
  →分布から見て100件以上でフィルタリングを行う，で良い．
• 自分以外の割り当ての多い開発者に注目する，という認識でOK
  • 数値的な閾値は考える必要がある

10/ 23†

TODO†

• 割り当て者の分布を算出する
• 全ての工程が違う開発者の場合の修正時間を短縮したい
  →親密度の高い人同士なら早いのではという仮説
  →親密度を割当率でやっていた
  →率ではなくて数でやったほうがいいのではないか

DONE†

• 前処理
  • assigner, assigneeの文字列に[ indox, eclipse, php, platform ] を含む列を除外
• 割り当て者の分布算出

• 結果
  • eclipseプロジェクトにおける割り当て者：21323人，割り当て数：234960件
    割り当ての80％を担当している割り当て者：1760人
  • 報告.pdf

10/15†

• assigner : 譲渡人(割り当てる人)
• assignee : 譲り受け人(修正者)

DONE†

• 前処理を丁寧にした
  • プロジェクトをeclipseに限定
  • Noneや空白を除外
  • メールアドレスに@がない，.orgがあるものを除外
  • 割当者と修正者が同一人物であるものを除外

• [求める結果]
  • 上位割当者に割り当てられている修正者が共通して1人以上いる
  • 明らかに割り当てられている割合が大きい開発者がいる

• [ぱっと見わかったこと]
  • 10%以上割り当てられている開発者が3名
    • Erich Gamma(2)，Martin Aeschlimann(2)，Dirk Baeumer(1)
  • 10名の内訳に多く存在する開発者
    • Erich Gamma(7)，Tod Creasey(6)，Olivier Thomann(5)，
    • Martin Aeschlimann(4),Dirk Baeumer(2)

TODO†

• Erich Gamma は eclipseの創立者だからその人しか直せない場合がある(親密であるとは言えない)
• データ分布がわからないと分析，議論できない
  • 上位10人がデータ分布の８割を占めるなどの根拠がないといけない．
• もともとある仮説を元に分析しているのでそれが当てはまっていなければその仮説が妥当ではなかったというだけ
  • 全ての工程が違う開発者の場合の修正時間を短縮したい
    →親密度の高い人同士なら早いのではという仮説
    →親密度を割当率でやっていた
    →率ではなくて数でやったほうがいいのではないか．分布がわからない以上，議論ができない．
• 組織を削除する処理が雑
  →eclipseから割り当てられているメールアドレスならorgがつくから．

10/7†

ADVICE†

• データ設計が8割
• 自分の見たいデータのみにすることがまず大事
  • 自分が報告して自分で修正している人の割合を見るとがっかりするが自分が見たいデータではない
  • 人が人に割り当てていることに着目するべきでBotが割り当てているのは自分がみたいデータではない
• 未加工のデータ知る

TODO†

• 一つのプロジェクトにのみ着目する
  • [eclipse]
• 割当者が組織であるケースを削除
• 自分が自分に割り当てているケースを削除
• 結果を見る際に期待している結果とどの程度差異があるのか
  • [求める結果を書く]
• 自分が扱っているデータがなにかをよく知る

DONE†

10/1†

DONE†

• assignee_nameがunknownでもメールアドレスがわかっている場合は考慮するべきか．
• プロジェクトごとの割当数