JPWO2016157433A1 - ソフトウェア管理装置およびソフトウェア管理方法 - Google Patents

Abstract

本発明は、バグの原因を効率的に特定することが可能なソフトウェア管理装置およびソフトウェア管理方法を提供することを目的とする。本発明によるソフトウェア管理装置は、ソースファイル内のソースコードの各行に対応するリビジョンと、ソースコードを改訂した改訂者とを含むリビジョン情報を取得するリビジョン情報取得部と、ソースコードの開発者のレベルを示す開発者レベルを管理し、リビジョン情報取得部で取得されたリビジョン情報に含まれる改訂者に対応する開発者の開発者レベルを抽出する開発者レベル管理部と、リビジョン情報取得部で取得されたリビジョン情報と、開発者レベル管理部で抽出された開発者レベルとに基づいて、ソースコードの各行を開発者レベルに応じて区別して表示するように制御する制御部とを備える。

Description

本発明は、ソフトウェア開発時におけるソフトウェアの管理を行うソフトウェア管理装置およびソフトウェア管理方法に関する。

大規模なソフトウェア開発では、技術レベルが異なる複数の開発者によって１つのプログラムが開発されている。

ソフトウェアの開発では、ソースコードを記述するコーディングの工程後に、ソースコードを実行可能なプログラムに変換するビルドの工程、ソースコードがコーディングルール等に反していないか等のチェックを行う静的解析の工程、およびプログラムが正しく動作するかチェックを行うテストの工程の各工程を行う。

コーディング後の各工程でバグ（ソースコードの誤り等）が発見された場合は、バグの原因を特定してコーディングを再度行う必要があるが、特にビルドおよびテストで発見されるバグの原因の特定には多大な時間を要する。また、プログラムの編集では、ソースコードが新たに追加されたり、ソースコードの変更が行われたりするが、このときにもバグが生じることがある。従って、バグの原因を特定するために要する時間を短縮することは、ソフトウェア開発の工数を削減することにつながる。

上記の問題の対策として、従来、１つのソースファイル内のソースコードの各行がどのリビジョンで改訂されたのかを確認することができるソースコードの改訂履歴を示すツールを、バグの原因の特定に役立てていた。また、ソフトウェアの開発者のレベルを評価する技術が開示されている（例えば、特許文献１，２参照）。

特開２００６−５９２７６号公報 特開２０１０−１８６３９４号公報

ソースコードの改訂履歴に基づいてバグの原因を特定する方法を用いても、ソースコード量が多い大規模なソフトウェア開発においてはバグの原因を特定するためには時間がかかるという問題がある。

また、特許文献１，２の技術を用いれば、ソースファイルごとの信頼度を把握することができる。すなわち、開発者のレベルが低い場合は、ソースファイルの信頼度が低いと判断することができ、バグが生じると信頼度が低いソースファイルを優先してバグの原因を特定する作業を行うことができる。しかし、このような場合であっても、ソースコードの量が増えるとバグの原因を特定するために時間を要し、バグの原因を効率的に特定しているとはいえなかった。

本発明は、このような問題を解決するためになされたものであり、バグの原因を効率的に特定することが可能なソフトウェア管理装置およびソフトウェア管理方法を提供することを目的とする。

上記の課題を解決するために、本発明によるソフトウェア管理装置は、ソースファイル内のソースコードの各行に対応するリビジョンと、ソースコードを改訂した改訂者とを含むリビジョン情報を取得するリビジョン情報取得部と、ソースコードの開発者のレベルを示す開発者レベルを管理し、リビジョン情報取得部で取得されたリビジョン情報に含まれる改訂者に対応する開発者の開発者レベルを抽出する開発者レベル管理部と、リビジョン情報取得部で取得されたリビジョン情報と、開発者レベル管理部で抽出された開発者レベルとに基づいて、ソースコードの各行を開発者レベルに応じて区別して表示するように制御する制御部とを備える。

また、本発明によるソフトウェア管理方法は、ソースファイル内のソースコードの各行に対応するリビジョンと、ソースコードを改訂した改訂者とを含むリビジョン情報を取得し、ソースコードの開発者のレベルを示す開発者レベルを管理し、取得したリビジョン情報に含まれる改訂者に対応する開発者の開発者レベルを抽出し、取得したリビジョン情報と、抽出された開発者レベルとに基づいて、ソースコードの各行を開発者レベルに応じて区別して表示するように制御する。

本発明によると、ソフトウェア管理装置は、ソースファイル内のソースコードの各行に対応するリビジョンと、ソースコードを改訂した改訂者とを含むリビジョン情報を取得するリビジョン情報取得部と、ソースコードの開発者のレベルを示す開発者レベルを管理し、リビジョン情報取得部で取得されたリビジョン情報に含まれる改訂者に対応する開発者の開発者レベルを抽出する開発者レベル管理部と、リビジョン情報取得部で取得されたリビジョン情報と、開発者レベル管理部で抽出された開発者レベルとに基づいて、ソースコードの各行を改訂者の開発者レベルに応じて区別して表示するように制御する制御部とを備えるため、バグの原因を効率的に特定することが可能となる。

また、ソフトウェア管理方法は、ソースファイル内のソースコードの各行に対応するリビジョンと、ソースコードを改訂した改訂者とを含むリビジョン情報を取得し、ソースコードの開発者のレベルを示す開発者レベルを管理し、取得したリビジョン情報に含まれる改訂者に対応する開発者の開発者レベルを抽出し、取得したリビジョン情報と、抽出された開発者レベルとに基づいて、ソースコードの各行を改訂者の開発者レベルに応じて区別して表示するように制御するため、バグの原因を効率的に特定することが可能となる。

本発明の目的、特徴、態様、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。

本発明の実施の形態１によるソフトウェア管理装置の構成の一例を示すブロック図である。 本発明の実施の形態１によるソフトウェア管理装置におけるソフトウェア機能に対応するハードウェア構成の一例を示す図である。 本発明の実施の形態１によるソフトウェア管理装置の構成の他の一例を示すブロック図である。 本発明の実施の形態１によるリビジョン情報データベースに格納されるリビジョン情報の一例を示す図である。 本発明の実施の形態１による開発者レベルデータベースに格納される開発者レベルの一例を示す図である。 本発明の実施の形態１によるソフトウェア管理装置の動作の一例を示すフローチャートである。 本発明の実施の形態１によるソフトウェア管理装置の動作の一例を示すフローチャートである。 本発明の実施の形態１による表示の一例を示す図である。 本発明の実施の形態１による開発者レベルデータベースに格納される開発者レベルの一例を示す図である。 本発明の実施の形態１によるソフトウェア管理装置の動作の一例を示すフローチャートである。 本発明の実施の形態１による開発者レベルデータベースに格納される開発者レベルの一例を示す図である。 本発明の実施の形態２によるソフトウェア管理装置の構成の一例を示すブロック図である。 本発明の実施の形態２による実行結果データベースに格納される実行結果の一例を示す図である。 本発明の実施の形態２によるソフトウェア管理装置の動作の一例を示すフローチャートである。 本発明の実施の形態２によるリビジョン情報取得部が取得するリビジョン情報の一例を示す図である。 本発明の実施の形態２による実行結果データベースに格納されるリビジョン情報の一例を示す図である。 本発明の実施の形態２による表示の一例を示す図である。 本発明の実施の形態３によるソフトウェア管理装置の構成の一例を示すブロック図である。 本発明の実施の形態３によるソフトウェア管理装置の動作の一例を示すフローチャートである。 本発明の実施の形態３によるリビジョン情報取得部が取得するリビジョン情報の一例を示す図である。 本発明の実施の形態３による実行結果データベースに格納される実行結果の一例を示す図である。 本発明の実施の形態３による実行結果データベースに格納されるリビジョン情報の一例を示す図である。 本発明の実施の形態３による評価後の開発者レベルの一例を示す図である。 本発明の実施の形態４によるソフトウェア管理装置の動作の一例を示すフローチャートである。 本発明の実施の形態４によるソフトウェア管理装置の動作を説明するための図である。 本発明の実施の形態４によるソフトウェア管理装置の動作を説明するための図である。 本発明の実施の形態４によるソフトウェア管理装置の動作を説明するための図である。 本発明の実施の形態５によるソフトウェア管理装置の動作の一例を示すフローチャートである。 本発明の実施の形態５によるリビジョン情報取得部が取得するリビジョン情報の一例を示す図である。 本発明の実施の形態５による実行結果データベースに格納される実行結果の一例を示す図である。 本発明の実施の形態５による評価後の開発者レベルの一例を示す図である。 本発明の実施の形態６によるソフトウェア管理装置の構成の一例を示すブロック図である。 本発明の実施の形態６によるソフトウェア管理装置の動作の一例を示すフローチャートである。 本発明の実施の形態６によるファイルの信頼度を説明するための図である。 本発明の実施の形態によるソフトウェア管理システムの構成の一例を示すブロック図である。 本発明の実施の形態によるソフトウェア管理システムの構成の他の一例を示すブロック図である。

