JP2018018267A - ソフトウェア開発支援装置、ソフトウェア開発支援方法及びプログラム - Google Patents

Abstract

【課題】ソフトウェア開発における不具合発生を検出するソフトウェア開発支援装置を提供する。【解決手段】ソフトウェア開発支援装置は、コミットが、当該コミットよりも以前にされた他のコミットにおいて混入されたバグを修正する更新であるか否かを、当該コミットにおいて変更されたソースコードの情報に基づいて判断し、バグ修正であるコミットを検出するバグ修正コミット検出部と、当該コミットがバグを修正する更新であると検出された場合に、当該コミットにおいて修正されたバグを混入した前記他のコミットのリビジョンを検出するバグ混入リビジョン検出部と、バグを混入した前記他のコミットのリビジョンを特定する情報を記憶するデータベースと、を備える。【選択図】図２

Description

本発明は、ソフトウェア開発支援装置、ソフトウェア開発支援方法及びプログラムに関する。

ソフトウェア開発における不具合の発生には、様々な原因が考えられる。例えば、同じソースコードを編集したとしても、開発者の技術に応じて不具合発生率に差異が生まれる。また、同一開発者がプログラミングをしたとしても、開発内容の難易度やプログラミングを行った曜日や、時間帯によって不具合発生率に違いが生じる。

これらの不具合を検出するために様々な機械学習を活用した手法が開発されている。不具合発生に規則性が存在すると、不具合の検出の精度及び速度を向上することが可能となる。一例として、非特許文献１に記載されているように、これらの不具合を検出するために様々なパラメータや機械学習のアルゴリズムを利用した手法が開発されている。

特開２０１６−２４７８４

T. Hall, "A systematic Literature Review on Fault Prediction Performance in Software Engineering," IEEE Trans. on Software Engineering, Nov. 2012, Volume 38, Issue 6, page 1276.

本発明が解決しようとする課題は、ソフトウェア開発における不具合発生を検出するソフトウェア開発支援装置を実現することにある。

一実施形態に係るソフトウェア開発支援装置は、
コミットが、当該コミットよりも以前にされた他のコミットにおいて混入されたバグを修正する更新であるか否かを、当該コミットにおいて変更されたソースコードの情報に基づいて判断し、バグ修正であるコミットを検出する、バグ修正コミット検出部と、
当該コミットがバグを修正する更新であると検出された場合に、当該コミットにおいて修正されたバグを混入した前記他のコミットのリビジョンを検出する、バグ混入リビジョン検出部と、
バグを混入した前記他のコミットのリビジョンを特定する情報を記憶する、データベースと、
を備える。

一実施形態に係るソフトウェア開発支援方法は、
バグ修正コミット検出部が、コミットが当該コミットよりも以前にされた他のコミットにおいて混入されたバグを修正する更新であるか否かを、当該コミットにおいて変更されたソースコードの情報に基づいて判断し、バグ修正であるコミットを検出するステップと、
バグ混入リビジョン検出部が、当該コミットがバグを修正する更新であると検出された場合に、当該コミットにおいて修正されたバグを混入した前記他のコミットのリビジョンを検出するステップと、
データベースに、バグを混入した前記他のコミットのリビジョンを特定する情報を記憶させるステップと、
を備える。

一実施形態に係るプログラムは、
コンピュータに、
コミットが、当該コミットよりも以前にされた他のコミットにおいて混入されたバグを修正する更新であるか否かを、当該コミットにおいて変更されたソースコードの情報に基づいて判断し、バグ修正であるコミットを検出する、バグ修正コミット検出手段、
当該コミットがバグを修正する更新であると検出された場合に、当該コミットにおいて修正されたバグを混入した前記他のコミットのリビジョンを検出する、バグ混入リビジョン検出手段、
バグを混入した前記他のコミットのリビジョンを特定する情報を記憶する、記憶手段、
として機能させる。

本発明によれば、ソフトウェア開発における不具合発生の規則性を機械学習により抽出することにより、不具合の検出の精度及び速度を向上することが可能となる。

一実施形態に係るソフトウェア開発支援装置の使用態様を示す図。 一実施形態に係るソフトウェア開発支援装置の概略を示すブロック図。 一実施形態に係るソースコードコミット時の動作を示すフローチャート。 一実施形態に係るバグ修正コミット判断の動作を示すフローチャート。 コミットがバグ修正であるか否かを判断する判断基準の一例を示す図。 一実施形態に係るバグ混入パラメータの学習動作を示すフローチャート。 一実施形態に係るソフトウェア開発支援装置の使用形態の別の例を示す図。

以下、図面を参照して、本発明の実施形態について説明する。本実施形態は、本発明を限定するものではない。

