【MSR2017】 Continuous Defect Prediction: The Idea and a Related Dataset
著者 Lech Maydeyski , Marcin Kawalerowicz
Abstract---
私たちは継続的バグ予測(Continuous Defect Prediction)研究のアイデアと私たちが作成したその研究に関連したデータセットを紹介しようと思う。私たちのデータセットは現在1100万行もあり、それらには継続的グレーション結果に私たちが持つソフトウェアリポジトリからマイニングしたデータを結合したビルド結果のファイルを含んでいる。私たちのデータセットには1265もの software projects を含み、それらには、30022 人もの commit authers や、以前からの研究で有効的であると判明したソフトウェアバグ予測の研究結果をもとにいくつかの software process metrix (ソフトウェア開発過程における基準)を採用したものが含まれている。この特定のデータセットの中で、継続的インテグレーションデータのソースとして TravisTorrent を使用した。TravisTorrent はTravis CI server と Github のオープンソースリポジトリから commit level information を提供してくれる。私たちはこのデータを file change level と software process metirix の計算ができるよう拡張した。この拡張により、例えば、もし継続的インテグレーションを有効にした repository に commit するとビルドを壊してしまいかねないような危険性の高い software change を予測するための性質、特徴として使用できる。
Introduction---
欠陥を起こしやすいモジュールやパッケージ、ファイルの定義付けは多くの研究者の興味をそそってきた。しかしながら、制限された資源やソフトウェア開発環境におけるタイトなスケジュールが研究者の興味をファイルやパッケージの定義付けから欠陥を起こす危険性の高いソフトウェアの変更の定義付けへと移行させる。私たちの長期間に及ぶ研究の目的は、欠陥を起こしやすいソフトウェアの変更(今のところは継続的インテグレーション結果を成功 / 失敗に制限している)を予測するために、機械学習(Machine leaning) ベースの予測モデルと大きなデータセット(オープンソースと、商業プロジェクトの両者から集めたもの)を用いたツールの支援によって Continuous Defect Prediction の実行(Practice) の提案することである。私たちは私たちの品質保証経験を継続的バグ予測の参考にしている。開発者たちは最新のコード変更が危険かどうか、また、もし 継続的インテグレーションを有効にしているリポジトリに commited/pushed/checked-in するとビルドを破壊してしまうかどうかを知らせるツールから継続的な feedback を受け取ることができるように。私たちは以前からのソフトウェア変更が問題ないかバグが存在しているかの分類という取り組み、仕事、研究(work)の上から(続きから？)ビルドをしている。←(このあたり曖昧なので詳しく訳していない)
しかし、すぐに知らせること(feedback)と、継続的に開発者に最も最新のコード変更がどれだけ危険性があるかfeedback することを心がけており、そして、このfeedbackのメカニズムをソフトウェア開発実践に埋め込んでいる。実はこのことは私たちの以前までの"Continuous Test-Driven Development" と”Agile Experimentation”の研究の延長である。これゆえ、私たちは今までの経験とこれまでの開発してきたツールの上でビルドを行っている。この論文では私たちは、欠陥を起こしやすいソフトウェア変更を定義するための、私たちの予測モデルを用いた大きなデータセットを共有する。
ビルドサーバ上での全てのビルドはたった1つまたは、1セットの commit (中央のリポジトリへの複数同時の commit and push)が引き金になりかねない。まず第一に私たちはそういった commit と、継続的インテグレーションのビルドに参加している全てのファイルの変更ごとに私たちが計算した測定項目のくくり(a set of metrics)を集めた。それらの測定項目(metrics)には、例えば、最後のビルドからの多数の修正コード数(a number of modified line(NML)) や、ビルドを commit した際のその日の現地時間(build commit local time of day(BCDTL)), そのビルドに含まれている多数の commiters (a number of distinct commiters(NDC)), 与えられたファイルに対する多数の訂正(改定?)(a number of revisions(NR)), ファイルがどこに含まれているかという最後のビルド結果の状態(last build status(LBS)),などが含まれている。私たちはそれらの測定項目を予測モデルをつくるための推測変数/独立変数などの特徴として使用した。
私たちは商業的な環境の中で実際にプロジェクトとして継続的バグ予測(CDP)に取り組んでいる。そこではビルドの成功/失敗の指標として、自社備え付けの Bitbucket から Jenkins CI build 結果を使用している。私たちはこの情報をGit repository から集めたデータと組み合わせている。しかし、秘密保持契約のため、私たちの含まれている商業プロジェクト以外の、多数のオープンソースプロジェクトから集めたデータのみを共有することができる。私たちは TravisTirrent のオープンデータベースプロジェクトの支援を受け集めたデータについて共有しようとおもう。TravisTorrent はTravis CI build server と GHTorrent から収集したデータを結合する。(GHTorrent--github のバージョン管理ホスティングサービスの API により供給されるオフラインのデータミラー)
TravisTorrent 上のデータは JRuby や Rails といった有名なオープンソースプロジェクトから集められている。TravisTorrent は commit はもっともきめ細かいデータの一部であり、commit level を蓄積している。順番に、私たちはファイル変更レベルに取り組んでいる。私たちにとって全ての CI build に参加している commit によるファイル変更は 重要な情報を私たちに知らせている。この情報を使用することで私たちは分類モデルをつくり、データをリポジトリにコミットする前に、build の出力結果を予測するために使用する。これに基づいて構築された予測モデルデータセットはこのデータペーパーの対象外である。
私たちは 30000 人以上の開発者が携わった 1265のGithub project の1100万行以上のデータを集めた。私たちは欠陥を起こしやすいソフトウェア変更予測や、ソフトウェア開発者の振る舞い、また、その他のソフトウェアエンジニアリング研究の分野に興味を持つ研究者の助けになることを願い、このデータを広く一般に利用できるようにした。
Data Collection and Storage---
私たちは以下に示す2つのソースからCDPに関連したデータを集めている。継続的インテグレーションプロセスと、バージョン管理システム(ソフトウェアリポジトリ)。継続的インテグレーションプロセスからのデータは CI server から集められている。CI server から提供される情報の中に、２つの興味深い情報があった。ビルド結果とそのビルド結果に含まれる commit または複数の commits のマークである。この情報は CI server の API を通して、または関連するデータベースをソースとしてなどで取得することができる。データベースを使用することは一時的なCI情報を処理することを助けている。関連するデータベースからのデータは、CIビルド情報の場合と同様に、通常はクリーニングされません。 最後のn個のビルド情報（例えば、ビルドの日時、その結果、ビルドログ）のみを保存して、CIサーバー上の記憶スペースに保存することが一般的である。
TravisTorrentデータベースを使用して、ビルド結果に関するデータを取得し、それらに含まれるビルドやコミット情報を取得します。 TravisTorrentは、オフラインミラー（GHTorrent）から取得したGitHubリポジトリデータと、APIを使用して取得した TravisCI server からの情報を合成します。 私たちは、travistorrent_11_1_2017テーブルへの問い合わせを、次のようにおこないます。
1) git trigger commit (hash of the commit which triggered the build),
2) gh project name (project name on GitHub),
3) gh pushed at (time of the push that triggered the build),
4) tr status (build result).
私たちは商業プロジェクトでのCDP研究で使用しているBitbucketデータベースに格納されたJenkins CIビルド結果にアクセスしています。 JenkinsとBitbucketはともに、銀行ソフトウェアを構築する会社に前もってインストールされています。 Jenkins CIとは別に、TeamCity CIサーバーAPIを使用してビルド結果を収集することも可能にしました。 私たちはGitのソース管理システムをサポートしていますが、このアプローチでは、この特定のシステムには何ら制限されません。 このアプローチをSubversion、Mercurial、その他のソース管理システムにまで拡張することが可能です。
選択されたCIサーバーによっては、ビルド結果の列挙が異なることに注意する必要があります。 表Iに示すように、成功、失敗、未知の3つの状態（例：ビルドが中断された場合、警告付きで終了した場合、またはCIサーバーによって不安定とマークされた場合）にマッピングします。
1つの特定のコミットまたは任意の数の異なるコミットに対して、CIサーバー上で1つのビルドを行うことができます。CIビルドに関わるコミットに関する情報は、CIサーバーAPIまたはデータベースから取得できます。 TravisTorrentデータベースに問い合わせて、私たちに必要な情報を取得します（前述のgit_trigger_commitカラムを使用）。
ビルドに関わる特定のコミットは、ソフトウェアリポジトリのブランチトポロジーツリーに基づいて計算されます。
次に、ソフトウェアリポジトリは、CDP用に収集された file level metrics のソースとして利用されます。これらの metrics は、予測モデルの項目です。その点で、データが収穫されたソフトウェアリポジトリのタイプ（Git、Subversion、Mercurialなど）は無関係です。現在、Gitリポジトリからデータを取得しています（具体的にはGitHub）。 TravisTorrentの場合のように、GitHub APIを使用しないことで、[10]で報告された帯域幅スロットリングに関する問題を回避しています。代わりに、すべてのGitHubリポジトリをローカルディスクに複製しています。データのソースとして、ローカルに格納されたコミット履歴を使用しています。結論から言うと、これはGitHubには何の問題もなく、必要な領域に関しても問題ではありません。私たちは、43GBを少し上回るディスク容量を占める1265のプロジェクトを複製しました。 Gitリポジトリ操作（クローン作成、コミット履歴の読み込み）を容易にするために、LibGit2Sharp1ライブラリを使用しています。
表IIは、ソフトウェアリポジトリから収集している metrics と、それらの取得方法に関する情報を示しています。 我々が使用しているソフトウェアプロセスメトリクスは、メディスキーとジュレチコ[11]が、いくつかのプロセスメトリック（NDCとNMLといいったもの）が製品メトリクスに基づいてソフトウェアの欠陥予測モデルを大幅に改善できることを発見したことからインスピレーションを受けています。 これらのメトリックと合わせて、データセットには以下も含まれます。
1) Project name
2) File path
3) Commit hash
4) Build commit hash
5) Export date (time stamp of the moment the data were collected)
データは、単純なMicrosoft SQL Serverデータベースに格納されます。メトリックを格納するデータベースの一部（表メトリック）を表IIIに示します。 データベースにある欠陥予測要求および分類モデルのためのテーブルの残りの部分は、このペーパーの範囲外のため提示しない。
Description of Dataset---
この記事の執筆時点では、メトリックデータベーステーブルに11,464,816行（CIビルドを行ったファイルをはじめとする）を含むデータセットを収集しました。 metrics は、TravisTorrentデータベースに集められた1265件のプロジェクトで収集されました。 異なるプロジェクトの行数(取得したデータセットのもの)は大幅に異なります（最小値は1、最大値は2706617、第1四分位数は405、第3四分位値は2876、中央値は938、平均値は9063）。 図1は、プロジェクトの行数のヒストグラムを対数スケールでプロットしたものです。 私たちのデータベースには30,022人の異なるコミット者がいます。 興味深いことに、私たちのデータベースには少数のデータ行しか持たない多数のプロジェクトがあります。たとえば、データレコードが1000件未満の657件のプロジェクトがあります（図1の1e + 03マーク）。 これらのプロジェクトのすべてのコミットが1000未満のファイルを変更したことを意味します。
私たちは、データベース内の最大の10個のプロジェクト（最も行が多いもの）と無作為に選ばれた10個のデータベース（以下のSQLコマンドを使用して。)
select top 10 ... order by newid（）
行数がデータベースの平均よりも大きいプロジェクト。
図2には選択したプロジェクトの名前が、表4にはこれらのプロジェクトのメトリックの要約データが示されています。
私たちのCDP研究では、オープンソースリポジトリとクローズドソースレポジトリの両方で作業しています。 ここでは、商業/非公開ソースソフトウェアプロジェクトなどの他の環境(context)には一般化できない脅威をもたらすデータセットを除いたオープンソースベースの部分のみを共有します。 我々が構築したTravisTorrentデータセットは、TRAVIS CI使用の履歴(50ビルドより大きいもの)を持つRubyやJavaの非フォーク、非おもちゃ、いくらか有名な（GITHUB上の10人より大勢のウォッチャーの存在）などをプロジェクトにフィルタリング基準を設けてプロジェクト空間を制限したことにも言及する価値があります。
この論文の目的は、私たちが共有したデータセットを簡単に説明することです。しかし、研究者としての私たちの役割は、一般にこのデータペーパーの範囲を超えていても、データを収集するだけでなく、それらを理解に変換することです。興味深い洞察やアイデアの例として、提供されたデータセットで今後の研究の質問に答えることができるようにするため、10の大きな大規模プロジェクトと10のランダムに選択されたプロジェクトのビルドコミット時間のボックスプロットを示します。これらの小さなサンプルがある程度代表的であると仮定すると、このプロットから2つの興味深い仮説を立てることができます。図2と表4から得られた最初のものは、大規模なプロジェクトの場合、CIビルドをトリガするコミットは昼間の後半で行われますが、それは平均ではより早く行われます。 2つ目は、オープンソースプロジェクトの統合(integration)は一般的に午後8時より前に行われるため、平均的なオープンソース開発者は、通常思われているようなナイトフクロウではないということです。実際には、ビルドは通常のbusiness時間内（午前9時から午後5時）に行われたコミットに基づいて行われます。
Future Work and Conclusions---
この論文で紹介したデータセットを使用して、成功/失敗継続的な統合の継続的な予測のための予測モデルを作成しています。 私たちは現在、この論文の著者の一人が管理する企業の商用ソフトウェア開発環境で指導者(pilot)としてCDPプロジェクトに取り組んでいますが、CDPプロジェクト全体をデュアルオープンソースと商用ライセンスを使用してデータを収集するためのツールとともにリリースします。我々は、収集したデータセットを、他の研究者による既存の研究結果をもとに、我々の予測モデルの特徴として使用することができる、より多くの metrics で豊かにするつもりである。 クラウドプロバイダーの協力を得て、オープンソースプロジェクトの開発を支援するために、Web上で予測モデルをすぐに利用できるように公開することも可能です。
データベースを公開することで、プロジェクトへの聴衆やフィードバックを引き付けるとともに、新しいメトリクスや新しい種類のメトリックによってデータセットを強化し、より多くのデータセットからのデータセットに基づいて予測モデルを構築する 1000人のソフトウェアプロジェクト、さらには独自の開発者、または実務者に有用な他の従属変数を予測することができます。 当社のデータが将来の研究に役立つ可能性がある分野には、ソフトウェア変更レベルの欠陥予測、長年にわたるソフトウェアプロジェクトの安定性と成熟度調査、開発者の活動と結果の調査、または一定期間にわたる継続的な統合の傾向の調査が含まれます。
このデータベースは、figshare2とMicrosoft SQL Server 2012ダンプファイルのCSVファイルとして利用できます。
Acknowladgment---
TravisTorrent [7]の著者たちに感謝したいと思います。TravisTorrent [7]は、私たちが目的に使用できるように拡張できる一連のデータを提供しました。 CODEFUSION社の従業員に貴重な情報とツール開発の助けをしてくれたことに感謝したいと思います。
【Github】Push の Reject されるエラーについて
Github 上にリモートのリポジトリを作成し、自分の PC のローカルのリポジトリとつなげて研究に使用しているプログラムのコードを管理しようとした。
そのため、ローカルにリポジトリを作成し、自分の Github のアカウントにもリモートのリポジトリを作成、そして最初に Push するところまではうまくいった。
その後、プログラムを新たに作成し、この変更を以下のようにリポジトリに反映。
その後、push しようとすると、以下のようなエラーが。
タイトルにもあるように reject されているのがわかる。
自分も Github 初心者なのでこの問題の解決方法についてまとめる。
解決方法
とりあえずエラーメッセージとともにヒントが出力されているので従ってみる。
エラーメッセージには、自分のローカルにないファイルがリモートにあるため反映が拒否されたとある。よくよく考えてみると、readme を作成していなかったため、リモートで直接作成したものが原因であるようだ。そのため、そのファイルをローカルにも反映させてこいといっており、ヒント通り pull を行う。
ちなみにgit pull はリモートの最新情報をとってきて(fetch)、反映させる(marge)この2つを行っている。これでとりあえず、リモートでの変更がローカルに反映された。その後ローカルの変更をリモートに変更するために再度 push を行ってみる。
すると今度は reject されることなく反映された。無事解決。
要するにリモートでの変更はきちんとローカルに反映させてからじゃないと push できないのかな？？
そもそもリモート上で編集することがあまりないか。
と、いろいろ考えながら今日はこのあたりにしておく。また詳しいことがわかり次第追記しようと思う。
ちなみに、今使っている Github のアカウントは Education 版であるため、 Private なリポジトリを作成できる。
Rによるクラスター分析【ユークリッド距離】
いよいよRによるクラスター分析を行う。その前にクラスター分析について簡単にまとめる。
クラスター(cluster)とは、英語で房、群れ、集団という意味があり、異なる性質のものが混ざり合った集団の中から、互いに似た性質のものを集め、似た者同士の集団を作り出し、分類する分析手法である。これはあらかじめ分類の基準が決まっているわけではなく、あくまでも似た者同士で集団を作り分類する分析方法である。
クラスター分析についてわかりやすくまとめてあるサイトを見つけたので参考までにURLを↓
今進めている研究では、とりあえずクラスター分析を試してみるという意味も含めて、クラスター分析の中でも有名なユークリッド距離を計算して分類をおこなう。
ユークリッド距離については省略するが、一応URLを↓
さすがはR、ユークリッド距離計算も非常に簡単、たった1行である!!
distance <- dist(data)
これで、distanceという変数にdataの中に入っているデータのすべての組み合わせの距離計算結果が入っている。dist 関数、非常に便利である。恐るべきRの便利さ。
ちなみにこの結果を出力してみると、
こんな感じ。dataの中に24のプロジェクトデータが入っていたため、このようにすべてのユークリッド距離計算結果が出力される。
さて、ここからいったんこの計算結果をファイルに出力しようと思う。
dist 関数は結果を行列でもデータフレームでもなく、dist クラスのオブジェクトとして返す。ファイルに出力するのは write.scv() 関数を用いようと思っているので、as.matrix() 関数を用いてオブジェクトを行列に変換し、出力する。
data.matrix <- as.matrix(distance)
write.csv(data.matrix,file="Euclidian_Result.csv")
とりあえずこんな感じにしてみた。ここまでRを使ってきた感覚から、もっとコードをすっきりかけるんだろうと思いながらいったん実行。するときちんとファイルが生成されていた。中身を確認すると、
こんな感じに。もともと dist 関数使用した結果のものは下三角行列のようになっていたものが as.matrix 関数使用後は対称行列に変換され出力されていた。
とりあえず目標としていたところまでこれたのでひと段落。
outlierTest() 結果
cat("【影響力のある観測地を特定】\n")
library(car)
print(outlierTest(m))
に対して実行結果↓
【影響力のある観測地を特定】
No Studentized residuals with Bonferonni p < 0.05
Largest |rstudent|:
rstudent unadjusted p-value Bonferonni p
2 2.917845 0.010061 0.24147
ボンフェロー二法による p 値調整結果、信頼できる 0.05 以下の p 値を得る標準化残差はなし。
【R】 線形重回帰結果のグラフ
Ｒで線形重回帰を実行すると4つのグラフをプロットすることができる。
以下にその４つのグラフの見方を簡単にまとめる。
１．Residuals vs Fitted
残差と線形重回帰による予測値の２要素による図。縦軸が残差、横軸が予測値である。これは線形性がない(non-liner relationship)ほど良いグラフと言えるようだ。そのため、作成されたグラフに赤で引かれている線が水平になっていればいるほど良い、ということになる。
２．Normal Q-Q
データの正規性を見るためのグラフである。これは残差の分散を視覚的に表している。正規分布に従っていればデータは直線上に並ぶようになっている。Q-Q 分布に関する知識がなかったため、以下のサイトで少し学習。
サイトに目を通してみたものの、まだわからないことは多いがこれはまた必要になったときに詳しく学ぶこととする。さて、この分布は得られたデータと理論分布を比較し、その類似度を可視化しているようだ。このグラフにおいてはプロットされている値が直線上に乗っていればいるほど良いグラフとなる。
３．Scale - Location
このグラフは Spread - Location とも呼ばれ、残差が予測した範囲内に均等に散らばっているかを可視化している。これもまた、プロットされたグラフにある赤色の線が水平になっていればいるほど良いものとされている。縦軸はどうやら標準化残差の絶対値にルートをとったもののようだ。残差の変動状況を考察するために使用しているとも。
ここに関しても勉強不足である、、、
標準化残差について↓
４．Residuals vs Leverage
１つのデータがモデルにどれだけ影響を与えているか示すグラフ。Cook's distance が 0.5 を超えると影響力があり、それが１を超えると非常に大きな影響力を持っていると判断することができる。要するに、特異値を判断する際、このグラフから Cook's distance が 0.5 以上のものに絞って調べるなど活用できそうだ。
参考にしたサイトを以下に示す↓
data.library.virginia.edu
Atom のインストール
Atom とはテキストエディタの一つでどうやら非常に優秀なもののようだ。自分自身あまり Atom に関する知識がなかったのでいろいろ調べてみた結果を軽くまとめてみる。
特徴としては、無料であることと、オープンソースなので拡張性がある点があげられそうだ。様々なサイトを見ていると、やはりオープンソースで開発されており、パッケージをダウンロードすることで自分好みにカスタマイズできる点と、そして尚且つこれが無料で利用できる点に多くの Atom ユーザは魅せられているようだ。自分好みにいろいろ拡張できるのは非常に良いかもしれない。
とりあえず、公式サイトからインストールしてみる。
無料だから雑なつくりだろうと思っていたら、かなりの完成度の高いウェブページに驚いた。とりあえず Windows 64bit版でバージョンは 1.26.1 。インストールはわりとすぐに終わった。インストール方法は以下のページを参考にした。
インストールしてから Atom の拡張性の凄さを感じることとなる。
インストールしてデフォルトの状態では言語は英語なので、日本語のパッケージをインストールしてみる。パッケージのインストールは簡単で、パッケージ名を検索すると候補がいくらかヒットし、そこから選ぶ形である。あっという間にインストールもおわったとおもうと、すぐに日本語を適応することができた。非常に簡単。パッケージを一度インストールすると後はそのパッケージを有効にするかは簡単に操作できる。非常に便利で簡単。ただ、パッケージをやみくもにインストールしまくると重くなりそうなのでしっかり選別はしないと。その結果いれたパッケージは、R言語に対応させるもの、アイコンをカスタマイズするもの、プログラムのソースの全体像を右に小さく表示させるもの、csvファイルをExcelみたいに表で表示するものくらいだろうか。パッケージはいろいろあるのでどんどん探していこうと思う。
Atom を入れて少し日がたってしまったため、内容が薄い文章になってしまったことは反省、、、
そろそろRを触りはじめよう。