本発明の実施の形態について、図面に基づいて以下に説明する。

＜実施の形態１＞
まず、本発明の実施の形態によるソフトウェア管理装置の構成について説明する。なお、本実施の形態においては、ソフトウェア管理装置単体で実現した場合について説明する。

図１は、本発明の実施の形態１によるソフトウェア管理装置１の構成の一例を示すブロック図である。なお、図１では、ソフトウェア管理装置１を構成する必要最小限の構成要素を示している。

図１に示すように、ソフトウェア管理装置１は、少なくともリビジョン情報取得部２と、開発者レベル管理部３と、制御部４とを備えている。

リビジョン情報取得部２は、ソースファイル内のソースコードの各行に対応するリビジョンと、ソースコードを改訂した改訂者とを含むリビジョン情報を取得する。

開発者レベル管理部３は、改訂者を含むソースコードの開発者のレベルを示す開発者レベルを管理し、リビジョン情報取得部２で取得されたリビジョン情報に含まれる改訂者に対応する開発者の開発者レベルを抽出する。

制御部４は、リビジョン情報取得部２で取得されたリビジョン情報と、開発者レベル管理部３で抽出された開発者レベルとに基づいて、ソースコードの各行を開発者レベルに応じて区別して表示するように制御する。

図２は、ソフトウェア管理装置１におけるソフトウェア機能に対応するハードウェア構成の一例を示す図である。

リビジョン情報取得部２、開発者レベル管理部３、および制御部４は、例えば図２のプロセッサ５がメモリ６等に記憶されたプログラムを実行することにより、当該プロセッサ５の機能として実現される。ただし、これらは、例えば複数のプロセッサ５が連携して実現されてもよい。

次に、図１のリビジョン情報取得部２、開発者レベル管理部３、および制御部４を含むソフトウェア管理装置１の他の構成について説明する。

図３は、ソフトウェア管理装置７の構成の一例を示すブロック図である。

図３に示すように、ソフトウェア管理装置７は、リビジョン情報取得部２と、開発者レベル管理部３と、制御部４とを備えている。また、リビジョン情報取得部２はリビジョン情報データベース８に接続され、開発者レベル管理部３は開発者レベルデータベース９に接続され、制御部４は表示装置１０に接続されている。

リビジョン情報データベース８は、例えば、ハードディスク（HDD：Hard Disk Drive）または半導体メモリなどの記憶装置から構成されており、バージョン管理ツール（本発明では、説明を分かりやすくするためリビジョン管理ツールと呼ぶこととする）によって管理されるリビジョン情報を格納している。図４は、リビジョン情報データベース８に格納されるリビジョン情報の一例を示す図である。図４に示すように、リビジョン情報は、ソースコード改訂情報とリビジョン対応情報とを含んでいる。

ソースコード改訂情報は、ソースコードと、当該ソースコードを改訂したリビジョン番号とをソースコードの行ごとに対応付けている。ソースコード改訂情報によって、ソースコードの各行がどのリビジョンで改訂されたのかを判別することができる。リビジョン対応情報は、リビジョン番号と、コミッター（改訂者）名およびコミット日時（日時情報）等を含むコミットに関する情報であるコミット情報とを対応付けている。リビジョン管理ツールは、コミッターによって改訂されるごとにリビジョン情報の修正等を行う。

なお、本実施の形態１では、リビジョン番号は、改訂順に整数値が割り当てられているが、これに限るものではない。例えば、リビジョン番号は、改訂ごとにハッシュ値が割り当てられてもよい。また、リビジョン管理ツールは、ソフトウェア管理装置７の外部に設けられているものとする。

リビジョン情報取得部２は、リビジョン情報データベース８から対象ファイルのリビジョン情報を取得する。ここで、対象ファイルとは、例えば、上述のソフトウェア開発における各工程でバグが生じた場合に当該バグの原因を特定する際に対象となるファイルのことをいい、または改訂者が既存のソースコードを改訂する際に対象となるファイルのことをいう。リビジョン情報取得部２は、取得したリビジョン情報を開発者レベル管理部３および制御部４の各々に出力する。

開発者レベルデータベース９は、例えば、ハードディスク（HDD：Hard Disk Drive）または半導体メモリなどの記憶装置から構成されており、ソフトウェアを開発する開発者のレベルである開発者レベルを格納している。図５は、開発者レベルデータベース９に格納される開発者レベルの一例を示す図である。図５に示すように、開発者レベルデータベース９では、開発者名と、当該開発者の開発者レベルとが対応付けて格納されている。開発者レベルは、種々の方法で設定される。例えば、開発者を適宜に評価して、人手によって（手動で）開発者レベルを設定する方法がある。また、例えば、開発者の勤務年数等に基づいて自動的に開発者レベルを設定する方法がある。

なお、開発者レベルデータベース９は、リビジョン情報データベース８に格納されているリビジョン情報に含まれるコミッターと同一である開発者の開発レベル、およびコミッター以外の開発者の開発者レベルを格納している。すなわち、開発者レベルデータベース９では、ソフトウェアの開発に関与し得る者を開発者とし、当該開発者の開発者レベルを格納している。

開発者レベル管理部３は、リビジョン情報取得部２から入力されたリビジョン情報に基づいて、開発者レベルデータベース９から開発者レベルを抽出する。開発者レベル管理部３は、抽出した開発者レベルを制御部４に出力する。

制御部４は、リビジョン情報取得部２から入力されたリビジョン情報と、開発者レベル管理部３から入力された開発者レベルとに基づいて、対象ファイルにおけるソースコードの各行を開発者レベルに応じて区別して表示するように制御する。表示装置１０は、制御部４の制御に従って、開発者レベルに応じて区別されたソースコードを表示する。

次に、本実施の形態１によるソフトウェア管理装置７の動作について説明する。なお、本文の例を用いた説明では、説明を分かりやすくするために１つのソースファイルに着目して動作を説明するが、本発明は複数のソースファイルに対しても適用可能である。

図６は、ソフトウェア管理装置７の動作の一例を示すフローチャートである。なお、ステップＳ１０１の前において、リビジョン情報取得部２は、どのファイルを対象ファイルとしているのかを把握しているものとする。

ステップＳ１０１において、リビジョン情報取得部２は、リビジョン情報データベース８からリビジョン情報を取得する。具体的には、リビジョン情報取得部２は、例えば図４に示すようなソースコード改訂情報およびリビジョン対応情報を含むリビジョン情報をリビジョン情報データベース８から取得する。そして、リビジョン情報取得部２は、リビジョン対応情報を開発者レベル管理部３に出力し、ソースコード改訂情報およびリビジョン対応情報を制御部４に出力する。

ステップＳ１０２において、開発者レベル管理部３は、リビジョン情報取得部２から入力されたリビジョン情報に含まれるリビジョン対応情報に基づいて、開発者レベルデータベース９から開発者レベルを取得する。

ここで、ステップＳ１０２の詳細について、図７を用いて説明する。

ステップＳ２０１において、開発者レベル管理部３には、リビジョン対応情報に含まれるコミッター名が入力される。