図１は、本実施形態に係るサーバを用いたソフトウェア開発の状態を示す図である。図１に示すように、ソフトウェア開発支援装置１とクライアント２は、有線又は無線のネットワークを介して接続されており、ソフトウェア開発者は、クライアント２を用いて作成又は修正したソースコードが含まれるファイルを、ソフトウェア開発支援装置１へとネットワークを介して送信する。以下、このクライアント２からソフトウェア開発支援装置１へのファイルの送信操作のことをコミットという。

コミットされたファイルに記載されたソースコードは、ソフトウェア開発支援装置１内に記憶され、クライアント２からネットワークを介して変更履歴等が参照できる状態となっている。このソフトウェア開発支援装置１を用いることにより、複数の開発者が同一ファイル内のソースコードを修正している場合においても、開発者間でファイル及びソースコードを共有することができる。

図２は、ソフトウェア開発支援装置１の構成を示すブロック図である。この図２に示すようにソフトウェア開発支援装置１は、バージョン管理部１０と、バグ情報学習部２０とを備えて構成される。このソフトウェア開発支援装置１は、例えば、Ｔｒａｃ、Ｒｅｄｍｉｎｅ、Ｂｕｇｚｉｌｌａ等のバグ管理システムやプロジェクト管理システムにより構成される。

バージョン管理部１０は、例えば、ｇｉｔ、Ｍｅｒｃｕｒｉａｌ、Ｓｕｂｖｅｒｓｉｏｎ、ＣＶＳ（Concurrent Versions System）、ＢｉｔＫｅｅｐｅｒ、ＡｌｉｅｎＢｒａｉｎ等の分散型又は集中型のバージョン管理システムにより構成される。このバージョン管理部１０は、ソースコード入力部１００と、ソースコードデータベース１０２と、変更履歴データベース１０４と、リポジトリ情報出力部１０６と、変更箇所検出部１０８と、変更行数計数部１１０と、を備えて構成される。この他、ソースコードのマージをするためのマージ部など所謂バージョン管理システムの基本的な構成を備えていてもよい。

ソースコード入力部１００は、図１のクライアント２からファイルのコミットがされた際に、そのファイルが入力され、ソースコードデータベース１０２へファイル内に記載されたソースコードを記録する。

ソースコードデータベース１０２は、コミットされたファイルに記載されたソースコードを記録し保持するためのデータベースである。本実施形態においては、このソースコードデータベース１０２は、ファイルごとにソースコードを記録するが、モジュールごと、或いは、ファンクションごとにソースコードを記録するものであってもよい。

変更履歴データベース１０４は、コミットされたファイルが、既にソースコードデータベース１０２に記録されているソースコードに関するファイルである場合に、それらのソースコード同士の差分を変更履歴として記録するためのデータベースである。なお、ソースコードデータベース１０２や変更履歴データベース１０４などの各データベースは、ＳＳＤ（Solid State Drive）やＨＤＤ（Hard Disc Drive）等の記録媒体により構成される。

また、データベースとしては、これらの他に図示しないバイナリファイル用のデータベースがあってもよいし、ソースコードデータベース１０２にバイナリファイルを記録できるようにしてもよい。また、ソースコードデータベース１０２に記録されるファイルは、ソースコードを記載したファイルには限られず、ライセンス情報に係るファイルであったり、ソースコードの使用方法を記載したドキュメントであったり、注意書きが書かれたテキストファイルであったりしてもよいし、これらに限られず、必要なファイルを記録するものであってもよい。さらに、ファイル自体を入力するものではなく、ファイルの属性等が変更されたファイルがコミットされた際に、これらの属性等を記録するものであってもよい。以下、これらのデータベースをまとめてリポジトリといい、各コミットを識別する識別子、例えば、シーケンシャルに付された識別番号をリビジョンという。

上記においては、ソースコードデータベース１０２には、コミットされたファイルが記録されるものとしたが、これには限られず、例えば、各ファイルにおいて、最初にコミットされた情報を記録しておき、現状のファイルを出力する際に、変更履歴データベース１０４に記録されている当該ファイルの変更履歴を過去から現在へと順に走査することにより現状のファイルを再構成し、出力するものとしてもよい。また、逆に、変更履歴データベース１０４は、各ファイルの変更リビジョンの番号等の識別子を記録しておき、変更履歴を出力する際に、ソースコードデータベース１０２における各リビジョンのファイルを比較することにより差分を出力するようにしてもよい。

リポジトリ情報出力部１０６は、クライアント２からの指令により、クライアント２へリポジトリ内にある情報を出力する出力部である。この出力は、クライアント２へファイルを転送することにより出力してもよいし、ブラウザを介してクライアント２に接続されているモニタへ表示させるものであってもよい。出力する情報は、ソースコードデータベース１０２等のデータベースに記録されているファイルや変更履歴データベース１０４に記録されている変更履歴である。また、変更履歴データベース１０４に記録されているソースコードの変更履歴を表示に適した形式へ変換して出力するものであってもよい。

