図面 (/)

技術 ソフトウェア開発支援装置、ソフトウェア開発支援方法及びプログラム

出願人 株式会社アイ・イー・テック
発明者 田中伸明田村陽介小林元也島田隆史
出願日 2016年7月27日 (4年4ヶ月経過) 出願番号 2016-147549
公開日 2018年2月1日 (2年10ヶ月経過) 公開番号 2018-018267
状態 未査定
技術分野 ストアードプログラム 学習型計算機
主要キーワード 変更履歴データベース 事前モデル 機械学習モデル 取得センサ リストバンド型 機能削除 外部環境情報 活性化関数
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年2月1日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (8)

課題

ソフトウェア開発における不具合発生を検出するソフトウェア開発支援装置を提供する。

解決手段

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

概要

背景

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

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

概要

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

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記バグ修正コミット検出部は、当該コミットにおいて更新されたファイルに記載されたソースコードにおいて削除された箇所と、追加された箇所とを比較することにより、当該コミットがバグ修正に係るコミットであるか否かを判断する、請求項1に記載のソフトウェア開発支援装置。

請求項3

前記バグ修正コミット検出部は、前記削除された箇所の情報量と、前記追加された箇所の情報量との差が、所定範囲内にある場合に、当該コミットがバグ修正にかかるコミットであると判断する、請求項2に記載のソフトウェア開発支援装置。

請求項4

前記削除された箇所の情報量と、前記追加された箇所の情報量は、行数文字数バイト数命令数ステップ数のうちの少なくとも1つに基づいて定義される、請求項3に記載のソフトウェア開発支援装置。

請求項5

当該コミットがなされた状況に基づいて、当該コミットにおいて更新されたファイルに新たなバグが混入された確率であるバグ混入確率を算出する、バグ混入確率算出部と、算出された前記バグ混入確率を出力する、バグ混入確率出力部と、をさらに備える請求項1乃至請求項4のいずれかに記載のソフトウェア開発支援装置。

請求項6

前記データベースは、各コミットがなされた状態をパラメータとして記憶し、前記バグ混入確率算出部は、前記データベースに記憶されているコミットをした状況を示すパラメータを用いて機械学習をして学習モデルを算出し、前記学習モデルに基づいて、当該コミットにおける前記バグ混入確率を算出する、請求項3乃至請求項5のいずれかに記載のソフトウェア開発支援装置。

請求項7

前記パラメータは、当該コミットを行った開発者の情報、及び、当該コミットを行った時間情報を少なくとも含む、請求項6に記載のソフトウェア開発支援装置。

請求項8

前記バグ混入確率算出部は、前記データベースに記憶されているコミットをした状況を示すパラメータに加えて、当該ソフトウェア開発支援装置の内部又は外部に設けられている環境データベースに記憶されているコミットをした状況を示すパラメータをも用いて、前記学習モデルを算出する、請求項6又は請求項7に記載のソフトウェア開発支援装置。

請求項9

前記環境データベースに記憶されているコミットをした状況を示すパラメータは、開発者の健康状態を示す情報であるバイタル情報、又は、開発者の周囲環境を示す情報である外部環境情報を少なくとも含む、請求項8に記載のソフトウェア開発支援装置。

請求項10

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

請求項11

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

技術分野

背景技術

0002

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

0003

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

0004

特開2016−24784

先行技術

0005

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.

発明が解決しようとする課題

0006

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

課題を解決するための手段

0007

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

0008

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

0009

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

発明の効果

0010

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

図面の簡単な説明

0011

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

実施例

0012

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

0013

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

0014

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

0015

図2は、ソフトウェア開発支援装置1の構成を示すブロック図である。この図2に示すようにソフトウェア開発支援装置1は、バージョン管理部10と、バグ情報学習部20とを備えて構成される。このソフトウェア開発支援装置1は、例えば、Trac、Redmine、Bugzilla等のバグ管理システムプロジェクト管理システムにより構成される。

0016

バージョン管理部10は、例えば、git、Mercurial、Subversion、CVS(Concurrent Versions System)、BitKeeper、AlienBrain等の分散型又は集中型バージョン管理システムにより構成される。このバージョン管理部10は、ソースコード入力部100と、ソースコードデータベース102と、変更履歴データベース104と、リポジトリ情報出力部106と、変更箇所検出部108と、変更行数計数部110と、を備えて構成される。この他、ソースコードのマージをするためのマージ部など所謂バージョン管理システムの基本的な構成を備えていてもよい。

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

なお、本実施形態においては、ソースコード入力部100、リポジトリ情報出力部106、変更箇所検出部108、および、変更行数計数部110は、ソフトウェア開発支援装置1に設けられたCPU(Central Processing Unit)が、種々のI/Oインターフェースを必要に応じて利用しながら、所定のプログラムを実行することにより実現される。

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

なお、学習データベース200は、上述したソースコードデータベース102や変更履歴データベース104などと同様に、SSDやHDD等の記録媒体により構成される。バグ混入確率出力部202と、バグ修正コミット検出部204と、バグ混入リビジョン検出部206と、バグ混入確率算出部208は、上述したソースコード入力部100、リポジトリ情報出力部106、変更箇所検出部108、および、変更行数計数部110と同様に、ソフトウェア開発支援装置1に設けられたCPU(Central Processing Unit)が、種々のI/Oインターフェースを必要に応じて利用しながら、所定のプログラムを実行することにより実現される。

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

削除、追加された行数が所定数以上である場合(ステップS202:Yes)、削除、追加された行数の比率が所定の範囲内にあるか否かを判断する(ステップS204)。すなわち、図5において当該コミットが領域R1に含まれる関係を満たすか、領域R1以外の領域に含まれる関係を満たすかを判断する。これは、削除された行数と追加された行数がそれほど大きな違いを有しない場合、当該コミットがバグ修正である確率が高いためである。

0041

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

0042

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

0043

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

0044

削除、追加された行数の比率が所定範囲内である場合(ステップS204:Yes)、バグ修正コミット検出部204は、当該コミットがバグ修正をおこなったコミットであると判断する(ステップS206)。

0045

一方で、削除、追加された行数が所定数以上ではなかった場合(ステップS202:No)、及び、削除、追加された行数の比率が所定範囲内では無かった場合(ステップS204:No)、当該コミットはバグ修正を行ったものではないと判断する(ステップS208)。

0046

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

0047

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

0048

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

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

なお、上述した実施形態において、各機能は、上述した機能を有する回路ASIC(Application Specific IntegratedCircuit)、FPGA(Field Programmable Gate Array)等のハードウェアにより構成されるものであってもよいし、プログラムを用いたソフトウェアにより構成されるものであってもよい。

0075

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

0076

1:ソフトウェア開発支援装置、2:クライアント、3:バイタル情報取得センサ、4:外部環境取得センサ、5:環境データベース、10:バージョン管理部、100:ソースコード入力部、102:ソースコードデータベース、104:変更履歴データベース、106:リポジトリ情報出力部、108:変更箇所検出部、110:変更行数計数部、20:バグ情報学習部、200:学習データベース、202:バグ混入確率出力部、204:バグ修正コミット検出部、206:バグ混入リビジョン検出部、208:バグ混入確率算出部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