ステップＳ２０２において、開発者レベル管理部３は、リビジョン情報取得部２から入力されたコミッター名に対応する開発者名を開発者レベルデータベース９から検索し、コミッター名と開発者名とが一致した場合に当該開発者の開発者レベルを開発者レベルデータベース９から抽出する。そして、開発者レベル管理部３は、抽出した開発者レベルを制御部４に出力する。

例えば、リビジョン情報取得部２から開発者レベル管理部３に図４に示すリビジョン対応情報が入力され、開発者レベルデータベース９には図５に示す開発者レベルが格納されているものとする。このような場合において、開発者レベル管理部３は、例えばリビジョン番号「５」のときのコミッター名「Tanaka」に対応する開発者名「Tanaka」を開発者レベルデータベース９から検索し、開発者名「Tanaka」の開発者レベル「３５」を抽出する。

図６に戻り、ステップＳ１０３において、制御部４は、リビジョン情報取得部２から入力されたリビジョン情報と、開発者レベル管理部３から入力された開発者レベルとに基づいて、対象ファイルのソースコードの各行を開発者レベルに応じて区別して表示するように制御する。具体的には、制御部４は、例えば図８に示すように、ソースコードの各行を開発者のレベルに応じて色分けして表示するように制御する。表示装置１０には、開発者レベルに応じて色分けされたソースコードの各行が表示される。

例えば、リビジョン情報取得部２から制御部４に図４に示すリビジョン情報が入力され、開発者レベル管理部３から制御部４に図５に示す管理者レベルが入力されたものとする。制御部４は、リビジョン番号が「１」のときのコミッターは「Sasaki」であるため、リビジョン番号「１」のソースコードの行を、「Sasaki」の開発者レベル「９０」に対応する色で表示するように制御する。他も同様に、リビジョン番号「５」のソースコードの行を、「Tanaka」の開発者レベル「３５」に対応する色で表示するように制御する。リビジョン番号「３」のソースコードの行を、「Suzuki」の開発者レベル「６０」に対応する色で表示するように制御する。

なお、ソースコードの各行を色分けして表示する方法として、例えば開発者レベルが勤務年数に基づいている場合は、開発者の勤務年数が１年未満のときは赤色、開発者の勤務年数が１年〜１０年未満のときは黄色、開発者の勤務年数が１０年以上であるときは青色にして表示するようにしてもよい。

本文ではソースコードを編集する（コーディングする）開発者とコミッターとが同一であるとして説明しているが、ソースコードを編集する開発者とコミッターとが異なる場合もあり得る。このような場合は、ソースコードを編集した開発者の開発者レベルではなく、編集されたソースコードを受け取ってソースコードのリビジョンの改訂を行ったコミッターの開発者レベルをもとにソースコードの各行が色分け表示される。よって、ソースコードの各行の色分けに反映されるコミッターの開発者レベルは、単にソースコードを編集する（コーディングの）能力としてではなく、他の開発者が編集したソースコードをチェックする能力も含めて捉えることになる。

次に、本実施の形態１の他の例（変形例１，２）について説明する。

＜変形例１＞
一般的に、開発者の開発レベルは、開発者の勤務年数の経過、または開発者の能力の向上に従って経時的に上がる。開発者レベルの向上を反映させるべく、開発者レベルデータベース９に格納されている開発者レベルも定期的に更新される。しかし、例えば図８に示すような表示を行う場合において、過去の開発者レベルが低いときに改訂したソースコードの行に対して、開発者レベルが過去の開発者レベルよりも上がった現在の開発者レベルに応じて色分けされてしまう（すなわち、改訂時の開発者レベルに応じた色分けができない）という問題がある。本変形例１は、このような問題を解決するものである。

図９は、開発者レベルデータベース９に格納される開発者レベルの一例を示す図である。

図９に示すように、開発者レベルデータベース９では、更新ごとに開発者レベルの履歴を格納している。図９では、３回の更新（更新Ａ，Ｂ，Ｃ）が行われたことを示している。また、各リビジョンとともに更新日時を示している。例えば、開発者「Tanaka」に注目すると、「Tanaka」の開発レベルは、更新Ａのときは「３５」、更新Ｂのときは「５０」、更新Ｃのときは「８０」であることが分かる。なお、開発者レベルの設定方法は、上述と同様である。

図１０は、図６のステップＳ１０２の詳細を示すフローチャートである。その他の動作は、図６と同様であるため、ここでは説明を省略する。

ステップＳ３０１において、開発者レベル管理部３には、リビジョン対応情報に含まれるコミッター名およびコミット日時が入力される。

ステップＳ３０２において、開発者レベル管理部３は、リビジョン情報取得部２から入力されたコミッター名およびコミット日時に基づいて、開発者レベルを開発者レベルデータベースから抽出する。そして、開発者レベル管理部３は、抽出した開発者レベルを制御部４に出力する。

例えば、リビジョン情報取得部２から開発者レベル管理部３に図４に示すリビジョン対応情報が入力され、開発者レベルデータベース９には図９に示す開発者レベルが格納されているものとする。このような場合において、開発者レベル管理部３は、例えばリビジョン番号「５」のときのコミッター名「Tanaka」に対応する開発者名「Tanaka」を開発者レベルデータベース９から検索する。そして、各更新Ａ〜Ｃにおける開発者「Tanaka」のうち、コミット日時よりも過去であって最新の更新Ｂにおける開発者レベル「５０」を抽出する。

上記より、ソースコードの各行を改訂時の開発レベルに応じて色分けして表示することができる。

＜変形例２＞
上述では、例えば図５に示すように、各開発者に対する開発者レベルの項目は１つである場合について説明したが、これに限るものではない。例えば、開発者の能力は、プログラミング言語の種別ごとに変わる場合がある。このような場合を想定して、開発者レベルを複数の項目にしてもよい。

図１１は、開発者レベルデータベース９に格納される開発者レベルの一例を示す図である。図１１の例では、各開発者に対して、「C/C++開発レベル」、「Java（登録商標）開発レベル」、および「Cobol開発レベル」の３つの項目が設定されている。

上記より、開発者レベル管理部３は、例えば対象ファイルのソースコードのプログラミング言語がC/C++である場合は、「C/C++開発レベル」を開発者レベルとして抽出すればよい。すなわち、開発者レベル管理部３は、実状に合った開発者レベルを抽出することができる。

以上のことから、本実施の形態１によれば、ソースコードの各行を開発者レベルに応じて区別して表示しているため、バグが発見された場合に開発者レベルが低いソースコードを優先して調べることによって、バグの原因を効率的に特定することが可能となる。また、既存のソースコードを改訂する場合において、ソースコードの各行の開発レベルを把握することができる。

なお、上記では、リビジョン管理ツールの管理によって、例えば図４に示すようなリビジョン情報がリビジョン情報データベース８に格納されている場合について説明した。しかし、ソースコードと当該ソースコードを改訂したリビジョン番号とをソースコードの行ごとに対応付けていないリビジョン情報を管理するリビジョン管理ツールがある。当該リビジョン管理ツールで管理されるリビジョン情報には、図４に示すようなソースコード改訂情報が含まれていない。このような場合において、リビジョン情報取得部２は、リビジョン情報データベース８から対象ファイルのリビジョン情報を全て取得し、取得したリビジョン情報に基づいて図４に示すようなソースコード改訂情報を生成するようにしてもよい。

リビジョン情報データベース８において、同姓のコミッターが複数存在する場合は、各コミッターを区別して格納する。開発者レベルデータベース９に格納される開発者名についても同様である。この場合、区別したコミッターと開発者名とを対応させる必要がある。

上記では、開発者レベルに応じてソースコードの各行を色分けして表示する場合について説明したが、これに限るものではない。開発者レベルが予め定められた閾値よりも低い場合は、対応するソースコードの行を太字等で強調したり、対応するソースコードの行が分かるような記号を付したりしてもよい。また、開発者レベルが予め定められた閾値よりも低いソースコードの行をリストアップしてもよい。

＜実施の形態２＞
まず、本発明の実施の形態２によるソフトウェア管理装置の構成について説明する。

図１２は、本実施の形態２によるソフトウェア管理装置１１の構成の一例を示すブロック図である。