変更箇所検出部１０８は、コミットされたファイルが既にソースコードデータベース１０２に記録されているファイルである場合には、コミットにより更新されたファイルと、既存のソースコードデータベース１０２に記録されているファイルとの差分を抽出することにより、変更箇所を検出する検出部である。

変更行数計数部１１０は、変更箇所検出部１０８が検出した変更箇所を走査することにより、コミットされたファイルにおいて削除された行数及び追加された行数を計数する計数部である。

なお、本実施形態においては、ソースコード入力部１００、リポジトリ情報出力部１０６、変更箇所検出部１０８、および、変更行数計数部１１０は、ソフトウェア開発支援装置１に設けられたＣＰＵ（Central Processing Unit）が、種々のＩ／Ｏインターフェースを必要に応じて利用しながら、所定のプログラムを実行することにより実現される。

バグ情報学習部２０は、バグ修正を行ったリビジョンと、バグ修正と見られるリビジョンにおいて修正されたバグを混入したリビジョンとを機械学習する学習部である。このバグ情報学習部２０は、学習データベース２００と、バグ混入確率出力部２０２と、バグ修正コミット検出部２０４と、バグ混入リビジョン検出部２０６と、バグ混入確率算出部２０８と、を備えて構成される。

学習データベース２００は、バグを混入したリビジョンを検出する機械学習のためのパラメータや、学習データやバグ混入確率算出のために確立した学習モデルを記憶するデータベースである。この学習データベース２００に記憶されているパラメータや学習データに基づいてバグ情報学習部２０は、バグを混入したリビジョンと、そのリビジョンにおける開発環境等を機械学習し、ファイルがコミットされた際のバグ混入確率を算出する。また、バグを修正したリビジョンを機械学習により検出するようにしてもよく、この場合、学習データベース２００は、バグ修正に関する学習データを記憶するようにしてもよい。

バグ混入確率出力部２０２は、ファイルがコミットされた際に、当該コミットにおけるバグ混入確率をクライアント２へと出力する。また、別の例としては、ファイルをコミットしようとしている場合において、ファイルのコミット前にクライアント２を介して開発者にバグ混入確率を表示するようにしてもよい。

バグ修正コミット検出部２０４は、ファイルがコミットされた際に、当該コミットがバグ修正に係るコミットであるか否かを判断する。このバグ修正をしたコミットを検出することにより、当該コミットにおいて修正されたバグがどのリビジョンで混入されたバグであるかを検出する基準とする。

バグ混入リビジョン検出部２０６は、バグが混入されたリビジョンを検出する。バグが混入されたリビジョンは、バグ修正コミット検出部２０４により検出されたバグ修正において修正されたバグを混入したリビジョンを検出する。

バグ混入確率算出部２０８は、バグ混入リビジョン検出部２０６により検出されたバグ混入リビジョンにおけるファイルのコミット時の状況に基づいて機械学習をすることにより、ファイルをコミットしようとする際に、当該コミットにおいてバグが混入される確率を算出する。バグ混入確率算出部２０８により求められたバグ混入確率は、バグ混入確率出力部２０２を介してクライアント２へと出力される。以上の構成は、例えばＰＣＩｅ（Peripheral Component Interconnect Express）やＳＡＴＡ（Serial Advanced Technology Attachment）等により接続されていてもよい。

なお、学習データベース２００は、上述したソースコードデータベース１０２や変更履歴データベース１０４などと同様に、ＳＳＤやＨＤＤ等の記録媒体により構成される。バグ混入確率出力部２０２と、バグ修正コミット検出部２０４と、バグ混入リビジョン検出部２０６と、バグ混入確率算出部２０８は、上述したソースコード入力部１００、リポジトリ情報出力部１０６、変更箇所検出部１０８、および、変更行数計数部１１０と同様に、ソフトウェア開発支援装置１に設けられたＣＰＵ（Central Processing Unit）が、種々のＩ／Ｏインターフェースを必要に応じて利用しながら、所定のプログラムを実行することにより実現される。

次に、本実施形態におけるソフトウェア開発支援装置１の動作について説明する。図３は、ソフトウェア開発支援装置１の処理の流れを示すフローチャートである。

まず、開発者は、クライアント２を介してソースコードの含まれたファイルをコミットする。コミットされたファイルに記載されたソースコードは、ソースコード入力部１００を介して、ソフトウェア開発支援装置１に入力される（ステップＳ１００）。ソースコード入力部１００から入力されたソースコードは、ソースコードデータベース１０２に登録される（ステップＳ１０２）。

次に、変更箇所検出部１０８は、入力されたソースコードが記載されたファイルと、ソースコードデータベース１０２に以前のコミットにより既に記憶されている同じファイルのソースコードとを比較して、変更箇所の検出を行う（ステップＳ１０４）。この変更箇所の変更は、例えば、ファイルのコミットがあった際にｄｉｆｆコマンドを自動的に実行することにより行われる。

