ソフトウェア・シンポジウム 2015 in 和歌山

Blocking Bug の発生原因を理解するための依存関係分析
金城 清史
株式会社サイバーリンクス
k-kinjo@cyber-l.co.jp

山谷 陽亮
和歌山大学 システム工学研究科
s151049@sys.wakayama-u.ac.jp

松本 明
和歌山大学 システム工学研究科
s151045@sys.wakayama-u.ac.jp

大平 雅雄
和歌山大学 システム工学部
masao@sys.wakayama-u.ac.jp

要旨

先行研究の多くは不具合修正作業および管理プロセスの効率化を目的とするものの，個々の不具合の特徴や影影響の大きい不具合の１つとして Blocking Bug があ

響範囲を十分に考慮したものではない．しかし，1 つのる．Blocking Bug とは他の不具合の修正を妨害する不具

不具合がシステム全体の挙動を不安定にさせたり，場合合のことである．先行研究では Blocking Bug の特徴を

によっては致命的なエラーにつながることもあるため，明らかにしている．しかし，発生の原因を分析したもの

重大な問題を招く可能性のある不具合を考慮することがではない．本論文では Blocking Bug の早期発見，発生重要である．

の予防を目的として，Blocking Bug の実態把握と発生

これまでの反省もあり，特に最近では，個々の不具合が原因を理解するための分析をおこなった．分析の結果，ユーザの満足度や開発スケジュールの変更などに与える

Blocking Bug は通常の不具合に比べて修正のために変影響の大きさを考慮する研究が増えている．保守プロセ

更するファイルが多いことや，多くのファイルに参照さスに充てられるコストやリソースには限りがあり，全てれていると Blocking Bug の発生の原因になることを明の不具合を同等に扱うのではなく，High Impact Bug[8]らかにした．

と呼ばれる影響度の大きな不具合 [9, 10, 11] を優先的に修正することの必要性が認識され始めたためである．

High Impact Bug の内，本研究では特に，Blocking

1. はじめにBug[12] を対象にする．Blocking Bug とは，他の不具合修正を妨害する不具合である．Blocking Bug が修正されない限り，関連する他の不具合 (Blocked Bug) も修正

ソフトウェア開発では，ソフトウェア保守に要するコストがソフトウェアライフサイクル全体に要するコストすることができないため，Blocking Bug は優先的に修の大半を占めることが知られている [1, 2]．そのため，ソ正されるべき不具合であるとされている．

フトウェア保守の改善支援を目的とする研究が盛んにおGarcia ら [12] の研究では，新たに報告された不具合
が Blocking Bug かどうかを予測するモデルを提案しているが，Blocking Bug が生じる原因や予防する方法に

こなわれてきた．特に，Mining Software Repositories(MSR) 分野では，主に不具合管理システムに蓄積された不具合データの解析結果に基づいて，不具合修正および不具合管理プロセスを支援する手法が提案されている．

ついては述べられていない．そのため，本研究では，不具合報告の依存関係，モジュールの依存関係，開発者の例えば，不具合修正タスクの最適割り当てを支援する手依存関係といった Blocking Bug の発生原因となり得る

法 [3] や不具合修正タスクの優先順位や重要度を推定す

依存関係を分析し，Blocking Bug の早期修正と予防をる手法 [4, 5] ，重複して報告された不具合を検出する手支援するための知見を得ることを目的とする．

法 [6, 7] などが挙げられる．

89

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

2. 修正活動における Blocking Bug の問題点

アの品質を改善（あるいは維持）することができない可能性がある．これら Blocking Bug の問題を，図 1 を用いて整理する．

2.1. Blocking Bug 定義!"#$%

Blocking Bug とは，他の不具合修正を妨害する不具!"#&%
blocks!

合である．例えば図 1 に示すように不具合 A および不具合 B が存在する状況を考える．不具合 A は不具合 Bt!

を修正しないとTfind_blocking!

不具合管理システムに報告された不具合が Blocking

Bug であることが判明した場合，Blocking Bug と不具

Tfix_blocking!

Tfix_blocked!

Tfix_blocking_set!

合修正を妨害されている側の不具合 (Blocked Bug) との間に関連付けがおこなわれる．この際，不具合管理システ

図 1. 不具合修正を阻害する Blocking Bug

ムでは，二つの不具合間の関連付けのために，Blocking

Bug の内容が記述された不具合報告には “blocks” というタグが付与される．同様に，Blocked Bug の内容が記報告された不具合 A は，不具合 B によって修正を妨害されており，不具合 B が先に修正されない限り不具合述された不具合報告には “is blocked by” というタグがA を修正することができない状態にある．つまり，不具合 A が甚大な影響を与える不具合であっても，不具合 Bが修正されない限り不具合 A を修正することができな付与される．なお，タグ付けは自動的におこなわれるのではなく，不具合管理システムの管理者らによっておこなわれる．

い．したがって，不具合 A を修正するには，本来必要な多くの不具合管理システムには，不具合修正に際し