図１２に示すように、本実施の形態２によるソフトウェア管理装置１１は、実行結果管理部１２およびソースコード抽出部１３を備えることを特徴としている。実行結果管理部１２は、実行結果データベース１４に接続されている。その他の構成および動作は、実施の形態１と同様であるため、ここでは詳細な説明を省略する。

リビジョン情報取得部２は、リビジョン情報データベース８から対象ファイルのリビジョン情報を取得するとともに、対象ファイルの実行結果を取得する。ここで、本実施の形態２による対象ファイルの実行結果とは、ソフトウェア開発の各工程（例えば、ビルド工程、テスト工程）での実行の成否のことをいう。実行結果は、例えばビルド工程で用いられるビルドツール、またはテスト工程で用いられるテストツールからリビジョン情報取得部２に入力される。このとき、実行結果とリビジョン情報とは、プラグインで対応付けられてリビジョン情報取得部２に入力される。このように、リビジョン情報取得部２は、対象ファイルを実行した時に、その実行結果とリビジョン情報とを取得する。リビジョン情報取得部２は、取得したリビジョン情報を開発者レベル管理部３および制御部４に出力し、取得した実行結果とリビジョン情報とを実行結果管理部１２に出力する。

実行結果管理部１２は、リビジョン情報取得部２から入力された実行結果とリビジョン情報とを対応付けて実行結果データベース１４に格納するように管理する。また、実行結果管理部１２は、実行結果データベース１４に格納しているリビジョン情報をソースコード抽出部１３に出力する。

実行結果データベース１４は、例えば、ハードディスク（HDD：Hard Disk Drive）または半導体メモリなどの記憶装置から構成されており、実行結果管理部１２の管理によって実行結果とリビジョン情報とを対応付けて格納している。図１３は、実行結果データベース１４に格納される実行結果の一例を示す図である。図１３に示すように、実行結果データベース１４では、実行したリビジョン番号ごとに、実行結果とリビジョン情報とを対応付けて格納している。例えば、リビジョン番号「１」およびリビジョン番号「５」の実行結果は「×（失敗）」であることを示しており、リビジョン番号「３」の実行結果は「○（成功）」であることを示している。

ソースコード抽出部１３は、実行結果管理部１２から入力されたリビジョン情報に基づいて、ソースコードの行を抽出する。ソースコード抽出部１３は、抽出したソースコードの行を開発者レベル管理部３に出力する。

なお、実行結果管理部１２およびソースコード抽出部１３は、例えば図２のプロセッサ５がメモリ６等に記憶されたプログラムを実行することにより、当該プロセッサ５の機能として実現される。ただし、これらは、例えば複数のプロセッサ５が連携して実現されてもよい。

次に、本実施の形態２によるソフトウェア管理装置１１の動作について説明する。

図１４は、ソフトウェア管理装置１１の動作の一例を示すフローチャートである。なお、図１４のステップＳ４０６、ステップＳ４０８、およびステップＳ４０９は、図６のステップＳ１０２およびステップＳ１０３の各々に対応しているため、ここでは説明を省略する。

ステップＳ４０１において、リビジョン情報取得部２は、リビジョン情報データベース８から対象ファイルのリビジョン情報を取得するとともに、対象ファイルの実行結果を取得する。例えば、リビジョン情報取得部２は、実行結果と、図１５に示すソースコード改訂情報を含むリビジョン情報とを取得する。なお、図１５では、ソースコードの現リビジョンのリビジョン番号が「５」であり、それよりも過去に改訂されたリビジョンも含むリビジョン番号「２」、「３」、「４」、「５」のリビジョンの改訂内容の影響を受けていることを示している。すなわち、リビジョン情報取得部２は、図１５に示すソースコード改訂情報を含む対象ファイルのリビジョン情報と、その実行結果を取得する。

ステップＳ４０２において、実行結果管理部１２は、リビジョン情報取得部２から入力された実行結果とリビジョン情報とを対応付けて実行結果データベース１４に格納するように管理する。図１３の例では、実行結果データベース１４には、リビジョン情報取得部２が今回取得したリビジョン番号「５」におけるリビジョン情報と実行結果とが格納されている。

ステップＳ４０３において、実行結果管理部１２は、今回の対象ファイルの実行結果が失敗であるか否かの判断を行う。実行結果が失敗である場合は、ステップＳ４０４に移行する。一方、実行結果が失敗でない（すなわち、実行結果が成功である）場合は、処理を終了する。図１３の例では、今回の対象ファイル（リビジョン番号「５」）の実行結果は「×（失敗）」となっている。

ステップＳ４０４において、実行結果管理部１２は、過去に実行結果が成功である親リビジョンのリビジョン情報が実行結果データベース１４に格納されているか否かの判断を行う。実行結果が成功である親リビジョンのリビジョン情報が実行結果データベース１４に格納されている場合は、ステップＳ４０５に移行する。一方、実行結果が成功である親リビジョンのリビジョン情報が実行結果データベース１４に格納されていない場合は、ステップＳ４０８に移行して実施の形態１と同様の処理が行われる。ここで、親リビジョンとは、対象ファイルにおける過去のリビジョン（改訂）のことをいう。図１３の例では、リビジョン番号「５」の親リビジョンはリビジョン番号「１」およびリビジョン番号「３」であり、リビジョン番号「３」のときの実行結果は「○（成功）」である。

ステップＳ４０５において、実行結果管理部１２は、今回のリビジョンのリビジョン情報と、過去に成功した親リビジョンのうちの最新の親リビジョンのリビジョン情報とを実行結果データベース１４から抽出してソースコード抽出部１３に出力する。図１３の例では、実行結果管理部１２は、リビジョン番号「５」（今回のリビジョン）のリビジョン情報と、リビジョン番号「３」（過去に成功した最新の親リビジョン）のリビジョン情報とを実行結果データベース１４から抽出してソースコード抽出部１３に出力する。なお、図１３に示すリビジョン番号「３」のリビジョン情報に含まれるソースコード改訂情報は、例えば図１６に示すソースコード改訂情報である。

ソースコード抽出部１３は、実行結果管理部１２から入力された今回のリビジョンのリビジョン情報と、過去に成功した最新の親リビジョンのリビジョン情報との差分をとり、当該差分部分のソースコードの行を改訂したコミッターを特定する。例えば、リビジョン番号「５」（今回のリビジョン）のリビジョン情報と、リビジョン番号「３」（過去に成功した最新の親リビジョン）のリビジョン情報との差分をとると、当該差分部分はリビジョン番号「４」およびリビジョン番号「５」に対応するソースコードの行となる。そして、ビジョン番号「４」およびリビジョン番号「５」のときに改訂したコミッターを特定する。

ステップＳ４０７において、制御部４は、リビジョン情報取得部２から入力されたリビジョン情報と、開発者レベル管理部３から入力された開発者レベルとに基づいて、対象ファイルのソースコードの各行をソースコード抽出部１３で特定されたコミッターの開発者レベルに応じて区別して表示するように制御する。具体的には、制御部４は、例えば図１７に示すように、リビジョン番号「４」およびリビジョン番号「５」に対応するソースコードの各行を開発者のレベルに応じて色分けして表示するように制御する。表示装置１０には、開発者レベルに応じて色分けされたソースコードの各行が表示される。

以上のことから、本実施の形態２によれば、今回失敗したリビジョン情報と、過去に成功した最新のリビジョン情報との差分部分のソースコードの行を色分けして表示しているため、ソースコードの全部の行を色分けして表示する実施の形態１よりも効率的にバグの原因を特定することができる。

＜実施の形態３＞
まず、本発明の実施の形態３によるソフトウェア管理装置の構成について説明する。

図１８は、本実施の形態３によるソフトウェア管理装置１５の構成の一例を示すブロック図である。

図１８に示すように、本実施の形態３によるソフトウェア管理装置１５は、実施の形態２によるソフトウェア管理装置１１（図１２参照）のソースコード抽出部１３に代えて、開発者評価部１６を備えることを特徴としている。その他の構成および動作は、実施の形態２と同様であるため、ここでは詳細な説明を省略する。