次に、変更行数計数部１１０は、変更箇所検出部１０８が検出した変更情報から、当該コミットにおけるファイルの追加行数、及び、削除行数を計数する（ステップＳ１０６）。なお、これらの変更箇所検出部１０８と変更行数計数部１１０は、１つの構成としてもよく、変更箇所を検出するとともに、変更行数を係数するようにしてもよい。これら検出された変更箇所及び変更行数の情報は、変更履歴データベース１０４へと登録される（ステップＳ１０８）。なお、上述したステップＳ１０２の順番はこの順番には限られず、ステップＳ１０４又はステップＳ１０６の動作の後にソースコードを登録するようにしてもよい。

次に、バグ修正であるか否かを判断する（ステップＳ１１０）。バグ修正であるか否かの判断を図４及び図５を用いて説明する。図４は、このバグ修正であるか否かを判断するステップＳ１１０の動作の詳細を示すフローチャートである。また、図５は、あるコミットにおけるファイルの追加行数と削除行数との関係を示すグラフである。この図５において、半直線Ｌ１は、削除した行数と追加した行数が等しい行数である場合を示すラインである。

まず、バグ修正コミット検出部２０４は、変更行数計数部１１０が計数した、あるコミットにおけるファイルの追加行数と削除行数とを比較する（ステップＳ２００）。当該コミットにおけるファイルの変更行数が所定行数より小さい場合には、バグの修正ではない可能性が高い。そこで、当該コミットにおいて削除、追加された行数が所定数以上であるか否かを判断する（ステップＳ２０２）。すなわち、図５において、当該コミットが領域Ｒ４に含まれる関係を満たすか、領域Ｒ４以外の領域に含まれる関係を満たすかを判断する。

ここで、所定行数とは、例えば、８行であり、より好ましくは１０行である。また、あらかじめ決められた行数としてもよいが、例えば、コミットメッセージによりバグ修正と分かるような情報を集積し学習データベース２００に登録することにより、機械学習によりコミット時の状況やコミットされたファイルの状態等を監視し、教師付学習をすることにより、この所定行数をコミットの内容に基づいて変化させるようにしてもよい。

削除、追加された行数が所定数以上である場合（ステップＳ２０２：Ｙｅｓ）、削除、追加された行数の比率が所定の範囲内にあるか否かを判断する（ステップＳ２０４）。すなわち、図５において当該コミットが領域Ｒ１に含まれる関係を満たすか、領域Ｒ１以外の領域に含まれる関係を満たすかを判断する。これは、削除された行数と追加された行数がそれほど大きな違いを有しない場合、当該コミットがバグ修正である確率が高いためである。

例えば、経験的・実験的に、０．８（半直線Ｌ３に相当）≦（追加された行数／削除された行数）≦１．２５（半直線Ｌ２に相当）の場合にはバグ修正である可能性が高い。この比率は、例えば、ソースコードを５０行削除し、４０行追加した場合や、ソースコードを４０行削除し、５０行追加した場合の比率である。この比率に関しても、上述と同様に、あらかじめ定められた所定の値であってもよいし、教師付学習により、所定の比率をコミットの内容に基づいて変化させるようにしてもよい。

また、本実施形態においては、単純に削除、追加された行数を比較することによりバグ修正を検出するものとしたが、これには限られず、削除、追加された文字数や、削除、追加されたバイト数等の情報量を比較するものとしてもよい。換言すれば、削除された箇所の情報量と、追加された箇所の情報量は、行数、文字数、バイト数のうちの少なくとも１つに基づいて定義されるようにしてもよい。また、削除、追加された行数のうち、コメント行や空行等の実質的にプログラムとしての情報を有しない行を省いて、削除された箇所の情報量と追加された箇所の情報量とを比較するものとしてもよい。さらには、削除、追加された情報に含まれる命令数、ステップ数、又は、これらの情報を概略的に推定した値等、プログラムの実行に係る情報を比較するものとしてもよい。このように、削除された箇所の情報量と追加された箇所の情報量のうちバグ修正と判定しうる有意な情報に基づく比較をするものであればどのような情報を比較するものでもよい。

なお、図５に示すように、削除行数が所定の数値と比較して十分に大きい場合、すなわち、曲線Ｌ４とｙ軸との間に挟まれた領域Ｒ２に含まれる関係を満たす場合には、当該コミットは機能削除を行ったものであると判断して、この状況を学習させるようにしてもよい。逆に、追加行数が所定の数値と比較して十分に小さい場合、すなわち、曲線Ｌ５とｘ軸との間に挟まれた領域Ｒ３に含まれる関係を満たす場合には、当該コミットは機能追加を行ったものであると判断して、この状況を学習させるようにしてもよい。このように学習させることにより、バグ修正を行ったコミットの判断の正確性を向上させるようにしてもよい。

