JP2011081496A - 成果物レビュー支援装置 - Google Patents

Abstract

【課題】コメントや修正例を適切に引き継ぐことのできる成果物のレビュー支援装置を提供する。
【解決手段】成果物の変更の履歴を版として保存し、指定された版の成果物を取り出す版管理手段と、成果物を作成する際に遵守すべきルールに基づいて成果物を検査し、ルール違反を指摘として摘示する検査手段と、前記ルール、前記指摘、前記指摘に対応して前記ルールを解説したコメント及び成果物の修正例を、前記ルール別かつ前記成果物の版別に検索可能に格納するデータ格納手段と、前記指摘を表示する表示手段と、新たな指摘が既に以前の版で指摘済みであるか判断する同等箇所特定手段と、前記指摘どうしの類似性を判定する類似性計算手段とを備え、新たな成果物あるいは版を解析して得られた前記指摘に対して、前記類似性計算手段で類似性が認められた場合に、既に登録済みの前記コメント、前記修正例を引き継いで、前記表示手段に表示する。
【選択図】図１

Description

本発明は、成果物のレビューを支援する成果物レビュー支援装置に関する。

従来より、プログラムのソースコード等の成果物の不具合の有無を検証するため、静的解析が行われている。静的解析の結果は、一連の指摘として表わされるが、指摘に含まれる情報は抽象度が高く、成果物の修正に必要な情報を必ずしも提供していない場合がある。

また、静的解析はそれぞれの成果物や、版（バージョン）ごとに実行されるので、各解析結果は互いに直接の関連を持っていない。

指摘をレビューするときに各指摘に対してコメント・修正例を付与しているが、指摘の中には同じようなものも多数存在している。