開発者評価部１６は、実行結果管理部１２から入力されたリビジョン情報に基づいて、開発者の評価を行う。具体的には、開発者評価部１６は、開発者レベルを下げる開発者（コミッター）を特定し、当該開発者の開発者レベルを下げると判断する。

なお、開発者評価部１６は、例えば図２のプロセッサ５がメモリ６等に記憶されたプログラムを実行することにより、当該プロセッサ５の機能として実現される。ただし、これらは、例えば複数のプロセッサ５が連携して実現されてもよい。

次に、本実施の形態３によるソフトウェア管理装置１５の動作について説明する。

図１９は、ソフトウェア管理装置１５の動作の一例を示すフローチャートである。

ステップＳ５０１において、リビジョン情報取得部２は、リビジョン情報データベース８から対象ファイルのリビジョン情報を取得するとともに、対象ファイルの実行結果を取得する。例えば、リビジョン情報取得部２は、実行結果と、図２０に示すソースコード改訂情報を含むリビジョン情報とを取得する。なお、図２０では、ソースコードの現リビジョンのリビジョン番号が「６」であり、それよりも過去に改訂されたリビジョンも含むリビジョン番号「２」、「３」、「４」、「６」のリビジョンの改訂内容の影響を受けていることを示している。すなわち、リビジョン情報取得部２は、図２０に示すソースコードを有する対象ファイルのリビジョン情報と、その実行結果を取得する。

ステップＳ５０２において、実行結果管理部１２は、リビジョン情報取得部２から入力された実行結果とリビジョン情報とを対応付けて実行結果データベース１４に格納するように管理する。例えば、図２１に示すように、実行結果データベース１４には、リビジョン情報取得部２が今回取得したリビジョン番号「６」におけるリビジョン情報と実行結果とが格納されている。

ステップＳ５０３において、実行結果管理部１２は、今回の対象ファイルの実行結果が成功であるか否かの判断を行う。実行結果が成功である場合は、ステップＳ５０４に移行する。一方、実行結果が成功でない（すなわち、実行結果が失敗である）場合は、処理を終了する。図２１の例では、今回の対象ファイル（リビジョン番号「６」）の実行結果は「○（成功）」となっている。

ステップＳ５０４において、実行結果管理部１２は、実行結果データベース１４に格納されている最新の親リビジョンの実行結果が失敗であるか否かの判断を行う。最新の親リビジョンの実行結果が失敗である場合は、ステップＳ５０５に移行する。一方、最新の親リビジョンの実行結果が失敗でない（最新の親リビジョンンの実行結果が成功である、または親リビジョンが実行結果データベース１４に格納されていない）場合は、処理を終了する。図２１の例では、リビジョン番号「６」の親リビジョンはリビジョン番号「１」、リビジョン番号「３」、およびリビジョン番号「５」であり、リビジョン番号「１」およびリビジョン番号「５」のときの実行結果は「×（失敗）」である。

ステップＳ５０５において、実行結果管理部１２は、今回のリビジョンのリビジョン情報と、過去に失敗した親リビジョンのうちの最新の親リビジョンのリビジョン情報とを実行結果データベース１４から抽出して開発者評価部１６に出力する。図２１の例では、実行結果管理部１２は、リビジョン番号「６」（今回のリビジョン）のリビジョン情報と、リビジョン番号「５」（過去に失敗した最新の親リビジョン）のリビジョン情報とを実行結果データベース１４から抽出して開発者評価部１６に出力する。なお、図２１に示すリビジョン番号「５」のリビジョン情報に含まれるソースコード改訂情報は、図２２に示すソースコード改訂情報であるものとする。

開発者評価部１６は、実行結果管理部１２から入力された今回のリビジョンのリビジョン情報と、過去に失敗した最新の親リビジョンのリビジョン情報との差分をとり、過去に失敗した最新の親リビジョンにおける当該差分部分に対応するリビジョンのコミッターを特定し、特定したコミッターの開発者レベルを下げると判断する。例えば、今回のリビジョンであるリビジョン番号「６」のリビジョン情報と、過去に失敗した最新の親リビジョンであるリビジョン番号「５」のリビジョン情報との差分をとると、当該差分部分は今回のリビジョンにおいてはリビジョン番号「６」に対応するソースコードの行となる（例では、過去に失敗した最新の親リビジョンから今回のリビジョンの間に改訂されたリビジョンがリビジョン番号「６」のリビジョンだけであるのでリビジョン番号「６」だけが対象となるが、過去に失敗した最新の親リビジョンから改訂されたリビジョンが複数ある場合は各リビジョンに対応するソースコードの行を対象とする）。過去に失敗した最新の親リビジョンにおいて、この行はリビジョン番号「５」のリビジョンに対応する（例では、過去に失敗した最新の親リビジョンのリビジョン番号と差分部分に対応するリビジョンのリビジョン番号が同一であるが異なる場合もあり得る）。これにより、バグがリビジョン番号「５」のリビジョンにより埋め込まれていたと推定できるので、開発者評価部１６は、リビジョン情報よりリビジョン番号「５」において改訂したコミッターを特定し、当該コミッターの開発者レベルを下げると判断する。

ステップＳ５０６において、開発者レベル管理部３は、開発者評価部１６で特定されたコミッターに対応する開発者の開発者レベルを下げる。すなわち、開発者レベル管理部３は、開発者レベルデータベース９に格納されている開発者レベルの更新を行う。例えば、開発者レベルデータベース９に図５に示す開発者レベルが格納されている場合において、開発者レベル管理部３は、開発者評価部１６で特定されたコミッター（ここでは「Tanaka」）の開発者レベルを「３５」から「３０」に下げる（図２３参照）。なお、開発者レベルをどのように下げるのかについては、任意の方法で決定すればよい。

以上のことから、本実施の形態３によれば、過去に改訂を失敗したコミッターを特定し、当該コミッターの開発者レベルを下げているため、より適切な開発者レベルの評価を行うことができる。また、このように更新された開発者レベルに応じてソースコードの各行を区別して表示することによって、バグの原因を効率的に特定することが可能となる。また、既存のソースコードを改訂する場合において、ソースコードの各行の開発レベルを把握することができる。

なお、図１９のステップＳ５０５とステップＳ５０６との間において、開発レベルを下げると判断されたコミッター名と、当該コミッターが改訂したソースコードとを表示し、コミッターの開発レベルを下げるか否かをユーザに確認するようにしてもよい。この場合、開発者の評価をより慎重に行うことができる。

＜実施の形態４＞
実施の形態３では、失敗したリビジョンにおけるリビジョン情報と、その後に成功したリビジョンにおけるリビジョン情報との差分部分にバグの原因があるものとして、当該差分部分を失敗したときに改訂したコミッターの開発者レベルを下げる場合について説明した。しかし、上記の差分部分は、バグの原因以外の部分も含まれることがあり、開発者レベルが適切に評価されているとはいえなかった。本発明の実施の形態４では、このような問題を解決したものであり、以下に詳細を説明する。なお、本実施の形態４によるソフトウェア管理装置の構成は、実施の形態３によるソフトウェア管理装置１５（図１８参照）の構成と同様である。以下では、実施の形態４によるソフトウェア管理装置は、図１８に示すソフトウェア管理装置１５であるものとして説明する。

図２４は、本実施の形態４によるソフトウェア管理装置１５の動作の一例を示すフローチャートである。

ステップＳ６０１において、リビジョン情報取得部２は、リビジョン情報データベース８から対象ファイルのリビジョン情報を取得するとともに、対象ファイルの実行結果を取得する。

ステップＳ６０２において、実行結果管理部１２は、リビジョン情報取得部２から入力された実行結果とリビジョン情報とを対応付けて実行結果データベース１４に格納するように管理する。

ステップＳ６０３において、実行結果管理部１２は、今回（第２のタイミング）の対象ファイルの実行結果が失敗であるか否かの判断を行う。実行結果が失敗である場合は、ステップＳ６０４に移行する。一方、実行結果が失敗でない（すなわち、実行結果が成功である）場合は、ステップＳ６０６に移行する。