削除、追加された行数の比率が所定範囲内である場合（ステップＳ２０４：Ｙｅｓ）、バグ修正コミット検出部２０４は、当該コミットがバグ修正をおこなったコミットであると判断する（ステップＳ２０６）。

一方で、削除、追加された行数が所定数以上ではなかった場合（ステップＳ２０２：Ｎｏ）、及び、削除、追加された行数の比率が所定範囲内では無かった場合（ステップＳ２０４：Ｎｏ）、当該コミットはバグ修正を行ったものではないと判断する（ステップＳ２０８）。

次に、ステップＳ２００からステップＳ２０８までの処理において学習をさせるべきデータが発生した場合には、学習データベース２００へそれらの学習データを学習情報として登録する（ステップＳ２１０）。例えば、コミットメッセージにバグ修正である旨が記載されていた場合などに、削除、追加の行数、ファイル名、修正したモジュール名等のバグ修正を行った内容や状況に関する情報を学習データベース２００へと登録することにより、コミットがされた際に、当該コミットがバグ修正を行ったコミットであることを判断する正確性を向上することが可能となる。

図３に戻り、コミットがバグ修正に関するコミットであるか否かが判断された後、バグ混入パラメータの学習へと遷移する（ステップＳ１１２）。図６は、バグ混入パラメータの学習の処理の概略を示すフローチャートである。

まず、ステップＳ１１０において、コミットがバグ修正であると判断された場合（ステップＳ３００：Ｙｅｓ）、バグ混入リビジョン検出部２０６は、バグを混入したリビジョンの検出を行う（ステップＳ３０２）。バグを混入したリビジョンの検出は、例えば、当該コミットにおいてバグ修正がされたファイルの以前のコミットがされたリビジョンをソースコードデータベース１０２及び変更履歴データベース１０４から抽出することにより、バグ混入リビジョンとして検出する。また、これには限られず、ファイルよりも範囲を狭めて、バグ修正を行ったモジュール、ファンクション単位において比較してバグ混入リビジョンを検出するものとしてもよいし、バグ修正において修正した箇所、例えば削除した行が含まれる箇所を追加、修正したリビジョンを検出するようにしてもよい。

次に、バグ混入リビジョンのコミットをした状況を示すパラメータを取得する（ステップＳ３０４）。ここで、パラメータとは、例えば、コミットを行った開発者の情報、コミットを行った日付、曜日、時間等の情報、コミットにおいて削除された行数と追加された行数の情報、ファイル名、ソースコードの中身と行ったコミットしたものに関する情報等、コミットをする際にその情報を表す指標となるパラメータである。これらのパラメータを組み合わせることにより、ある開発者が昼の３時にコミットしたファイルにバグが存在していた、といった情報や、あるファイルの特定のファンクションに関するコミットにおいて、バグの混入がされた、といった情報を得ることが可能となる。

なお、これらパラメータとする情報は、ソースコードデータベース１０２に記憶されている情報に基づいて取得するようにしてもよいし、変更履歴データベース１０４に記憶されている情報に基づいて取得するようにしてもよい。さらには、パラメータとする情報は、バージョン管理システムから得られる情報には限られるものではない。例えば、開発者の血圧、脈拍数、心拍数、体温、当日の消費カロリーや歩いた歩数等の活動量等のコミットやファイル更新の際における開発者の健康状態を示すバイタル情報や、天気、気温、湿度、気圧、場所等のコミットした際の開発者の周囲の情報を示す外部環境情報といった特殊な入力デバイスから得られる情報をパラメータとして取得してもよい。

例えば、リストバンド型の血圧、脈拍数、体温、活動量計や心拍数計のように直接開発者が装備するものによりバイタルサインを取得してもよいし、画像を介して体温を計測する赤外線カメラのように直接開発者が装備しないものによりバイタルサインを取得してもよい。また、ヘッドセットなどを通して開発者の呼吸やその他の情報を取得したり、開発機に備えられたカメラを介して得られた開発者の顔の画像から健康状態を推定したりするものとしてもよい。さらには、スマートホン等のデバイスにより自動的に健康状態を取得するものとしてもよいし、その日の体調を開発者がそれらのデバイスにあらかじめ入力するものであってもよい。

外部情報に関しても同様であり、温度計、湿度計、気圧計により計測するようにしてもよいし、インターネット上の天気情報データベース等にアクセスして取得するようにしてもよい。場所に関しては、例えば、コミットした開発機の設置場所や、無線ＬＡＮを使用した場所などの情報により取得するが、これらの方法には限られない。また、時間に関しては、コミットしたタイミングにおける時間には限られず、コミットしたファイルをコミット前において最終的に更新した時間や、ファイルに記憶されているタイムスタンプにより取得するようにしてもよい。さらには、前回のコミットと今回のコミットとの間の時間を取得するようにしてもよい。これら全ての情報は、それぞれ、有線により取得してもよいし無線により取得してもよい。

