(57)【要約】      （修正有）【課題】ソースコード中に含まれるエラー箇所について、管理者等による修正不要の判断がされた場合に、再度のインスペクション処理においてエラー箇所として検出することを防止するソースコードインスペクションシステムを提供する。【解決手段】ソースコードインスペクションシステムは、インスペクション装置７００と、適用除外申請装置によりソースコードがコピーされたインスペクション用データベース１０５と、インスペクションルール適用除外データベース１０４とを備える。インスペクション装置７００は、予め定義されたルール情報７０１及びインスペクションルール適用除外データベース１０４内の適用除外登録情報とを参照し、ソースコードインスペクション用データベース１０５に登録されているソースコードについてインスペクション処理を行い、検査結果情報７０２，除外対象結果情報７０３，不正除外結果情報７０４の各情報を出力する。【選択図】図７
2006092475.tif 000002
【特許請求の範囲】
【請求項１】
予め定義されたインスペクションルール情報に基づき、インスペクション処理対象となるソースコードについてインスペクション処理を行い、前記インスペクションルール情報に違反するエラー箇所を検出し、検出したエラー箇所を検査結果として出力するインスペクション手段を備えたソースコードインスペクションシステムにおいて、
前記ソースコード中に含まれる任意のエラー箇所を、前記インスペクション手段による検査結果出力の対象から除外するための情報として、ソースコード識別情報と、エラー箇所識別情報と、違反ルール識別情報とを含む検出除外情報を登録する検出除外情報登録手段を備えることを特徴とするソースコードインスペクションシステム。
【請求項２】
前記ソースコードインスペクションシステムは、
前記ソースコードの作成者による前記検出除外情報の登録申請を受付け、管理者による登録許可の指定に基づき、前記検出除外登録手段に対する登録指示を行う検出除外申請手段を備えることを特徴とする請求項１に記載のソースコードインスペクションシステム。
【請求項３】
前記検出除外登録手段は、
前記検出除外対象識別情報として、ソースコード中における検出除外箇所を一意に識別するキーを生成し、前記ソースコード中の検出除外箇所に対応する位置に前記キーを埋め込む手段を備えることを特徴とする請求項１又は２のいずれかに記載のソースコードインスペクションシステム。
【請求項４】
前記インスペクション手段は、
前記検出除外登録情報を参照し、前記ソースコード中に埋め込まれたキーと、前記検出除外登録情報に含まれるキーとの一致又は不一致を判定し、不一致の場合に不正除外情報として出力する手段を備えることを特徴とする請求項１〜３のいずれかに記載のソースコードインスペクションシステム。
【請求項５】
前記インスペクション手段は、
前記検出除外登録情報を参照し、前記エラー箇所識別情報に示すエラー箇所に前記キーが埋め込まれているか否かを判定し、前キーが埋め込まれていない場合に、不正除外情報として出力する手段を備えることを特徴とする請求項１〜４のいずれかに記載のソースコードインスペクションシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウエア開発作業におけるインスペクション処理を行うソースコードインスペクションシステムに関し、特に、設計上の理由から修正不要とされるエラー箇所について、インスペクションルールの適用除外の設定を可能とする構成に関する。
【背景技術】
【０００２】
一般に、ソフトウェア開発プロジェクトでは、開発対象となるシステムを構成するソースコードに対し、予めコーディング規準が設定されており、各開発者はこれに従いコーディングを行う。
この場合、ソフトウエア開発者は机上デバッグ時にソースコードの内容を１ステップずつ追いかける目視確認によりコーディング規準が遵守されているかを確認していた。このようなデバッグ時の目視確認では、ソースコードの内容の論理を追いかけながらの確認となってしまうため、細かなルール違反の見落としが発生し、実際にプログラムを動かしながらのマシンテスト時に動作不正の発生により現象化して見つかることが多いという問題があった。
このため、ソースコードを機械的に解析し、コーディング規準に基づき定義されたルール情報により、ソースコードのコーディングミス等、ルール情報に違反するエラー箇所を検出するインスペクション装置が用いられている。
【０００３】
図１３は、従来のインスペクション装置の概略構成を示すブロック図であり、図１４は従来のインスペクション装置によるインスペクション処理を含む作業工程の概要を示すフローチャートである。
図１３に示すように、従来の構成では、インスペクション装置１３００と、開発者１３１０により作成されたソースコードを登録するソースコード管理データベース１３０１と、予め定義されたルール情報１３０２とを備え、管理者１３２０の指示に応じてインスペクション処理を行った検査結果１３０３を開発者１３１０に提供する。
図１４に示すように、インスペクション装置１３００は、管理者１３２０の指示に応じて、ソースコード管理データベース１３０１からソースコードを取得する（ステップ１４０１）。ソースコードの取得は、日の終わり，週の終わり，工程区切り等のタイミングで定期的に行うこととなる。
インスペクション装置１３００は、ルール情報１３０２を参照して、取得したソースコードについてのインスペクション処理を行い、ルール情報１３０２に違反するエラー箇所を示す検査結果１３０３を出力して、当該検査結果１３０３を開発者１３１０に送信する（ステップ１４０２〜１４０４）。
開発者１３１０は検査結果１３０３を参照し、検査結果１３０３により指摘されたエラー箇所を修正するため再度ソースコードの編集を行い、編集後のソースコードをソースコード管理データベース１３０１に登録する。インスペクション装置１３００は、編集後のソースコードについて再度インスペクション処理を行う。
以上のように、開発者１３１０により編集されたソースコードについて、検査結果１３０３のエラー箇所が全て修正され、エラーが検出されなくなるまで、インスペクション処理を繰返す（ステップ１４０５）。
【０００４】
以上のようなインスペクション作業においては、原則として、予め定義されたルール情報１３０２に違反するものは全て修正することとなるが、エラー箇所として検出されたソースコードの中には、設計上の理由から開発者が意図的に埋め込んだルール違反もある。
例えば、Ｊａｖａ言語（「Ｊａｖａ」は、サン・マイクロシステムズ社の登録商標）において、ｔｒｙ節に対するｃａｔｃｈ内での例外処理の実装がされていない時、ルール違反を検出する、という場合を考える。Ｊａｖａ言語では、構文上、ｔｒｙ節で括らなければコンパイルが通らないものがある。他のクラスで例外処理を実装している場合等、ｔｒｙ節に対するｃａｔｃｈ内に例外処理を実装する必要のない場合もある。この場合、インスペクション処理の結果、エラー箇所として検出されるが、実際はその部分を修正する必要はないこととなる。
従って、管理者１３２０は、インスペクション装置１３００による検査結果１３０３をチェックし、設計上、修正が必要なエラー箇所かを判定する必要があり、この判定作業に多大な工数が掛かっていた。特に、管理者１３２０により修正不要と判定された場合であっても、インスペクション装置１３００によるインスペクション処理では、再度エラー情報として検出されてしまうため、同様の判定作業をインスペクション処理毎に行うことが必要となっていた。
その一方で、修正が必要か否かは、ソースコード中の前後の記述の仕方等により異なるため、一般的なルール情報として定義をすることが困難であった。
【０００５】
このようなインスペクション装置１３００による処理の問題点を解決するために、従来のインスペクション装置１３００として、前回インスペクション処理を行った旧ソースコードと修正後のソースコードとを比較して、変更のあった箇所のみを抽出してチェックを行う構成が公知となっている（例えば、特許文献１参照。）。即ち、エラー箇所として検出された部分については、ソースコードの修正がされていなければ、次回のインスペクション処理ではエラー箇所として検出がされないこととなる。
【特許文献１】特開２００２−３４２１２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、前記特許文献１に記載の構成では、開発者１３１０による修正の有無で、インスペクション装置１３００がチェックを行うか否かが決まるため、本当にインスペクション処理をする必要が無いのかが判断できず、開発者１３１０任せとなってしまうという問題があった。
従って、本来修正すべきエラー箇所についてインスペクション処理がされずに残る可能性があるため、結局は管理者１３２０によるチェックが必要となり、管理者１３２０の負担軽減を図ることができなかった。
【０００７】
本発明は前記課題を解決するためのものであり、インスペクション装置によるインスペクション処理で検出されたエラー箇所について、管理者等による修正不要の判断がされた場合に、再度のインスペクション処理においてエラー箇所として検出することを防止して、管理者の作業負担の軽減を可能とするソースコードインスペクションシステムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するため本発明は、予め定義されたインスペクションルール情報に基づき、インスペクション処理対象となるソースコードについてインスペクション処理を行い、前記インスペクションルール情報に違反するエラー箇所を検出し、検出したエラー箇所を検査結果として出力するインスペクション手段を備えたソースコードインスペクションシステムにおいて、前記ソースコード中に含まれる任意のエラー箇所を、前記インスペクション手段による検査結果出力の対象から除外するための情報として、ソースコード識別情報と、エラー箇所識別情報と、違反ルール識別情報とを含む検出除外情報を登録する検出除外情報登録手段を備えることを特徴とする。
また、前記ソースコードインスペクションシステムは、前記ソースコードの作成者による前記検出除外情報の登録申請を受付け、管理者による登録許可の指定に基づき、前記検出除外登録手段に対する登録指示を行う検出除外申請手段を備えることを特徴とする。
また、前記検出除外登録手段は、前記検出除外対象識別情報として、ソースコード中における検出除外箇所を一意に識別するキーを生成し、前記ソースコード中の検出除外箇所に対応する位置に前記キーを埋め込む手段を備えることを特徴とする。
また、前記インスペクション手段は、前記検出除外登録情報を参照し、前記ソースコード中に埋め込まれたキーと、前記検出除外登録情報に含まれるキーとの一致又は不一致を判定し、不一致の場合に不正除外情報として出力する手段を備えることを特徴とする。
また、前記インスペクション手段は、前記検出除外登録情報を参照し、前記エラー箇所識別情報に示すエラー箇所に前記キーが埋め込まれているか否かを判定し、前キーが埋め込まれていない場合に、不正除外情報として出力する手段を備えることを特徴とする。
【発明の効果】
【０００９】
以上の構成により、本発明によれば、設計上の理由等により管理者により修正不要と判断されたエラー箇所について、インスペクション手段の検査結果出力対象から除外されるため、インスペクション処理の度にエラー箇所として検出されることを防止することができ、管理者の確認作業工数を大幅に削減することが可能となる。
また、開発者の申請を受付け、管理者の判断に基づき適用除外登録情報として登録することとしたので、管理者は開発者から申請されたエラー箇所についてのみ修正の要否を判断すればよいため、インスペクション処理の結果として検出されたエラー箇所の全てについて修正の要否を判断する必要が無くなり、管理者の作業工数を大幅に削減することが可能となる。
また、検出除外箇所に対しキーを埋め込むこととしたので、インスペクション手段によるインスペクション処理では、キーの有無により容易に検出除外とするか否かを判定することが可能となる。
また、ソースコード中に埋め込まれたキーと検出除外登録情報に含まれるキーとが一致しない場合、または、検出除外登録情報に示されるキーがソースコード中に埋め込まれていない場合に、不正除外情報を出力することとしたので、管理者は不正なキー等を容易に判断することが可能となる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の一実施の形態に係るソースコードインスペクションシステムについて、図面に基づき説明する。
図１は、本発明の一実施の形態に係るソースコードインスペクションシステムの概略構成を示すブロック図である。
本実施の形態に係るソースコードインスペクションシステムは、適用除外申請装置１０１と、適用除外登録装置１０２と、適用除申請データベース１０３と適用除外登録データベース１０４と、インスペクション用データベース１０５とから構成される。
適用除外申請装置１０１は、ソースコード中の任意のエラー箇所について開発者１２０による適用除外申請を受付け、管理者１３０による承認又は却下の判定結果を返す。判定結果が承認の場合には、適用除外承認情報を適用除外登録装置１０２に送信する。また、ソースコード管理データベース１１０内のソースコードをインスペクション用データベース１０５にコピーする。
適用除外登録装置１０２は、受信した適用除外承認情報について一意な承認キーを生成して、適用除外承認情報とともに適用除外登録データベース１０４に登録する。
【００１１】
図２は、適用除外申請データベース１０３のデータ構造の一例を示す図である。
適用除外申請データベース１０３は、開発者により申請内容を示す情報等として、ソースコードを識別するソース名２０１，適用除外を申請した開発者を示すユーザ名２０２，適用除外するインスペクションルールを識別するルール名２０３，ソースコードの適用除外箇所を示す行番号２０４，適用除外申請の理由を示すメッセージ２０５，申請情報の修正の有無を示す修正フラグ２０６，申請情報について修正がされた場合の修正内容２０７，管理者による判定結果を示すステータス２０８の各情報を有する。
ルール名２０２により識別されるインスペクションルールとは、例えばＪａｖａ言語の場合、ｉｆ節の中で代入が行われている、初期化していないフィールドがある、といった内容のものが該当し、後述するルール情報に定義されたルール名が使用される。
例えば、レコード２１０では、開発者「Ｓｈｕｄｏ」により作成されたソースコード「Ｓａｍｐｌｅ．ｊａｖａ」の２０行目において、ルール名「Ｘ０００１」のルール情報に違反するエラー箇所について、「例外処理は上位クラスで実装済みのため対象外とします。」という理由により適用除外申請が行われている。
また、本実施の形態では、適用除外申請情報の修正の受付けを可能とし、修正を受付けた場合には、登録されているレコードの修正フラグ２０６を「−」から「Ｔｒｕｅ」に変更し、変更後の行番号を修正内容２０７に挿入し、承認・却下されているステータス２０８を「―」に更新することで、再度、管理者による承認・却下の判定を行わせる。
【００１２】
図３は、適用除外登録データベース１０４のデータ構造の一例を示す図である。
適用除外登録データベース１０４は、適用除外登録情報を一意に識別するための承認キー３０１と、適用除外申請装置から受信した承認情報に対応するソース名３０２，ユーザ名３０３，ルール名３０４，行番号３０５，メッセージ３０６の各情報を有する。
例えば、図２に示すレコード２１０の適用除外申請情報に対応して、レコード３１０では、「ａＢ９４Ｓｇｒｌａｓ」という承認キーを付加した適用除外登録情報が登録されている。
【００１３】
図４は、適用除外申請装置１０１の行う処理を示すフローチャートである。
適用除外申請装置１０１は、開発者による適用除外申請を、プロジェクト単位で定められた所定期間経過まで受付け、受付けた全ての適用除外申請情報を適用除外申請データベース１０３に登録する（ステップ４０１，４０２）。
次に、管理者１３０の操作に応じて、適用除外申請データベース１０３からステータス２０８の登録されていない適用除外申請情報を取得して表示する（ステップ４０３）。
管理者１３０による承認，却下のいずれかの判定結果の入力を受付け、判定結果を適用除外申請データベース１０３のステータス２０８に登録する（ステップ４０４）。
適用除外申請に対する承認・却下の判定結果（ステータス２０８）を開発者用端末等に送信するとともに、適用除外承認情報を適用除外登録装置１０２に送信する（ステップ４０５）。
さらに、適用除外申請装置１０１は、ソースコード管理データベース１１０内のソースコードをインスペクション用データベース１０５にコピーする（ステップ４０６）。
【００１４】
図５は、適用除外申請装置１０１から適用除外承認情報を受信した適用除外登録装置１０２の行う処理を示すフローチャートである。
適用除外登録装置１０２は、適用除外申請装置１０１から受信した適用除外承認情報に対して一意となる承認キーを生成し(ステップ５０１)、適用除外承認情報に基づく各情報とともに適用除外登録データベース１０４に登録する（ステップ５０２）。
さらに、インスペクション用データベース１０５にコピーされたソースコードの該当箇所に、前記承認キーを埋め込む（ステップ５０３）。この場合、承認キーを埋め込む該当箇所は、適用除外登録情報に含まれる行番号３０５により判断する。
【００１５】
図６は、適用除外登録装置１０２により生成された承認キーを埋め込んだソースコードの一例を示す図である。
図６に示すように、適用除外承認情報を受信した適用除外登録装置１０２は、インスペクション用データベース１０５にコピーされたソースコード６００の該当箇所に承認キー６０１を埋め込む。
本例では、適用除外登録装置１０２の生成した承認キー「ａＢ９４Ｓｇｌａｓ」をソースコード「Ｓａｍｐｌｅ．ｊａｖａ」の２０行目に埋め込んでいる。
【００１６】
以上のように、適用除外申請が承認され、承認キーが埋め込まれたソースコードについてのインスペクション処理について説明する。
図７は、本実施の形態に係るインスペクション装置の概略構成を示すブロック図である。
本実施の形態では、インスペクション装置７００と、適用除外申請装置１０１によりソースコードがコピーされたインスペクション用データベース１０５と、インスペクションルール適用除外データベース１０４とを備える。
インスペクション装置７００は、予め定義されたルール情報７０１及びインスペクションルール適用除外データベース１０４内の適用除外登録情報とを参照し、ソースコードインスペクション用データベース１０５に登録されているソースコードについてインスペクション処理を行い、検査結果情報７０２，除外対象結果情報７０３，不正除外結果情報７０４の各情報を出力する。
ここで、除外対象結果情報７０３は、適用除外登録情報に基づき適用除外された結果を示し、不正除外結果情報７０４は、不正な承認キーの検出又は適用除外登録情報とソースコードとの不一致を示す。
不正な承認キーの検出としては、例えば、同一の承認キーが複数個含まれている場合や、適用除外登録データベース１０４に登録されていない承認キーが含まれていない場合が該当する。適用除外登録情報とソースコードとの不一致としては、例えば、適用除外登録情報に示された行番号に、承認キーが埋め込まれていない場合等を示す。これは、開発者による適用除外申請時と、適用除外申請装置１０１によるソースコードのコピー時とで、ソースコード中の行番号にズレが生じること等を理由とする。
【００１７】
図８は、インスペクション装置７００の参照するルール情報７０１のデータ構造の一例を示す図である。
ルール情報７０１は、管理者等により予め定義されるものであり、各インスペクションルールを一意に識別するためのルール名８０１と、重要度８０２と、種類８０３と、チェック内容８０４との各情報で構成される。
重要度８０２はそのルールの重要度を表す。種類８０３は、そのルールの種別を表す。チェック内容８０４は、このルールがソースコードをどのようにチェックするのかを表す。ソースコードをチェックするロジックはインスペクション装置７００に実装されている。例えば、ルール名「Ｘ００００１」のルール情報８１０は、ｔｒｙ節に対応するｃａｔｃｈ文の中身が空かどうかということをチェックするルールを示している。
【００１８】
図９は、インスペクション装置７００の出力する検査結果情報７０２のデータ構造の一例を示す図である。
検査結果情報７０２は、プロジェクト名９０１，ソース名９０２，更新日時９０３，ルール名９０４，行番号９０５，メッセージ９０６，検査日９０７の各情報を有する。
プロジェクト名９０１は、インスペクション対象であるプロジェクトを示す。これは、インスペクションを行う際に管理者１３０により入力される。ソース名９０２は、インスペクションを行うソースコードを識別する名前である。更新日時９０３は、ソースコードの更新日時である。ルール名９０４は、ソースコード中に検出されたルール違反のルール名を表している。行番号９０５はルール違反が検出された行番号である。メッセージ９０６は、ルール違反の内容を表している。検査日９０７はインスペクション処理を実行した日時を表す。
例えば、レコード９１０は、ソースコード「Ｓａｍｐｌｅ．ｊａｖａ」の１７行目において、変数を初期化しているエラーが検出されていることを表している。
【００１９】
図１０は、インスペクション装置７００の出力する除外対象結果情報７０３のデータ構造の一例を示す図である。
除外対象結果情報７０３は、適用除外登録情報に基づき、インスペクション処理において処理対象から除外されたものを示し、適用除外登録データベース１０４に登録された適用除外承認情報に対応する情報として、ユーザ名１００１，ソース名１００２，行番号１００３，ルール名１００４，メッセージ１００５の各情報を有する。
例えば、レコード１０１０は、ソースコード「Ｓａｍｐｌｅ．ｊａｖａ」の２０行目に存在するエラー箇所は、インスペクション処理時に正しく除外されたことを表している。
【００２０】
図１１は、不正除外結果情報７０４のデータ構造の一例を示す図である。
不正除外結果情報７０４は、適用除外登録データベース１０４に登録されていない承認キーがソースコード中に含まれているか、または、適用除外登録情報に対応するエラー箇所がソースコード中の該当行に含まれていないこと等、適用除外登録情報に関する不正処理結果を示す。不正除外結果情報７０４には、ユーザ名１１０１，ソース名１１０２，行番号１１０３，エラー内容１１０４の各情報を含んでいる。
ユーザ名１１０１は、不正の検出されたソースコードの担当開発者である。ソース名１１０２は、不正の検出されたソース名である。行番号１１０３は、不正の検出された行番号である。エラー内容１１０４は、不正の種別を説明した内容である。
例えば、レコード１１１０は、「Ｂｂｂ．ｊａｖａ」というソースコードの３２行目において、適用除外登録情報に対応するエラー箇所が検出されなかったことを表している。
【００２１】
図１２は、本実施の形態に係るインスペクション装置７００によるインスペクション処理を示すフローチャートである。
インスペクション装置７００は、インスペクション用データベース１０５からソースコードを取得し（ステップ１２０１）、ルール情報７０１を参照して、インスペクション用データベース１０５から取得したソースコードのインスペクションを行う（ステップ１２０２）。この場合、インスペクションして得られたエラー箇所の検出結果は一時領域などに記憶しておく。
また、適用除外登録データベース１０４の適用除外登録情報を参照して、不正箇所の検出を行う（ステップ１２０３）。具体的には、適用除外登録装置１０２が生成した承認キーのみが埋め込まれているか、生成された承認キーが複数箇所に埋め込まれていないか、インスペクションルールの適用除外として登録された情報がステップ１２０２でルール違反として検出されているかをチェックして、不正を検出した場合には、不正除外結果情報７０４として出力する（ステップ１２０４）。
インスペクションの結果、検出されたエラー箇所に承認キーが埋め込まれているか否かを判定し（ステップ１２０５）、承認キーが埋め込まれている場合には、除外対象結果情報７０３として出力する（ステップ１２０６）。
一方、エラー箇所に承認キーが埋め込まれていない場合には、検査結果情報７０２として出力する（ステップ１２０７）。
以上の判定処理及び除外対象結果情報７０３又は検査結果除法７０２の出力処理を、検出したエラー箇所の全てについて行った後（ステップ１２０８）、出力結果を開発者等に送信する（ステップ１２０９）。
【００２２】
インスペクション装置７００は、出力した検査結果７０２，除外対象結果７０３，不正除外結果７０４を管理者１３０及び開発者１２０に提供する。
開発者１２０は、検査結果７０２に基づき、ソースコードの修正又は新たな適用除外申請を行う。また、不正除外結果７０４を参照して、重複する承認キーの削除を行うか、適用除外申請情報の修正を行う。
インスペクション装置７００は、開発者１２０により修正されたソースコードについて、図１２に示すインスペクション処理を行う。
以上のように、インスペクション装置７００による処理と開発者１２０によるソースコードの修正とを、エラー検出が無くなるまで繰返して行う。
【００２３】
以上のように、本実施の形態に係るソースコードインスペクションシステムによれば、設計上の理由等により管理者により修正不要と判断されたエラー箇所について、インスペクション手段の検査結果出力対象から除外されるため、インスペクション処理の度にエラー箇所として検出されることを防止することができ、管理者の確認作業工数を大幅に削減することが可能となる。
また、開発者からの適用除外申請を受付ける手段を備え、管理者の判断に基づき適用除外登録情報として登録することとしたので、管理者は開発者から申請されたエラー箇所についてのみ修正の要否を判断すればよいため、インスペクション処理の結果として検出されたエラー箇所の全てについて修正の要否を判断する必要が無くなり、管理者の作業工数を大幅に削減することが可能となる。
また、検出除外箇所に対し承認キーを埋め込むこととしたので、インスペクション手段によるインスペクション処理では、承認キーの有無により適用除外箇所か否かを容易に判定することが可能となる。
また、ソースコード中に埋め込まれたキーと検出除外登録情報に含まれるキーとが一致しない場合、または、検出除外登録情報に示される承認キーがソースコード中に埋め込まれていない場合等に、不正除外情報を出力することとしたので、管理者は不正な承認キー等を容易に判断することが可能となる。また、開発者も、適用除外申請時と承認キー埋め込み時とでソースコードの該当箇所にズレが生じたこと等を容易に把握することが可能となる。
【００２４】
なお、前記実施の形態では、適用除外申請装置，適用除外登録装置及びインスペクション装置のそれぞれを別端末により構成しているが、これに限らず、一つの端末に複数の処理手段を備える構成としてもよい。
また、前記実施の形態では、開発者による適用除外申請情報に基づき、適用除外情報の登録を行うこととしているが、インスペクション処理により検出された検査結果の中から任意に指定されたレコードに基づき適用除外情報の登録を行うこととしてもよい。
また、前記実施の形態では、インスペクション装置によるインスペクション処理のエラー検出結果から適用除外登録情報に示すエラー項目を除外することとしているが、インスペクション処理の前に、予め適用除外登録情報に示す行を処理対象から除外することとしてもよい。
また、前記実施の形態では、ソースコード中の行の追加等により、開発者による適用除外申請時と、適用除外申請装置によるソースコードのコピー時とで、ソースコード中の行番号にズレが生じた場合には不正除外結果情報として出力することとしているが、他の処理を行うこととしてもよい。例えば、適用除外申請受付時において該当行の文字列を抽出しておき、適用除外登録時に、適用除外申請情報の行番号の前後１０行等の所定範囲から、予め抽出した該当行の文字列とのマッチングにより該当箇所を検出してキーを埋め込むこととしてもよい。
【図面の簡単な説明】
【００２５】
【図１】本発明の一実施の形態に係るソースコードインスペクションシステムの一部の概略構成を示すブロック図である。
【図２】ソースコードインスペクションシステムを構成する適用除外申請データベースのデータ構造の一例を示す図である。
【図３】ソースコードインスペクションシステムを構成する適用除外登録データベースのデータ構造の一例を示す図である。
【図４】ソースコードインスペクションシステムを構成する適用除外申請装置の行う処理手順を示すフローチャートである。
【図５】ソースコードインスペクションシステムを構成する適用除外登録装置の行う処理手順を示すフローチャートである。
【図６】本発明の一実施の形態に係るソースコードインスペクションシステムの一部の概略構成を示すブロック図である。
【図７】承認キーを埋め込んだソースコードの一例を示す図である。
【図８】ルール情報のデータ構造の一例を示す図である。
【図９】検査結果情報のデータ構造の一例を示す図である。
【図１０】除外対象結果情報のデータ構造の一例を示す図である。
【図１１】不正除外結果情報のデータ構造の一例を示す図である。
【図１２】ソースコードインスペクションシステムを構成するインスペクション装置の行う処理手順を示すフローチャートである。
【図１３】従来のソースコードインスペクション装置の概略構成を示す図である。
【図１４】従来のソースコードインスペクション装置を用いたインスペクション処理手順を示すフローチャートである。
【符号の説明】
【００２６】
１０１  適用除外申請装置、１０２  適用除外登録装置、１０３  適用除外申請データベース、１０４  適用除外登録データベース、１０５  インスペクション用データベース、１１０  ソースコード管理データベース、７００  インスペクション装置、７０１  ルール情報、７０２  検査結果情報、７０３  除外対象結果情報、７０４  不正除外結果情報。
【図１】
2006092475.tif 000003
【図２】
2006092475.tif 000004
【図３】
2006092475.tif 000005
【図４】
2006092475.tif 000006
【図５】
2006092475.tif 000007
【図６】
2006092475.tif 000008
【図７】
2006092475.tif 000009
【図８】
2006092475.tif 000010
【図９】
2006092475.tif 000011
【図１０】
2006092475.tif 000012
【図１１】
2006092475.tif 000013
【図１２】
2006092475.tif 000014
【図１３】
2006092475.tif 000015
【図１４】
2006092475.tif 000016