ステップＳ６０４において、実行結果管理部１２は、過去（第１のタイミング）に実行結果が成功である親リビジョンのリビジョン情報が実行結果データベース１４に格納されているか否かの判断を行う。実行結果が成功である親リビジョンのリビジョン情報が実行結果データベース１４に格納されている場合は、ステップＳ６０５に移行する。一方、実行結果が成功である親リビジョンのリビジョン情報が実行結果データベース１４に格納されていない場合は、処理を終了する。

ステップＳ６０５において、実行結果管理部１２は、今回のリビジョンのリビジョン情報と、過去に成功した親リビジョンのうちの最新の親リビジョンのリビジョン情報とを実行結果データベース１４から抽出して開発者評価部１６に出力する。

開発者評価部１６は、実行結果管理部１２から入力された今回のリビジョンのリビジョン情報と、過去に失敗した最新の親リビジョンのリビジョン情報との差分をとり、当該差分部分に対応するリビジョンをバグ原因候補リビジョン（第１のリビジョン）として記憶する。なお、バグ原因候補リビジョンは、開発者評価部１６に記憶してもよく、他の記憶部（図示せず）に記憶してもよい。

例えば、図２５に示すソースコード改訂情報が今回（ここでは実行結果は失敗）のリビジョンのリビジョン情報に含まれており、図２６に示すソースコード改訂情報が過去に成功した最新の親リビジョンのリビジョン情報に含まれている場合において、開発者評価部１６は、各リビジョン情報の差分部分に対応するリビジョン番号「７」およびリビジョン番号「８」をバグ原因候補リビジョンとする。なお、図２５はリビジョン番号「８」のときに実行されたソースコード改訂情報を示し、図２６はリビジョン番号「６」のときに実行されたソースコード改訂情報を示している。

ステップＳ６０６において、開発者評価部１６は、バグ原因候補リビジョンが記憶されているか否かの判断を行う。バグ原因候補リビジョンが記憶されている場合は、ステップＳ６０７に移行する。一方、バグ原因候補リビジョンが記憶されていない場合は、処理を終了する。

ステップＳ６０７において、開発者評価部１６は、過去に失敗した最新の親リビジョンのリビジョン情報と、今回（第３のタイミング）のリビジョン（第２のリビジョン）のリビジョン情報との差分をとり、当該差分部分にバグ原因候補リビジョンに対応するソースコードの行が含まれているか否かの判断を行う。バグ原因候補リビジョンに対応するソースコードの行が含まれている場合は、ステップＳ６０８に移行する。一方、バグ原因候補リビジョンに対応するソースコードの行が含まれていない場合は、処理を終了する。

ステップＳ６０８において、開発者評価部１６は、バグ原因候補リビジョンに記憶されているリビジョンの内、当該差分部分のソースコードに改訂を行ったリビジョンのコミッターの開発レベルを下げると判断し、バグ原因候補リビジョンに対応するソースコードの行を今回改訂したコミッターの開発者レベルを上げると判断する。

例えば、図２７に示すソースコード改訂情報が今回（ここでは、実行結果は成功）のリビジョンのリビジョン情報に含まれており、図２５に示すソースコード改訂情報におけるリビジョン番号「７」およびリビジョン番号「８」がバグ原因候補リビジョンであるものとする。このような場合において、各リビジョン情報の差分部分におけるリビジョン番号「９」に対応するソースコードをリビジョン番号「７」のときに改訂したコミッターの開発レベルを下げると判断し、リビジョン番号「９」のときに改訂したコミッターの開発レベルを上げると判断する。なお、図２７は、リビジョン番号「１０」のときに実行されたソースコード改訂情報を示している。

ステップＳ６０９において、開発者レベル管理部３は、開発者評価部１６で特定されたコミッターに対応する開発者の開発者レベルを変更する。具体的には、開発者レベル管理部３は、実行結果が失敗となった原因となるソースコードを改訂したコミッター（図２５の例では、リビジョン番号「７」のときに改訂したコミッター）の開発者レベルを下げる。また、開発者レベル管理部３は、実行結果が成功となった（過去の失敗を解消した）原因となるソースコードを改訂したコミッター（図２７の例では、リビジョン番号「９」のときに改訂したコミッター）の開発者レベルを上げる。

ステップＳ６１０において、バグ原因候補リビジョンとして記憶していたすべてのリビジョンをバグ原因候補リビジョンから消去する。

以上のことから、本実施の形態４によれば、実施の形態３よりも精度良く、過去に改訂を失敗したコミッターを特定することができる。また、過去の失敗を解消したコミッターの評価を上げているため、より適切な開発者の評価を行うことができる。

なお、図２４のステップＳ６０８とステップＳ６０９との間において、開発レベルを変更する判断されたコミッター名と、当該コミッターが改訂したソースコードとを表示し、コミッターの開発レベルを変更するか否かをユーザに確認するようにしてもよい。この場合、開発者の評価をより慎重に行うことができる。

＜実施の形態５＞
本発明の実施の形態５では、ソフトウェア開発における静的解析工程等の問題のある（バグの原因となる）ソースコードの行が特定できる場合においてエラーまたは警告が出たときに、当該エラーまたは警告を生じさせたコミッターの評価を下げることを特徴としている。以下では、静的解析工程に関してのみ記述するが、問題のあるソースコードの行が特定できるツールを用いる場合は静的解析工程に限らず本実施の形態の対象とすることが可能である。なお、本実施の形態５によるソフトウェア管理装置の構成は、実施の形態３によるソフトウェア管理装置１５（図１８参照）の構成と同様である。ただし、実行結果データベース１４には必ずしも過去のリビジョンの実行結果を蓄積する必要はない。以下では、実施の形態５によるソフトウェア管理装置は、図１８に示すソフトウェア管理装置１５であるものとして説明する。

図２８は、本実施の形態５によるソフトウェア管理装置１５の動作の一例を示すフローチャートである。

ステップＳ７０１において、リビジョン情報取得部２は、リビジョン情報データベース８から対象ファイルのリビジョン情報を取得するとともに、対象ファイルの実行結果を取得する。ここで、本実施の形態５における対象ファイルの実行結果とは、ソフトウェア開発における静的解析工程での実行結果のことであり、ソースコードのエラーまたは警告が生じている箇所（行）を指摘するものである。静的解析工程では、ソースコードがコーディングルール等に従っているか（コーディングルール等に反していないか）否かを判断しており、ソースコードがコーディングルール等に従っていない場合は、エラーまたは警告を示す実行結果がリビジョン情報取得部２に入力される。また、実行結果およびリビジョン情報は、プラグインで対応付けられてリビジョン情報取得部２に入力される。

例えば、リビジョン情報取得部２は、実行結果と、図２９に示すソースコード改訂情報を含むリビジョン情報とを取得する。なお、図２９では、今回、リビジョン番号「６」のソースコードの行が改訂されたことを示している。すなわち、リビジョン情報取得部２は、図２９に示すソースコード改訂情報を含む対象ファイルのリビジョン情報と、その実行結果を取得する。

ステップＳ７０２において、実行結果管理部１２は、リビジョン情報取得部２から入力された実行結果とリビジョン情報とを対応付けて実行結果データベース１４に格納するように管理する。例えば、図３０に示すように、実行結果データベース１４には、リビジョン情報取得部２が今回取得したリビジョン番号「６」のリビジョン情報と実行結果（図３０では図示せず）が格納されている。

ステップＳ７０３において、実行結果管理部１２は、今回の対象ファイルの実行結果においてエラーまたは警告が生じている箇所があるか否かの判断を行う。エラーまたは警告が生じている箇所がある場合は、ステップＳ７０４に移行する。一方、エラーまたは警告が生じている箇所がない場合は、処理を終了する。

ステップＳ７０４において、実行結果管理部１２は、今回のリビジョンのリビジョン情報と、過去の最新の親リビジョンのリビジョン情報とを実行結果データベース１４から抽出して開発者評価部１６に出力する。図３０の例では、実行結果管理部１２は、リビジョン番号「６」（今回のリビジョン）のリビジョン情報と、リビジョン番号「５」のリビジョン情報とを実行結果データベース１４から抽出して開発者評価部１６に出力する。

