分析結果

表3は，ロジスティックモデルを用いて，図8，図9中の，B点を予測点とし，

B点から12ヶ月，9ヶ月，6ヶ月，3ヶ月前までの不具合修正数を学習モデルデータ

として予測モデルを構築し，B点で修正完了する不具合数を予測した結果を示す．

表3の各セルは，最右列にB点で実際に修正完了する不具合数を示す．左から2 列目〜5列目の各セルでは，B点で実際に修正が完了している不具合数を100%と

表 3 ロジスティックモデルを用いたB点における不具合修正数の予測結果 ライブラリ 12ヶ月前 9ヶ月前 6ヶ月前 3ヶ月前 実際の不具合修正数

slf4j 90 (106%) 96 (98%) 101 (103%) 102 (104%) 98 (100%） log4j 799 (274%) 815 (265%) 932 (269%) 1053 (297%) 358 (100%）

し，各時点までの不具合修正数を用いて，B点で修正完了する不具合数を予測し た値と，実際のB点での修正数との割合を示す．なお，ロジスティックモデルと log4j，slf4jにおける不具合修正曲線との残差平方和は，それぞれ，23651，475で あった．残差平方和は，値が小さい程，信頼性モデルのフィッティングが良いこ とを示す指標である．以下，まとめと結果について述べる．

信頼性曲線による不具合数の予測結果

全体の不具合修正数の80%が修正されている点(B点)から，任意の時点（12ヶ 月，9ヶ月，6ヶ月，3ヶ月前）までの，不具合修正数を学習データとし，B点 での不具合修正数を予測した結果，slf4jでは，96〜102%，log4jでは，265〜 297%で予測された．

B点の12ヶ月前の時点までの不具合修正数，ロジスティックモデルを用いて予

測モデルを構築した場合，B点での修正完了不具合数は，slf4jでは90%，log4jで

は274%であった．9ヶ月，6ヶ月，3ヶ月前までの不具合修正数を学習データとし，

B点での不具合修正完了数を予測した結果，slf4jでは，96%〜102%と，100%に近 い割合で予測できていることがわかる．一方，log4jの結果では，265〜297%と，B 点での実際の不具合修正数よりも約3倍にあたる予測値を示している．本実験に おいては，slf4jの場合，全期間において高精度での予測が可能であったが，log4j

では，3ヶ月，6ヶ月前のようにB点に近い時点においても，予測精度の向上は見

られなかった．

5.4 考察

本節では，ロジスティックモデルを用いて，slf4j，log4jの不具合修正数を予測

月，9ヶ月前，6ヶ月，3ヶ月前）において，ほぼ100%の精度で図8中B点での不具 合修正数を予測している．この理由として，予測時点である2011年3月（B点）

から12ヶ月前の2010年3月の期間で，不具合修正がほとんど行われていなかっ

たことが挙げられる．図2を見ると，2010年，2011年の不具合修正数はそれぞ れ，15，5と少なく，不具合修正曲線が収束したと判断され，ロジスティックモ デルによる予測値も，実際の不具合数に近い値になったと考えられる．また，B 点において修正された実際の不具合数が98個と少ないため，予測が安定したと 考えられる．

一方，log4jの予測結果では，すべての予測時点において，ロジスティックモデ

ルの予測値が，実際の不具合数の約3倍である．これは，予測期間である，2008 年，2009年の不具合修正数が，それぞれ，36，34とslf4jよりも多いため，slf4j と比較して，予測精度が低くなったと考えられる．また，B点で実際に修正され た不具合数も358個と多く，不具合修正の規模が予測に影響したと考えられる．

他の理由として，不具合修正曲線の傾きと，ロジスティックモデルとのフィッ ティングが考えられる．図8で，slf4jの不具合修正曲線を見ると，不具合修正が 開始された時期から，時間経過とともに不具合修正の傾きが急激に大きくなり．

最終的に収束に向かっているため，S字カーブを描くロジスティック曲線が適し ていたと考えられる．一方で，図9と表2から，log4jの不具合修正曲線は，不具 合修正が始まった当初から，緩やかに増減しているため，ロジスティックモデル が適さなかったと考えられる．従って，ロジスティックモデルとは異なるモデル を適用することで，予測精度が改善が見込める．

6. ^{結果の妥当性}

本論文では，ライブラリの利用者が，信頼できるバージョンを選択するための 方針を示すことを目的とし，ライブラリのバージョン選択を調査した．第3章の 分析では，同ライブラリ内でのバージョン選択に注目したが，実際には同ライブ ラリ内のバージョン選択だけでなく，別のライブラリへ移行することもあるため，

ライブラリ間での移行も踏まえ，より深く分析する必要がある．

ライブラリの利用数と不具合修正数との分析では，不具合修正数の収束状況と，

バージョン選択との関係を示した．第2章の分析では，不具合の修正数のみに注 目したが，修正された不具合の内容を考慮していない．ソフトウェアの不具合に 注目した研究は多く行われており，近年では特に，セキュリティやパフォーマンス に関する不具合などが，利用者に与える影響が大きい不具合（High Impact Bug）

と呼ばれ，自動分類に関する研究が盛んに行われている[15][16]．本論文において

も，High Impact Bugがどれだけ修正されているかに注目することは重要である

が，High Impact Bugの自動分類は依然として難しく，いまなお，研究者が目視 で不具合票を読み，手動での分類がすることが多いため，データの確保が難しい．

また，不具合修正に関する従来研究では，不具合の修正数だけでなく，不具合 の報告数をみることも多い．しかしながら，不具合として報告されたものの，報 告された不具合が再現できないため修正されないことや，過去に修正済みである 不具合が再度報告されることもある．故に，不具合報告数が不具合修正数が対応 しないことが多いため，本論文では，実際にプロジェクトによって修正された不 具合数のみに着目した．

不具合修正数の収束状況を分析するために，不具合修正曲線を作成したが，従 来研究での筆者の取り組みでは，不具合修正曲線を作バージョン毎に作成してい る．しかし，本論文ではバージョンの分類は行っていない．その理由として，本論 文で対象としたライブラリでは，不具合票にバージョン情報が記載していない不 具合も多かったため，各ライブラリの不具合をまとめ，ライブラリ全体でひとつ の不具合修正曲線を作成した．バージョン毎に不具合修正曲線を作成することが 望ましいといえるが，OSSライブラリは拡張開発であるため，過去のバージョン

て，ライブラリ全体としての不具合修正曲線であったとしても，新しいバージョ ンは品質が向上していると考えられ，各バージョンの品質の向上を理解できると 考える．

第5章では，ソフトウェア信頼性曲線を用いて，不具合修正数の予測を試みた．

本論文では，信頼性曲線の中でも，よく利用されるロジスティックモデルを用いて 予測を行ったが，信頼性曲線の関連研究では，基本的な信頼性モデルの他に，開 発者の変化など，時間変化によって変化する不確実性を考慮したモデルの拡張な ども行われている．本論文においても，各プロジェクトの不具合修正曲線にフィッ ティングする信頼性曲線を適用することで，log4jにおける予測精度が期待でき る．また，第5.3節の不具合修正数の予測では，ライブラリ利用数のグラフ上に 示したB点での修正不具合数の予測を試みたが，不具合修正曲線の傾きが異なる 複数の点において予測結果を比較することで，結果の妥当性を高めることができ ると期待される．

7. ^おわりに

ソフトウェア開発においてライブラリの需要が高まる一方で，どのようにバー ジョンを選択を行うべきかのを示す選択指針が存在しない．本論文では，ライブ ラリを利用するユーザが，そのバージョン選択を行う際の指針を示すため，群衆 の英知に基づくバージョン選択に注目し，ライブラリの利用数を分析した．その 結果，プロジェクトがライブラリの利用を開始する時期では，プロジェクトが利 用するバージョンは分散しているが，時間経過により，多くのプロジェクトが同 一のバージョンを選択し始めるなど，時期によるプロジェクトのバージョン選択 の違いを明らかにした．また，不具合修正数とバージョン選択との関係も分析し た．特に，不具合修正の収束状況と，多くのプロジェクトが同一のバージョンを 選択し始める時期との関係に注目した結果，不具合修正数が収束し始め，ライブ ラリの品質が高まると，多くのプロジェクトが選択するバージョンが現れること がわかった．最後に，不具合の修正が収束しているか否かを予測する試みとして，

ソフトウェア信頼性曲線を用いて，将来的に修正される不具合数の予測を試みた．

最後に，本論文で得られたライブラリ利用数に関する知見を以下に示す．

• プロジェクトがライブラリを利用をし始める時期は，利用されるバージョ ンが分散する．その後，プロジェクトが同一のバージョンを選択し始める と，それ以後は，利用数に基づくバージョン選択が可能になる．

• 不具合の修正が収束し始めライブラリの品質が高まると，プロジェクトが 同一のバージョンを選択し始める傾向があるため，不具合の修正が収束し 始めると，利用数に基づくバージョン選択が可能になる．

本論文では，ライブラリのバージョン選択の方法として，不具合修正が収束し，

かつ，多くのプロジェクトが利用するバージョンが存在する場合，利用数の多い ものの中から利用するバージョンを選択することで，信頼できるバージョンを選 択することができると結論付ける．今後さらに，不具合数の予測について分析を 深めることで，不具合の修正が収束状況にあるのか，また，どのくらい待てば不