時間 (Tf ix blocked ) よりも多くの時間 (Tf ix blocking set )て依存関係のある不具合同士を関連付けて管理するたが必要となる．不具合修正の遅延は顧客満足度の低下にめの機能が備わっている．本研究では，依存関係のある

繋がるため，できるだけ早く Blocking Bug を検出する

Blocking Bug と Blocked Bug のことを Blocking Set と必要がある．

呼ぶこととする．また，ソフトウェアの不具合は，複数

しかしながら，不具合 A の担当者は不具合 B を修正のファイルが関連しあって 1 つの不具合の症状として現するためのコードやモジュールについて熟知しているとれる場合や，1 つのファイルが原因となって複数の不具合は限らず，不具合 B，すなわち，Blocking Bug の検出自の症状を引き起こす場合があり得るが，本研究では，1 件

体に時間 (Tf ind blocking ) がかかってしまう場合もある．

の不具合報告に記録された症状を 1 つの不具合として取また，Blocking Bug である不具合 B を検出できたとしり扱う．したがって，本論文中で特に断りなく Blockingても，不具合 A と不具合 B の担当者が異なる場合は互Bug という用語を使う場合は，不具合報告に記載された

いに情報交換しながら修正作業をおこなう必要があるた

Blocking Bug の症状，あるいは，不具合報告そのものを指すこととする．

め，通常の不具合よりも多くの時間 (Tf ix blocking ) を必要とする．実際，6 つのオープンソースプロジェクトを対象とした Garcia らの研究 [12] では，Blocking Bug は，2.2. 問題点