いずれの場合においても、コミットの際に、これら入力デバイスから得られる情報をパラメータとして記録してもよいし、これらの入力デバイスから得られる情報をいずれかのデータベースへと記録しておき、コミットの時間や環境、コミットをした開発者等、種々の情報に基づいて取得するものとしてもよい。

図７は、上述したバイタル情報や外部環境情報を取得する装置と、外部データベースとをソフトウェア開発支援装置１の外部に備える一例を示す概略図である。この図７に示すように、ソフトウェア開発支援装置１の外部に、バイタル情報取得センサ３と、外部環境情報取得センサ４と、環境データベース５とをさらに備える。

バイタル情報取得センサ３は、例えば、上述したリストバンド型のデバイスや、各種カメラ、ヘッドセット、スマートホン等のデバイスである。

外部環境取得センサ４は、例えば、上述した温度計、湿度計、気圧計や、インターネット上の天気情報データベースである。

環境データベース５は、これらのバイタル情報や外部環境情報を記憶し、格納するデータベースである。図７において環境データベース５は、ソフトウェア開発支援装置１の外部にあるものとしたが、形態としてはこれには限られず、例えば、変更履歴データベース１０４や、学習データベース２００等のソフトウェア開発支援装置１の内部にあるデータベースにこれらの情報を記録するようにしてもよいし、ソフトウェア開発支援装置１内に別途データベースを設けることとしてもよい。

バグ混入リビジョンのパラメータが取得された後、バグ混入パラメータを学習データベースへと登録する（ステップＳ３０６）。各パラメータを学習データベースへと登録することにより、機械学習におけるサンプル量を増やし、機械学習の正確度をより向上することとなる。

次に、学習データベースに登録された各種パラメータ及び以前の学習データに基づき、バグ混入確率算出部２０８は、バグ混入リビジョンにおけるパラメータがどのような傾向があるか等の機械学習を行う。続いて、機械学習により算出された各種パラメータとバグ混入確率とを紐付ける学習データを新たな機械学習パラメータとして更新する（ステップＳ３０８）。また、機械学習により推定された学習モデルを学習データベース２００へ登録するようにしてもよい。

各リビジョンがバグ混入リビジョンであったか否かを教師データとして、前述のバグ混入パラメータに追加して機械学習の教師付きデータを作成する。場合によっては、この教師付きデータは、バグなし・低いバグの可能性・高いバグの可能性など、二値ではなく多値で扱ってもよい。機械学習アルゴリズムには、一般にはランダムフォレストやサポートベクタマシンなどを採用するが、ディープラーニングを含む別のアルゴリズムでもよい。

上記のように作成した教師付きデータを入力として、機械学習モデルを作成する。モデルを作成する際のハイパーパラメータは、グリッドサーチ、ランダムサンプリング、ベイジアン最適化などの探索により決定し、可変とするパラメータには、バグ混入確率を決定するための比率も含んでもよい。ここでハイパーパラメータとは、事前モデルを決定するパラメータや、確率モデル全体に影響を与えるパラメータのことをいう。

採用するアルゴリズムによりグリッドサーチ等に用いるハイパーパラメータは異なり、ランダムフォレストであれば決定木の個数、深さ、サンプル数などであり、サポートベクタマシンであれば、ガンマ値、コストなどであり、ディープラーニングであれば、活性化関数の選択、ユニット数、中間層の数、初期の重みなどがそれにあたる。ここで作成した学習モデルに対してコミット時のバグ混入パラメータを入力として与え、バグ混入確率を結果として出力する。

ランダムフォレストを採用する場合には、まず、各種パラメータと、バグが発生したか否かのデータを教師データとしてランダムに所定の組数だけサブサンプリングする。例えば、ある開発者が、ある曜日のある時間内において行ったコミットがバグであった、又は、バグでは無かった、というデータをランダムに取得し、所定数、一般的には全サンプル数の２／３程度のサブサンプリングデータを作成する。その後、各サブサンプリングデータを教師データとして、各サブサンプリングデータに対する決定木を生成する。生成されたこれらの木に対して、一例として、開発者と時間をパラメータとして、学習データを作成する。最終的な木のノード数を調整することにより、二値又は多値の分類を細かくすることも可能である。この学習データを様々なパラメータを用いて木の構成を決定することにより、各木同士の相関を低くする。このように学習データに基づいて求められた学習モデルを用いて、各パラメータに対する重み付けや関数の選択を行うことにより、バグ混入確率を出力する。

サポートベクタマシンを採用する場合には、各種パラメータと、バグが発生したか否かのデータを教師データとして、パラメータ数の次元を持つ空間内で分類を可能とし、各パラメータから構成される空間内の点からのマージンが最大となるような超平面を算出する。上述したように、ハイパーパラメータとしては、誤差に対する重み付けを示すコストＣや、マージンの最大化と誤差の最小化との比率を決定するガンマγなどが用いられる。上述したランダムフォレストと同様に、二値分類又は多値分類をすることも可能であり、このように求められたパラメータに基づいて、バグ混入確率を出力する学習モデルを推定する。

