(57)【要約】【課題】ソースコードに対する静的解析により検出された警告に対し、どの警告に対応する修正から行うべきかの優先度付けを行うことができるソースコード修正優先度付けシステムおよびその優先度付け方法を提供する。【解決手段】本発明に係るソースコード修正優先度付けシステム１０は、ソースコードの記憶を行う構成管理部１１、不具合情報管理ＤＢ１２、変更履歴にもとづく修正優先度付けを行う変更履歴優先度付け装置１３、不具合情報にもとづく修正優先度付けを行う不具合優先度付け装置１４、総合的な修正優先度付けを行う修正優先度決定装置１５、修正優先度ＤＢ１６、一般的な静的解析を行う静的解析装置２１および静的解析結果ＤＢ２２を有するものである。【選択図】  図１
2008021244.tif 000002
【特許請求の範囲】
【請求項１】
初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶する構成管理データベースと、
前記構成管理データベースに記憶された前記新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成し、このモジュールごとの変更の情報を前記新たなソースコードと関連付けて前記構成管理データベースに記憶させる差分作成装置と、
前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力する静的解析装置と、
この静的解析装置の出力した警告を前記新たなソースコードと関連付けて記憶する静的解析結果データベースと、
前記構成管理データベースからこの構成管理データベースに記憶されている全ての前記モジュールごとの変更の情報を、前記静的解析結果データベースから前記新たなソースコードの警告を、それぞれ取得し、前記全てのモジュールごとの変更の情報にもとづき前記初回記憶時のソースコードから前記新たなソースコードまでの前記モジュールごとの変更の累計回数を計算し、この変更の累計回数が多いモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けを行う変更履歴優先度付け装置と、
を備えたことを特徴とするソースコード修正優先度付けシステム。
【請求項２】
前記変更履歴優先度付け装置は、前記モジュールごとの変更の累計回数が同一回数のモジュールがある場合は、この同一回数のモジュールのうち変更時期が新しいモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けをさらに行うよう構成された請求項１記載のソースコード修正優先度付けシステム。
【請求項３】
初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶し、この新たなソースコードが変更後のソースコードでありかつこの変更が不具合に対応するための変更であった場合にはこの不具合の不具合ＩＤをこの新たなソースコードに関連付けてさらに記憶する構成管理データベースと、
前記構成管理データベースに記憶された前記新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成し、このモジュールごとの変更の情報を前記新たなソースコードと関連付けて前記構成管理データベースに記憶させる差分作成装置と、
前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力する静的解析装置と、
この静的解析装置の出力した警告を前記新たなソースコードと関連付けて記憶する静的解析結果データベースと、
前記構成管理データベースから前記新たなソースコードに関連付けられたモジュールごとの変更の情報および存在する場合は前記不具合ＩＤを、前記静的解析結果データベースから前記新たなソースコードの警告および前記前回記憶時のソースコードの警告を、それぞれ取得し、前記不具合ＩＤが存在しかつ前記前回記憶時のソースコードにあり前記新たなソースコードにない削除された警告がある場合は、この削除された警告と同一種類の前記新たなソースコードの警告から修正すべき旨の優先度付けを行う不具合優先度付け装置と、
を備えたことを特徴とするソースコード修正優先度付けシステム。
【請求項４】
初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶し、この新たなソースコードが変更後のソースコードでありかつこの変更が不具合に対応するための変更であった場合にはこの不具合の不具合ＩＤをこの新たなソースコードに関連付けてさらに記憶する構成管理データベースと、
前記構成管理データベースに記憶された前記新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成し、このモジュールごとの変更の情報を前記新たなソースコードと関連付けて前記構成管理データベースに記憶させる差分作成装置と、
前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力する静的解析装置と、
この静的解析装置の出力した警告を前記新たなソースコードと関連付けて記憶する静的解析結果データベースと、
前記構成管理データベースからこの構成管理データベースに記憶されている全ての前記モジュールごとの変更の情報を、前記静的解析結果データベースから前記新たなソースコードの警告を、それぞれ取得し、前記全てのモジュールごとの変更の情報にもとづき前記初回記憶時のソースコードから前記新たなソースコードまでの前記モジュールごとの変更の累計回数を計算し、この変更の累計回数が同一回数のモジュールがない場合は、この変更の累計回数が多いモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けを行い、前記モジュールごとの変更の累計回数が同一回数のモジュールがある場合は、この同一回数のモジュールのうち変更時期が新しいモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けをさらに行う変更履歴優先度付け装置と、
前記構成管理データベースから前記新たなソースコードに関連付けられたモジュールごとの変更の情報および存在する場合は前記不具合ＩＤを、前記静的解析結果データベースから前記新たなソースコードの警告および前記前回記憶時のソースコードの警告を、それぞれ取得し、前記不具合ＩＤが存在しかつ前記前回記憶時のソースコードにあり前記新たなソースコードにない削除された警告がある場合は、この削除された警告と同一種類の前記新たなソースコードの警告から修正すべき旨の優先度付けを行う不具合優先度付け装置と、
前記変更履歴優先度付け装置から受けた優先度付けの結果と、前記不具合優先度付け装置から受けた優先度付けの結果とにもとづき、総合的にどの前記警告から修正すべきかの優先度付けを行う修正優先度決定装置と、
を備えたことを特徴とするソースコード修正優先度付けシステム。
【請求項５】
初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶するステップと、
前記新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成してこのモジュールごとの変更の情報を前記新たなソースコードと関連付けて記憶するステップと、
前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力するステップと、
前記関連付けて記憶するステップで記憶した全ての前記モジュールごとの変更の情報にもとづき前記初回記憶時のソースコードから前記新たなソースコードまでの前記モジュールごとの変更の累計回数を計算するステップと、
この変更の累計回数が多いモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けを行うステップと、
を有することを特徴とするソースコード修正優先度付け方法。
【請求項６】
前記優先度付けを行うステップは、前記モジュールごとの変更の累計回数が同一回数のモジュールがある場合、変更時期が新しいモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けを行うステップをさらに有する請求項５記載のソースコード修正優先度付け方法。
【請求項７】
初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶するステップと、
前記新たなソースコードが変更後のソースコードでありかつこの変更が不具合に対応するための変更であった場合にはこの不具合の不具合ＩＤをこの新たなソースコードに関連付けて記憶するステップと、
この新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成してこのモジュールごとの変更の情報を前記新たなソースコードと関連付けて記憶するステップと、
前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力するステップと、
前記不具合ＩＤが存在しかつ前記前回記憶時のソースコードにあり前記新たなソースコードにない削除された警告がある場合は、この削除された警告と同一種類の前記新たなソースコードの警告から修正すべき旨の優先度付けを行うステップと、
を有することを特徴とするソースコード修正優先度付け方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソースコードに対する静的解析により検出された警告に対応する修正の優先度付けを行うソースコード修正優先度付けシステムおよびその優先度付け方法に関する。
【背景技術】
【０００２】
ソースコードに対する静的解析は、動作不良などの不具合を起こす可能性を減らす目的で行われる。静的解析では、不具合に繋がりやすい一定のパターンをあらかじめ定義しておき、この定義に合致するパターンをソースコード内に検出した場合に、その旨が警告として出力される。ユーザは、この警告に対応する修正と静的解析を繰り返すことにより、ソースコードの品質改善を行うことができる。
【０００３】
この静的解析により検出される警告は、ソースコードが大きくなるにつれ、膨大な量になっていく。実際には、静的解析の結果、不具合に繋がらないもの等も含め、修正しきれないほど大量の警告が出力されることも多い。このため、ユーザに対し、どの警告から修正すべきかを提示する技術が求められている。
【０００４】
従来、この種のソースコード修正支援技術として、特開２００４−３２６３３７号公報（特許文献１）に開示されたものがある。
【０００５】
特開２００４−３２６３３７号公報（特許文献１）に開示されたコード解析プログラム、コード解析自動化プログラム及び自動コード解析システムは、ソースコードに変更（修正）があった場合に変更前と変更後のソースコードの差分情報を生成し、この差分情報にもとづいて、変更後のソースコードの静的解析結果を絞り込むことができるようになっている。このため、変更のないソースコードに対する解析結果はリストアップされない。したがって、修正する必要のないソースコードを静的解析ごとにチェックする手間を省略することができるとともに、静的解析ごとに余分な警告が増大することも防止することができる。
【特許文献１】特開２００４−３２６３３７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来のソースコード修正支援技術では、ソースコードの変更箇所に対する警告を単に抽出するだけであり、この抽出された警告が複数の場合、どの警告が優先的に修正されるべきかが全く不明である。つまり、この警告のうち、どの警告が実際に不具合に結びつくコーディングミスに由来するものか、どの警告がソースコード作成者の仕様に対する理解不足に由来するものなのか、関連付けられてはいない。また、ソースコードの変更が広く分布している場合には、そもそも警告の絞込みが効果的に行えない。
【０００７】
本発明は、上述した事情を考慮してなされたもので、ソースコードに対する静的解析により検出された警告に対し、どの警告に対応する修正から行うべきかの優先度付けを行うことができるソースコード修正優先度付けシステムおよびその優先度付け方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明に係るソースコード修正優先度付けシステムは、上述した課題を解決するために、新初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶する構成管理データベースと、前記構成管理データベースに記憶された前記新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成し、このモジュールごとの変更の情報を前記新たなソースコードと関連付けて前記構成管理データベースに記憶させる差分作成装置と、前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力する静的解析装置と、この静的解析装置の出力した警告を前記新たなソースコードと関連付けて記憶する静的解析結果データベースと、前記構成管理データベースからこの構成管理データベースに記憶されている全ての前記モジュールごとの変更の情報を、前記静的解析結果データベースから前記新たなソースコードの警告を、それぞれ取得し、前記全てのモジュールごとの変更の情報にもとづき前記初回記憶時のソースコードから前記新たなソースコードまでの前記モジュールごとの変更の累計回数を計算し、この変更の累計回数が多いモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けを行う変更履歴優先度付け装置と、を備えたことを特徴とするものである。ここで、モジュールごとの変更の情報とは、少なくともモジュールごとの変更の有無と、新たなソースコードの変更時期（記憶日時）の情報を含むものをいう。以下同じ。
【０００９】
また、本発明に係るソースコード修正優先度付けシステムは、上述した課題を解決するために、初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶し、この新たなソースコードが変更後のソースコードでありかつこの変更が不具合に対応するための変更であった場合にはこの不具合の不具合ＩＤをこの新たなソースコードに関連付けてさらに記憶する構成管理データベースと、前記構成管理データベースに記憶された前記新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成し、このモジュールごとの変更の情報を前記新たなソースコードと関連付けて前記構成管理データベースに記憶させる差分作成装置と、前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力する静的解析装置と、この静的解析装置の出力した警告を前記新たなソースコードと関連付けて記憶する静的解析結果データベースと、前記構成管理データベースから前記新たなソースコードに関連付けられたモジュールごとの変更の情報および存在する場合は前記不具合ＩＤを、前記静的解析結果データベースから前記新たなソースコードの警告および前記前回記憶時のソースコードの警告を、それぞれ取得し、前記不具合ＩＤが存在しかつ前記前回記憶時のソースコードにあり前記新たなソースコードにない削除された警告がある場合は、この削除された警告と同一種類の前記新たなソースコードの警告から修正すべき旨の優先度付けを行う不具合優先度付け装置と、を備えたことを特徴とするものである。
【００１０】
さらに、本発明に係るソースコード修正優先度付けシステムは、上述した課題を解決するために、初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶し、この新たなソースコードが変更後のソースコードでありかつこの変更が不具合に対応するための変更であった場合にはこの不具合の不具合ＩＤをこの新たなソースコードに関連付けてさらに記憶する構成管理データベースと、前記構成管理データベースに記憶された前記新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成し、このモジュールごとの変更の情報を前記新たなソースコードと関連付けて前記構成管理データベースに記憶させる差分作成装置と、前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力する静的解析装置と、この静的解析装置の出力した警告を前記新たなソースコードと関連付けて記憶する静的解析結果データベースと、前記構成管理データベースからこの構成管理データベースに記憶されている全ての前記モジュールごとの変更の情報を、前記静的解析結果データベースから前記新たなソースコードの警告を、それぞれ取得し、前記全てのモジュールごとの変更の情報にもとづき前記初回記憶時のソースコードから前記新たなソースコードまでの前記モジュールごとの変更の累計回数を計算し、この変更の累計回数が同一回数のモジュールがない場合は、この変更の累計回数が多いモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けを行い、前記モジュールごとの変更の累計回数が同一回数のモジュールがある場合は、この同一回数のモジュールのうち変更時期が新しいモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けをさらに行う変更履歴優先度付け装置と、前記構成管理データベースから前記新たなソースコードに関連付けられたモジュールごとの変更の情報および存在する場合は前記不具合ＩＤを、前記静的解析結果データベースから前記新たなソースコードの警告および前記前回記憶時のソースコードの警告を、それぞれ取得し、前記不具合ＩＤが存在しかつ前記前回記憶時のソースコードにあり前記新たなソースコードにない削除された警告がある場合は、この削除された警告と同一種類の前記新たなソースコードの警告から修正すべき旨の優先度付けを行う不具合優先度付け装置と、前記変更履歴優先度付け装置から受けた優先度付けの結果と、前記不具合優先度付け装置から受けた優先度付けの結果とにもとづき、総合的にどの前記警告から修正すべきかの優先度付けを行う修正優先度決定装置と、を備えたことを特徴とするものである。
【００１１】
一方、本発明に係るソースコード修正優先度付け方法は、上述した課題を解決するために、初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶するステップと、前記新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成してこのモジュールごとの変更の情報を前記新たなソースコードと関連付けて記憶するステップと、前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力するステップと、前記関連付けて記憶するステップで記憶した全ての前記モジュールごとの変更の情報にもとづき前記初回記憶時のソースコードから前記新たなソースコードまでの前記モジュールごとの変更の累計回数を計算するステップと、この変更の累計回数が多いモジュールに付された前記新たなソースコードの警告から修正すべき旨の優先度付けを行うステップと、を有することを特徴とする方法である。
【００１２】
また、本発明に係るソースコード修正優先度付け方法は、上述した課題を解決するために、初回記憶時のソースコードから前回記憶時のソースコードまでと新たなソースコードとの全てのソースコードをモジュールごとに記憶するステップと、前記新たなソースコードが変更後のソースコードでありかつこの変更が不具合に対応するための変更であった場合にはこの不具合の不具合ＩＤをこの新たなソースコードに関連付けて記憶するステップと、この新たなソースコードと前記前回記憶時のソースコードを比較しモジュールごとの変更の情報を作成してこのモジュールごとの変更の情報を前記新たなソースコードと関連付けて記憶するステップと、前記新たなソースコードに対して静的解析を行い、不具合に繋がりやすい一定のパターンを検出した場合に、その旨を警告として出力するステップと、前記不具合ＩＤが存在しかつ前記前回記憶時のソースコードにあり前記新たなソースコードにない削除された警告がある場合は、この削除された警告と同一種類の前記新たなソースコードの警告から修正すべき旨の優先度付けを行うステップと、を有することを特徴とする方法である。
【発明の効果】
【００１３】
本発明に係るソースコード修正優先度付けシステムおよびその優先度付け方法によれば、ソースコードに対する静的解析により検出された警告に対し、どの警告に対応する修正から行うべきかの優先度付けを行うことができる。
【発明を実施するための最良の形態】
【００１４】
本発明に係るソースコード修正優先度付けシステムおよびその優先度付け方法の実施の形態について、添付図面を参照して説明する。
【００１５】
図１は、本発明に係るソースコード修正優先度付けシステムの一実施形態を示す概略的な全体構成図である。
【００１６】
ソースコード修正優先度付けシステム１０は、構成管理部１１、不具合情報管理ＤＢ１２、変更履歴優先度付け装置１３、不具合優先度付け装置１４、修正優先度決定装置１５、修正優先度ＤＢ１６、静的解析装置２１および静的解析結果ＤＢ２２を有する。
【００１７】
構成管理部１１は、構成管理ＤＢ１１ａと、監視装置１１ｂと、差分生成装置１１ｃとを有する。
【００１８】
構成管理ＤＢ１１ａは、ユーザから、ユーザの意思をソースコード修正優先度付けシステム１０に伝える機能を有するキーボードなどの入力装置３１を介して受けたソースコードをモジュールごとに記憶する。変更（修正）後のソースコードを受けた場合、構成管理ＤＢ１１ａはこの変更後のソースコードをさらに記憶する。また、この変更が不具合に対応するための変更であった場合には、変更後のソースコードに対しこの不具合の不具合ＩＤを関連付けて記憶する。
【００１９】
監視装置１１ｂは、構成管理ＤＢ１１ａを監視し、ソースコードの記憶が行われたかどうか判定する。ソースコードの記憶が行われた場合、監視装置１１ｂは、その旨を差分生成装置１１ｃ、変更履歴優先度付け装置１３、不具合優先度付け装置１４および静的解析装置２１に通知する。
【００２０】
差分生成装置１１ｃは、構成管理ＤＢ１１ａに記憶されたソースコードと前回記憶時のソースコードとを取得し、両者を比較して変更（差分）があるかどうかを判定し、ソースコードのモジュールごとに差分情報を作成する。また、差分生成装置１１ｃは、モジュールごとの変更（差分）の情報（少なくともモジュールごとの変更の有無と、ソースコードの変更時期（記憶日時）の情報を含む）（以下、変更の情報という）を、ソースコードと関連付けて、構成管理ＤＢ１１ａに記憶させる。
【００２１】
不具合管理ＤＢ１２は、ユーザから入力装置３１を介して受けた、ソースコードの開発中に発見された不具合に関する情報（以下、不具合情報という）を記憶する。不具合情報は、不具合ごとに付与する不具合ＩＤと、不具合の原因（コーディングミス、その他（仕様誤解等））を少なくとも含む。不具合の原因を、原理的に静的解析で検出困難な仕様の誤解等によるものと、静的解析で検出しやすいコーディングミスとに分けることで、より精度良く実際の不具合と静的解析による警告を結びつけることができる。
【００２２】
変更履歴優先度付け装置１３は、構成管理ＤＢ１１ａからソースコードのモジュールごとの変更の情報を、静的解析結果ＤＢ２２からこのソースコードの警告（各警告を識別するための警告ＩＤ、警告内容、ソースコード内の警告位置、警告種類の情報を少なくとも含む）を、それぞれ取得する。また、変更履歴優先度付け装置１３は、この変更の情報からモジュールごとの変更の累計回数を計算し、この変更回数および変更時期にもとづいてどの警告から修正すべきかの優先度付けを行い、この優先度付けの結果を修正優先度決定装置１５に与える。
【００２３】
不具合優先度付け装置１４は、構成管理ＤＢ１１ａからソースコードのモジュールごとの変更の情報および存在する場合は不具合ＩＤを、静的解析結果ＤＢ２２からこのソースコードの変更前後の警告を、それぞれ取得する。また、不具合優先度付け装置１４は、不具合ＩＤが存在し、かつ、変更により削除された警告がある場合は、この削除された警告が実際に不具合の原因になっていたとみなして、この削除された警告と同一種類の警告に対する優先度を上げるよう優先度付けを行い、この優先度付けの結果を修正優先度決定装置１５に与える。
【００２４】
修正優先度決定装置１５は、変更履歴優先度付け装置１３および不具合優先度付け装置１４から優先度の情報を受け、総合的にどの警告から修正すべきかの優先度を決定する。また、修正優先度決定装置１５は、この総合的な修正優先度を修正優先度ＤＢ１６に記憶させる。さらに、修正優先度決定装置１５は、ＣＲＴやＬＣＤなどの表示装置３２を介して、修正優先度ＤＢ１６が記憶している修正優先度付けされた警告のリストをユーザに提示する。
【００２５】
静的解析装置２１は、ソースコードに対し、一般的な静的解析を行う装置であり、この静的解析の結果（警告）をソースコードと関連付けて静的解析結果ＤＢ２２に記憶させる。また、静的解析装置２１は、構成管理ＤＢ１１ａから静的解析を行ったソースコードの変更の情報を取得し、このソースコードの構成管理ＤＢ１１ａへの記憶が初めてである場合（変更時期が一つも記憶されていない場合）は、その旨を修正優先度決定装置１５に与える。
【００２６】
静的解析結果ＤＢ２２は、静的解析装置２１から受けたソースコードの静的解析の結果（警告）をソースコードと関連付けて記憶する。
【００２７】
なお、構成管理ＤＢ１１ａ、不具合管理ＤＢ１２、静的解析結果ＤＢ２２および修正優先度ＤＢ１６の各データベースは、磁気的もしくは光学的記憶媒体または半導体メモリなどのコンピュータ読み取り可能な記憶媒体を含んだ構成を有してもよく、各データベース内のデータの一部または全部は電子ネットワークを介してダウンロードされるように構成してもよい。
【００２８】
次に、ソースコード修正優先度付けシステム１０の作用について説明する。
【００２９】
図２は、図１に示すソースコード修正優先度付けシステム１０により、ソースコードに対する静的解析により検出された警告に対し、どの警告に対応する修正から行うべきかの優先度付けを行う際の手順を示すフローチャートである。図２において、Ｓに数字を付した符号は、フローチャートの各ステップを示す。
【００３０】
この手順は、あらかじめ、ソースコードの開発中に発見された不具合情報を不具合管理ＤＢ１２に記憶させた状態でスタートとなる。
【００３１】
まず、ステップＳ１において、監視装置１１ｂは、構成管理ＤＢ１１ａを監視し、ソースコードの記憶が行われたかどうか判定する。記憶が行われた場合は、ステップＳ２に進む。一方、記憶が行われない場合は、引き続き構成管理ＤＢ１１ａの監視を続ける。
【００３２】
このソースコードの記憶は、ユーザにより入力装置３１を介して行われる。この記憶には、ソースコードを初めて構成管理ＤＢ１１ａに記憶させる場合と、すでに構成管理ＤＢ１１ａに記憶させてある（開発中の）ソースコードに対して変更を行った後にこの変更後のソースコードをさらに構成管理ＤＢ１１ａに記憶させる場合とがある。
【００３３】
変更後のソースコードを記憶させる場合、この変更が不具合に対応するための変更であった場合には、ユーザは、変更後のソースコードに対しこの不具合の不具合ＩＤを関連付けて構成管理ＤＢ１１ａに記憶させる。この結果、構成管理ＤＢ１１ａに記憶されたソースコードには、不具合ＩＤが関連付けられているものと不具合ＩＤが関連付けられていないものとが存在することになる。
【００３４】
次に、ステップＳ２において、静的解析装置２１は、監視装置１１ｂからソースコードの記憶が行われた旨の通知を受け、このソースコードに対して静的解析を行う。静的解析装置２１は、この静的解析の結果（警告）をソースコードと関連付けて静的解析結果ＤＢ２２に記憶させる。この警告には、各警告を識別するための警告ＩＤ、警告内容、ソースコード内の警告位置、警告種類の情報を少なくとも含む。
【００３５】
次に、ステップＳ３において、静的解析装置２１は、構成管理ＤＢ１１ａに従って静的解析を行ったソースコードを検索し、このソースコードに対応する変更の情報（少なくともモジュールごとの変更の有無と、ソースコードの変更時期（記憶日時）の情報を含む）を取得し、このソースコードの構成管理ＤＢ１１ａへの記憶が初めてであるかどうか判定する。初めてである場合（変更時期が一つも記憶されていない場合）は、ステップＳ４に進む。一方、２度目以降である場合（変更時期が記憶されている場合）は、ステップＳ５に進む。
【００３６】
次に、ステップＳ４において、修正優先度決定装置１５は、静的解析装置２１からソースコードの初回記憶が行われた旨の通知を受け、静的解析結果ＤＢ２２からソースコードの警告を読み込み、全ての警告に対する優先度をデフォルトの値に設定して修正優先度ＤＢ１６に記憶させ、ステップＳ１に戻る。このデフォルト値の設定は、たとえば優先度を数値化する場合は、全ての警告に対する優先度（数値）を同一の数値に設定することなどにより行う。
【００３７】
次に、ステップＳ５において、差分生成装置１１ｃは、監視装置１１ｂからソースコードの記憶が行われた旨の通知を受け、構成管理ＤＢ１１ａに従ってこのソースコードと前回記憶時のソースコードとを取得し、両者を比較して変更（差分）があるかどうかを判定する。変更がある場合はステップＳ６に進む。一方、変更がない場合はステップＳ１に戻る。
【００３８】
次に、ステップＳ６において、差分生成装置１１ｃは、前回記憶時のソースコードと今回記憶したソースコードの差分情報を作成する。この差分情報の作成は、ソースコードのモジュールごとに行う。差分生成装置１１ｃは、ソースコードの変更の情報（少なくともモジュールごとの変更の有無と、ソースコードの変更時期（記憶日時）の情報を含む）を、ソースコードと関連付けて、構成管理ＤＢ１１ａに記憶させる。この結果、構成管理ＤＢ１１ａには、少なくとも、ソースコードと、このソースコードのモジュールごとの変更の有無と、変更が行われた場合にはこの変更の日時（変更時期）とが互いに関連付けられて記憶される。また、ソースコードの記憶ごとに各ソースコードに関連付けられたモジュールごとの変更の情報が記憶されるため、構成管理ＤＢ１１ａには、モジュールごとの変更の情報の履歴が作成されることになる。
【００３９】
次に、ステップＳ７において、変更履歴優先度付け装置１３は、監視装置１１ｂからソースコードの記憶が行われた旨の通知を受け、構成管理ＤＢ１１ａに従ってソースコードを検索し、このソースコードに対応する変更の情報をから変更のあったモジュールに関する情報（モジュール名など）を取得する。そして、変更履歴優先度付け装置１３は、静的解析結果ＤＢ２２に従ってこのソースコードの変更のあったモジュールを検索し、この変更のあったモジュールに警告が存在するかどうか判定する。警告がある場合はステップＳ８に進む。一方、警告がない場合はステップＳ１に戻る。
【００４０】
次に、ステップＳ８において、変更履歴優先度付け装置１３は、構成管理ＤＢ１１ａに記憶されているソースコードの変更の情報にもとづいて、どの警告から修正すべきかの優先度付けを行い、この優先度付けの結果を修正優先度決定装置１５に与える。
【００４１】
図３は、図２のステップＳ８で変更履歴優先度付け装置１３により実行される、変更履歴にもとづく修正優先度付けの際の手順を示す、サブルーチンフローチャートである。図３において、Ｓに数字を付した符号は、フローチャートの各ステップを示す。
【００４２】
図４は、警告に対応して行われるソースコードの修正の様子を概念的に示す説明図である。図４には、ModuleＡ、ModuleＢおよびModuleＣの３つのモジュールで構成されるソースコードについて、ソースコード修正の一例を示した。
【００４３】
図４において、Ｗａ−１、Ｗａ−２などと示す記号は静的解析装置２１により付される警告を簡略的に表したもので、アルファベット（ＷａおよびＷｂ）は警告の種類を表し、数字（１〜６）はソースコード内の警告位置を表す。たとえば、図４に示すソースコードVersion１には、ＷａおよびＷｂの２種類の警告が、それぞれソースコード内の６箇所に存在している。
【００４４】
また、図４において、ソースコードVersion１（以下、Ｖｅｒ１という）は変更前のソースコードを、ソースコードVersion２（以下、Ｖｅｒ２という）はＶｅｒ１のModuleＢの警告に対応する修正を行ったソースコードを、ソースコードVersion３（以下、Ｖｅｒ３という）はＶｅｒ２のModuleＡの警告に対応する修正を行ったソースコードを、それぞれ表している。
【００４５】
つづいて、図３を参照して、図４に示すＶｅｒ３の記憶が行われた場合の、変更履歴にもとづく修正優先度付けの際の手順について説明する。
【００４６】
まず、ステップＳ８１において、変更履歴優先度付け装置１３は、構成管理ＤＢ１１ａに従ってソースコードを検索し、モジュールごとの変更の情報を取得する。この取得は、構成管理ＤＢ１１ａに記憶されているソースコード全てについて、それぞれのソースコードに関連付けられたモジュールごとの変更の情報を取得することにより行う。この結果、変更履歴優先度付け装置１３は、モジュールごとの変更の情報の履歴を得ることができる。
【００４７】
次に、ステップＳ８２において、変更履歴優先度付け装置１３は、モジュールごとの変更の情報から、モジュールごとの変更回数の累計を計算する。たとえば図４に示すソースコードでは、ModuleＡとModuleＢの変更回数がそれぞれ１回であり、ModuleＣは０回である。
【００４８】
次に、ステップＳ８３において、変更履歴優先度付け装置１３は、静的解析結果ＤＢ２２に従ってＶｅｒ３のソースコードを検索し、このＶｅｒ３に対応する警告を取得して、変更回数の多いモジュールに付された警告に対する優先度を上げるべき旨の情報を修正優先度決定装置１５に与える。
【００４９】
図５（ａ）は、図４に示したソースコードに対して変更回数にもとづく修正優先度付けを行った結果を示す説明図である。図４に示したソースコードの場合、変更履歴優先度付け装置１３は、ModuleＡに付された警告Ｗａ-１、Ｗａ−２およびＷｂ−１と、ModuleＢに付された警告Ｗａ−３およびＷｂ−４の優先度を、ModuleＣに付された警告Ｗａ−５、Ｗａ−６、Ｗｂ−５およびＷｂ−６の優先度よりも上げるべき旨の情報を修正優先度決定装置１５に与える。
【００５０】
次に、ステップＳ８４において、変更履歴優先度付け装置１３は、モジュールごとの変更の情報から、同一変更回数のモジュールがあるかどうかを判定する。同一変更回数のモジュールがある場合はステップＳ８５に進む。一方、ない場合は変更履歴にもとづく修正優先度付けの一連の手順は終了となり、図３のステップＳ９に進む。
【００５１】
次に、ステップＳ８５において、変更履歴優先度付け装置１３は、変更時期の新しいモジュールに付された警告の優先度をさらに上げるべき旨の情報を修正優先度決定装置１５に与えて、変更履歴にもとづく修正優先度付けの一連の手順は終了となり、図３のステップＳ９に進む。
【００５２】
図５（ｂ）は、図４に示したソースコードに対して変更履歴（変更回数および変更時期）にもとづく修正優先度付けを行った結果を示す説明図である。図４に示したソースコードでは、ModuleＡとModuleＢの変更回数は同じであるが、ModuleＡの変更時期のほうが新しい。したがって、図４に示したソースコードの場合、変更履歴優先度付け装置１３は、ModuleＡに付された警告Ｗａ-１、Ｗａ−２およびＷｂ−１の優先度を、ModuleＢに付された警告Ｗａ−３およびＷｂ−４の優先度よりも上げるべき旨の情報を修正優先度決定装置１５に与える。
【００５３】
この変更履歴にもとづく修正優先度付けの手順により、変更履歴（変更回数および変更時期）にもとづいて、修正優先度付けを行うことができる。この結果、更新回数が多いモジュールおよび変更時期の新しいモジュールに付された警告に対して高い優先度が与えられることになる。
【００５４】
次に、ステップＳ９において、不具合優先度付け装置１４は、監視装置１１ｂからソースコードの記憶が行われた旨の通知を受け、構成管理ＤＢ１１ａに従ってソースコードを検索し、このソースコードに不具合ＩＤが関連付けられているかどうか調べる。不具合ＩＤが関連付けられている場合は、ソースコードの変更が不具合に対応するためのものであったと判定し、ステップＳ１０に進む。一方、不具合ＩＤが関連付けられていない場合は、ステップＳ１１に進む。
【００５５】
次に、ステップＳ１０において、不具合優先度付け装置１４は、構成管理ＤＢ１１ａに記憶されている不具合ＩＤにもとづいて、どの警告から修正すべきかの優先度付けを行い、この優先度付けの結果を修正優先度決定装置１５に与える。
【００５６】
図６は、図２のステップＳ１０で不具合優先度付け装置１４により実行される、図４に示すＶｅｒ３の記憶が行われた場合の不具合情報にもとづく修正優先度付けの際の手順を示す、サブルーチンフローチャートである。図６において、Ｓに数字を付した符号は、フローチャートの各ステップを示す。
【００５７】
まず、ステップＳ１０１において、不具合優先度付け装置１４は、構成管理ＤＢ１１ａに従ってソースコードを検索し、このソースコードの変更の情報から変更のあったモジュールに関する情報（モジュール名など）を取得する。そして、不具合優先度付け装置１４は、静的解析結果ＤＢ２２からこの変更のあったモジュールについて変更後と変更前のモジュールの警告を取得し、この変更のあったモジュールの警告に変更によって削除されたものがあるかどうか判定する。削除された警告がある場合はステップＳ１０２に進む。一方、削除された警告がない場合は不具合情報にもとづく修正優先度付けの一連の手順は終了となり、図３のステップＳ１１に進む。
【００５８】
次に、ステップＳ１０２において、不具合優先度付け装置１４は、削除された警告と同一種類の警告に対する優先度を上げるべき旨の情報を修正優先度決定装置１５に与えて、不具合情報にもとづく修正優先度付けの一連の手順は終了となり、図３のステップＳ１１に進む。
【００５９】
図７は、図４に示したソースコードの警告について、不具合情報にもとづく優先度付けを行った結果を示す説明図である。図４に示したように、Ｖｅｒ３に対し不具合ＩＤが関連付けられて構成管理ＤＢ１１ａに記憶されているため、Ｖｅｒ２からＶｅｒ３への変更（修正）は、不具合ＩＤ１の不具合に対応するための変更であることがわかる。また、ModuleＡからは、この変更（修正）によって警告Ｗｂ−２が削除されている。このため、警告Ｗｂ−２は、実際に不具合に結びつく重要な警告であるといえる。
【００６０】
したがって、図４に示したソースコードの場合、不具合優先度付け装置１４は、Ｗｂ−２と同一種類の警告に対する優先度を、つまりＷｂ−４、Ｗｂ−５およびＷｂ−６に対する優先度を、上げるべき旨の情報を修正優先度決定装置１５に与える。
【００６１】
この不具合情報にもとづく修正優先度付けの手順により、実際の不具合と静的解析による警告を容易に結びつけることができ、不具合情報にもとづいて、修正優先度付けを行うことができる。この結果、不具合に結びつく警告に対して高い優先度が与えられることになる。
【００６２】
次に、ステップＳ１１において、修正優先度決定装置１５は、変更履歴優先度付け装置１３および不具合優先度付け装置１４から受けた優先度の情報にもとづき、総合的にどの警告から修正すべきかの優先度を決定し、この総合的な修正優先度を修正優先度ＤＢ１６に記憶させる。
【００６３】
図８は、図４に示したソースコードに対して、不具合情報にもとづく優先度付け結果が優先されるように総合的な修正優先度付けを行った結果を示す説明図である。
【００６４】
不具合情報にもとづく修正優先度が高い警告から低い警告の順に、変更履歴にもとづく修正優先度を参照して、総合的な修正優先度を決定することにより、不具合情報にもとづく修正優先度付け結果を、変更履歴にもとづく修正優先度付け結果より優先することができる。
【００６５】
図８に示す例では、修正優先度決定装置１５は、まず、不具合情報にもとづく修正優先度が高いもの、つまり警告種類Ｗｂの警告Ｗｂ−１、Ｗｂ−４、Ｗｂ−５およびＷｂ−６について、変更履歴にもとづく修正優先度を参照して、総合的な修正優先度を決定する。次に、警告種類Ｗａの警告について、同様に総合的な修正優先度を決定する。
【００６６】
次に、ステップＳ１２において、表示装置３２は、修正優先度決定装置１５から総合的な修正優先度付けを行った旨の情報を受け、修正優先度ＤＢ１６から修正優先度付けされた警告のリストを取得し、ユーザに提示する。
【００６７】
以上の手順により、ソースコードに対する静的解析により検出された警告に対し、どの警告に対応する修正から行うべきかの優先度付けを行うことができる。
【００６８】
図１に示したソースコード修正優先度付けシステム１０は、ソースコードに対する静的解析により検出された警告に対し、不具合情報にもとづいてどの警告に対応する修正から行うべきかの優先度付けを行う。このため、静的解析によって得られる警告と実際の不具合との関わりに応じた修正優先度を自動的にユーザに提示することができる。したがって、このソースコード修正優先度付けシステム１０によれば、ユーザは、不具合に結びつく警告を容易に絞り込んで修正することができるため、非常に効率がよい。
【００６９】
また、このソースコード修正優先度付けシステム１０は、ソースコードに対する静的解析により検出された警告に対し、ソースコードのモジュールごとの変更履歴にもとづいてどの警告に対応する修正から行うべきかの優先度付けを行う。このため、モジュールごとの変更回数（変更頻度）および変更時期に応じた修正優先度を自動的にユーザに提示することができる。一般に、変更回数が多く、変更時期の新しいモジュールは、ソースコード全体にとって、不具合を起こす可能性が高い危険なモジュールである場合が少なくない。したがって、このソースコード修正優先度付けシステム１０によれば、ユーザは、より不具合を起こす可能性が高いモジュールから修正に取りかかることによって警告の絞込みを行うことができ、非常に効率がよい。
【００７０】
一般的な不具合管理では、警告箇所はソースコード内の位置で示されるが、不具合箇所や不具合の修正箇所は、ソースコード内の位置ではなく、ソースコードの機能の分類で記述されることが多い。このため、不具合箇所や不具合の修正箇所のソースコード内での位置は、大まかにしか把握できず、静的解析の警告と不具合を関連付けて絞りこみを行うことが困難であった。
【００７１】
しかし、このソースコード修正優先度付けシステム１０は、不具合ＩＤと、この不具合ＩＤと関連付けられたソースコードの削除警告とを対応させる。このため、削除警告の位置から、不具合の修正箇所のソースコード内の位置を知ることができる。また、ソースコード修正優先度付けシステム１０は、不具合に結びつく警告種類を特定する。したがって、このソースコード修正優先度付けシステム１０によれば、この不具合に結びつく（不具合関連の）警告種類と同一種類の警告のソースコード内の位置から、修正すべき不具合関連の警告の位置を容易に知ることができる。
【００７２】
なお、本実施形態では、総合的な修正優先度付けを行う手順では、不具合情報にもとづく優先度付け結果が優先されるような手順を示したが（図８参照）、この手順は、変更履歴にもとづく優先度付け結果が優先されるような手順であってもかまわない。修正優先度決定装置１５は、いずれの手順にも対応できるように構成する。
【００７３】
また、新たなソースコードの開発を行うにあたり、過去にこのソースコードと同一または類似のソースコードに対してソースコード修正優先度付けシステム１０を適用していた場合は、この適用の結果得た総合的な修正優先度を新たなソースコードのデフォルトの修正優先度として利用してもよい。この場合、ユーザは、新たなソースコードの初回記憶時から警告の絞込みを行うことができる。
【００７４】
なお、本発明は上述した実施形態に限定されず、当業者に自明な種々の改変が可能である。たとえば、上述したソースコード修正優先度付けシステム１０における構成の一部または全部を、コンピュータによりプログラムを実行させて機能させることもできる。
【図面の簡単な説明】
【００７５】
【図１】本発明に係るソースコード修正優先度付けシステムの一実施形態を示す概略的な全体構成図。
【図２】図１に示すソースコード修正優先度付けシステムにより、ソースコードに対する静的解析により検出された警告に対し、どの警告に対応する修正から行うべきかの優先度付けを行う際の手順を示すフローチャート。
【図３】図２のステップＳ８で変更履歴優先度付け装置により実行される、変更履歴にもとづく修正優先度付けの際の手順を示す、サブルーチンフローチャート。
【図４】警告に対応して行われるソースコードの修正の様子を概念的に示す説明図。
【図５】（ａ）は図４に示したソースコードに対して変更回数にもとづく修正優先度付けを行った結果を示す説明図、（ｂ）は図４に示したソースコードに対して変更履歴（変更回数および変更時期）にもとづく修正優先度付けを行った結果を示す説明図。
【図６】図２のステップＳ１０で不具合優先度付け装置により実行される、不具合情報にもとづく修正優先度付けの際の手順を示す、サブルーチンフローチャート。
【図７】図４に示したソースコードの警告について、不具合情報にもとづく優先度付けを行った結果を示す説明図。
【図８】図４に示したソースコードに対して、不具合情報にもとづく優先度付け結果が優先されるように総合的な修正優先度付けを行った結果を示す説明図。
【符号の説明】
【００７６】
１０  ソースコード修正優先度付けシステム
１１  構成管理部
１１ａ  構成管理ＤＢ
１１ｂ  監視装置
１１ｃ  差分生成装置
１２  不具合管理ＤＢ
１３  変更履歴優先度付け装置
１４  不具合優先度付け装置
１５  修正優先度決定装置
１６  修正優先度ＤＢ
２１  静的解析装置
２２  静的解析結果ＤＢ
３１  入力装置
３２  表示装置
【図１】
2008021244.tif 000003
【図２】
2008021244.tif 000004
【図３】
2008021244.tif 000005
【図４】
2008021244.tif 000006
【図５】
2008021244.tif 000007
【図６】
2008021244.tif 000008
【図７】
2008021244.tif 000009
【図８】
2008021244.tif 000010