Comments
Description
Transcript
修士論文 オープンソースソフトウェアライブラリにおける バージョン選択の
NAIST-IS-MT1451090 修士論文 オープンソースソフトウェアライブラリにおける バージョン選択の分析 藤野 啓輔 2016 年 3 月 13 日 奈良先端科学技術大学院大学 情報科学研究科 本論文は奈良先端科学技術大学院大学情報科学研究科に 修士 (工学) 授与の要件として提出した修士論文である。 藤野 啓輔 審査委員： 松本 健一 教授 （主指導教員） 井上 美智子 教授 （副指導教員） 鷲崎 弘宜 准教授 （早稲田大学） 伊原 彰紀 助教 （副指導教員） オープンソースソフトウェアライブラリにおける バージョン選択の分析∗ 藤野 啓輔 内容梗概 本論文の目的は，オープンソースソフトウェア (OSS) として公開されているラ イブラリを利用するユーザが，そのバージョン選択を行う際の指針を示すことで ある．ライブラリの利用者は常に最新のバージョンを利用すればよいわけではな く，例えば大規模なシステムにおいては高品質さが指標となる．従来研究では， 群衆の英知に基づき，利用者の多いバージョンが推薦されているが，大量の利用 者が不具合の発覚を境にバージョンダウンする事例もあり，群衆の選択が常に良 い選択であるとは言えない．本論文では，新バージョンのリリース直後から安定 期にかけて，利用者がどのようにライブラリを選択しているかを調査し，ライブ ラリの選択指針をより詳細に示す．調査においては，ケーススタディとして四つ の著名かつ利用者数の多いロギングライブラリ (Log4j, Slf4j, Commons logging, Logback) の利用状況を分析する．分析の結果，リリース直後は利用者ごとに異な るバージョンを選択しているが，ある時期を境に単一のバージョンが多く利用さ れる傾向が明らかになったため，利用者のライブラリ選択が収束した後，従来の 方針で選択することが良いと考えられる．また，同一のバージョンが選択され始 める時期と，不具合修正が収束する時期が同時期であることも明らかとなった． キーワード オープンソースソフトウェア，ソフトウェアライブラリ，不具合修正曲線，ソフ トウェア信頼度成長モデル，群衆の英知 ∗ 奈良先端科学技術大学院大学 情報科学研究科 修士論文, NAIST-IS-MT1451090, 2016 年 3 月 13 日. i Analysis of Version Selecting on Open Source Software Library∗ Keisuke Fujino Abstract The principle aim of this paper was to provide a reliable guideline for software developers who want to use the open source software library. They should not always use the latest versions. For example, quality is important in the large scale systems. In the previous study, most popular version is recommended based on the wisdom of the crowds. However, there is the example that many users downgrade after reporting bugs in the library which they are using. Therefore, the wisdom of crowds is not always reliable when they select library. In this paper, to provide a reliable guideline, I investigate the version selection through the case study of 4 Java logging libraries (Log4j, Slf4j, Commons logging, and Logback) from the initial release to plateau. From the results, users select different version in the soon after initial release, but many users will come to use same version after a certain time. Therefore, after version selection of users converged, the wisdom of crowds is available to select version. In addition, I clear the extreme trend version increases as soon as the bug fixing curve begins to converge. Keywords: Open Source Software, Software Library, Bug Fixing Curve, Software Reliability Growth Model, The Wisdom of Crowds ∗ Master’s Thesis, Graduate School of Information Science, Nara Institute of Science and Technology, NAIST-IS-MT1451090, March 13, 2016. ii 関連発表論文 国際会議 1. Keisuke Fujino, Akinori Ihara, Kiyoshi Honda, Hironori Washizaki, and Ken-ichi Matsumoto, “Toward Monitoring Bugs-Fixing Process After the Releases in Open Source Software,” In Proceedings of the 6th International Workshop on Empirical Software Engineering in Practice (IWESEP 2014), November 2014. 国内会議（査読付き） 1. 藤野啓輔，伊原彰紀，本田澄，鷲崎弘宜，松本健一. OSS の不具合修正曲 線に基づく未修正不具合数の予測の試み. 第 21 回ソフトウェア工学の基礎 ワークショップ (FOSE2014)， pp. 57-62 2014． iii 目次 1. はじめに 1 1.1 背景と目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ライブラリの利用 4 2.1 ライブラリの機能と利用目的 . . . . . . . . . . . . . . . . . . . . 4 2.2 ライブラリのバージョン選択における課題 . . . . . . . . . . . . . 4 3. ライブラリ利用数の計測方法 6 3.1 ライブラリの管理方法 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 利用数計測の関連研究 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 分析対象 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 分析手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 分析結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. プロジェクト利用数とソフトウェア品質の分析 17 4.1 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 不具合の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3 不具合修正曲線の作成 . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4 分析概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5 分析結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. 不具合修正曲線へのソフトウェア信頼性曲線の適用 29 5.1 ソフトウェア信頼性曲線 . . . . . . . . . . . . . . . . . . . . . . . 29 5.2 アプローチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3 分析結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 iv 5.4 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. 結果の妥当性 33 7. おわりに 35 謝辞 36 参考文献 38 v 図目次 1 POM.xml ファイルの一例 . . . . . . . . . . . . . . . . . . . . . . 7 2 利用数計測の概略図 . . . . . . . . . . . . . . . . . . . . . . . . . 9 3 slf4j におけるプロジェクト利用数の計測結果: . . . . . . . . . . . 13 4 log4j におけるプロジェクト利用数の計測結果 . . . . . . . . . . . 14 5 logback におけるプロジェクト利用数の計測結果 . . . . . . . . . . 15 6 commons logging におけるプロジェクト利用数の計測結果 . . . . 16 7 不具合修正曲線の概略図 . . . . . . . . . . . . . . . . . . . . . . . 18 8 slf4j のプロジェクト利用数と不具合修正曲線 . . . . . . . . . . . . 25 9 log4j のライブラリ利用数と不具合修正曲線 . . . . . . . . . . . . . 26 10 logback のライブラリ利用数と不具合修正曲線 . . . . . . . . . . . 27 11 commons logging のライブラリ利用数と不具合修正曲線 . . . . . . 28 表目次 1 ロギングライブラリの詳細 . . . . . . . . . . . . . . . . . . . . . . 8 2 1 年間に修正された不具合数 . . . . . . . . . . . . . . . . . . . . . 20 3 ロジスティックモデルを用いた B 点における不具合修正数の予測結果 31 vi 1. はじめに 1.1 背景と目的 オープンソースソフトウェア（OSS）のリリース間隔は，年々短期化する傾向 にあり，リリース後 1 年以内に新たなバージョンをリリースすることが多い．特 に，Google Chrome や Mozilla Firefox では，数週間から数ヶ月の周期で次のバー ジョンを開発する超短期リリース（ラピッドリリース）に取り組んでおり，OSS のリリースサイクルは商用ソフトウェアに比べて極めて早い [1]．OSS プロジェク トがこのような開発体制を採用する理由は，利用者からの不具合修正要求や機能 追加要求へ迅速に対応し，OSS の機能・品質向上を効率化する狙いがある [2]． ソフトウェアライブラリ（以降，ライブラリ）もまた，OSS として世界中で開 発されており，ソフトウェア開発企業において利用されている．ソフトウェア開 発企業は，プログラムの一部にライブラリを組み込むことで，開発でよく使われ る機能を平易に実装することができる．ライブラリを利用する企業は，リリース された多くのライブラリの中から，自社の利用環境や目的に適したライブラリ， バージョンを選択し，開発に利用する． 昨今のソフトウェア開発において，ライブラリの利用は不可欠であるが，新し いバージョンが常に信頼できるバージョンとは限らないため，ライブラリのバー ジョン選択は容易ではない．新しくリリースされたバージョンは，過去のバージョ ンで報告された不具合の修正や機能拡張により，過去のバージョンより優れた機 能を持つ一方，不具合修正や機能拡張に伴うソースコードの修正により，新たな 不具合が混入することが多い [3]．そのため，ライブラリを利用する企業は，過去 のバージョンと新しいバージョンとを比較し，安定して利用できる品質，かつ， 必要な機能を持つバージョンを選択する必要がある． 従来研究において，群衆の英知 “The Wisdom of Crowds” [4] の考え方に基づく バージョン推薦が提案されている．群衆の英知とは，少数の専門家による意思決 定や結論よりも，多数の素人の意見の集合のほうが役に立つという考え方であり， たとえば，一般人の協調作業によって作成されるウィキペディアが典型的な例と して挙げられる．ライブラリのバージョン選択においては，多くのソフトウェア 1 開発プロジェクトが選択するバージョンは，機能性，他のライブラリとの互換性， ドキュメントが充実していることなど，複数の観点が他のバージョンよりも優れ ているという理由で，特定のライブラリにプロジェクトの選択が集中していると 考えられる．しかしながら，ライブラリを利用するプロジェクトは，不具合の報 告や類似機能を持つ競合ライブラリの登場などにより，頻繁にライブラリ，バー ジョンを変更すると考えられるため，一時点の利用数に基づいて選択したバージョ ンは，信頼できるバージョンか否かの判断が難しいと考えられる．従って，本論 文では，ライブラリの利用数の変動を理解し，利用数に基づくバージョン選択に 適した時期を明らかにするために，実際のライブラリの利用を分析する． 本論文における事前調査として，人気の高い 4 つの Java Logging Framework ライブラリ（slf4j, log4j, commons logging, logback）を対象とし，各ライブラリ の初期バージョンリリース後の約 10 年間において，当該ライブラリを利用する プロジェクト数の推移を調査した．調査の結果，分析対象ライブラリのリリース 当初は，各ライブラリにおいてリリースされた複数のバージョンに利用プロジェ クト数が分散し，利用プロジェクト数の多い 1 バージョンを特定することは容易 ではないことがわかった． 事前調査に基づき，本論文では，ライブラリの利用数と不具合の修正数の関係 を分析し，二つの観点を用いることで，バージョン選択の指針を示すことを目的 とする．本論文における取り組みの貢献として，ソフトウェア開発企業における ソフトウェア開発において，ライブラリのバージョン選択における一指標として 用いることが期待される． 1.2 Research Questions 本論文では，利用数に基づくライブラリのバージョン選択が有用か否かを判断 するための事前調査として，ライブラリの利用数の推移を分析し，プロジェクト のバージョン選択を時系列で調査した．調査結果から，多くのプロジェクトが同 一のバージョンを利用し始めるまでの期間では，利用数の多い 1 バージョンを特定 することが難しいため，利用数に基づくバージョン選択が難しいことがわかった． そのため，利用数に加えて，バージョン選択に影響する観点として不具合修正数 2 に注目し，利用数と不具合の修正数との関係を分析し，利用者が同一のバージョ ンを選択し始める時期を理解する．特に，以下の Research Question に答える． RQ1: OSS ライブラリの不具合修正曲線と利用数の変動は連動しているのか？ ライブラリのバージョン選択とライブラリの品質との関係を明らかにすること を目的とし，不具合修正が収束する過程で，ライブラリのバージョン選択がどの ように変化するのかを調査する． RQ2: 将来的に修正される不具合数をどの程度で予測できるのか？ ライブラリの不具合修正が収束傾向にあるか否かを理解する試みとして，将来 的に修正される不具合数を予測する．将来的に修正される不具合数を把握するこ とで，現状の不具合修正が収束しているか否かを知る手掛かりとなる． 1.3 本論文の構成 本論文の構成は以下のとおりである．続く 2 章ではライブラリの利用と管理に ついて述べる．3 章では，ライブラリの利用調査について説明し，4 章では，利用 数と不具合修正数の分析について述べる．5 章では，ソフトウェア信頼性曲線を 用いて，不具合修正数の予測ついて述べる．6 章では，本論文の妥当性について 述べ，最後に 7 章で本論文のまとめを述べる． 3 2. ライブラリの利用 2.1 ライブラリの機能と利用目的 ライブラリは，特定の機能を持つ複数のモジュールから構成されたプログラム の集合であり，ソフトウェア開発工程でよく使われる機能を平易に実装すること ができる．近年，多くの OSS ライブラリが公開されており，ソフトウェア開発 企業での利用が普及している．多くのライブラリの中でも特に，Java ライブラリ は人気が高く，Java Community Process1 が提供する標準ライブラリの他に，多 数のオープンソースライブラリが提供されている．例えば，Web アプリケーショ ンを開発する際には，GWT2 ，Spring3 ，Hibernate4 などのライブラリやフレーム ワークが利用できる．その他にも，プログラム実行時のログ出力，HTML 解析， SSH（セキュアシェル），暗号化などの機能を持つ多くのライブラリがある． ソフトウェア開発企業がライブラリを使用する背景には，ソースコードの再利 用によるソフトウェア開発工程の短期化，開発工程の短期化に伴う開発の低コス ト化，既存のソースコードの再利用による製品の品質維持などの狙いがある [2]． 第 1 章で述べたように，OSS プロジェクトがラピッドリリースの開発体制をとる ことにより，短い周期でアップデートが繰り返されるため，一つのライブラリ内 でさえ，機能の異なる多くのバージョンがリリースされている．ライブラリを利 用するソフトウェア開発企業は，開発環境の変化に伴い，利用するライブラリも 最新の環境や機能要件に対応したバージョンに変更する必要があるため，ライブ ラリを利用する限り，バージョン選択に迫られる機会が多い． 2.2 ライブラリのバージョン選択における課題 OSS プロジェクトがラピッドリリースの開発体制を取ることで，機能拡張や利 用者からの不具合報告への素早い対応に重点を置く半面，過去のバージョンで報 1 https://www.jcp.org/en/home/index http://www.gwtproject.org/ 3 https://projects.spring.io/spring-framework/ 4 http://hibernate.org/ 2 4 告された不具合修正や機能拡張に伴い，新たな不具合が混入することも知られて いる [3]．そのため，新たにリリースされるバージョンであるからといって，リ リース直後に利用を開始することが最善であるとは限らない．新しいバージョン のリリース後，社会で稼働するプロジェクトが利用を開始し始め，仕様や機能が 利用者のニーズを満たすものであれば，利用され続ける可能性がある．一方，新 たな不具合の報告や類似機能を持つ競合ライブラリの登場により，バージョンダ ウン，利用を停止するプロジェクトが現れ，利用が継続しないこともある．万が 一，ライブラリの導入後に脆弱性が発表され，ライブラリの変更やアップデート に迫られた時，大規模な (ミッションクリティカルな) システムであるほど，また， 導入後に企業が独自の拡張を行っていた場合などは，手戻りコストが増大するこ とも指摘されている [5]．ライブラリの導入後も，公式サイトの発表や Web ドキュ メント等に基づき，リリース毎の特徴を把握し，アップデートするか否かを継続 的に判断し，利用するバージョンを選択し続けなければならない． 本論文では，ライブラリの導入後に発生する手戻りコスト発生リスクを抑える ために，多くのプロジェクトが利用し続けるライブラリ/バージョンを選択する ことが重要だと考える．その理由として，多くのプロジェクトが継続的に利用し ているバージョンは，社会で稼働される中で，利用上の機能に問題がない，不具 合報告が少ない，Web ドキュメントが充実しているなどの要因が，他のバージョ ンより優れていると考えられるからである，そのため，社会で稼働するプロジェ クトがどのバージョンを利用しているのかを計測し，ライブラリのバージョン選 択への貢献を目指す． 5 3. ライブラリ利用数の計測方法 本章では，多くのプロジェクトが利用するライブラリとそのバージョンを特定 するために，Github で管理されている OSS プロジェクトを対象とし，対象 OSS プロジェクトが実際に利用しているライブラリをバージョン別に計測する．各プ ロジェクトがライブラリを利用し始めた時点から，2015 年 3 月 1 日までの期間に おけるバージョン選択の推移を分析することで，利用数に基づくバージョンに適 した時期を明らかにする． 3.1 ライブラリの管理方法 ソフトウェア開発プロジェクトの大規模化に伴い，プロジェクトが利用するラ イブラリ数も増加する．近年，ライブラリ数増加に伴い煩雑化するライブラリの 管理を容易にするため，プロジェクト管理ツールを用いてライブラリを一括管理 するプロジェクトが増加している． 代表的なプロジェクト管理ツールとして，Java プロジェクト管理ツールである MAVEN が広く知られている5 ．MAVEN は，プロジェクトのビルド，テスト，成 果物の配備などを管理するツールであり，プロジェクトが依存するライブラリ情 報を Project Object Model（以下，POM）ファイルで一括管理する機能を提供し ている．MAVEN のようなプロジェクト管理ツールが普及し，ライブラリが定め られた形式で一元管理されるようになったため，ライブラリの利用実績を，過去 に遡って計測することが可能となった． POM ファイルでは，ライブラリの情報を，図 1 のように＜ depedency ＞内に 記述する．また，＜ dependency ＞内では，以下の三つの子属性が記述される． • ＜ groupId ＞: ライブラリの開発元（企業，組織，グループ） • ＜ artfactId ＞: 企業や組織が開発したライブラリであることを示す • ＜ version ＞: ライブラリのバージョン情報 5 http://mvnrepository.com 6 図 1 POM.xml ファイルの一例 本論文では，＜ groupId ＞と＜ artfactId ＞が，MAVEN Repository6 の記載と 同じ組み合わせであれば利用数計測の対象とする． 3.2 利用数計測の関連研究 従来研究において，MAVEN でライブラリの管理を行っているプロジェクトを 対象として，ライブラリの利用数の計測を試みている．Mileva ら [6] は，本論文と 同様に，群衆の英知の考え方に基づき，ライブラリのバージョン推薦を行うシス テム AKTARI を開発している．AKTARI は，今現在のライブラリ利用数をバー ジョン別に計測し，最も多くのプロジェクトが利用しているバージョンを，開発 者に推薦するシステムである．Mileva らは，人気のあったバージョンに不具合が 報告されたため，多くのプロジェクトが，古いバージョンへとダウングレードし た事例を報告している． Mileva らの従来研究でダウングレードが起こった事例のように，ライブラリの 利用は，不具合の報告や類似機能を持つ競合ライブラリの登場などの影響を受け ると考えられる．従って，将来的な利用数の動向を予測することは難しく，一時 点のスナップショットにおける利用数のみによって推薦されるバージョンは，長 期的に利用できるとは限らない．Mileva らは，一時点のスナップショットにおい て，最も利用数の多いバージョンを推薦するシステムであったが，本論文では， 2005 年から 2015 年間を分析対象とし，分析期間の最終日である 2015 年 3 月 1 日 時点までの利用数をすべて抽出し，利用数の変動を理解することで，利用数に基 6 http://mvnrepository.com/open-source/logging-frameworks 7 表 1 ロギングライブラリの詳細 ライブラリ名 概要 運営期間 バージョン数 Log4j ログ出力ライブラリ 1999 年 10 月 15 日∼2012 年 5 月 6 日 62 Commons Logging ログファザードライブラリ 2002 年 8 月 13 日∼2014 年 7 月 9 日 10 Logback ログ出力ライブラリ 2006 年 2 月 9 日∼2014 年 4 月 2 日 60 Slf4j ログファザードライブラリ 2005 年 5 月 1 日∼2015 年 1 月 6 日 68 づくバージョン選択の有用性を確認する．次節から，対象とするライブラリの詳 細や利用数計測のアプローチについて述べる． 3.3 分析対象 分析対象ライブラリとして，MAVEN の Popular Category である Logging Frame- work から，利用ランキング上位 4 つのライブラリ（SLF4J API Module，Apache Log4j，Logback Classic module，ApacheCommons Logging）を選択し，各バー ジョンを使用しているプロジェクト数を数え上げることで，バージョン毎の利用 プロジェクト数の推移を分析する． Apache Software Foundation は，Apache ライセンスの下，OSS の開発，運営 を支援する非営利団体であり，年々プロジェクト数が増加している．1999 年に Apache Log4j の登場以後，2002 年に Apache Commons Logging がリリースされ ている．その後，Log4j の開発者の一人が SLF4J API Module，Logback Classic module プロジェクトを立ち上げ，昨今では Log4j の代わりに，この 2 つのライブ ラリを使用することも増えてきた．表 1 は本論文が対象とする各プロジェクトの バージョン数と運営期間を示す． 3.4 分析手順 本論文では，ライブラリ利用数の計測対象プロジェクトとして，Apache Software Foundation が Github 上に公開している OSS プロジェクト 5987 件の中で，プロ ジェクト管理ツール MAVEN を使用している 330 プロジェクトを選択した．調査 7 2015 年 3 月 1 日現在 8 <gr…>log4j <ver…>1.0 <gr…>log4j <ver…>1.0 <gr…>log4j <ver…>1.1 <gr…>log4j <ver…>1.0 <gr…>log4j <ver…>1.1 <gr…>log4j <ver…>1.2 変更履歴 Ver1.0 Ver1.1 Ver1.2 利用数の計測 2001/3/1 2005/8/1 2015/3/1 図 2 利用数計測の概略図 対象とした OSS プロジェクトは，POM ファイルを含めたソースコードを Github で管理している．本実験では図 2 に示すように，POM ファイルの変更履歴をた どっていくことで，各プロジェクトが使用するライブラリ，バージョンの変更履 歴を追跡する． 図 2 は log4j のライブラリ利用数を調査する流れを示す．たとえば，POM ファ イルの変更履歴の中で最も古い日付である，2001 年 3 月 1 日に変更が行われた POM ファイルを調べると，log4j の利用が確認できた．この場合，この日に log4j の Ver1.0 の利用を始めたとみなし，Ver1.0 の利用数に 1 をカウントする．次に， 2005 年 8 月 1 日に POM ファイルに変更があった POM ファイルを調べる．ここ で，2001 年 3 月 1 日の時点で，Ver1.0 を利用していたプロジェクトが，2005 年 8 月 1 日にも Ver1.0 を利用していた場合，このプロジェクトは 2001 年 3 月 1 日か ら 2005 年 8 月 1 日まで，Ver1.0 を利用し続けているとみなす．最後に，2015 年 3 月 1 日に POM ファイルの変更があった時，2001 年 3 月 1 日から 2005 年 8 月 1 日 まで Ver1.0 を利用していたプロジェクトが，Ver1.1 にバージョンアップをしてい た場合，そのプロジェクトは，2014 年 2 月 28 日まで Ver1.0 を利用し続け，2015 年 3 月 1 日に，Ver1.0 から Ver1.1 へとバージョンアップしたとみなす．このよう に，POM ファイルに変更があったすべての日付における POM ファイル変更を 調べ，その変更前後でのライブラリの利用を確認することで，バージョン別の利 用数を時系列データとしてグラフ化する． 9 2015 年 3 月 1 日の最終時刻 23:59 の時点で Github 上に存在する OSS プロジェ クトのうち，前節で述べた 4 種類の Logging Framework ライブラリを利用してい るプロジェクトをバージョン別に計測する． 3.5 分析結果 図 3，図 4，図 5，図 6 はそれぞれ，SLF4J API Module，Apache Log4j，Logback Classic Module，Apache Commons Logging を利用しているプロジェクト数をバー ジョン別に計測した結果である．本論文では特に，各ライブラリが利用され始め， 利用プロジェクトが異なるバージョンを利用している時期（図中の A 点）と，最 も多くのプロジェクトが利用するバージョンの利用プロジェクト数が，他のバー ジョンと比較して 2 倍に達した時期（図中の B 点）に注目し，ライブラリ利用数 調査のまとめを述べ，次に，各ライブラリにおいて特徴的な結果を述べていく． ライブラリ利用数調査のまとめ ライブラリが利用され始めてから，利用者が同一のバージョンを利用し始め る時期までは，利用数の多い 1 バージョンを特定することが難しく，利用数 に基づくバージョン選択が容易ではない． Logback を除く 3 つのライブラリの結果では，ライブラリの利用開始から時間 が経過すると，別々のバージョンを利用していたプロジェクトが特定のバージョ ンを選択し始める傾向があった．さらに，一度，多くのプロジェクトが同一のバー ジョンを選択し始めた後は，多くのプロジェクトが選択するバージョンが存在し 続ける．従って，利用者が同一のバージョンを利用し始めると，その後も多くの プロジェクトが選択するバージョンが 1 つ以上存在し続ける． SLF4J API Module 図 3 中の A 点では，Ver.1.4.3 や Ver1.5.8 をはじめとした複数のバージョンが利 用されており，利用するプロジェクト数に差が見られない．この時期には，新しい 10 バージョンが登場すると，すぐにバージョンの変更が起き，一つのバージョンを継 続して利用するプロジェクトは見られない．Log4j・Compiler Assisted Localization (CAL10N)8 との依存関係を改善，および，Open Service Gateway initiative (OSGi) 9 の不具合修正が行われた Ver.1.6.1 のリリース以降，同バージョンを選択する プロジェクトが多く，図中の B 点では，同バージョンを利用するプロジェクト数 が，他のバージョンの 2 倍になっている．その後，Ver.1.6.4，Ver.1.6.7，Ver.1.7.2， Ver.1.7.10 は，総利用プロジェクト数のうち約 50%以上が使用し，たとえ新しい バージョンがリリースされても利用プロジェクト数に大きな変動は見られなかった． Apache Log4j 図 4 中の A 点では，Ver1.2.8，Ver1.2.12，Ver1.2.13，Ver.1.2.14 などのバージョ ンの利用されているが，各バージョンにおける利用プロジェクト数には差が見られ ない．その後，利用者からの要望が多かった，ログの出力先を変更する Appender が実装された Ver1.2.14 の利用が増加し始め，図中の B 点では，同バージョンを 利用するプロジェクトが他のバージョンの 2 倍に増加している．その後 Ver1.2.16 がリリースされるまでの約 1 年半，全体の 50%以上のプロジェクトが Ver1.2.14 を継続して利用している．また，Ver.1.2.16，Ver.1.2.17 がリリースされると，そ れぞれ，最も利用されるバージョンとしてプロジェクトに選択されている． Logback Classic Module logback が利用され始めてから 3 年間は，プロジェクトが選択するバージョンが 点在している．図 5 中の A 点では，Ver1.0.9 を利用するプロジェクトが他のバー ジョンの 2 倍になっている．その後も多くのバージョンがリリースされているが， Ver1.0.9 のほか，Ver1.1.2 の利用され始めている． Apache Commons Logging 図 6 中の A 点では，プロジェクトが選択するバージョンは，Ver1.0.4，Ver1.1， 8 9 ResourceBundle クラスを提供する Java ライブラリ Java 言語に基づくサービスプラットフォーム 11 Ver1.1.1 の 3 バージョンに分散していた．図中の B 点では，Ver.1.1.1 を利用する プロジェクトが増加し，他 2 バージョンの利用数の 2 倍以上のプロジェクトが利 用している．その後も，総プロジェクト数の 50%以上が Ver.1.1.1 の利用を継続 し続けている．Ver1.1.3，Ver1.2 がリリースされた以後は，Ver1.1.1 からのバー ジョンアップが起こっているが，調査期間内では，Ver1.1.1 の利用が多いままで あった． 3.6 考察 本節では，ライブラリが利用され始めてからの経過日数によって，プロジェク トのバージョン選択に違いがある理由について考察する． 前節では，ライブラリ利用を調査するためのケーススタディとして，4 つのロ ギングライブラリの利用実態を調査した結果，時期によって，プロジェクトのラ イブラリ選択に違いがあった．その理由として，ライブラリの品質が低いことや， ドキュメントが不足していることなどが関係していると考える． OSS はリリース直後に利用者からの不具合報告を受け，徐々に品質を向上させ る傾向がある [7] ため，初期のバージョンでは，バージョンによって利用可能な環 境が異なることや，機能性が十分でないことが多い．また，独立行政法人情報処 理推進機構 (IPA) が実施した，企業における OSS 利用についての調査では，ソフ トウェア開発企業の約 5 割が，OSS を利用するメリットとして， 「関連情報がイン ターネット上に豊富に存在していること」を挙げている [8]．初期バージョンのリ リース当初は，ライブラリを利用するプロジェクトが少なく，Web 上で閲覧可能 なドキュメントなどが不足していると考えられる．すなわち，多くのプロジェク トが実際にライブラリを利用しながら，使い勝手がよいバージョンを模索するた め，プロジェクトが利用するバージョンが分散していると考える．その後，OSS プロジェクトが不具合修正や機能拡張を行いながら，ライブラリの品質を向上さ せることで，利用者の要望を満たすようなバージョンが登場し，当該バージョン の利用が増加する．さらに，多くの利用者が，Web 上で各バージョンの違いや特 徴などを共有し始めることでドキュメントが充実し，多くのプロジェクトが選択 するバージョンとして利用され続けると考える． 12 図 3 slf4j におけるプロジェクト利用数の計測結果: 13 図 4 log4j におけるプロジェクト利用数の計測結果 14 図 5 logback におけるプロジェクト利用数の計測結果 15 図 6 commons logging におけるプロジェクト利用数の計測結果 16 4. プロジェクト利用数とソフトウェア品質の分析 本章では，不具合修正数とライブラリの利用数の変化との関係を分析する．以 下で Research Question と実験手順について述べる． 4.1 概要 OSS であるライブラリは，機能拡張や不具合報告といった利用者の要望に対応 することで，徐々に品質を高めていく [7]．そのため，過去の問題が解決された新 しいバージョンは，過去のバージョンと比較し，利用者を獲得しやすいと考えら れる．また，Mileva らは，利用数に基づくライブラリの推薦システム AKTARI を開発する過程で，不具合が報告されたことが原因で，利用者がダウングレード した事例を報告している [6]．さらに，IPA の調査 [8] において，ソフトウェア開 発企業が抱える事業の約 4 割が，脆弱性へ対応するか否か，不具合の修正に手間 がかかるなどをデメリットとして回答している．このことから，OSS の利用に関 して，不具合の有無が利用者のバージョン選択に影響すると考えられるため，不 具合の修正数と利用数の推移との関係を分析する． また，不具合の修正数は，時間経過とともに収束する傾向を持つため，不具合 の修正数から利用数の変動を把握することが可能であれば，不具合修正数の収束 状況を観察することで，プロジェクト利用数が変動しやすい時期か否かの判断を 助けることができると考えられる． RQ1: OSS ライブラリの不具合修正曲線と利用数の変動は連動しているのか？ 4.2 不具合の管理 ソフトウェア開発プロジェクトには，リリースしたソフトウェアの利用者が直 面した不具合の報告や機能拡張の要求が寄せられ，1 日に 100 件以上の不具合が 報告されることもある [9]．一般的な OSS 開発では，世界中に点在する開発者同 17 図 7 不具合修正曲線の概略図 士が不具合に関する情報を共有するために，Bugzilla10 ，RedMine11 ，Jira12 など の不具合管理システム（BTS: Bug Tracking System）が利用されている．BTS で は，開発者あるいは利用者から報告された 1 つの不具合に対して 1 つの不具合票 を作成し，各不具合の修正の進捗を効率よく管理するためのシステムである． 各不具合票には，不具合の基本情報（重要度や優先度），不具合の詳細情報（不 具合の内容や不具合の再現手順），議論情報（不具合の内容や修正作業について の開発者同士の議論），状態遷移管理情報（不具合の状態管理を記録），の 4 種 類の情報が記録される．本実験では，不具合の状態管理情報を用いて，対象期間 内の不具合の状態が，修正済み，あるいは解決済みとなった時刻を修正完了時刻 とし，不具合の修正数を時系列で取得する． 18 4.3 不具合修正曲線の作成 本章では，修正完了した不具合数が収束する様子を観察するために，時間経過 とともに累積する修正済み不具合数を，不具合修正曲線として表現し，分析に用 いる．不具合修正曲線は，不具合票の修正完了時刻を元に，修正完了した不具合 から順にグラフ上にプロットした各点を，曲線としてつなぐことで作成する [10]． 曲線として表現することで，不具合の修正状況を曲線の傾きから直感的に読み取 ることができる． 本論文では，不具合修正曲線を用いて，不具合の修正数とライブラリの利用数 との関係を分析する．図 7 は不具合修正曲線の概略図を示している．横軸は，ラ イブラリの利用開始日からの時間経過を表す．縦軸は，観測時点における累積の 不具合修正数である． 表 2 は，不具合管理システムで管理されている，各プロジェクトにおける修正 済み不具合数である13 ．本論文で作成する不具合修正曲線は，これらの修正済み 不具合数の情報を用いて作成する．まず，不具合票から，修正が完了している不 具合を抽出する．本論文で実験に用いるライブラリでは，BTS として Jira を利用 している．Jira の場合，不具合の対応状況を表す Status が，RESOLVED，あ るいは，CLOSED であり，かつ，解決状況を表す Resolution が，FIXED に変 更された時刻を，不具合の修正完了時刻として扱う．そして，修正完了日が古い ものから順にグラフ上にプロットしていき，プロットを曲線で表すことで，不具 合修正曲線として可視化する．本章では，不具合修正曲線を用いて，時間経過に よって減衰していく不具合修正数と，ライブラリの利用数の推移との関係を分析 する． 10 https://www.bugzilla.org/ https://www.redmine.org/ 12 https://jira.atlassian.com/secure/Dashboard.jspa 13 2015 年 3 月 1 日現在 11 19 表 2 1 年間に修正された不具合数 Year Slf4j Log4j Logback Commons Logging 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 4 5 24 34 16 15 5 10 4 1 44 50 9 47 64 49 92 36 34 30 3 19 4 0 104 16 55 15 34 42 15 7 10 3 10 47 0 0 5 7 3 Total 118 481 288 85 4.4 分析概要 本章では，不具合修正曲線を用いて，不具合修正数の推移と，ライブラリの利 用数との関係を分析する．具体的には，事前調査で作成したライブラリ利用数の グラフと，不具合修正曲線とを同じ図に表し，不具合曲線の収束傾向とプロジェ クトのバージョン選択の傾向とを比較することで，不具合修正数とライブラリ利 用数の推移との関係を分析する． 4.5 分析結果 表 2 は，各ライブラリで 1 年間に修正された不具合数と，調査期間内に修正さ れたすべての不具合数を示している．また，図 8，図 9，図 10，図 11，は，3 章 で作成したプロジェクト利用数のグラフ上に，不具合修正曲線を追加した図を示 している．横軸は，時間経過を表し，左の縦軸は，ライブラリの利用数を表して いる．さらに，右の縦軸は，累積の不具合修正数を表している．次節で分析結果 20 とまとめを述べる． 不具合修正曲線とライブラリの利用数の変化を比較すると，プロジェクトが利 用するバージョンが分散している時期（図中の A 点）は，不具合修正曲線の傾き が大きい傾向にある．一方，利用が集中するバージョンが登場する時期 (図中の B 点) では，修正される不具合のうちの約 80%が修正されており，不具合修正曲 線の傾きが緩やかになっている．また，不具合修正曲線が収束傾向（不具合の修 正がほとんど行われない）にある時期では，他のバージョンの利用数と比較し，2 倍 3 倍以上のプロジェクトに利用されているバージョンが一つ以上存在する．結 果から，不具合修正曲線の収束に伴い，ライブラリの利用数が増加し，総利用数 の 40%∼50%以上のプロジェクトから選択されるバージョンが登場し始めている ことが分かった． 実験結果から，不具合修正が収束状態にある場合は，ライブラリを利用するプ ロジェクトのうちの 40%∼50%が利用するバージョンが存在することが確認でき たため，不具合修正が収束し始めると，利用数に基づくバージョン選択が有用で あると考えられる．一方，不具合修正曲線が収束していない場合は，プロジェク トの利用が，複数のライブラリに点在しているため，利用の多いバージョンを特 定することが困難であり，利用数に基づくバージョン選択が難しいと考えられる． 以下，まとめと，各プロジェクトにおいて特徴的な結果を説明する． ライブラリの利用と不具合修正数との関係まとめ 不具合修正曲線の傾きが大きい時期では，プロジェクトは異なるバージョン を利用している．一方，全修正不具合数のうち約 80%が修正される時期にな ると，利用が集中するバージョンが登場し始める．その後は，利用が集中す るバージョンが常に一つ以上存在する状況になるため，不具修正が収束して いる状況下では，利用数に基づくバージョン選択を行うことができる． Slf4J API Module 図 8 中の A 点では，複数のライブラリに利用数が分散している．この時期の不 21 具合修正曲線は，傾きが大きく，不具合修正が活発に行われていることが分かる． 一方，他のバージョンの 2 倍以上のプロジェクトが Ver1.6.1 を利用する B 点では， 全体の約 80%の不具合が修正されており，不具合修正曲線の傾きが緩やかになっ ている．その後，約 1 年後に Ver1.6.4 がリリースされるまで，同バージョンの利 用プロジェクト数は伸び続けている．また，2012 年 5 月には，全体の約 90%の不 具合が修正されており，Ver1.6.1 のほか，Ver1.6.4 を利用するプロジェクトが増 加している．その後は，Ver1.7.2 や Ver1.7.5 のように，多くのプロジェクトに選 択されるバージョンが次々登場し始める． Apache Log4 図 9 中の A 点では，利用が集中するバージョンが存在しない．この時期の不 具合修正曲線は，全体の約 60%の不具合が修正されているが，不具合修正曲線の 傾きは大きい．Ver1.2.14 に利用が集中する B 点以降では，不具合修正曲線の傾 きが徐々に緩やかになっていることが分かる．また，2010 年 4 月には，全体の約 90%の不具合が修正されており，不具合修正曲線の傾きも並行状態にあり，不具合 修正が収束状態にあると言える．不具合修正が収束する時期になると，Ver1.2.14， Ver1.2.16，Ver1.2.17 のように，プロジェクトが選択するバージョンが絞られて くる． Logback Classic Module 図 10 中の A 点では，利用が集中するバージョンが存在しない．B 点では，Ver1.0.9 を利用するバージョンが 6 プロジェクトと最も多い．B 点での不具合修正数を見 ると，全体の約 80%の不具合が修正されている．しかし，logback の修正曲線は， 他の 3 つライブラリの修正曲線と比較すると，不具合修正曲線の傾きが大きく， 不具合修正が収束しているか否かを判断することは難しい．しかしながら，修正 完了済みの不具合数の増加に伴い，Ver1.0.9 や Ver1.1.2 のように，利用数が伸び ているバージョンも確認できるため，他のライブラリの結果から，今後不具合の 修正数が収束状態に近づくにつれ，利用が集中するバージョンが登場すると考え られる． 22 Apache Commons Logging 2010 年 1 月に，全体の 50%以上の不具合が集中して修正されている．この他 にも，Commons Logging では，同日にまとめて不具合修正が行われている日が 目立つ．これは，既に解決済みでありながら不具合票に記載されている Status タグが未修正であった不具合票を，当該日にまとめて変更したことにより生じた 可能性がある．図 11 中の A 点では，Ver1.0.4，ver1.1 や Ver1.1.1 に利用プロジェ クトが分散していた状態が続いている．この時期に修正完了している不具合，全 体の 20%以下である．一方，B 点では全体の約 80%が修正されており，Ver1.1.1 の利用数が伸びている．また，その後も Ver1.1.1 の利用を継続して利用するプロ ジェクトが多いが，B 点以後の約 4 年間を見ても，修正された不具合数は 14 個と 少ない． 4.6 考察 本節では，本論文で対象としたライブラリのうち，3 つのライブラリ（slf4j， log4j，commons logging）において，不具合修正曲線が収束するにつれ，多くの プロジェクトが選択するバージョンが現れた理由を考察する． 前節で述べたように，OSS プロジェクトが修正する不具合数が逓減し，不具合 修正曲線が収束し始めると時期と，プロジェクトが同一のバージョンを利用し始 める時期は関係していると考えられる．OSS プロジェクトが不具合修正を行わな くなる理由として，(1) 不具合修正を繰り返すうちに，修正すべき不具合が報告 されなくなることや，(2) 利用者がライブラリを利用をしなくなり，プロジェクト が不具合への対応を止めることが挙げられる．本論文で対象としたロギングライ ブラリのうち，slf4j，log4j，commons logging の 3 つのライブラリでは，社会で 稼働するソフトウェア開発プロジェクトで利用され続けており，かつ，プロジェ クトが修正する不具合数が低減しているため，不具合修正曲線が収束している理 由として，(1) が妥当である．すなわち，これら 3 つのライブラリは十分な不具 合修正がなされたために品質が高まり，結果的に多くのプロジェクトから利用さ れるようになったと考えられる． 23 高品質のライブラリが多く利用される背景として，ライブラリ間の複雑な依存 関係が挙げられる．ライブラリ間に依存関係があれば，あるライブラリのバージョ ンを変更する際に，依存するライブラリでもまたバージョン変更を要する場合が ある．大規模な（ミッションクリティカルな）プロジェクトであるほど，利用ラ イブラリ数は増え，その間の依存関係も複雑になる．こうしたプロジェクトでは， 利用するライブラリに不具合が報告された際，変更に要するコストが増大するこ とが指摘されており，ライブラリのバージョン変更時の作業コストも高まると予 想される [5]．結果として作業工数削減のために，修正すべき不具合の多くが修正 済みであり，今後，不具合によるバージョン変更が発生するリスクの少ないライ ブラリが求められることになる． 24 図 8 slf4j のプロジェクト利用数と不具合修正曲線 25 図 9 log4j のライブラリ利用数と不具合修正曲線 26 図 10 logback のライブラリ利用数と不具合修正曲線 27 図 11 commons logging のライブラリ利用数と不具合修正曲線 28 5. 不具合修正曲線へのソフトウェア信頼性曲線の適用 第 4 章で述べたように，不具合修正数が収束し始める時期と，多くのプロジェ クトが同一のバージョンを選択する時期とが同時期であったため，利用数に基づ くバージョン選択に適した時期を把握するためには，不具合修正が収束している か否かを理解することが重要だと考えられる．本章では，任意の期間に修正が完 了している不具合数を学習データとし，将来に修正される不具合数の予測を試み る．将来的に修正される不具合数を予測することにより，対象のライブラリが今 後も継続的に多くの不具合を修正する場合は，不具合の修正が収束していないと 考えられる．一方で，修正される不具合数が少ない場合は，予測時点において不具 合の修正が収束していると考えられ，利用数に基づくバージョン選択を信頼して も良い時期だと考えることができる．従って，将来の不具合修正数を予測するこ とで．現状の不具合の修正が収束しているか否かを理解し，利用数に基づくバー ジョン選択を活用するか否かの判断を助けることができる．本論文では，ソフト ウェア信頼性曲線を用いて，将来に修正される不具合数を予測することで，不具 合修正の収束状況を理解する． 5.1 ソフトウェア信頼性曲線 開発のテスト段階において，ソフトウェアに残存する不具合数を予測し，累 積される不具合の発見数をソフトウェアの信頼度成長過程とみなす，ソフトウェ ア信頼度成長モデル (SRGM:Software Reliability Growth Model) に関する研究 がある [11]．実際の開発現場では，ソフトウェアの信頼性評価の基準として，発 見された不具合の累積数を計測する方法が広く用いられており，この観点に基づ く信頼性モデルとして，不具合の発見を確率過程とみなす非同次ポアソン過程 （NHPP:Non-Homogeneous Pois-son Process）モデル [12][13] や，時間経過や不具 合数の減少など，曲線の複雑な変化を近似するロジスティックモデルが研究され ている [14]． 従来研究において，ソフトウェアリリース後に累積する修正済み不具合数を俯 瞰する不具合修正曲線を提案し，不具合修正曲線にソフトウェア信頼性モデルを 29 適応させることで，修正された不具合修正数が時期によってどう変動し収束して いくのかの理解を試みている [10]．同論文では，信頼性モデルはそれぞれのモデ ル式に，観測地点までのリリース日からの経過日数，不具合修正数を学習データ として用いる．つまり，過去から予測モデル作成時点までの不具合修正数の時間 的変動を考慮し，不具合修正曲線の予測モデルを構築することを意味する．本章 では，以下の RQ2 に回答する． RQ2: 将来的に修正される不具合数をどの程度で予測できるのか？ 5.2 アプローチ 本節では，不具合修正曲線の収束状況を理解するためにソフトウェア信頼性曲 線を用いて，将来に修正される不具合数を予測する．現在の修正曲線が収束して いるか否かを理解するためには，将来修正される不具合数を把握することが重要 であるため，先ずは，信頼性曲線を用いて，どの程度の精度で将来修正される不 具合数を予測できるのかを分析する． 本論文では，slf4j，log4j を対象に，3 章，2 章の図中に示した B 点で修正完了 している不具合数を，どのくらい前から予測できるのかの特定を試みた．具体的 には，B 点以前のデータ（12ヶ月，9ヶ月．6ヶ月，3ヶ月前) を用いて予測モデル を構築し，実際の B 点における修正完了した不具合数と，予測した不具合数との 違いを評価する．なお，本章における分析対象として，不具合修正が収束してい ると考えられる slf4j と log4j のみを選出した． 5.3 分析結果 表 3 は，ロジスティックモデルを用いて，図 8，図 9 中の，B 点を予測点とし， B 点から 12ヶ月，9ヶ月，6ヶ月，3ヶ月前までの不具合修正数を学習モデルデータ として予測モデルを構築し，B 点で修正完了する不具合数を予測した結果を示す． 表 3 の各セルは，最右列に B 点で実際に修正完了する不具合数を示す．左から 2 列目∼5 列目の各セルでは，B 点で実際に修正が完了している不具合数を 100%と 30 表 3 ロジスティックモデルを用いた B 点における不具合修正数の予測結果 ライブラリ 12ヶ月前 slf4j 90 (106%) log4j 9ヶ月前 6ヶ月前 3ヶ月前 実際の不具合修正数 96 (98%) 101 (103%) 102 (104%) 98 (100%） 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 の不具合修正数を予測 した結果の違いについて考察する．slf4j の予測結果では，すべての予測時点（12ヶ 31 月，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 の不具合修正曲線は，不具 合修正が始まった当初から，緩やかに増減しているため，ロジスティックモデル が適さなかったと考えられる．従って，ロジスティックモデルとは異なるモデル を適用することで，予測精度が改善が見込める． 32 6. 結果の妥当性 本論文では，ライブラリの利用者が，信頼できるバージョンを選択するための 方針を示すことを目的とし，ライブラリのバージョン選択を調査した．第 3 章の 分析では，同ライブラリ内でのバージョン選択に注目したが，実際には同ライブ ラリ内のバージョン選択だけでなく，別のライブラリへ移行することもあるため， ライブラリ間での移行も踏まえ，より深く分析する必要がある． ライブラリの利用数と不具合修正数との分析では，不具合修正数の収束状況と， バージョン選択との関係を示した．第 2 章の分析では，不具合の修正数のみに注 目したが，修正された不具合の内容を考慮していない．ソフトウェアの不具合に 注目した研究は多く行われており，近年では特に，セキュリティやパフォーマンス に関する不具合などが，利用者に与える影響が大きい不具合（High Impact Bug） と呼ばれ，自動分類に関する研究が盛んに行われている [15][16]．本論文において も，High Impact Bug がどれだけ修正されているかに注目することは重要である が，High Impact Bug の自動分類は依然として難しく，いまなお，研究者が目視 で不具合票を読み，手動での分類がすることが多いため，データの確保が難しい． また，不具合修正に関する従来研究では，不具合の修正数だけでなく，不具合 の報告数をみることも多い．しかしながら，不具合として報告されたものの，報 告された不具合が再現できないため修正されないことや，過去に修正済みである 不具合が再度報告されることもある．故に，不具合報告数が不具合修正数が対応 しないことが多いため，本論文では，実際にプロジェクトによって修正された不 具合数のみに着目した． 不具合修正数の収束状況を分析するために，不具合修正曲線を作成したが，従 来研究での筆者の取り組みでは，不具合修正曲線を作バージョン毎に作成してい る．しかし，本論文ではバージョンの分類は行っていない．その理由として，本論 文で対象としたライブラリでは，不具合票にバージョン情報が記載していない不 具合も多かったため，各ライブラリの不具合をまとめ，ライブラリ全体でひとつ の不具合修正曲線を作成した．バージョン毎に不具合修正曲線を作成することが 望ましいといえるが，OSS ライブラリは拡張開発であるため，過去のバージョン で報告された不具合は，新しいバージョンでは修正済みである場合も多い．従っ 33 て，ライブラリ全体としての不具合修正曲線であったとしても，新しいバージョ ンは品質が向上していると考えられ，各バージョンの品質の向上を理解できると 考える． 第 5 章では，ソフトウェア信頼性曲線を用いて，不具合修正数の予測を試みた． 本論文では，信頼性曲線の中でも，よく利用されるロジスティックモデルを用いて 予測を行ったが，信頼性曲線の関連研究では，基本的な信頼性モデルの他に，開 発者の変化など，時間変化によって変化する不確実性を考慮したモデルの拡張な ども行われている．本論文においても，各プロジェクトの不具合修正曲線にフィッ ティングする信頼性曲線を適用することで，log4j における予測精度が期待でき る．また，第 5.3 節の不具合修正数の予測では，ライブラリ利用数のグラフ上に 示した B 点での修正不具合数の予測を試みたが，不具合修正曲線の傾きが異なる 複数の点において予測結果を比較することで，結果の妥当性を高めることができ ると期待される． 34 7. おわりに ソフトウェア開発においてライブラリの需要が高まる一方で，どのようにバー ジョンを選択を行うべきかのを示す選択指針が存在しない．本論文では，ライブ ラリを利用するユーザが，そのバージョン選択を行う際の指針を示すため，群衆 の英知に基づくバージョン選択に注目し，ライブラリの利用数を分析した．その 結果，プロジェクトがライブラリの利用を開始する時期では，プロジェクトが利 用するバージョンは分散しているが，時間経過により，多くのプロジェクトが同 一のバージョンを選択し始めるなど，時期によるプロジェクトのバージョン選択 の違いを明らかにした．また，不具合修正数とバージョン選択との関係も分析し た．特に，不具合修正の収束状況と，多くのプロジェクトが同一のバージョンを 選択し始める時期との関係に注目した結果，不具合修正数が収束し始め，ライブ ラリの品質が高まると，多くのプロジェクトが選択するバージョンが現れること がわかった．最後に，不具合の修正が収束しているか否かを予測する試みとして， ソフトウェア信頼性曲線を用いて，将来的に修正される不具合数の予測を試みた． 最後に，本論文で得られたライブラリ利用数に関する知見を以下に示す． • プロジェクトがライブラリを利用をし始める時期は，利用されるバージョ ンが分散する．その後，プロジェクトが同一のバージョンを選択し始める と，それ以後は，利用数に基づくバージョン選択が可能になる． • 不具合の修正が収束し始めライブラリの品質が高まると，プロジェクトが 同一のバージョンを選択し始める傾向があるため，不具合の修正が収束し 始めると，利用数に基づくバージョン選択が可能になる． 本論文では，ライブラリのバージョン選択の方法として，不具合修正が収束し， かつ，多くのプロジェクトが利用するバージョンが存在する場合，利用数の多い ものの中から利用するバージョンを選択することで，信頼できるバージョンを選 択することができると結論付ける．今後さらに，不具合数の予測について分析を 深めることで，不具合の修正が収束状況にあるのか，また，どのくらい待てば不 具合の修正が収束し，利用数に基づくバージョン選択が利用できるかを判断でき ると考えられる． 35 謝辞 本論文を進めるにあたり，多くの方々にご指導，ご協力，ご支援を賜りました． ここに謝意を添えてお名前を記させて頂きます． 主指導教員であり，本校の審査委員を務めて頂いた奈良先端科学技術大学院大 学 情報科学研究科 松本 健一 教授に対し，厚く御礼申し上げます．研究に取り組 む上での心構えから，研究者としての在り方まで，あらゆる面で熱心なご指導を 賜りました．本論文の執筆にあたり，基本的な言葉遣いから，短い言葉で簡潔に 内容を伝える重要さなど，時に優しく，時に厳しい意見を頂き，己の未熟さを省 みる機会を得ることができました．また，学術会議やカナダへの研究留学などで， 多くの資金援助をしていただけたことで，成長の機会を逃すことなく二年間を有 意義に過ごすことができました．松本先生のご尽力に心より感謝申し上げます． 副指導教員であり，本稿の審査委員を務めて頂いた奈良先端科学技術大学院大 学 情報科学研究科 井上 美智子 教授には，学内の研究発表において，研究目的 や意義について貴重な意見を頂き，論文の質を高めることができました．心より 感謝申し上げます． 早稲田大学理工学術院 基幹理工学部 情報理工学科 鷲崎 弘宜 准教授には，博 士前期課程 1 年の 5 月から修了に至るまで，研究に対する建設的なアドバイスを 賜りました．また，2015 年の 3 月から 1ヶ月間の研究合宿を行う案が出た際には， 私の受け入れを快諾して頂き，早稲田大学への訪問が実現しました．他大学で研 究を進めるという機会は，誰にでも与えられるものではないので，貴重な機会を 与えて頂けたこと深く感謝しています，また，研究室訪問の際，鷲崎先生をはじ めとする鷲崎研究室のメンバーにあたたかく受け入れて頂けたこと，一生忘れる ことはありません．先生の尽力に心より感謝申し上げます． 奈良先端科学技術大学院大学 情報科学研究科 伊原 彰紀 助教には，研究の進 め方から，普段の生活のことまで，数え切れない程多くのことを学ばせて頂きま した．思い返せば大学院入学当初，新入生歓迎会で初めてソフトウェア工学研究 室に訪問した際，先生に出会いました．研究室説明会後の食事会で，研究を熱く 語る姿に憧れを抱き，分野を変えることになろうとも，先生のもとで研究しよう と決断しました．今思い返しても，その決断に間違いはなかったと確信していま 36 す．研究成果だせず一人で悩む時期もありましたが，先生の支えがあったからこ そ，ここまで諦めることなく研究を進めることができました．心より感謝してお ります． 岡山大学大学院 自然科学研究科 産業創成工学専攻 計算機科学講座 門田 暁人 教授には，研究室ミーティングで研究についてのアドバイスを頂きました．いつ も的確かつ丁寧なご指導，建設的なアドバイスを賜りました．また，インターン シップの学生を研究室に迎える際には，得意のカレーを振舞って頂きました．研 究だけでなく普段の生活まで面倒を見て頂きました．心より感謝申し上げます． 奈良先端科学技術大学院大学 情報科学研究科 畑 秀明 助教には，入学当初から 気にかけて頂き，何も分からなかった私に，ソフトウェア工学に関する多くの研 究を教えて頂きました．また，いつも斬新なアイデアを持っており，その発想力 と柔軟さ，ソフトウェア工学分野の発展のため，積極的に他分野とのコラボレー ションに取り組む姿勢など，研究者として尊敬しています．研究のみならず，普 段の生活でも，積極的に話しかけて頂きました．心より感謝申し上げます． 早稲田大学 本田 澄 さんには，ソフトウェア信頼性曲線について，丁寧にご指 導頂きました．早稲田大学での研究合宿では，一ヶ月間付きっきりでご指導して いただきました．本田さんと多くの議論を重ねる中で，他の研究者の方とも臆す ることなく議論できるようになりました．私が教えて頂くことばかりでしたが， 大変感謝しております． Department of Computer Science and Software Engineering at Concordia University の Emad Shihab 先生には，4ヶ月の留学を受け入れて頂きました不慣れな 海外生活でしたが，いつも前向きな言葉をかけてくださったおかげで，研究に熱 中することができました．心より感謝申し上げます． 奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア工学研究室の皆様と は，大変仲良くさせて頂きました．皆様がいたからこそ，充実した二年間を過ご すことができました．修了後も苦楽を共にし，刺激し合える仲間として付き合っ ていける関係が続くことを願っています． 最後に，いつも私の判断を否定することなく，暖かく見守り支援してくれた家 族に深く感謝いたします． 37 参考文献 [1] Mika V Mäntylä, Bram Adams, Foutse Khomh, Emelie Engström, and Kai Petersen. On rapid releases and software testing: a case study and a semisystematic literature review. Empirical Software Engineering, Vol. 20, No. 5, pp. 1384–1425, 2015. [2] Frank McCarey, Mel Ó Cinnéide, and Nicholas Kushmerick. Knowledge reuse for software reuse. Web Intelligence and Agent Systems: An International Journal, Vol. 6, No. 1, pp. 59–81, 2008. [3] Michele Tufano, Fabio Palomba, Gabriele Bavota, Rocco Oliveto, Massimiliano Di Penta, Andrea De Lucia, and Denys Poshyvanyk. When and why your code starts to smell bad. In Proceedings of the 37th International Conference on Software Engineering-Volume 1, pp. 403–414, 2015. [4] James Surowiecki. The wisdom of crowds. Anchor Books, 2005. [5] Henrik Plate, Serena Elisa Ponta, and Antonino Sabetta. Impact assessment for vulnerabilities in open-source software libraries. In Software Maintenance and Evolution (ICSME), 2015 IEEE International Conference on, pp. 411– 420, 2015. [6] Yana Momchilova Mileva, Valentin Dallmeier, Martin Burger, and Andreas Zeller. Mining trends of library usage. In Proceedings of the joint international and annual ERCIM workshops on Principles of software evolution (IWPSE) and software evolution (Evol) workshops, pp. 57–62, 2009. [7] Eric Raymond. The cathedral and the bazaar. Vol. 12, pp. 23–49, 1999. [8] 独立行政法人情報処理推進機構. 第 3 回オープンソースソフトウエア活用ビ ジネス実態調査 (2009 年度調査), 2010. 38 [9] Philip J Guo, Thomas Zimmermann, Nachiappan Nagappan, and Brendan Murphy. Characterizing and predicting which bugs get fixed: an empirical study of microsoft windows. In Software Engineering, 2010 ACM/IEEE 32nd International Conference on, Vol. 1, pp. 495–504, 2010. [10] 藤野啓輔, 伊原彰紀, 本田澄, 鷲崎弘宜, 松本健一. オープンソースソフトウェ アの不具合修正曲線に基づく未修正不具合数の予測の試み. 第 21 回ソフト ウェア工学の基礎ワークショップ (FOSE2014), pp. 57–62, 2014. [11] 山田茂. ソフトウェア信頼性の基礎: モデリングアプローチ. 共立出版, 2011. [12] Richard Lai and Mohit Garg. A detailed study of nhpp software reliability models. Journal of Software, Vol. 7, No. 6, pp. 1296–1306, 2012. [13] Amrit L Goel. Software reliability models: Assumptions, limitations, and applicability. Software Engineering, IEEE Transactions on, No. 12, pp. 1411– 1423, 1985. [14] Rakesh Rana, Miroslaw Staron, Claire Berger, Jorgen Hansson, Martin Nilsson, and Fredrik Torner. Evaluating long-term predictive power of standard reliability growth models on automotive systems. In Software Reliability Engineering (ISSRE), 2013 IEEE 24th International Symposium on, pp. 228– 237, 2013. [15] Yutaro Kashiwa, Hayato Yoshiyuki, Yusuke Kukita, and Masao Ohira. A pilot study of diversity in high impact bugs. In 2014 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 536–540, 2014. [16] Emad Shihab, Audris Mockus, Yasutaka Kamei, Bram Adams, and Ahmed E Hassan. High-impact defects: a study of breakage and surprise defects. In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering, pp. 300–310, 2011. 39