開発者評価部１６は、実行結果管理部１２から入力された今回のリビジョンのリビジョン情報と、過去の最新の親リビジョンのリビジョン情報との差分をとり、当該差分部分が静的解析によるエラーまたは警告の該当箇所である場合は、当該差分部分の静的解析によるエラーまたは警告の該当箇所を改訂したコミッターの開発者レベルを下げると判断する。図２９の例では、リビジョン番号「６」が今回のリビジョンのリビジョン情報と過去の最新の親リビジョンのリビジョン情報との差分部分に該当し、リビジョン番号「６」に対応するソースコードにおいて、「＝」の前後にスペースを入れなければならないコーディングルールに従っておらず、静的解析の実行結果においてエラーまたは警告の該当箇所になっている。よって、リビジョン情報よりリビジョン番号「６」のリビジョンのコミッターを特定し、当該コミッターの開発者レベルを下げると判断する。

ステップＳ７０５において、開発者レベル管理部３は、開発者評価部１６で特定されたコミッターに対応する開発者の開発者レベルを下げる。すなわち、開発者レベル管理部３は、開発者レベルデータベース９に格納されている開発者レベルの更新を行う。例えば、開発者レベルデータベース９に図５に示す開発者レベルが格納されている場合において、開発者レベル管理部３は、開発者評価部１６で特定されたコミッター（ここでは「Sasaki」）の開発者レベルを「９０」から「８０」に下げる（図３１参照）。

以上のことから、本実施の形態５によれば、静的解析においてエラーまたは警告が出るソースコードを記述したコミッターの開発レベルを下げているため、より適切な開発者レベルの評価を行うことができる。

なお、図２８のステップＳ７０４とステップＳ７０５との間において、開発レベルを下げると判断されたコミッター名と、当該コミッターが改訂したソースコードとを表示し、コミッターの開発レベルを下げるか否かをユーザに確認するようにしてもよい。この場合、開発者の評価をより慎重に行うことができる。

＜実施の形態６＞
まず、本実施の形態６によるソフトウェア管理装置の構成について説明する。

図３２は、本実施の形態６によるソフトウェア管理装置１７の構成の一例を示すブロック図である。

図３２に示すように、本実施の形態６によるソフトウェア管理装置１７は、ファイルレベル評価部１８を備えることを特徴としている。その他の構成および動作は、実施の形態１と同様であるため、ここでは詳細な説明を省略する。

ファイルレベル評価部１８は、リビジョン情報取得部２から入力された対象ファイルのリビジョン情報と、開発者レベル管理部３から入力された対象ファイルに寄与する開発者レベルとに基づいて、ソースファイルおよびソフトウェアのうちの少なくとも１つのレベルを評価する。

次に、本実施の形態６によるソフトウェア管理装置１７の動作について説明する。

図３３は、ソフトウェア管理装置１７の動作の一例を示すフローチャートである。なお、図３３のステップＳ８０１およびステップＳ８０２は、図６のステップＳ１０１およびステップＳ１０２に対応しているため、ここでは説明を省略する。

ステップＳ８０３において、ファイルレベル評価部１８は、対象ファイルのレベルを評価する。具体的には、ファイルレベル評価部１８は、リビジョン情報取得部２から入力された対象ファイルのリビジョン情報と、開発者レベル管理部３から入力された対象ファイルに寄与する開発者レベルとに基づいて、例えば図３４に示すような、開発者レベルごとにソースコードの行数を集計する。そして、ファイルレベル評価部１８は、対象ファイルのソースコードの全ての行に対して、予め定められた開発者レベル以上のコミッターが改訂したソースコードの行数の割合を算出し、算出した割合をファイルのレベルとする。ここで、予め定められた開発者レベルとは、ユーザが任意に設定したものである。

ステップＳ８０４において、ファイルレベル評価部１８は、対象ファイルを含む複数のファイルから一のソフトウェアが構成されているか否かの判断を行う。ソフトウェアが対象ファイルを含む複数のファイルから構成されている場合は、ステップＳ８０５に移行する。一方、ソフトウェアが対象ファイルを含む複数のファイルから構成されていない場合は、処理を終了する。

ステップＳ８０５において、ファイルレベル評価部１８は、ソフトウェアを構成する複数のファイルのレベルに基づいて、当該ソフトウェアのレベルを算出する。ソフトウェアのレベルは、例えば、各ファイルのレベルの平均としてもよい。なお、ステップＳ８０５の処理を行う場合は、ステップＳ８０３においてソフトウェアを構成する各ファイルのレベルが算出されている必要がある。

以上のことから、本実施の形態６によれば、対象ファイルのレベル、または対象ファイルを含むソフトウェアのレベルを把握することができる。

以上で説明したソフトウェア管理装置は、サーバ、および携帯通信端末（例えば、携帯電話、スマートフォン、およびタブレット端末など）を適宜に組み合わせてシステムとして構築されるソフトウェア管理装置にも適用することができる。この場合、ソフトウェア管理装置の各機能あるいは各構成要素は、上記システムを構築する各機能に分散して配置される。

具体的には、一例としてソフトウェア管理装置の機能をサーバに配置することができる。例えば、図３５に示すように、ユーザ側に図３に示す表示装置１０と同様の機能を有する表示装置１０を備え、サーバ１９に図３に示すソフトウェア管理装置７と同様の機能を有する各構成要素を備えることによってソフトウェア管理システムを構築することができる。なお、サーバ１９に備えられる各構成要素は、適宜にサーバ１９および表示装置１０に分散して配置するようにしてもよい。また、図１２，１８，３２に示す各構成要素についても同様である。

また、他の一例として、ソフトウェア管理装置の機能をサーバおよび携帯通信端末に配置することができる。例えば、図３６に示すように、ユーザ側に図３に示す表示装置１０と同様の機能を有する表示装置１０を備え、サーバ２０に図３に示すリビジョン情報取得部２および開発者レベル管理部３を備え、携帯通信端末２１に図３に示す制御部４を備えることによってソフトウェア管理システムを構築することができる。なお、サーバ２０および携帯通信端末２１に備えられる各構成要素は、適宜に表示装置１０、サーバ２０、および携帯通信端末２１に分散して配置するようにしてもよい。また、図１２，１８，３２に示す各構成要素についても同様である。

上記の構成とした場合であっても、上記の実施の形態と同様の効果が得られる。

また、上記の実施の形態における動作を実行するソフトウェア（ソフトウェア管理方法）を、例えばサーバや携帯通信端末に組み込んでもよい。

具体的には、一例として、上記のソフトウェア管理方法は、ソースファイル内のソースコードの各行に対応するリビジョンと、ソースコードを改訂した改訂者とを含むリビジョン情報を取得し、改訂者を含むソースコードの開発者のレベルを示す開発者レベルを管理し、取得したリビジョン情報に含まれる改訂者に対応する開発者の開発者レベルを抽出し、取得したリビジョン情報と、抽出された開発者レベルとに基づいて、ソースコードの各行を開発者レベルに応じて区別して表示するように制御する。

上記より、上記の実施の形態における動作を実行するソフトウェアをサーバや携帯通信端末に組み込んで動作させることによって、上記の実施の形態と同様の効果が得られる。

なお、図１，３，１２，１８，３２，３５，３６において、リビジョン情報取得部２、開発者レベル管理部３、制御部４、実行結果管理部１２、ソースコード抽出部１３、開発者評価部１６、およびファイルレベル評価部１８の各々は、図２のプロセッサ５がメモリ６等に記憶されたソフトウェアプログラムに従って動作することにより実現された。しかし、これに代えて、リビジョン情報取得部２、開発者レベル管理部３、制御部４、実行結果管理部１２、ソースコード抽出部１３、開発者評価部１６、およびファイルレベル評価部１８の各々は、ハードウェア（例えば、電気信号に対して特定の演算あるいは処理を行うように構成された演算／処理回路等）として構成するようにしてもよい。また、上記の両者を混在させてもよい。