そこで、静的解析システムが抱えている問題点を解消しようとする静的解析ツールを用いたシステムが提案されている(例えば、特許文献１参照。）。

これは、プログラム・ファイルの変更が発生した状態をバージョンとして、各バージョンにおける静的解析ツールによる解析結果を記憶する複数の解析結果ファイルを備えて、あるバージョンの解析結果ファイルと、他のバージョンの解析結果ファイルとの差分情報からこの差分にある変更処置部分を抽出し、かつこの差分情報の警告文中の範囲情報を得て、この差分情報に対応する警告文を出力するデータ管理部を備えたものである。

特開２００４−１２６８６６号公報

上記した特許文献１では、前後の版間で指摘を行・列番号によって比較し、一致／不一致をリスト化し、このリストを利用して様々なフィルタリングを行って警告文の抑止などを行い、結果として前後の版間で指摘の引継ぎを実現するが、１対１の引継ぎになっている。

しかしながら、静的解析においては、静的解析の結果出力される抽象的な指摘だけではどのように修正してよいか分からず、指摘ごとの修正方法を示すレビューが要請されている。さらに、成果物ごとの静的解析結果は、互いに直接の関連を持たないため、解析するたびにレビューをやり直すことになり、過去の情報を十分に有効活用できておらず、レビューの際のコメントの作成や修正例の提示には、時間がかかるという問題点があった。

そこで、本発明は、上記の問題に鑑みてなされたもので、指摘に付与されたコメントや修正例を適切に引き継ぐことのできる成果物のレビュー支援装置を提供するものである。

本発明の一態様によれば、成果物の変更の履歴を版として保存し、指定された版の成果物を取り出す版管理手段と、成果物を作成する際に遵守すべきルールに基づいて成果物を検査し、ルール違反を指摘として摘示する検査手段と、前記ルール、前記検査手段によって摘示された指摘、前記指摘に対応して前記ルールを解説したコメント及び前記指摘に対応するとともに前記ルールに沿った成果物の修正例を、前記ルール別かつ前記成果物の版別に検索可能に格納するデータ格納手段と、前記指摘を前記データ格納手段から取り出して表示する表示手段と、前記取り出した指摘に対応する前記コメント、前記修正例を編集する編集手段と、前記データ格納手段に格納されている指摘を利用して、新たな指摘が既に以前の版で指摘済みであるか判断する同等箇所特定手段と、前記指摘どうしの類似性を判定する類似性計算手段と、ユーザから前記検査の開始、前記検査結果の閲覧、前記コメントの登録要求を受け付ける入力手段とを備え、新たな成果物あるいは版を解析して得られた前記指摘に対して、前記類似性計算手段で類似性が認められた場合に、既に登録済みの前記コメント、前記修正例を引き継いで、前記表示手段に表示することを特徴とする成果物レビュー支援装置が提供される。

また、本発明の別の一態様によれば、前記コメント、前記修正例は、別々に管理して前記データ格納手段に格納されることを特徴とする成果物レビュー支援装置が提供される。

本発明によれば、指摘に付与されたコメントや修正例を適切に引き継ぐので、版を更新するごとにリセットされていた指摘とコメント、修正例の対応関係を自動的に構築でき、レビューにかかる負担が軽減される。また、成果物や成果物の版を越えたコメント、修正例の引き継ぎ及び再利用が可能で、互いに重複するコメントや修正例が多数蓄積されるのを防止することが可能となる。

本発明の実施形態に係る成果物レビュー支援装置の構成例を示す概念図である。 指摘テーブルの一例を示す図である。 ルールの持つ属性を説明する図である。 ルールテーブルの一例を示す図である。 指摘の持つ属性を説明する図である。 指摘テーブルの一例を示す図である。 コメントの持つ属性を説明する図である。 コメントテーブルの一例を示す図である。 修正例の持つ属性を説明する図である。 修正例テーブルの一例を示す図である。 指摘_コメントのデータ構造を説明する図である。 指摘テーブル、コメントテーブル、指摘_コメントテーブルの関連の一例を示す図である。 指摘_修正例のデータ構造を説明する図である。 指摘テーブル、修正例テーブル、指摘_修正例テーブルの関連の一例を示す図である。 コメントと修正例の一例を示す図である。 ルール、指摘、コメント、修正例の関係を説明する図である。 静的解析結果の一例を示す図である。 レビュー処理の全体の流れを示すフローチャートである。 解析の実行の流れを示すフローチャートである。 解析結果の登録処理の流れを示すフローチャートである。 解析結果の表示処理の流れを示すフローチャートである。 レビュー実施の詳細な流れを示すフローチャートである。 再利用依頼受付処理の流れを示すフローチャートである。 レビュー結果の登録処理の流れを示すフローチャートである。 成果物の埋め込み形式によるレビュー画面の一例を示す図である。 レビュー登録画面の一例を示す図である。 成果物の版間の差分を説明するための図である。 コメント引継ぎの流れを説明するための図である。 指摘を引き継いだレビュー画面の一例を示す図である。 指摘引継ぎ後のレビュー登録画面の一例を示す図である。 コメント再利用時のレビュー登録画面の一例を示す図である。

以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。

図1は、本発明の実施形態に係る成果物レビュー支援装置の構成例を示す概念図である。図１に示すように、成果物レビュー支援装置１００は、例えば通信網で接続されるサーバ機器１０とクライアント機器２０とから構成されている。サーバ機器１０は、成果物レビュー支援装置１００の中核をなすもので、検査部１１、登録部１２、レビュー支援部１３、データ格納部１４、表示データ作成・提示部１５から構成されている。これらの詳細については、後述する。サーバ機器１０は、図１に示すように、版管理システム３０に接続されている。版管理システム３０は、都度、更新され、成果物が名称と版番号で保管・管理されているレポジトリである。成果物、版等の詳細については、後述する。

クライアント機器２０は、ウェブブラウザが搭載され、一定の入力機能を果たす入力受付部２１を備える。クライアント機器２０としては、例えばパーソナルコンピュータが好適である。

本実施形態では、ソースコードの静的解析結果についてレビュー支援する成果物レビュー支援装置を例にとって説明する。

まず、発明の実施形態の説明に入る前に、主要な用語について説明する。

「検査」とは、成果物をあらかじめ定義された一連のルールに従ってチェックし、ルールに違反している箇所を列挙することをいう。ソースコードを静的解析する成果物レビュー支援装置では、一連のソースコードに対して解析ツールを適用し、解析する行為がこれに該当する。

「成果物」とは、検査の対象となるドキュメント全般を指す。ソースコードを静的解析する成果物レビュー支援装置では、静的解析にかけられる一連のソースコードを指す。

「版」とは、日時や改変時などの一定のタイミングで登録された一連の成果物中の成果物を特定する際に利用する識別子を指す。ソースコードを静的解析する成果物レビュー支援装置では、変更を加える度に追加登録した一連のソースコードに対し、日付や版番号を指定して取り出す特定のソースコードを指す。

「ルール」とは、あらかじめ定義された成果物を作成する際に守らなければならない決まりを指す。ソースコードを静的解析する成果物レビュー支援装置では、ソースコードを静的解析する際に利用する一連のチェック項目を指す。図４は、ルールテーブルの一例を示す図である。それぞれのルールにはＩＤが付され、ルールは、言わば表題と言えるTitleと、具体的な中身としてのContentから成っている。

「指摘」とは、ルールに従って対象ドキュメントを検査した結果、検出されたルール違反箇所を指す。指摘は、例えば、図５に示すような属性を持っている。各指摘は、個々の成果物を特定するためのProduct ＩＤ、版の情報であるRevision、ファイル名（File name）、どのルールに違反したかを特定するためのRule ID、ルールに違反した箇所の位置情報Locationを持っている。図６は、指摘テーブルの一例を示す図である。図６に示すように、指摘は必ずいずれか一つのルールに属している。ソースコードを静的解析する成果物レビュー支援装置では、指摘はソースコードを解析して出力した警告を指す。この警告は、警告が出た位置（ファイル名、行番号、列番号）と、どのルールに違反したかを示すルールIDを含んでいる。

「解析結果」とは、成果物を検査した結果であり、検査を通して検出された指摘の集合を指す。解析結果は、個々の成果物を特定するためのProduct ＩＤと版番号とでグルーピングされる。ソースコードを静的解析する成果物レビュー支援装置では、ソースコードを解析して得られた指摘の集合はリスト化された形式で表現され、成果物の版単位でグルーピングされる。図２は、指摘テーブルの一例を示す図である。

「レビュー」とは、検査の結果見つかった一連の指摘に対して、ルールに適合させるべく、コメントと修正例を付与する作業を指す。ソースコードを静的解析する成果物レビュー支援装置では、静的解析結果のレビュー依頼を受けたレビュアが一連の指摘に対して、コメントと修正例を付与する作業を指す。

「コメント」とは、各指摘に対してレビュアが付与するアドバイスを指す。修正内容に関する具体的な指示は含まず、通常は当該指摘が属するルールの解説に相当する。コメントは、ルールの識別子であるルールIDによってグルーピングされる。ソースコードを静的解析する成果物レビュー支援装置では、具体的な修正例であるソースコードを除いた文章の部分がコメントとして扱われる。図15にコメントと修正例の一例を示す。図１５に示す例では、ルールに違反したソースコードに対して、ファイル名、行番号、列番号、ルールID及び具体的なルール０８７７の内容が、「#if式に記述できるのは汎整数定数のみです。」と警告文の形で指摘されている。図１５において、「タイトルのとおりISO C規格に違反しており、危険です。下記の通り、修正してください。」が、コメントの一例である。「修正例」とは、レビューの際、各指摘に対してレビュアが付与する具体的な修正方法を指す。修正例は、ルールIDによってグルーピングされる。ソースコードを静的解析する成果物レビュー支援装置では、具体的な修正方法として記述されたソースコードそのものを指す。図１５において、「#define MAXVAL 10000 」が修正例の一例である。図１６は、ルール、指摘、コメント、修正例の関係を説明する図である。図１７は、静的解析結果の一例を示す図で、一つの成果物の特定の版を、図１中の検査部１１で解析した結果、出力される解析結果です。図１７に示す例では、成果物ＩＤ１−版番号１０３の解析結果である。解析結果は、最終的には、図１中の登録部１２を通してＤＢに格納され、図６に示す形で管理される。

「担当者」とは、検査対象である成果物の作成者であって、成果物を検査にかけるユーザを指す。ソースコードを静的解析する成果物レビュー支援装置では、一連のソースコードの作成者であって、ソースコードを解析にかけるユーザを指す。

「レビュア」とは、検査の結果見つかった一連の指摘をレビューし、指摘ごとにコメントと修正例を付与するユーザである。担当者とレビュアは兼任が可能である。ソースコードを静的解析する成果物レビュー支援装置では、静的解析の結果出力された一連の指摘に対して担当者から依頼を受けてコメントと修正例を記入するユーザを指す。

「引き継ぎ」とは、新たな成果物もしくは版を解析して得た解析結果中の各指摘に対して、既に登録済みの既存のコメント、修正例を引用するように設定することを指す。

「再利用」とは、引き継ぎが発生しなかった指摘に対して、レビュアが手動で引き継ぐコメント、修正例を設定することを指す。また、自動的な引継ぎで設定されたコメント、修正例が適切でない場合に、レビュアが、再利用を含む手動での編集を行って当該コメント、修正例を有用なものにすることがある。

「ルール別の解説」とは、ルールに関する一般的な解説であり、ルール別に記述される。ルールと当該ルールについての解説は、1対1に対応する。異なる指摘であっても同じルールに属している場合は、ルール別の解説の内容は同じになる。本実施形態において、ルール別の解説は、「引き継ぎ」と「再利用」の対象ではない。

「指摘別の解説」とは、解析の結果検出された各指摘と１対１で対応するコメントと修正例の組みを指す。例えば、ルール１００番に違反する指摘が解析結果全体で５０件検出されているとすると、最大５０件のコメント、修正例が登録されうる。本実施形態において、指摘別の解説は、「引き継ぎ」と「再利用」の対象である。

本実施形態にかかる成果物レビュー支援装置は、対象ドキュメントを検査し、同等箇所の特定を経て検査結果を格納する機能と、保存した検査結果に対するレビューの支援から、レビュー時の既存コメントと修正例の再利用、そしてレビューの実施結果であるコメントと修正例を登録する機能を実現するものである。次いで、成果物レビュー支援装置の具体的な構成例について詳述する。

まず、成果物レビュー支援装置において、受け取ったデータに何らかの処理を加える処理系の機能について説明する。

クライアント機器における「入力受付部」は、ユーザから検査の開始や検査結果の閲覧、コメント登録要求などを受け付け、サーバ機器の検査部と表示データ作成・提示部に一定の処理を依頼する。「入力受付部」は、ウェブブラウザから入力を受け付けるウェブアプリケーション形態のほか、ネットワークを介してユーザから入力を受け取り、データ格納部のデータに接続可能な個別のアプリケーションの形態でもあっても良い。

「版管理システム」は、成果物を版ごとに管理する機能を持つシステムである。「入力受付部」を介して成果物を受け取り、同じ成果物が既に登録されていれば版を更新し、新しい版として成果物を格納する。また、ユーザから成果物のIDあるいは名称と版の番号を受け取ると、該当する成果物が存在するか自らを検索し、該当する成果物をユーザに返すことができる。

「検査部」は、検査対象となる成果物の特定の版を入力として受け取り、あらかじめ定義された一連のルールに従ってこれを検査し、検査結果を指摘一覧として出力する。

「同等箇所特定部」は、検査した成果物の他の版に対して既に検査が実施され、その指摘一覧とレビュー結果がデータ格納部に蓄積されている場合に、検査結果である指摘一覧中の各指摘に対して、その指摘が既出であるかどうか、同等箇所の特定を行う。同等箇所の特定に際しては、「類似性計算部」で計算して得られた結果をもとに行う。判定の結果、その指摘は既出であると認められた場合には、その指摘に対して登録済みの「コメント」、「修正例」を検索し、それらを現在の版の解析結果に引き継がせる。

「類似性計算部」は、比較対象となる二つの指摘を受け取り、それらの指摘の類似性を計算する。類似性の計算は、例えば、各指摘の検出された版の間で差分を取り、両指摘の位置が十分に近ければ類似度が高いと判定する。また、指摘の検出されたソースコードの構造を解析し、構造がよく似ていれば類似性と高いと判定してもよい。

「登録部」は、検査部から出力された指摘一覧を入力として受け取り、指摘一覧中の各指摘に対して、「同等箇所特定部」を用いて前回の版で同等箇所が存在するかをチェックしたあと、その指摘をデータ格納部の所定のテーブルに格納するものである。同等箇所が存在する場合は、関連テーブルである「指摘_コメント」テーブルと「指摘_修正例」テーブルに、それぞれ「指摘とコメント」、「指摘と修正例」の関連情報を格納後、「指摘」テーブルに指摘を格納する。同等箇所が存在しない場合は、「指摘」テーブルにのみ指摘を格納する。

「表示データ作成・提示部」は、検査結果の表示要求を受け取った後、成果物のIDと版番号をキーとして検査結果を「指摘結果」テーブルから検索し、検索結果を所定の形式で表示するものである。表示形式には少なくとも成果物への埋め込み形式と、リスト表示形式とがある。「成果物埋め込み形式」は、検査の結果検出された各指摘を検査元成果物に埋め込む形で表示する形式である。図２５は、成果物の埋め込み形式によるレビュー画面の一例を示している。「リスト表示形式」は、検査の結果、検出された各指摘を、ある規則に則って列挙する形式である。この形式では、検査元成果物の情報は表示されず、指摘ごとにその指摘が検出された行と列番号が表示される。また、表示データ作成・提示部は表示した指摘ごとに「コメント」「修正例」を追加・編集するためのインターフェースを提供する。

「レビュー支援部」は、レビュー対象となる指摘のIDを「表示データ作成・提示部」から受け取り、その指摘に対して「コメント」、「修正例」を付与させ、データ格納部の「コメント」テーブル、「修正例」テーブルに格納するものである。また、「コメント」と「修正例」を付与する過程で、その指摘が属するルールをキーにしてこれまで付与された「コメント」及び「修正例」を検索し、再利用候補としてユーザに提示する。レビュー支援部のサブ機能として、「コメント再利用」及び「修正例再利用」がある。「コメント再利用」は、ユーザがコメントの編集中に再利用候補の取得を要求した際に、編集中の指摘が属するルールのIDを入力として受け取り、コメントリスト取得部を使って、そのルールIDに属するコメント一覧を取得、ユーザに提示するものである。「修正例再利用」は、ユーザが修正例の編集中に再利用候補の取得を要求した際に、編集中の指摘が属するルールのIDを入力として受け取り、修正例リスト取得部を使って、そのルールIDに属する修正例一覧を取得、ユーザに提示するものである。

「コメントリスト取得部」は、登録部のサブ機能であるコメント再利用の具体的な処理部である。レビュー対象となっている指摘が属するルールのIDを入力として受け取り、そのIDに対応するコメント一覧を「コメント」テーブルから取得、それらをレビュー支援部に再利用候補として出力する。

「修正例リスト取得部」は、登録部のサブ機能である修正例再利用の具体的な処理部である。レビュー対象となっている指定が属するルールIDを入力として受け取り、そのIDに対応する修正例のリストを「修正例」テーブルから取得、それらを登録部に再利用候補として出力する。

次に、成果物レビュー支援装置において、処理されたデータを格納、必要に応じて取り出すことを可能にするデータ管理系の機能について説明する。

「データ格納部」は、本実施形態において必要な情報である「ルール」、「指摘」、「コメント」、「修正例」、「指摘_コメント」、「指摘_修正例」を格納するもので、必要に応じていつでも取り出すことが可能となっている。通常はリレーショナルデータベースとして実現することができるが、版番号、ルールＩＤ、コメント、修正例の関係から必要に応じて引き出せるならば、データベースの種別は問わない。

ルールは、図３に示すような属性を持つ。全ての「指摘」、「コメント」、「修正例」はルールのIDを属性として持ち、このIDをキーとして対応する特定のルールを検索できる。全ての検査はルールに従ってチェックされ、ルールに違反した箇所が指摘として列挙される。図4に「ルール」テーブルの一例を示す。図４に示す例では、ルールの属性をTitleとContentsに分割しているが、特定のルールを一意に特定可能な構造であれば、属性の構成は問わない。

「指摘」は、過去に登録された全ての指摘を格納するデータ構造である。指摘は、図５に示すような属性を持つ。検査された成果物の各版の単位でグルーピングされており、成果物と版番号をキーとして与えると、その成果物の特定の版を検査して得られた全ての指摘を検索する。図６に「指摘」テーブルの一例を示し、複数の成果物−版の解析結果がDB中の一つのテーブル「指摘」の中で管理されている様子を示している。様々な成果物ID, 版番号が存在することが分かる。図６に示す例では、指摘の位置を一意に特定するために行番号と列番号を属性として与えているが、指摘の位置を一意に特定できるのであれば、属性の構成は問わない。

「コメント」は、過去に登録された全てのコメントを格納するデータ構造である。コメントは、図７に示すような属性を持つ。ルールIDごとにグルーピングされており、ルールIDをキーとして与えると、これまでにそのルールに対して登録された全てのコメントを検索できる。図８に「コメント」テーブルの一例を示す。contentのフィールドにはレビュアが指摘に対して記入したコメントが格納される。

「修正例」は、過去に登録された全ての修正例を格納するデータ構造である。修正例は、図９に示すような属性を持つ。ルールIDごとにグルーピングされており、ルールIDをキーとして与えると、これまでにそのルールに対して登録された全ての修正例を検索できる。図１０に「修正例」テーブルの一例を示す。本実施形態では、contentのフィールドにはレビュアが指摘に対して記入した修正例ソースコードの形で格納される。

尚、図３から図１０に示すデータ格納部の構成要素はIDという属性を持っているが、これはデータが一意に特定可能であることを説明するために付与した属性であり、必ずしも必要ではない。ここまでに説明した構成要素はIDが無い場合でもその他の属性を用いることで任意の行を一意に特定することができるならば、どのようなデータ構造であってもよい。

「関連付け」は、二つの異なるテーブルを互いに関連付けるための特別なデータ構造であり、二つのテーブルのうち一方のテーブルのレコードが指定されると、それに対応するもう一方のテーブルのレコードを特定することを可能にする。対応するレコードが複数件存在すれば、それら全てを特定する。

「指摘_コメント」は、関連付けの特性を持つデータ構造の一つである。図11に示すように、指摘のIDとコメントのIDの組として表現され、一方のIDを指定すれば、もう一方のIDが定まる。通常は、一つの指摘のIDに対して、0ないし1つのコメントのIDが定まり、一つのコメントのIDに対して1件以上の指摘のIDが定まる。図１２は、指摘テーブル、コメントテーブル、指摘_コメントテーブルの関連の一例を示している。

「指摘_修正例」は、関連付けの特性を持つデータ構造の一つである。図１３に示すように、指摘のIDと修正例のIDの組として表現され、一方のIDを指定すれば、もう一方のIDが定まる。通常は、一つの指摘のIDに対して、0ないし1つの修正例のIDが定まり、一つの修正例のIDに対して1件以上の指摘のIDが定まる。図１４は、指摘テーブル、修正例テーブル、指摘_修正例テーブルの関連の一例を示している。

尚、図１１乃至図１４に示すように、「指摘とコメント」、「指摘と修正例」の関連は必ずしも一致しない。これはレビュアがコメントを再利用、修正例は新規登録する場合や、その逆が起こりえるためである。

次に、以上のように構成した成果物レビュー支援装置のレビュー支援処理の流れについて説明する。ここでは、成果物としてソースコードを静的解析する場合のレビュー支援を取り上げる。静的解析の実行は検査部が担当し、データ格納部としてリレーショナルデータベースを採用し、データ格納部内のデータ構造はテーブル形式で管理する。図１８は、レビュー処理の全体の流れを示すフローチャートである。

（最初のレビュー完了まで）
まず、成果物レビュー支援装置が初回起動してから、最初のレビューを完了するまでの流れを説明する。初期状態では、データ格納部はあらかじめ登録済みの「ルール」テーブルを除き、全て空の状態である。

起動すると、静的解析が実行される（ステップＳ１８０１）。次いで、静的解析の結果が表示される（ステップＳ１８０２）。解析結果を受けて、検出された指摘についてレビューが実施される（ステップＳ１８０３）。レビューに際して、コメント・修正例の再利用が行われる（ステップＳ１８０４）。当該指摘に対するレビュー結果が登録される（ステップＳ１８０５）。尚、コメント・修正例の再利用ができない場合には、ステップＳ１８０３から直ちにステップＳ１８０５への流れとなる。指摘の総数がＮ個であれば、ステップＳ１８０３からステップＳ１８０５がＮ回繰り返される。

次に、解析処理の流れについて説明する。図１９は、解析の実行の流れを示すフローチャートである。

まず、担当者が静的解析の対象となる成果物の名称と版番号を指定し、検査部に対し入力受付部を介して解析を要求する。

検査部は入力受付部から、解析対象となる成果物の名称と版番号を受け取り（ステップＳ１９０１）、それらをキーとして版管理システムから静的解析の対象となる一連のソースコードを取得する（ステップＳ１９０２）。

その後、検査部は取得した一連のソースコードに対して静的解析を実行する（ステップＳ１９０３）。静的解析では、あらかじめ登録されたルールを使って違反している箇所が調べられ、違反の見つかったファイル名と違反している箇所の位置（行・列）情報、及び違反したルールのIDを属性として持つ指摘がリストされる。例えば、IDが１で識別される成果物の版番号１０３のソースコードに対して静的解析を実行した結果は、図１７に示すような形で出力される。

解析が終ると検査部は解析結果である指摘のリストを登録部に送信する（ステップＳ１９０４）。登録部では、静的解析結果を登録する（ステップＳ１９０５）。全ての登録が完了すると、解析終了を通知する（ステップＳ１９０６）。

次に、解析結果の登録について説明する。図２０は、解析結果の登録処理の流れを示すフローチャートである。

登録部は、与えられた指摘リスト中の各指摘に対して、同等箇所特定部を用いてその指摘に一致する指摘がデータベースに既に登録されていないかを確認する。

同等箇所特定部は、登録部から成果物のIDと版番号、ならびに指摘を入力として受け取る（ステップＳ２００１）。その後、成果物のIDと指摘の属するルールのIDをキーにして、同じルールに属する指摘が「指摘」テーブルに既に登録されていないかを「指摘」テーブルに対して問い合わせる（ステップＳ２００２）。この時点では「指摘」テーブルは空であるので既存指摘の検索に失敗する（ステップＳ２００３）。その結果、同等箇所特定機能は既存の指摘は登録されていないと判断し、登録部にその結果を通知する。登録部は、同等箇所特定機能から、同等箇所が無いことを通知された後、その指摘を「指摘」テーブルへと追加する（ステップＳ２０１４）。「指摘_コメント」テーブル、「指摘_修正例」テーブルへのレコード追加は行わない。登録部が検査部から受け取った全てのＮ個の指摘について、「指摘」テーブルへの追加を完了すると、検査部は解析の終了を担当者に通知する。

解析が終ると、レビュアは解析結果に対するレビューを実施することが可能となる。図２１は、解析結果の表示処理の流れを示すフローチャートである。

レビュアは、入力受付部を介して、表示データ作成・提示部に対し先に登録された解析結果の表示を、成果物の名称と版番号を指定して依頼する（ステップＳ２１０１）。

表示データ作成・提示部は、レビュアから受け取った成果物の名称と版番号をキーにして、「指摘」テーブルから解析結果である指摘のリストを取得する（ステップＳ２１０２）。その後、見つかった指摘リスト中の各指摘について、指摘の初期ステータスを「コメント未登録」「修正例未登録」に設定する。その後、その指摘に対して関連付けられたコメント、修正例が無いかを指摘のIDをキーにして「指摘_コメント」テーブル、「指摘_修正例」テーブルを使って検索する（ステップＳ２１０３）。いずれのテーブルもシステム起動後の初回レビューの際には空であり、その指摘に対して登録されているコメント、修正例は無い。よって表示される全ての指摘は「コメント未登録」「修正例未登録」ステータスとなる。図２５は、解析結果を成果物埋め込み形式で表示した一例である。レビュアは表示形式として少なくとも成果物埋め込み形式とリスト表示形式とを選択することができる（ステップＳ２１０４）。

レビュアは表示データ作成・提示部を通して解析結果を確認（ステップＳ２１０５）し、指摘ごとに付与されたレビュー機能へのリンクを選択してレビュー支援部を呼び出す。この際、表示データ作成・提示部は指摘のIDをレビュー支援部に渡して、解析結果の表示を完了する（ステップＳ２１１６）。

図２２は、レビュー実施の詳細な流れを示すフローチャートである。

レビュー支援部は、指摘IDの入力を受けて、レビュー画面表示依頼を受け付け（ステップＳ２２０１）、レビュアに対してコメント、修正例の登録フォームを表示する。この際、指摘のIDをキーとして登録済みのコメントと修正例の検索を試みる（ステップＳ２２０２、ステップＳ２２０５）が、この時点ではコメント、修正例は登録されておらず、全ての指摘は新規の指摘である。よってレビュー支援部は空のコメント、修正例登録フォームをレビュアに提示する（ステップＳ２２０８）。次いで、再利用の依頼を受け付け（ステップＳ２２０９）、再利用可能なコメント、修正例を検索する。しかし、この時点では、「コメント」テーブルは空であるので、コメント検索部はレビュー支援部に対し、空のリストを検索結果として渡す。同様に、この時点では、「修正例」テーブルは空であるので、修正例検索部はレビュー支援部に対し、空のリストを検索結果として渡す。レビュー支援部は、コメント検索部あるいは修正例検索部から検索結果を受け取ると、それを再利用候補としてレビュアに提示する。この時点では、検索結果は必ず空のリストとなるので、レビュー支援部は再利用可能なコメントあるいは修正例が無いことをレビュアに通知する。次いで、レビュー支援部は登録要求を受け取ると、コメント、修正例をデータ格納部に送信し、コメント及び修正例の登録処理（ステップＳ２２１０）となるが、システム起動後の初回レビューでは再利用可能なコメント・修正例がまだ登録されていないので、レビュアはコメント・修正例を一から手動入力する必要がある。

次に、再利用依頼の受付について説明する。図２３は、再利用依頼受付処理の流れを示すフローチャートである。

レビュアはコメントまたは修正例の編集中に、レビュー支援部のサブ機能である「コメント検索」、「修正例検索」を、編集中の指摘が属するルールに対して既に登録されているコメントまたは修正例がないかを検索できる。図２６は、レビュー登録画面の一例を示している。レビュアは、図２６中の「再利用」ボタンを押して呼び出し、編集中の指摘が属するルールに対して既に登録されているコメントまたは修正例がないかを検索できる。

まず、コメントの場合、再利用候補の検索要求を受け取る（ステップＳ２３０１）と、レビュー支援部はコメント検索部に対して、現在編集の対象となっている指摘の属するルールのIDを入力として与える（ステップＳ２３０２）。コメント検索部は、このルールIDをキーとして「コメント」テーブルを検索する（ステップＳ２３０３）。しかし、この時点では、「コメント」テーブルは空である（ステップＳ２３０４）ので、コメント検索部はレビュー支援部に対し、空のリストを検索結果として渡す。

同様に、修正例の場合、再利用候補の検索要求を受け取る（ステップＳ２３０１）と、レビュー支援部は修正例検索部に対して、現在編集の対象となっている指摘の属するルールのIDを入力として与える（ステップＳ２３０２）。修正例検索部は、このルールIDをキーとして「修正例」テーブルを検索する（ステップＳ２３０３）。しかし、この時点では、「修正例」テーブルは空である（ステップＳ２３０４）ので、修正例検索部はレビュー支援部に対し、空のリストを検索結果として渡す。

レビュー支援部は、コメント検索部あるいは修正例検索部から検索結果を受け取ると、それを再利用候補としてレビュアに提示する（ステップＳ２３０６）。この時点では、検索結果は必ず空のリストとなるので、レビュー支援部は再利用可能なコメントあるいは修正例が無いことをレビュアに通知する。

続いて、レビュー結果の登録について説明する。図２４は、レビュー結果の登録処理の流れを示すフローチャートである。

システム起動後の初回レビューでは、レビュアにとって再利用可能なデータが存在しないので、全て手動でコメントと修正例を記述する必要がある。仮に、コメント・修正例を入力しないまま、登録要求を送る場合は、図２４に示すとおり、データ格納部には何の変化も起こらない。

（複数回のレビュー実行後の流れ）
続いて、上に示したソースコードの静的解析とレビューが複数回行われ、各ルールに対してコメント、修正例が十分に蓄積された後の静的解析とレビューの流れについて説明する。ある一連のソースコードに対して少なくとも一度解析とレビューが行われ、その結果を受けて更新された新しい版を解析にかける場合には、下記に示す処理の流れとなる。

まず、担当者は静的解析の対象となる成果物の名称と版番号を指定し、検査部に対し、入力受付部を介して解析を要求する。解析の実行の流れは、図１９に示すように、検査部は入力受付部から、解析対象となる成果物の名称と版番号を受け取り（ステップＳ１９０１）、それらをキーとして版管理システムから静的解析の対象となる一連のソースコードを取得する（ステップＳ１９０２）。

その後、検査部は取得した一連のソースコードに対して静的解析を実行する（ステップＳ１９０３）。解析が終ると検査部は解析結果である指摘のリストを登録部に送信する（ステップＳ１９０４）。送信された指摘のリストを登録部が受け取り、解析結果として登録する（ステップＳ１９０５）。全ての登録が完了すると、解析終了を通知する（ステップＳ１９０６）。

解析が終ると検査部は解析結果である指摘リストを登録部に送信する。登録部は、与えられた指摘リスト中の各指摘に対して、同等箇所特定機能を用いてその指摘がこれまでの解析で検出されていないかを確認する。

次に、解析結果の登録について説明する。解析結果の登録処理は、図２０に示すように、登録部は、与えられた指摘リスト中の各指摘に対して、同等箇所特定部を用いてその指摘に一致する指摘がデータベースに既に登録されていないかを確認する。

同等箇所特定部は、登録部から成果物のIDと版番号、ならびに指摘を入力として受け取る（ステップＳ２００１）。その後、成果物のIDと指摘の属するルールのIDをキーにして、同じルールに属する指摘が「指摘」テーブルに既に登録されていないかを「指摘」テーブルに対して問い合わせる（ステップＳ２００２）。問い合わせの結果、「指摘」テーブルから1件以上の既存指摘を受け取った場合は、「既存指摘の有無」でYesが選択される（ステップＳ２００３）。次いで、既存指摘リストを既存指摘に入力する（ステップＳ２００４）。

同等箇所特定部は、受け取った各既存指摘が検出された版を「版管理システム」から取り出し（ステップＳ２００５）、類似性計算部を用いて現在処理中の指摘の箇所と既存指摘の箇所の類似性を計算する（ステップＳ２００６）。類似性の計算には「版管理システム」が提供するソースコード間の差分機能の他、指摘箇所のソースコードの構造を比較する方法など様々な手法が考えられるが、類似性を判定可能な方法であれば、方法の種類は問わない。類似性の高いコメント、修正例が複数検出された場合に、最も類似性の高いコメント、修正例を引き継ぐことが好適である。図２７は、成果物の版間の差分を説明するものであり、ここでは、行・列番号は異なるが、ソースコードの類似性から同等であると判断される一例を示している。

類似性計算部により、現在処理中の指摘と既存指定が同等であるとみなされた場合（ステップＳ２００７）、同等箇所特定部は、既存指摘のIDをキーにして、既存指摘に対して既に登録されているコメントが無いかを検索する（ステップＳ２００８）。検索の結果、コメントが見つかった場合（ステップＳ２００９）、同等箇所特定部は、コメントのIDと現在処理中の指摘のIDの組を「指摘_コメント」テーブルに登録する（ステップＳ２０１０）。同様に、同等箇所特定部は、既存指摘のIDをキーにして、既存指摘に対して既に登録されている修正例が無いかを検索する（ステップＳ２０１１）。検索の結果、修正例が見つかった場合（ステップＳ２０１２）、同等箇所特定部は、修正例のIDと現在処理中の指摘のIDの組を「指摘_修正例」テーブルに登録する（ステップＳ２０１３）。

図２８は、コメント引継ぎの流れを説明するための図である。図２８に示す例では、新規指摘ID=５００と既存指摘ID=３が同等であるとみなされ、既存指摘 ID =３に対して登録されていたコメントID=２５０１が新規指摘 ID=５００に対して引き継がれる流れを示している。図２８に示すとおり、新規指摘と既存のコメントのIDの組（５００、２５０１）が「指摘_コメント」テーブルに新規登録される。

登録部が検査部から受け取った全ての指摘について「指摘」テーブルへ追加し、同等箇所の特定及び指摘の登録を完了（ステップＳ２０１４）すると、検査部は解析終了を担当者に通知する。解析が終るとレビュアは解析結果に対するレビューを実施することが可能になる。

解析結果の表示の流れは、図２１に示す。レビュアは、入力受付部を介して、表示データ作成・提示部に対し先に登録された解析結果の表示を、成果物の名称と版番号を指定して依頼する（ステップＳ２１０１）。

表示データ作成・提示部は、入力受付部から受け取った成果物のIDと版番号をキーにして、「指摘」テーブルから解析結果である指摘リストを検索する（ステップＳ２１０２）。その結果見つかった指摘リスト中の各指摘に対して、表示データ作成・提示部は指摘の初期ステータスを「コメント未登録」「修正例未登録」に設定する。その後、その指摘に対して既に登録されたコメント・修正例が無いかを「指摘_コメント」テーブル、「指摘_修正例」テーブルを使って検索する（ステップＳ２１０３）。図２５は、解析結果を成果物埋め込み形式で表示した一例である。レビュアは表示形式として少なくとも成果物埋め込み形式とリスト表示形式とを選択することができる（ステップＳ２１０４）。レビュアは表示データ作成・提示部を通して解析結果を確認（ステップＳ２１０５）し、指摘ごとに付与されたレビュー機能へのリンクを選択してレビュー支援部を呼び出す。

ここで、表示データ作成・提示部における表示処理について詳述する。指摘リストを指摘に入力する（ステップＳ２１０６）。表示データ作成・提示部は指摘の初期ステータスを「コメント未登録」に設定する（ステップＳ２１０７）。同様に、「修正例未登録」に設定する（ステップＳ２１０８）。解析結果の登録時に同等箇所が特定され、コメントが引き継がれた指摘については、指摘ＩＤをキーにして対応する登録済みコメントを検索する（ステップＳ２１０９）。コメント有り（ステップＳ２１１０）の場合には、その指摘のステータスを、「コメント登録済み(未編集）」に設定してレビュアに提示する（ステップＳ２１１１）。同様に解析結果の登録時に同等箇所が特定され、修正例が引き継がれた指摘については、指摘ＩＤをキーにして登録済み修正例を検索する（ステップＳ２１１２）。修正例有り（ステップＳ２１１３）の場合には、その指摘のステータスを、「修正例登録済み(未編集)」に設定してレビュアに提示する（ステップＳ２１１４）。例えば、図２９において、新規の指摘と引継ぎが行われた指摘は色分けなどで区別される。また、図３０は、指摘引継ぎ後のレビュー登録画面の一例を示す図である。

レビュアは表示データ作成・提示部を通して解析結果を確認し、指摘ごとに付与されたレビュー機能へのリンクを選択してレビュー支援部を呼び出す。この際、表示データ作成・提示部はコメント、修正例の登録対象である指摘のIDをレビュー支援部に渡す（ステップＳ２１１５）。

次いで、レビュー実施の流れを説明する。図２２に示すように、レビュー支援部は、指摘IDの入力を受けて、レビュー画面表示依頼を受け付け（ステップＳ２２０１）、レビュアに対してコメント、修正例の登録フォームを表示する。この際、指摘のIDをキーとして登録済みのコメントを検索する（ステップＳ２２０２）。コメントが有る場合には（ステップＳ２２０３）、コメントの入力フォームに既存コメントを設定する（ステップＳ２２０４）。同様に、指摘のIDをキーとして登録済みの修正例を検索する（ステップＳ２２０５）。修正例が有る場合には（ステップＳ２２０６）、修正例の入力フォームに既存修正例を設定する（ステップＳ２２０７）。レビュー支援部はコメント登録フォーム、修正例登録フォームをレビュアに提示する（ステップＳ２２０８）。次いで、登録画面の表示（ステップＳ２２０９）後、レビュアが再利用を依頼した場合に限り、再利用候補の検索と提示を行う。再利用の依頼がない場合は、コメント・修正例の登録処理（ステップＳ２２１０）となる。

また、レビュアはコメント、修正例の編集中に、レビュー支援部のサブ機能である「コメント検索」「修正例検索」を呼び出して、編集中の指摘が属するルールに対して既に登録されているコメント、修正例がないかを検索することができる。図２３に再利用依頼受付の流れを示す。

コメントの場合、再利用候補の検索要求を受け取ると、レビュー支援部はコメント検索部に対して、現在編集の対象となっている指摘の属するルールのIDを入力として与える。コメント検索部は、このルールIDをキーとして「コメント」テーブルを検索し、見つかった一連のコメントをレビュー支援部に検索結果として渡す。

修正例の場合、再利用候補の検索要求を受け取ると、レビュー支援部は修正例検索部に対して、現在編集の対象となっている指摘の属するルールのIDを入力として与える。修正例検索部は、このルールIDをキーとして「修正例」テーブルを検索し、見つかった一連の修正例をレビュー支援部に検索結果として渡す。

レビュー支援部は、コメント検索部あるいは修正例検索部から検索結果を受け取ると、それを再利用候補としてレビュアに提示する。レビュアは提示されたコメント、修正例の再利用候補の中から望ましいものを選択し、登録画面中のコメントの入力フォームまたは修正例の入力フォームの内容を置き換えることができる。図３１にコメントの再利用候補検索結果の一例を示す。尚、修正例の場合も同様である。

尚、ルールが実質的に同等のものであって、ルールに対応する複数種類のコメントおよび修正例が存在するとき、それらコメントおよび修正例は重み付けがされ、重み付けされた順序で表示データ作成・提示部に表示することが好適である。例えば、重み付けは、同等指摘結果に対する参照回数によって付与することができる。

レビュアはコメント、修正例を記入後に、レビュー支援部に対して登録を要求する。コメント、修正例の登録の流れを図２４に示す。

この時、レビュー支援部は登録されようとしているコメント、修正例が再利用されたものである場合には「コメント」テーブル、「修正例」テーブルへの新規レコード登録は行わず、代わりに「指摘_コメント」テーブル、「指摘_修正例」テーブルに指摘IDとコメントID、指摘IDと修正例IDの組を追加する。その後、コメント、修正例に対して個別に、登録された場合はステータスを「コメント登録済み」あるいは「修正例登録済み」に設定する。

新規のコメント・修正例に関しては、「コメント」テーブルと「修正例」テーブルにレコードを追加した上で、指摘IDとコメントID、指摘IDと修正例IDの組を、それぞれ「指摘_コメント」テーブル、「指摘_修正例」テーブルに追加する。その後、コメント、修正例に対して個別に、登録された場合はステータスを「コメント登録済み」あるいは「修正例登録済み」に設定する。

尚、既に登録済みのコメント、修正例を更新しようとしている場合は、既存の「コメント」テーブルのレコードと「修正例」テーブルのレコードを更新する。指摘のステータスは「コメント登録済み」「修正例登録済み」のまま変化しない。

レビュアはこのようなコメント、修正例の登録を、解析して検出された各指摘に対して実施する。このレビューの結果は後ほど担当者に通知され、担当者は表示データ作成・提示部を通して登録されたコメント・修正例を参照することができる。

本実施形態によれば、成果物に修正に際して、指摘に対応した具体的な指示を受けることができる。また、コメントと修正例を個別に管理しているので、冗長な情報のリストアップを未然に防止することができる。さらに、コメント、修正例の引き継ぎが自動化されるので、版を更新するごとにリセットされていた指摘とコメント、修正例の対応関係を自動的に構築でき、レビューにかかる負担が軽減される。加えて、引き継ぎ・再利用の際に、成果物や成果物の版を越えたコメント、修正例の引き継ぎ及び再利用が可能で、冗長性の高いコメントや修正例が蓄積されるのを防止することが可能となる。再利用の仕組みは自動的な引き継ぎ結果が正しくない場合に、手動での引き継ぎ対象の再選択という機能をレビュアに提供する。この仕組みは類似性の判定による自動的な引き継ぎが行なわれたが、その引き継ぎ結果は必ずしも正しくない場合に非常に有効であり、実際このような自動引継ぎ結果のミスマッチングは非常に頻繁に発生しうる。

なお、本発明は上記の実施形態のそのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記の実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１００…成果物レビュー支援装置、１０…サーバ機器、１１…検査部、１２…登録部、１３…レビュー支援部、１４…データ格納部、１５…表示データ作成・提示部、２０…クライアント機器、２１…入力受付部、３０…版管理システム。

Claims (11)

1. 成果物の変更の履歴を版として保存し、指定された版の成果物を取り出す版管理手段と、成果物を作成する際に遵守すべきルールに基づいて成果物を検査し、ルール違反を指摘として摘示する検査手段と、
   前記ルール、前記検査手段によって摘示された指摘、前記指摘に対応して前記ルールを解説したコメント及び前記指摘に対応するとともに前記ルールに沿った成果物の修正例を、前記ルール別かつ前記成果物の版別に検索可能に格納するデータ格納手段と、
   前記指摘を前記データ格納手段から取り出して表示する表示手段と、
   前記取り出した指摘に対応する前記コメント、前記修正例を編集する編集手段と、
   前記データ格納手段に格納されている指摘を利用して、新たな指摘が既に以前の版で指摘済みであるか判断する同等箇所特定手段と、
   前記指摘どうしの類似性を判定する類似性計算手段と、
   ユーザから前記検査の開始、前記検査結果の閲覧、前記コメントの登録要求を受け付ける入力手段とを備え、
   新たな成果物あるいは版を解析して得られた前記指摘に対して、前記類似性計算手段で類似性が認められた場合に、既に登録済みの前記コメント、前記修正例を引き継いで、前記表示手段に表示することを特徴とする成果物レビュー支援装置。
2. 前記コメント、前記修正例は、別々に管理して前記データ格納手段に格納されることを特徴とする請求項１記載の成果物レビュー支援装置。
3. 前記類似性の高いコメント、修正例が複数検出された場合に、最も類似性の高い前記コメント、修正例を引き継ぐことを特徴とする請求項１または請求項２記載の成果物レビュー支援装置。
4. 前記類似性は、前記指摘の検出された版の間で差分を取り、前記指摘どうしの位置が近似しているかによって類似度が高いと判定することを特徴とする請求項１乃至請求項３のいずれか１項に記載の成果物レビュー支援装置。
5. 前記類似性は、前記指摘の検出された成果物の構造を解析し、構造が近似しているかによって類似度が高いと判定することを特徴とする請求項１乃至請求項３のいずれか１項に記載の成果物レビュー支援装置。
6. 引き継いだ前記コメント、前記修正例は、ユーザが編集可能であることを特徴とする請求項１乃至請求項５のいずれか１項に記載の成果物レビュー支援装置。
7. 前記指摘が、引き継ぎができなかったもの、あるいは新たな成果物の指摘である場合、前記ルール別に蓄積された前記コメント、前記修正例から、再利用候補として提示することを特徴とする請求項１記載の成果物レビュー支援装置。
8. 再利用候補の前記コメント、前記修正例は、ユーザが編集可能であることを特徴とする請求項７に記載の成果物レビュー支援装置。
9. 前記ルールが実質的に同等のものであって、前記ルールに対応する複数種類の前記コメントおよび前記修正例が存在するとき、それら前記コメントおよび前記修正例は重み付けがされ、重み付けされた順序で前記表示手段に表示することを特徴とする請求項１乃至請求項８のいずれか１項に記載の成果物レビュー支援装置。
10. 前記重み付けが、同等指摘結果に対する参照回数によって付与されることを特徴する請求項９記載の成果物レビュー支援装置。
11. 前記コメント、前記修正例は、前記ルールの識別子によってグループ化されていることを特徴とする請求項１乃至請求項１０のいずれか１項に記載の成果物レビュー支援装置。

Images