ディープラーニングを採用する場合にも、各種パラメータと、バグが発生したか否かのデータを教師データとして、学習データを生成する。ディープラーニングは、一般的には、中間層として複数の層を設けたニューラルネットワークにより構成される。多種多様な構成方法が有り、例えば、コンボリューションニューラルネットワーク、リカレントニューラルネットワーク、自己符号化、ディープボルツマンマシンなどのアルゴリズムがあり、またこれらのうち複数のアルゴリズムを組み合わせて学習をしてもよい。使用するアルゴリズムによりハイパーパラメータの構成は変わるが、上述したように、各層を構成するニューロン同士を接続するシナプスを発火させるための活性化関数の選択や、中間層におけるユニット数、中間層の数、初期の重み付け関数などがハイパーパラメータとなる。これらのハイパーパラメータに基づいて、二値分類又は多値分類をすることにより、バグ混入確率を出力する学習モデルを推定する。

また、上述したアルゴリズムに限られず、適切に教師付学習をできる機械学習モデルであればどのようなアルゴリズムを用いてもよい。

次に、コミット時のパラメータを学習データベース２００へと登録する（ステップＳ３１０）。ここで登録するデータは、ステップＳ３０４において取得したパラメータと同等のパラメータである。すなわち、当該コミットにおける開発者や時間情報等のデータを学習データベース２００へと登録する。このようにすることで、当該コミットにおいてバグが混入されていた場合に、将来的になされるバグ修正コミットにおいて、当該コミットをバグが混入されたコミットとして検出することが可能となる。また、バグ混入されたコミットであると検出されない場合においては、バグ混入ではないパラメータとして学習データベース２００へと記憶されることとなる。

一方で、ステップＳ３００で、当該コミットがバグ修正と判断されなかった場合（ステップＳ３００：Ｎｏ）において、同様にコミット時のパラメータを学習データベース２００へと登録する（ステップＳ３１０）。これも上記と同様の理由であり、バグ修正コミットであるか否かに拘わらず、当該コミットの状態や環境を学習データとして登録するためである。

バグ混入パラメータの学習が終了すると、再び図３に戻り、入力されたソースコードのバグ混入確率の算出と出力を行う（ステップ１１４）。バグ混入確率算出部２０８は、学習したバグ混入パラメータに基づいて、当該コミットにおいてバグが混入された確率を算出する。例えば、ある開発者が３時前後にコミットをした場合、バグ混入確率が３０％であるといった情報や、あるファイルのある特定の部分を変更するコミットをした場合、バグ混入確率は５０％である、といった情報が算出される。算出された情報は、バグ混入確率出力部２０２を介してクライアント２へと出力される。

以上の処理は、全てコミットが行われた後に処理されるものとしたが、例えば、コミットする予定のファイルをサーバであるソフトウェア開発支援装置１へと送信する前に、そのコミット予定に係る情報を用いてバグ混入確率を算出することにより、コミット前に当該コミット予定のものにバグが含まれている確率を表示することも可能となる。

また、上記においては、コミットごとに学習するようにしたが、これには限られず、バッチ処理等により一定周期で行うようにしてもよい。例えば、所定数のコミットがされた場合に学習をおこなってもよいし、午前０時などの決まった時間に学習を行うようにしてもよいし、これらには限られず、適切なタイミングで行うようにしてもよい。

以上のように、本実施形態によれば、コミット時やコミット前に不具合発生の確率を開発者へと表示することが可能となる。例えば、コミット前に不具合発生確率が高いと表示された場合に、あらかじめテストをすることにより、バグの混入を回避したり、コミット後においても、バグ修正の確実性を向上させたりすることが可能となる。

開発者をパラメータとすることにより、開発者本人にバグを混入しがちな状況を自覚させることにより、事前にバグの混入を防止することも可能である。さらに、ある特定のファイルにおいてバグの発生確率が高い場合は、当該ファイルの内容は高度な内容であり、バグ混入する蓋然性が高いというワーニングを表示することにより、コミット前にテストを再度行い、かつ、バグ修正を行うことにより、バグ混入の回避をすることも可能である。このように、コミットする際の環境や状況をパラメータとして機械学習をすることにより、バグ修正の正確性や高速性を向上するとともに、そもそもバグの混入を減少させるという効果を得ることもできる。

なお、上述した実施形態において、各機能は、上述した機能を有する回路、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等のハードウェアにより構成されるものであってもよいし、プログラムを用いたソフトウェアにより構成されるものであってもよい。

本発明は、以上の実施形態に限定されること無く、均等な範囲を含めて種々の変更が可能であり、これら変更を加えた実施形態や、上述した実施形態を組み合わせた形態についても本発明の範囲内に包含されるものである。