また、ソフトウェアのリビジョン情報取得部２、開発者レベル管理部３、制御部４、実行結果管理部１２、ソースコード抽出部１３、開発者評価部１６、およびファイルレベル評価部１８の各々と、ハードウェアのリビジョン情報取得部２、開発者レベル管理部３、制御部４、実行結果管理部１２、ソースコード抽出部１３、開発者評価部１６、およびファイルレベル評価部１８の各々とを組み合わせた概念として、「部」という語に代えて「処理回路」という語を用いることもできる。

なお、本発明は、その発明の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略することが可能である。

本発明は詳細に説明されたが、上記した説明は、すべての態様において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。

１ ソフトウェア管理装置、２ リビジョン情報取得部、３ 開発者レベル管理部、４ 制御部、５ プロセッサ、６ メモリ、７ ソフトウェア管理装置、８ リビジョン情報データベース、９ 開発者レベルデータベース、１０ 表示装置、１１ ソフトウェア管理装置、１２ 実行結果管理部、１３ ソースコード抽出部、１４ 実行結果データベース、１５ ソフトウェア管理装置、１６ 開発者評価部、１７ ソフトウェア管理装置、１８ ファイルレベル評価部、１９，２０ サーバ、２１ 携帯通信端末。

Claims (15)

1. ソースファイル内のソースコードの各行に対応するリビジョンと、前記ソースコードを改訂した改訂者とを含むリビジョン情報を取得するリビジョン情報取得部と、
   前記ソースコードの開発者のレベルを示す開発者レベルを管理し、前記リビジョン情報取得部で取得された前記リビジョン情報に含まれる前記改訂者に対応する前記開発者の前記開発者レベルを抽出する開発者レベル管理部と、
   前記リビジョン情報取得部で取得された前記リビジョン情報と、前記開発者レベル管理部で抽出された前記開発者レベルとに基づいて、前記ソースコードの各行を前記開発者レベルに応じて区別して表示するように制御する制御部と、
   を備える、ソフトウェア管理装置。
2. 前記開発者レベルは、予め定められたタイミングで更新されることを特徴とする、請求項１に記載のソフトウェア管理装置。
3. 前記リビジョン情報は、前記改訂者が前記ソースコードを改訂した日時を示す日時情報を含み、
   前記制御部は、前記ソースコードの各行を、前記日時情報に示される前記日時よりも過去でありかつ最新の前記予め定められたタイミングで更新された前記開発者レベルに応じて区別して表示するように制御することを特徴とする、請求項２に記載のソフトウェア管理装置。
4. 前記ソースコードの実行結果と、前記リビジョン情報取得部で取得された前記リビジョン情報とを対応付けて管理し、今回の前記実行結果は失敗であると判断した場合において、当該今回の前記実行結果に対応する前記リビジョン情報と、前記実行結果は成功であると判断した過去の前記リビジョン情報のうちの最新の前記リビジョン情報とを抽出する実行結果管理部と、
   前記実行結果管理部で抽出された前記今回のリビジョン情報に含まれるソースコードと、前記最新のリビジョン情報に含まれるソースコードとの差分部分における前記ソースコードの行を抽出するソースコード抽出部と、
   をさらに備え、
   前記制御部は、前記ソースコード抽出部で抽出された前記ソースコードの行を区別して表示するように制御することを特徴とする、請求項１に記載のソフトウェア管理装置。
5. 前記ソースコードの実行結果と、前記リビジョン情報取得部で取得された前記リビジョン情報とを対応付けて管理し、今回の前記実行結果は成功であると判断した場合において、当該今回の前記実行結果に対応する前記リビジョン情報と、前記実行結果は失敗であると判断した過去の前記リビジョン情報のうちの最新の前記リビジョン情報とを抽出する実行結果管理部と、
   前記実行結果管理部で抽出された前記今回の前記実行結果に対応する前記リビジョン情報と、前記最新の前記リビジョン情報との差分部分における前記ソースコードの行を前記過去に改訂した前記改訂者を特定し、特定した前記改訂者に対応する前記開発者の前記開発者レベルを下げる評価を行う開発者評価部と、
   をさらに備えることを特徴とする、請求項１に記載のソフトウェア管理装置。
6. 前記ソースコードの実行結果と、前記リビジョン情報取得部で取得された前記リビジョン情報とを対応付けて管理する実行結果管理部と、
   第１のタイミングで前記実行結果管理部が前記実行結果は成功であると判断した前記リビジョンと、前記第１のタイミング後の第２のタイミングで前記実行結果管理部が前記実行結果は失敗であると判断した前記リビジョンとの間において改訂された前記リビジョンである第１のリビジョンを特定し、前記第２のタイミング後の第３のタイミングで前記実行結果管理部が前記実行結果は成功であると判断した前記リビジョンである第２のリビジョンにおいて、前記第１のリビジョンで改訂された前記ソースコードの行をさらに改訂したか否かに基づいて前記開発者レベルの評価を行う開発者評価部と、
   をさらに備えることを特徴とする、請求項１に記載のソフトウェア管理装置。
7. 前記開発者評価部は、前記第２のリビジョンにおいて前記第１のリビジョンで改訂された前記ソースコードの行をさらに改訂したと判断した場合は、前記第１のリビジョンで前記ソースコードの行を改訂した前記改訂者に対応する前記開発者の前記開発者レベルを下げる評価を行うことを特徴とする、請求項６に記載のソフトウェア管理装置。
8. 前記開発者評価部は、前記第２のリビジョンにおいて前記第１のリビジョンで改訂した前記ソースコードの行をさらに改訂したと判断した場合は、前記第２のリビジョンで前記ソースコードの行を改訂した前記改訂者に対応する前記開発者の前記開発者レベルを上げる評価を行うことを特徴とする、請求項６に記載のソフトウェア管理装置。
9. 前記ソースコードの実行結果と、前記リビジョン情報取得部で取得された前記リビジョン情報とを対応付けて管理する実行結果管理部と、
   前記実行結果管理部が今回の前記実行結果は失敗であると判断した場合において、当該今回の前記実行結果に対応する前記リビジョン情報と、前記実行結果管理部が管理する過去の最新の前記リビジョン情報との差分部分における前記ソースコードが静的解析によるエラーまたは警告の該当箇所である場合は、前記静的解析によるエラーまたは警告の該当箇所である前記ソースコードの行を改訂した前記改訂者に対応する前記開発者の前記開発者レベルを下げる評価を行う開発者評価部をさらに備えることを特徴とする、請求項１に記載のソフトウェア管理装置。
10. 前記ソースコード全体に対する、予め定められた前記開発者レベル以上の前記改訂者が改訂した前記ソースコードの行数の割合に基づいて、前記ソースファイルのレベルを評価するファイルレベル評価部をさらに備えることを特徴とする、請求項１に記載のソフトウェア管理装置。
11. 複数の前記ソースファイルから一のソフトウェアが構成される場合において、
    前記ファイルレベル評価部は、各前記ソースファイルのレベルに基づいて、前記ソフトウェアのレベルを評価することを特徴とする、請求項１０に記載のソフトウェア管理装置。
12. 前記開発者レベル管理部は、プログラミング言語の種別ごとに前記開発者レベルを管理することを特徴とする、請求項１に記載のソフトウェア管理装置。
13. 前記開発者レベルは、手動で設定されることを特徴とする、請求項１に記載のソフトウェア管理装置。
14. 前記開発者レベルは、自動で設定されることを特徴とする、請求項１に記載のソフトウェア管理装置。
15. ソースファイル内のソースコードの各行に対応するリビジョンと、前記ソースコードを改訂した改訂者とを含むリビジョン情報を取得し、
    前記ソースコードの開発者のレベルを示す開発者レベルを管理し、前記取得した前記リビジョン情報に含まれる前記改訂者に対応する前記開発者の前記開発者レベルを抽出し、
    前記取得した前記リビジョン情報と、前記抽出された前記開発者レベルとに基づいて、前記ソースコードの各行を前記開発者レベルに応じて区別して表示するように制御する、ソフトウェア管理方法。

Images