非 Blocking Bug (Blocking Bug 以外の不具合）に比べBlocking Bug を予測するための Garcia ら [12] の研究

15–40 日程度の修正時間が長くなるとされている．なお，

では，いくつかのオープンソースプロジェクトを対象とない不具合（非 Blocking Bug）よりも多くの修正時間

Blocking Bug が検出されるまでの時間 (Tf ind blocking )は短い場合もあれば長い場合もあり (3–18 日)，プロジェ
クト毎に傾向は異なる．プロダクトの複雑度やコンポーを必要とすることが示されている．リリース直前やプロネント間の結合度に関連があるように思われる．Garcia

ジェクトの繁忙期であったり，緊急な対応を要する不具らの分析結果を受けて，Blocking Bug の発生原因を理

合修正をおこなっているときなど，十分な時間が確保で解することが Blocking Bug を早期に検出したり予防しきない場合に Blocking Bug が発見されると，ソフトウェたりするのにより重要であると考えるに至った．

した予備調査から，Blocking Bug は Blocking Bug では

90

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

3. 先行研究

不具合の担当者とその不具合を修正できずに新たな担当者として不具合を担当した開発者間にエッジを結び作成したトポロジグラフにおいて，トポロジの変化が大きい

3.1. Blocking Bug 予測

ほど不具合が発生しやすいことが確認された．

Garcia らの研究では Blocking Bug に関する特徴を分

いずれもモジュール間でのみの分析や人のみの分析で析し，新たに報告された不具合が Blocking Bug か否かあり，本研究のように，不具合，モジュール，人を結びを予測するモデルを構築している [12]．6 つの OSS プロ

つけて 1 セットで分析した研究はまだされていない．

ジェクト（Chromium, Eclipse, FreeDesktop, Mozilla,

NetBeans, OpenOﬃce）を対象におこなった分析では，
Blocking Bug は非 Blocking Bug と比較して 2 倍から 3

4. Blocking Bug の発生原因理解のための依存関係分析

倍ほど修正時間が長くなる（15 日から 40 日程度修正時間が長くなる）ことや，プロジェクトによって差はある

4.1. 概要

ものの，検出にかかる時間は 3 日から 18 日程度であると述べている．

プロジェクトに報告される不具合のうち Blocking Bug

また，Blocking Bug かどうかを予測するモデルでもっに特化した研究は，Garcia らの研究 [12] 以外には存在

とも高く寄与したメトリクスは不具合票に投稿されたコ

しない．また，Garcia らの研究は，Blocking Bug の予

メントであることを明らかにしている（Mozilla のみ，そ測を目的としたものであり，Blocking Bug の実態や発の不具合票に関わりを持つことを望んだユーザ (CCList)

生原因を明らかにはしていない．

の数がもっとも寄与している）．

そこで本研究ではまず，Blocking Bug の実態を調査

先行研究の分析は，Blocking Bug の検出を目的としし，その後，Blocking Bug の発生原因理解のための分ており，Blocking Bug の発生原因や発生の予防法につ析を行う．Blocking Bug の発生原因理解のための分析

いては述べられていない．

にあたり，本研究では 3 つの分析視点を導入する．

本研究の目的は Blocking Bug の早期修正，発生の予不具合管理システムに報告された不具合は，まず適任防をおこなうことである．そのために Blocking Bug がの修正担当者（多くの場合，修正対象物の作者）に割り発生する原因を理解する必要があり，発生原因を理解す当てられる．次に修正担当者は，その不具合を発生させるための分析をおこなう点で先行研究と異なる．

ている原因を調査し，修正対象物（パッケージ，コンポー
ネント，ファイルなど）を決定する．この不具合解決プ

3.2. 依存関係分析

ロセスは，Blocking Bug を対象にした分析においては非常に複雑なものとなる．複雑な関係は，修正すべき不ソフトウェア保守における依存関係の分析は盛んにお具合が単独で発生したものであれば（Blocking Bug で

こなわれている．Biazzini ら [13] は， 87 プロジェクト

なければ）発生しない．この点からも Blocking Bug のを対象として，分散管理システムにおけるコミット履歴

解決は通常の不具合修正に比べて容易なものでないことを基に共同開発における特徴を分析している．分析の結が分かる．したがって，分析の切り口としてまず，以下

果，開発者の人数が多くなると複雑なブランチを形成すの 3 つの視点で複雑な依存関係を分解する．

ることやブランチごとのコミット回数と開発者の共同作• 不具合報告間の依存関係（Blocking Bug と Blocked

業には関係がないことを示している．

Bhattacharya ら [14] は，11 プロジェクトを対象にBug の依存関係）

ソースコードを基に作成したグラフと開発者を基に作成• 修正担当者間の依存関係（修正作業を進める上でのしたグラフを用いて，ソフトウェアの開発支援のための依存関係）分析をおこなっている．分析の結果，ソースコードの参照関係を基に作成したトポロジグラフのうち，入次数が• 修正対象物間の依存関係（call-caller 関係などの依存関係）多い，つまり多くのファイルから参照されているほど，
そのファイルから発生するバグの重要度が高いことや，

91

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

これらの依存関係をそれぞれ分析することで，Block-

1. 各 Blocking Set の担当者の数：各 Blocking Set に含まれるそれぞれの不具合の修正をおこなった修正
担当者の数を調査する．

ing Bug の発生原因をある程度絞り込むことができ，
Blocking Bug の予防する上での知見が得られるものと期待している．さらに，補足的な分析視点として，それ2. 修正担当者の経験：Blocking Bug を埋め込んだ開発者の経験がどの程度であったかを調査する．開発者

ぞれの分析観点の重畳的な分析を行う．

Blocking Bug が特定の開発者に割り当てられている状況や特定の修正対象物が Blocking Bug を引き起こす可能性などについて調査することで，Blocking Bug の発の経験はコミットの回数から測ることにする．まず，開発者を経験の浅い開発者と豊かな開発者に分けるために対象期間中の各開発者の総コミット回数を求生原因をより正確に捉えることができると期待される．

める．対象期間中のコミット回数が第一四分位数以下である時期は「経験が浅い開発者」とし，第一四4.2. Blocking Bug の実態把握のための分析

分位数以上である時期は「経験が豊かな開発者」であると定義する．

• 不具合報告のメトリクス• 修正対象物のメトリクス：

1. 不具合の数：Blocking Bug と非 Blocking Bug の不具合票の数を調査する．

1. 修正ファイル数：Blocking Bug と非 Blocking Bug
2. 修正時間：Blocking Bug，非 Blocking Bug，Blockedの修正ファイル数を調査する．本研究では不具合

Bug の修正時間を調査する．本研究では不具合票のStatus が “Resolved” または “Closed” のものを解修正の際に変更されたファイルを修正ファイルとみなす．

決済みの不具合として扱うことにし，不具合が報告

2. 各 Blocking Set の修正ファイル数：各 Blocking
Set に含まれる不具合を修正するために変更したファ

された日時から解決した日時までを修正時間と定義
する．

イルの総数を調査する．

3. Blocking Bug の検出時間：Blocking Bug が検出されるまでの時間を調査する．本研究では不具合が報告された日時から “blocks” のタグがつけられる

4.3. Blocking Bug の発生理解のための依存関係分析

までの日時を Blocking Bug の検出時間と定義する．

本節では Blocking Bug の発生原因を調査するための取り組む RQ について述べる．不具合報告間の依存関

4. 優先度別の不具合票の内訳優先度別に Blocking Bugと非 Blocking Bug の不具合票の数を調査する．

係の観点から RQ1 を立てる．修正担当者の依存関係の観点からは RQ2 を，修正対象物の依存関係の観点から

5. 各 Blocking Set の構成不具合数：各 Blocking Set

RQ3，分析視点間の依存関係の観点から RQ4 を立てる．

が持つ不具合票の数を調査する．本研究では Block-ing Set に含まれる Blocking Bug と Blocked Bug

RQ1–1：優先度が高い Blocked Bug の発生によってBlocking Bug の修正は活発になるかの合計を Blocking Set を構成している不具合票の動機：報告されたすべての不具合をリリースまでに修正数とする．

することは困難である．そのため各不具合には優先度が付与される．優先度は不具合が報告された時点で決定さ

6. Blocking Set の 発 生 順 序：Blocking Bug とれる（途中で変更することも可能）．不具合単体として

Blocked Bug のどちらが先に報告されたのかを調査する．Blocking Set の中でもっとも早く報告されたものが Blocking Bug である場合 Blocking Bug

は優先度が高いない不具合が Blocking Bug である場合
や，Blocking Bug が重要でないとしても Blocked Bugが重要な可能性もある．単体では重要でないと判断され，が先に報告されたものとし，1 つでも Blocked Bug

修正作業を後回しにされた Blocking Bug によって，早が先に報告されていれば Blocked Bug が先に報告期に修正しなければならない Blocked Bug の修正に取されたものとしてカウントする．

り掛かれないという状況が発生してしまう．今まで，修正作業が後回しにされていた Blocking Bug が重要であ• 修正担当者のメトリクス

92

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

ることが確認されれば，不具合の優先度の割り当てをよが発生しやすいか

り適切なものにすることができる．結果，Blocking Bug

動機：大規模なソフトウェアは複数のソフトウェア部品の早期修正に役立つと考えられる．

によって構成されている．複数のファイルを参照し，組アプローチ：本研究では Blocked Bug の優先度が高く，修み合わせることでソフトウェアを構築している．これは正作業が後回しにされた Blocking Bug が何件存在するか

ファイルごとに機能をまとめることでファイル管理の観を確かめる．本研究では不具合票の Priority が “Blocker”

点からは有効であると言える．しかし，ファイルを参照

または “Critical” のものを優先度が高い不具合とする．

していることで予期しない不具合が発生することがある．

また，修正が後回しにされたかの判断については，不具

例えば，機能追加等で他のファイルから参照されている

合報告後，Blocking Bug の検出時間の中央値より長い

ファイルを変更するとする．このとき，ファイルの変更

時間，コメントやパッチ投稿を不具合管理システムにおによって他のファイルに与える影響を十分に考慮する必

こなわなかった不具合票を修正作業を後回しにされたと要があるが．このように，ファイルの参照関係が多いほ

定義する．

ど同時に変更すべきファイルが多くなり，不具合が発生

RQ1–2：優先度が高い Blocked Bug の発生が Block-

する可能性も高くなる．ファイルの被参照数が多いほどing Bug の発見に寄与するか
動機：RQ1–1 で述べた仮説では優先度の高い Blocked

Blocking Bug になりやすいことが確認されれば，被参照数を減らすことで Blocking Bug の発生を予防するこ

Bug の修正に取り掛かかることで Blocking Bug の存在が判明するケースも考えられる．RQ1–1 と合わせて，優先度の高い Blocked Bug の修正が Blocking Bug に発見とができる．

に寄与するかどうかを RQ1–2 として調査する．

ファイル数を比較する．比較には U 検定を用いる．参照

アプローチ：優先度が高い不具合の定義は RQ1–1 と同されている状態について定義する．本研究ではインポー様とする．報告された不具合票には不具合に関してのトや継承によって他のファイルから利用されているとき，コメントや依存関係にある不具合の情報を追加登録（変ファイルが「参照されている」と定義する．
「参照されて更）することができる．Blocking Bug の不具合票においる」状態かを分析するためにはソースコード解析ツー

いて最初の追加登録（変更）が “blocks” タグをつける

ルである Understand1 を用いる．

（Blocking Bug であると定める）ことであった場合を，RQ4：経験が豊富な開発者によって Blocking Bug の優先度が高い Blocked Bug が Blocking Bug の発見に寄発生を予防できるか与したと考える．

動機：ファイルの変更権限が与えられた開発者（コミッ

RQ2：修正担当者が多いほうが Blocking Bug が発生

タ）のコードやプロジェクトに対する理解は開発者ごとしやすいかに異なる．経験が浅い開発者は経験が豊かな開発者に比

動機：OSS 開発現場では不特定多数の人々が開発に参加

べてファイルの依存関係の理解が浅い．ファイルの依存している．ファイルの変更が他のファイルへ影響する場

関係によって発生するような Blocking Bug は経験が浅合，修正担当者が複数人いることで変更されたファイル

い開発者のほうが発生させやすいと考えられる．経験のからの影響をよく理解しないまま修正をおこなう可能性

豊かな開発者がいる場合，こうした Blocking Bug の発がある．結果として Blocking Bug が発生する頻度が高生を予防することができる可能性がある．経験の豊かなまる．修正担当者が多いほうが Blocking Bug が発生し開発者が Blocking Bug の発生を予防することが確認でやすいということが確認できれば，不具合の修正担当者

きれば，Blocking Bug が発生する可能性の高いファイを割り当てる際に関連がありそうな不具合は 1 セットとルは経験豊富な開発者にチェック依頼することで発生を考えて，1 人の担当者に任せることで Blocking Bug の予防できると考えられる．

発生を予防することが可能であると考えられる．

アプローチ：RQ4 に答えるためのアプローチについて述

アプローチ：RQ2 に答えるために，修正担当者数別にべる．経験豊かな開発者がいることで Blocking Bug のBlocking Bug の件数を示す．修正担当者は Blocking Setの不具合の修正をおこなった開発者とする．
RQ3：ファイルが参照されているほど Blocking Bug

発生を予防できるかどうかを確かめるために，チームをアプローチ：RQ3 に答えるために，Blocking Bug と非Blocking Bug のそれぞれのファイルが参照されている

1 Understand: https://www.techmatrix.co.jp/quality/
understand/

93

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

作成する．Blocking Bug が埋め込まれたファイルに変表 1. データセットの概要

更を加えた経験をもつ開発者群をチームとする．開発者

コンポーネント

Blocking Bug

非 Blocking Bug

Hadoop Common

107

1,223

で述べた定義を使うことにする．RQ4 に答えるために，

HDFS

57

1,851

経験豊かな開発者のみ，経験が豊かな開発者と浅い開発

Hadoop YARN

10

134

者の混合，経験の浅い開発者のみの 3 つのグループに分

Hadoop Map/Reduce

60

1,575

全体

234

4,783

の経験については 4.2 節の不具合担当者間のメトリクス

けて，各チームが発生させた Blocking Bug の件数を比較することにする．

表 2. 修正時間
修正時間（日）5. ケーススタディ

Blocking Bug

非 Blocking Bug

Blocked Bug

10

11

52

ができる．また，SZZ アルゴリズム [15] を併用すること

5.1. 対象プロジェクト

で，該当する不具合が混入したリビジョンを特定するこ
本論文では，Apache Hadoop プロジェクトをケースとができる．特定ができた Blocking Bug と関係のない

スタディの対象とする．Hadoop プロジェクトは，大不具合を本研究で扱う「非 Blocking Bug」とする．ま

規模データの分散処理を可能とする OSS である．主た，Blocking Set のすべての不具合が特定できたものをに，Hadoop Common, HDFS, Hadoop YARN, Hadoop

本研究で扱う「Blocking Bug」とする．

Map/Reduce の 4 つのコンポーネントで構成される．
Hadoop を選定した理由は，4 つのコンポーネントが互いに密接な関係にあるため Blocking Bug が発生しやす

5.3. Blocking Bug の実態把握のための分析いと考えたためである．

5.3.1

不具合報告のメトリクス

1. 不具合の数

5.2. 対象データ
依存関係分析の対象データとして，不具合データ，ソー

Blocking Bug と非 Blocking Bug の不具合数についての分析結果を表 1 に示す．

スコード及びソースコードの変更履歴のデータを用いる．

234 件の Blocking Bug と 4,783 件の非 Blocking

Hadoop プロジェクトでは，不具合データは不具合管理

Bug が確認された．

システム JIRA から，ソースコード及びソースコードの

2. 修正時間

変更履歴は Git から取得することができる．対象データ

修正時間についての分析結果を表 2 に示す．

を作成するまでの 3 つの手順を以下に示す．

Step1：取得した不具合データから解決済みの不具合

表 2 で は ，Blocking Bug，非 Blocking Bug，

データのみを抽出する．解決済みの不具合データのみを

Blocked Bug の修正時間の中央値を日数単位で示抽出するのは，不具合の修正がおこなわれるまでは修正している．Blocking Bug と非 Blocking Bug の間で対象物（ソースファイル等）を特定することができないた

修正時間に大きな差はみられなかった（U 検定の結めである．本研究では不具合票の Resolution が “Fixed”

果，p = 0.46 であった）．また，Blocked Bug は修のものを解決済みの不具合とする．

正時間が中央値で 52 日であることが確認された．

Step2：Blocking Bug のうち Blocking Set を作成する
3. 優先度別の不具合票の内訳ことができるものを抽出する．本研究では Blocking Bugの依存関係を分析したいと考えているため Blocking Set

優先度別に不具合票の内訳を表 3 に示す．

の構築が可能である Blocking Bug に限定する．

高い優先度 (Blocker と Critical) が割り当てられた

Step3：抽出した不具合データのうち，不具合データとコミット履歴の紐付けができるものを抽出する．コ

不具合の割合については，Blocking Bug と非 Block-ing Bug の間で大きな違いはみられなかった．低い優先度（Minor や Trivial）が割り当てられた不具合のミットメッセージに不具合 ID が含まれていれば，該当する不具合を修正するためのコード変更を特定すること

94

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

表 3. 優先度別の不具合票の内訳

表 6. 先に報告された不具合の数

優先度の割合BlockingBug

非 BlockingBug

Blocker

25 (10.7%)426 (8.9%)

Critical

12 (5.1%)

319 (6.7%)

Major

177 (75.6%)

2,965 (62.0%)

Minor

18 (7.7%)854 (17.9%)

開発者の経験

件数

Trivial2 (0.9%)219 (4.6%)

浅い

13

614

豊か

173

6066

先に報告された不具合の数

最大値

最小値

平均値

中央値

標準偏差

不具合票の数

4.0

2.0

2.2

2.0

0.2

修正担当者の数

3.0

1.0

1.4

1.0

0.3

9405.0

1.0

85.8

13.0

件数

2件

187 (80.3%)

3件

37 (15.9%)

4件

9 (3.9%)165（70.5%）

コミット回数

表 8. 修正ファイル数（中央値）
Blocking Bug

非 Blocking Bug

4

2

修正ファイル数661.1

表 5. 構成不具合票数別の Blocking Set の件数
構成不具合票数

Blocked Bug

69（29.5%）

表 7. 開発者の経験による Blocking Bug の発生件数

表 4. 各 Blocking Set の基本統計量

修正ファイル数

Blocking Bug

Blocking Set に含まれる不具合を修正した担当者の数を表 4 の 2 行目に示す．修正担当者の中央値は 1人であった．

2. 修正担当者の経験経験の違いによる Blocking Bug の発生件数とコミッ割合については，非 Blocking Bug に比べて Block-

ト回数を表 7 に示す．234 件の Blocking Bug のう

ing Bug のほうが少ないことが確認された．

ち，新たなファイルの作成のみで修正を完了させ

4. Blocking Set の構成不具合数 Blocking Set の構成

た Blocking Bug が 48 件存在した．この 48 件の不具合数を表 4 の 1 行目に示す．表 4 に，Blocking

Blocking Bug を除いた，186 件の Blocking Bug に分析をおこなった結果，経験が浅い開発者は 47 回

Set の統計量（1 つの Blocking Set に含まれる不具合数，修正担当者数，修正ファイル数）を示す．

に 1 回の割合で Blocking Bug を発生させることがBlocking Set に含まれる不具合の数の最小値と中央値が 2 件であることから，半数以上の Blocking Set

確認された．また経験が豊かな開発者は 35 回に 1回の割合で Blocking Bug を発生させていた．

は Blocking Bug と Blocked Bug が 1 件ずつである
ことがわかる．

5.3.3

修正対象物のメトリクス

表 5 に Blocking Set の構成不具合数別の件数を示

1. 修正ファイル数（中央値）

す．約 8 割の Blocking Set は，構成する不具合の数が 2 つである．つまり，約 8 割の Blocking Bug

Blocking Bug と非 Blocking Bug の修正時に変更しは 1 つの Blocked Bug の修正を妨害していることたファイルの数を表 8 に示す．分析の結果，修正ファが確認された．

イル数の中央値は Blocking Bug の方が多いことが確認された（U 検定をおこなった結果，p < 0.00）．

5. Blocking Set の発生手順

つまり，Blocking Bug の修正には非 Blocking Bug

Blocking Bug と Blocked Bug のどちらが先に報告されたかを表 6 に示す．

と比べてより多くのファイルを修正する必要がある
ことが確認された．

Blocking Bug の約 7 割が Blocked Bug のほうが先

2. 各 Blocking Set のファイル数に報告されていることが確認された．

各 Blocking Set に含まれる不具合を修正するために変更したファイルの総数を表 4 の 3 行目に示す．

5.3.2

表 4 から修正総ファイルは最大で 9405 ファイル，最修正担当者のメトリクス

小で 1 ファイルであることが確認された．また中央値は 13 ファイルであった．

1. Blocking Set の担当者の数

95

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

表 9. 修正担当者の人数の内訳

表 10. 参照ファイル数（中央値）

修正担当人数件数

Blocking Bug

非 Blocking Bug

p値

1145（62.0%）

参照数

1

1

0.39

2

79（33.8%）

被参照数

4

3

0.00**

310（4.2%）

表 11. チーム別の Blocking Bug 発生件数

5.4. Blocking Bug の発生理解のための依存関係分析
RQ1–1：優先度が高い Blocked Bug の発生によっ

チーム

件数

経験豊富な開発者のみ

81

経験豊富な開発者と浅い開発者の混合

102

経験の浅い開発者のみ

3て Blocking Bug の修正は活発になるか

243 件の Blocking Bug のうち，優先度が高い Blocked
Bug を持っている不具合は 45 件確認された．45 件の確認された．RQ3 の結果から，多くのファイルから呼ば

Blocking Bug のうち，Blocking Bug の検出時間の中央値である 2 日を超えた後に修正が開始された Blocking

された．

Bug は 3 件のみであった．

の発生を予防できるかれているほうが Blocking Bug になりやすいことが確認

RQ4：経験が豊富な開発者によって Blocking Bug
開発者の経験を基に分けたグループの Blocking Bug のRQ1–2：優 先 度 が 高 い Blocked Bug の 発 生 が発生件数を表 11 に示す．表 11 に示すように経験の浅い

Blocking Bug の発見に寄与するか
45 件の Blocking Bug のうち，不具合管理システムでの開発者のみのチームによって埋め込まれる Blocking Bug

最初の変更が “blocks” のタグの挿入であるものは 4 件

は経験豊富な開発者が存在しているチームによって埋めのみであった．

込まれていることがわかる．したがって，経験が豊富なは全体の 1.6%（3/186）であり，98.4%の Blocking Bug

RQ1–1 と RQ1–2 の結果から優先度が高い Blocked

開発者がいても Blocking Bug の発生を予防できるとはBug であっても Blocking Bug の発見にはつながらない
ことが確認された．

言えないことが確認された．

6. 考察
RQ2：修正担当者が多いほうが Blocking Bug が発生しやすいか

本章では，まずケーススタディの結果に基づいた考察

表 9 に Blocking Set の修正担当者の人数に関する詳をおこなう．その後，本研究の制約について述べる．

細な内訳を示す．

6.1. Blocking Bug とファイルの関係

全 Blocking Set のうち，約 62%が 1 人の担当者によって修正されていることが確認された．RQ2 の結果から，

本研究では，Blocking Bug が埋め込まれるファイル

修正担当者が多くても Blocking Bug が発生するとは言は他のファイルに比べて被参照ファイルが多いことが確えないことが確認された．

認された．また，Blocking Bug は非 Blocking Bug に比べて修正するために変更しなければならないファイルがRQ3：ファイルが参照されているほど Blocking Bug

多いことも確認された．Blocking Bug が埋め込まれるが発生しやすいか

ファイルは参照されているファイルが多いので，ファイ

表 10 に Blocking Bug と非 Blocking Bug ごとの参照

ルの変更によって与える影響が大きく修正すべきファイ数の中央値を示す．
表 10 は Blocking Bug と非 Blocking Bug のそれぞれ

ルも多くなったと考えられる．また，これらの結果から，の参照数の中央値と，U 検定をおこなった際の p 値を示
イルのほうが，将来 Blocking Bug とならないファイル

Blocking Bug は非 Blocking Bug に比べて修正にコストがかかると言えるので，早期修正と発生の予防の両方の観点から参照されているファイルを減らすことは重要でと比べてより多くのファイルから参照されていることがあると考えられる．ファイルの被参照数を減らすためのしている．分析の結果，将来 Blocking Bug になるファ

96

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

方法としては，メソッドの利用を継承に変更する方法や修正が効率化されると考えられる．実際に，修正担当者

子クラスの共通メソッドを親クラスに引き上げるなどのが 1 人の場合と複数人の場合で Blocking Bug の修正時リファクタリング方法が考えらえれる．

間の差を比較した結果，修正時間の中央値は，修正担当

実際に Hadoop プロジェクトで修正されたファイルの差者が 1 人である場合は 7 日であるのに対し，複数人で依存関係の一部を用いて被参照ファイルを減らす方法をある場合は 20 日であった（U 検定の結果 p 値 = 0.02∗）．

説明する．図 2 において “Writable” ファイルは Block-

つまり，Blocking Bug の早期修正をおこなうためには

ing Bug として修正されたファイルである．“Writable”
ファイルは “Configuration” ファイルから継承のためBlocking Set を 1 人で修正する方が効率的であると言える．

に，また，“WritableUtils” ファイルからはメソッドの6.3. 本研究の制約利用のために参照されている．“WritableUtils” ファイ
ルは “Configuration” ファイルからメソッド利用のため

本研究ではファイルを変更する際のコメントを用いて，に参照されている．このとき，“Configuration” ファイ

不具合，モジュール，人の 3 つのデータを結びつけてい

ルは “Writable” ファイルを継承しているが，図 2 のる．しかし，コメントの内容によっては結びつけができ

下図のように “WritableUtils” ファイルが “Writable”

ないこともあるため，結びつけができなかったデータはファイルを継承することで “Configuration” ファイルは対象から除外している．また，不具合の解決方法によっ“Writable” ファイルを継承する必要がなくなる．結果
として，“Writable” ファイルは “Configuration” ファイルから参照されなくなり，参照されるファイルの数は 2ては，結びつけができないために対象から除外しているものもある．これは，不具合の解決方法の中にはファイルの変更を伴わないものがあるためである．例えば，ファイルから 1 ファイルへ減少する．

“Won’t Fix” とつけられている不具合表では，ファイルの変更がおこなわれる可能性は低い．よって，本研究で6.2. Blocking Bug と修正担当者の関係扱う Blocking Bug は Blocking Set 中のすべての不具合
票で最低 1 ファイル以上の修正がおこなわれた Blocking

本研究では，約 62%の Blocking Set は 1 人で修正す

Bug に限定される．

ることが確認された．これは修正の効率化を重視した結果であると言える．例えば，修正担当者が複数人であ

7. おわりにる場合，各修正担当者はそれぞれの不具合に関する情報を交わしながら担当する不具合を修正する必要がある．

本論文では Hadoop プロジェクトを対象に Blocking

そのため，非 Blocking Bug に比べて修正に時間がかか

Bug の実態把握と発生原因を理解するための分析をおこなった．Blocking Bug の発生原因を理解するため，不る．しかし，修正担当者 1 人で Blocking Set に対応すれば，不具合に関する情報を交わす必要がなくなるので非具合間の依存関係，修正担当者間の依存関係，修正対象

Blocking Bug 同様に議論のための時間は必要なくなり，

メソッド利用Configuration
継承
Configuration

メソッド利用物の依存関係の 3 つの視点に加えて，3 つの視点の重畳的な依存関係の 4 つの視点から依存関係分析をおこなっ

WritableUtils

た．Hadoop プロジェクトを対象におこなったケースス

Writable

告されてから報告されることが多いことや，非 Blocking

メソッド利用タディの結果，Blocking Bug は Blocked Bug が先に報Bug に比べて修正のために変更を加えるファイル数が多いことが確認された．また，多くのファイルに参照さ

WritableUtils

れていると Blocking Bug になりやすいことが確認され継承た．今後の課題としては，本研究で得られた知見を基にWritable

Blocking Bug の発生をどの程度予防できるかを確かめる必要があると考えられる．また，本論文で得られた知図 2. Hadoop プロジェクトの実態例

見は Blocking Bug 検出の予測やファイル変更時の影響分析にも活用できると考えられる．

97

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

参考文献[9] Chen, T., Nagappan, M., Shihab, E. and Hassan, A. E.: An Empirical Study of Dormant Bugs,
in Proceedings of the 11th Working Conference on[1] Page-Jones, M.: Practical Guide to Structured
Systems Design (2nd Edition) (1988).

Mining Software Repositories (MSR ’14), pp. 82–
91 (2014).

[2] April, A. and Abran, A.: Software MaintenanceManagement: Evaluation and Continuous Improvement (2008).

[10] Shihab, E., Mockus, A., Kamei, Y., Adams, B.
and Hassan, A. E.: High-impact Defects: A Studyof Breakage and Surprise Defects, in Proceedings[3] Shokripour, R., Anvik, J., Kasirun, Z. M. and Zamani, S.: Why So Complicated? Simple Term Fil-of the 19th ACM SIGSOFT Symposium and the13th European Conference on Foundations of Soft-tering and Weighting for Location-based Bug Report Assignment Recommendation, in Proceedingsof the 10th Working Conference on Mining Soft-ware Engineering (ESEC/FSE ’11), pp. 300–310(2011).
[11] Nistor, A., Jiang, T. and Tan, L.: Discovering,ware Repositories (MSR’ 13), pp. 2–11 (2013).

Reporting, and Fixing Performance Bugs, in Proceedings of the 10th Working Conference on Min-

[4] Menzies, T. and Marcus, A.: Automated severity assessment of software defect reports, in 24 thIEEE International Conference on Software Maintenance (ICSM ’08), pp. 346–355 (2008).

ing Software Repositories (MSR ’13), pp. 237–246(2013).
[12] Garcia, H. V. and Shihab, E.: Characterizing[5] Tian, Y., Lo, D. and Sun, C.: DRONE: Predicting
Priority of Reported Bugs by Multi-factor Anal-and Predicting Blocking Bugs in Open Source
Projects, in Proceedings of the 11th Working Con-ysis, in 29th IEEE International Conference on
Software Maintenance (ICSM ’13), pp. 200–209(2013).

ference on Mining Software Repositories (MSR
’14), pp. 72–81 (2014).
[13] Biazzini, M., Monperrus, M. and Baudry, B.: On[6] Runeson, P., Alexandersson, M. and Nyholm, O.:
Detection of Duplicate Defect Reports Using Nat-

Analyzing the Topology of Commit Histories in
Decentralized Version Control Systems, in Pro-

ural Language Processing, in Proceedings of the
29th international conference on Software Engineering (ICSE ’07), pp. 499–510 (2007).

ceedings of the 30th International Conference on
Software Maintenance and Evolution (2014).
[14] Bhattacharya, P., Iliofotou, M., Neamtiu, I. and[7] Sun, C., Lo, D., Wang, X., Jiang, J. and Khoo, S.C.: A discriminative model approach for accurate

Faloutsos, M.: Graph-based Analysis and Prediction for Software Evolution, in Proceedings of the

duplicate bug report retrieval, in Proceedings ofthe 32nd ACM/IEEE International Conference on
Software Engineering (ICSE ’10) - Volume 1, pp.

34th International Conference on Software Engineering, ICSE ’12, pp. 419–429 (2012).
[15] Śliwerski, J., Zimmermann, T. and Zeller, A.:

45–54 (2010).

When Do Changes Induce Fixes?, in Proceedingsof the 2005 International Workshop on Mining[8] Kashiwa, Y., Yoshiyuki, H., Kukita, Y. andOhira, M.: A Pilot Study of Diversity in HighImpact Bugs, in Proceedings of 30th International
Conference on Software Maintenance and Evolu-

Software Repositories, MSR ’05, pp. 1–5 (2005).

tion (ICSME2014), pp. 536–540 (2014).

98

SEA