１：ソフトウェア開発支援装置、２：クライアント、３：バイタル情報取得センサ、４：外部環境取得センサ、５：環境データベース、１０：バージョン管理部、１００：ソースコード入力部、１０２：ソースコードデータベース、１０４：変更履歴データベース、１０６：リポジトリ情報出力部、１０８：変更箇所検出部、１１０：変更行数計数部、２０：バグ情報学習部、２００：学習データベース、２０２：バグ混入確率出力部、２０４：バグ修正コミット検出部、２０６：バグ混入リビジョン検出部、２０８：バグ混入確率算出部

Claims (11)

1. コミットが、当該コミットよりも以前にされた他のコミットにおいて混入されたバグを修正する更新であるか否かを、当該コミットにおいて変更されたソースコードの情報に基づいて判断し、バグ修正であるコミットを検出する、バグ修正コミット検出部と、
   当該コミットがバグを修正する更新であると検出された場合に、当該コミットにおいて修正されたバグを混入した前記他のコミットのリビジョンを検出する、バグ混入リビジョン検出部と、
   バグを混入した前記他のコミットのリビジョンを特定する情報を記憶する、データベースと、
   を備えるソフトウェア開発支援装置。
2. 前記バグ修正コミット検出部は、当該コミットにおいて更新されたファイルに記載されたソースコードにおいて削除された箇所と、追加された箇所とを比較することにより、当該コミットがバグ修正に係るコミットであるか否かを判断する、請求項１に記載のソフトウェア開発支援装置。
3. 前記バグ修正コミット検出部は、前記削除された箇所の情報量と、前記追加された箇所の情報量との差が、所定範囲内にある場合に、当該コミットがバグ修正にかかるコミットであると判断する、請求項２に記載のソフトウェア開発支援装置。
4. 前記削除された箇所の情報量と、前記追加された箇所の情報量は、行数、文字数、バイト数、命令数、ステップ数のうちの少なくとも１つに基づいて定義される、請求項３に記載のソフトウェア開発支援装置。
5. 当該コミットがなされた状況に基づいて、当該コミットにおいて更新されたファイルに新たなバグが混入された確率であるバグ混入確率を算出する、バグ混入確率算出部と、
   算出された前記バグ混入確率を出力する、バグ混入確率出力部と、
   をさらに備える請求項１乃至請求項４のいずれかに記載のソフトウェア開発支援装置。
6. 前記データベースは、各コミットがなされた状態をパラメータとして記憶し、
   前記バグ混入確率算出部は、前記データベースに記憶されているコミットをした状況を示すパラメータを用いて機械学習をして学習モデルを算出し、前記学習モデルに基づいて、当該コミットにおける前記バグ混入確率を算出する、請求項３乃至請求項５のいずれかに記載のソフトウェア開発支援装置。
7. 前記パラメータは、当該コミットを行った開発者の情報、及び、当該コミットを行った時間情報を少なくとも含む、請求項６に記載のソフトウェア開発支援装置。
8. 前記バグ混入確率算出部は、前記データベースに記憶されているコミットをした状況を示すパラメータに加えて、当該ソフトウェア開発支援装置の内部又は外部に設けられている環境データベースに記憶されているコミットをした状況を示すパラメータをも用いて、前記学習モデルを算出する、請求項６又は請求項７に記載のソフトウェア開発支援装置。
9. 前記環境データベースに記憶されているコミットをした状況を示すパラメータは、開発者の健康状態を示す情報であるバイタル情報、又は、開発者の周囲環境を示す情報である外部環境情報を少なくとも含む、請求項８に記載のソフトウェア開発支援装置。
10. バグ修正コミット検出部が、コミットが当該コミットよりも以前にされた他のコミットにおいて混入されたバグを修正する更新であるか否かを、当該コミットにおいて変更されたソースコードの情報に基づいて判断し、バグ修正であるコミットを検出するステップと、
    バグ混入リビジョン検出部が、当該コミットがバグを修正する更新であると検出された場合に、当該コミットにおいて修正されたバグを混入した前記他のコミットのリビジョンを検出するステップと、
    データベースに、バグを混入した前記他のコミットのリビジョンを特定する情報を記憶させるステップと、
    を備えるソフトウェア開発支援方法。
11. コンピュータに、
    コミットが、当該コミットよりも以前にされた他のコミットにおいて混入されたバグを修正する更新であるか否かを、当該コミットにおいて変更されたソースコードの情報に基づいて判断し、バグ修正であるコミットを検出する、バグ修正コミット検出手段、
    当該コミットがバグを修正する更新であると検出された場合に、当該コミットにおいて修正されたバグを混入した前記他のコミットのリビジョンを検出する、バグ混入リビジョン検出手段、
    バグを混入した前記他のコミットのリビジョンを特定する情報を記憶する、記憶手段、
    として機能させるためのプログラム。

Images