(57)【要約】      （修正有）【課題】システム開発の試験工程において、安定的に複数の試験をパラレルに実行させる。【解決手段】マスタＤＢを備える製造・単体試験用ソース管理ＤＢサーバ３０４のマスタＤＢ内の第１のソースプログラムの更新に伴う同期指示に応答して、更新された第１のソースプログラムをソース処理サーバ１０１が、結合試験用ソース管理ＤＢサーバ３０７あるいは総合試験用ソース管理ＤＢサーバ３１０に第１のソースプログラムと同じファイルパスを用いてコピーする。【選択図】図１
2016134021.tif 000002
【特許請求の範囲】
【請求項１】
単体試験用の第１のソースプログラムを格納するマスタDBを備える第１のソース管理DBサーバ、前記単体試験用以外の他の試験用の、前記第１のソースプログラムと同じファイルパスを持つ第２のソースプログラムを格納するソース管理DBを備える第２のソース管理DBサーバ、及び前記第１のソースプログラムの更新に伴う同期指示に応答して、更新された前記第１のソースプログラムを、前記第２のソースプログラムの前記ファイルパスを用いて、前記ソース管理DBにコピーするソース処理サーバを有することを特徴とするソース管理システム。
【請求項２】
前記ソース処理サーバは、前記マスタDBに格納されている前記第１のソースプログラムと前記ソース管理DBに格納されている前記第２のソースプログラムとの差分の有無をチェックし、差分がある場合はメッセージを出力することを特徴とする請求項１記載のソース管理システム。
【請求項３】
前記マスタDBは、前記第１のソースプログラムの開発者及び管理者が更新権限を有し、前記ソース管理DBは、前記開発者は更新権限を有せず、前記管理者が更新権限を有することを特徴とする請求項２記載のソース管理システム。
【請求項４】
ソースプログラムを管理するソース管理システムにおける管理方法であって、
第１のソース管理DBサーバが、単体試験用の第１のソースプログラムを格納するマスタDBを備え、
第２のソース管理DBサーバが、前記単体試験用以外の他の試験用の、前記第１のソースプログラムと同じファイルパスを持つ第２のソースプログラムを格納するソース管理DBを備え、
ソース処理サーバが、前記第１のソースプログラムの更新に伴う同期指示に応答して、更新された前記第１のソースプログラムを、前記第２のソースプログラムの前記ファイルパスを用いて、前記ソース管理DBにコピーすることを特徴とするソース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウォーターフォールモデルの試験工程において、ソースプログラムを管理するソース管理システムに関するものである。
【背景技術】
【０００２】
システム開発では、ウォーターフォールモデルを採用した場合、ソースプログラムを一元管理するのは一般的である。しかし、製造完了し、試験工程に入ってから、開発スケジュールの圧迫により、パラレルに複数の試験工程を並列かつ同時に実施する場合、ソースプログラムを一元管理すると、パラレルに異なる試験工程を同時に進めることは困難である。
【０００３】
特許文献１は、ソースプログラムのバージョンの食い違いやソースプログラムの破壊を効果的に防ぎ、かつ、大規模アプリケーション開発におけるリポジトリ検索時のトラフィック負荷の分散を実現する複数サーバ間のソースプログラム一元管理システムについて記載している。ソースプログラムのマスタサーバ、マスタサーバとミラーリングするサーバを複数用意し、定期的にデータ同期することで、ソースプログラムの一元管理を実現している。また、マスタサーバとミラーリングサーバをそれぞれアクセスすることで、マスタサーバにアクセス負荷が集中せず、トラフィック負荷の分散も実現している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−７８１５７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一般的にウォーターフォールモデルに従い、製造後の試験工程を単体試験（個々のプログラムの試験）、結合試験（データの送受や、起動・停止などの制御などにより関連する複数プログラムの試験）、総合試験（システムを構成するすべてのプログラムの試験）と分け、これらの試験をパラレルに実行すると、特許文献１のソース一元管理方法を採用すると、次のような場合に対応できない。
【０００６】
まず、プログラムバグの修正は進行中の他の試験工程を中断させ、中断した試験のやり直しにより、試験工程を遅延させることがある。たとえば、結合試験中に発生したバグを修正すると、ソースを一元管理しているため、他の試験もバグの修正の影響を受け、試験を止めなければならない。これにより、安定的に試験の実施ができず、試験遅延につながる事態となる。
【０００７】
また、同じプログラムを対象とした複数の試験工程中に異なるバグが起きた場合、ソース修正競合が発生し、ソースを修正できないことがある。たとえば単体試験のバグ修正でＡ処理を修正する必要があるが、結合試験で同じソースに対するバグ修正でＡ処理を無くす（削除する）必要がある。この場合、ソース修正の調整が必要となり、長時間試験が止まる事態となる。
【０００８】
以上の状況に鑑み、システム開発の試験工程において、全体の開発期間を短縮するため、安定的に複数の試験をパラレルに実行できるソース管理システムが必要である。
【課題を解決するための手段】
【０００９】
開示するソース管理システムは、単体試験用の第１のソースプログラムを格納するマスタDBを備える第１のソース管理DBサーバ、単体試験用以外の他の試験用の、第１のソースプログラムと同じファイルパスを持つ第２のソースプログラムを格納するソース管理DBを備える第２のソース管理DBサーバ、及び第１のソースプログラムの更新に伴う同期指示に応答して、更新された第１のソースプログラムを、第２のソースプログラムのファイルパスを用いて、ソース管理DBにコピーするソース処理サーバを有する。
【発明の効果】
【００１０】
開示するソース管理システムによれば、システム開発の試験工程において、安定的に複数の試験をパラレルに実行できる。
【図面の簡単な説明】
【００１１】
【図１】ソース管理システムの構成例である。
【図２】ソース管理DBの初期構築処理のフローチャートである。
【図３】ソース同期指示受付処理部のフローチャートである。
【図４】ソース同期処理のフローチャートである。
【図５】ソース管理DB間差分チェック処理のフローチャートである。
【図６】ソース管理DBの構成例である。
【図７】ソース同期リストの例である。
【発明を実施するための形態】
【００１２】
図１は、ソースプログラム（以下、単にソースまたはソースファイルと呼ぶことがある。）を管理するソース管理システムの構成例である。ソース管理システムは、試験工程に対応させた試験実施環境(３０１、３０２、３０３)とソース処理サーバ１０１を含んでいる。ここでは、試験工程を、単体試験、結合試験、および総合試験と定義し、それぞれの試験に対応して試験実施環境を有している。試験工程の定義は、システム開発の規模等に応じて任意に定められる。
【００１３】
ソース管理システムは各試験実施環境に、ソース管理DBサーバ(３０４、３０７、３１０)、ビルドサーバ(３０５、３０８、３１１)および試験サーバ(３０６、３０９、３１２)を有し、これらのサーバを、試験を実施する環境とする。製造・単体試験用ソース管理DBサーバ３０４は、全開発者に更新権限を付与したソースファイルを格納するマスタDBを管理するDBサーバである。マスタDB以外のソース管理DBサーバ３０７、３１０は、管理者に更新権限を付与した、ソースファイルを格納するマスタDBを管理するDBサーバであり、ソース処理サーバ１０１を通して処理を実行する。以下、ソース管理DBサーバ３０４を、マスタDBまたはマスタDBサーバと呼び、ソース管理DBサーバ３０７、３１０を、マスタDB以外のソース管理DBまたはマスタDB以外のソース管理DBサーバと呼ぶ。
【００１４】
マスタDB３０４は、ウォーターフォールモデルにおける製造が完了したタイミングで、マスタDB３０４の内容（ソースファイル）をコピーし、マスタDB以外のソース管理DB３０７、３１０を作成する。これを初期構築処理と呼ぶ。初期構築処理以降、マスタDBサーバ３０４では、追加仕様変更に対応するための製造と単体試験や、各試験工程で発生したバグを修正し、単体試験を実行する。マスタDB以外のソース管理DBサーバ３０７、３１０は、基本的にバグ修正を実行せずに、自らの試験のための試験用資材（試験用プログラム、ステトデータ、など）を作成し、パラレルに試験を実行する。
【００１５】
マスタDB以外のソース管理DBサーバ３０７、３１０は、他の試験工程のバグ修正と競合した場合に、自らの試験を続行するためのバグ修正を許可する。この場合、バグ修正は管理者が行い、後日、調整後、調整したバグの修正をマスタDB３０４に反映する。
【００１６】
各試験工程でバグが発生した場合、バグ票（バグの内容、バグがあるときの試験結果、修正すべき内容などを含む）を発行し、バグの修正はマスタDBサーバ３０４で実行する。バグ修正が完了し、単体試験が完了したら、ソース同期指示を発行し、バグを修正したソースファイルをマスタDB以外のソース管理DB３０７、３１０にコピーする。ソース同期とは、ソースをデータとみなしたデータ同期であり、実行後に各ソース管理DB３０４、３０７、３１０は格納するソースの内容が一致する。そして、各試験工程で試験用資材を再作成し、各試験工程で再試験を実行する。再試験で問題なければ（バグの修正内容の正しいことの確認、新たなバグがないことの確認など）、バグ票をクローズする。同じように、マスタDBサーバ３０４は、追加仕様変更に対応するソースの製造と単体試験が完了したら、ソース同期指示を発行し、ソースファイルをマスタDB以外のソース管理DB３０７、３１０にコピーし、パラレルに各試験を実行する。
【００１７】
ソース処理サーバ１０１は、ソース管理DB３０４、３０７、３１０の初期構築処理部２０１、ソース同期指示受付部２０２、ソース同期処理部２０３、ソース管理DB間の差分チェック処理部２０４を持つサーバである。
【００１８】
なお、図１のシステム構成において、ソース処理サーバ１０１、ソース管理DBサーバ(３０４、３０７、３１０)、ビルドサーバ(３０５、３０８、３１１)、および試験サーバ(３０６、３０９、３１２)は、それぞれメモリ、ハードディスク、CPU、入出力装置、システムバスなどを有するコンピュータである。
【００１９】
図２は、ソース管理DBの初期構築処理２０１のフローチャートである。初期構築処理２０１は、ウォーターフォールモデルにおける製造工程が完了し、試験工程に入る直前のタイミングで実行される。
【００２０】
ソースファイルをマスタDB３０４にコピーし、マスタDB３０４を作成する（ステップ４０１）。製造工程が完了したタイミングで、作成されたソースファイルを格納する、製造工程のマスタDBをコピー元であり、マスタDB３０４がコピー先である。
【００２１】
マスタDB３０４をコピーし、初期化対象ソース管理DBを作成する（ステップ４０２）。ここでは、ソース管理DB３０７、３１０をコピー先とするので、これらに関してステップ４０２を繰り返す。
【００２２】
ソース管理DBの初期構築処理より、マスタDB３０４とマスタDB以外のソース管理DB３０７、３１０は、同じソースを格納し、各ソース管理DB間で差分がなくなる。
【００２３】
図３は、ソース同期指示受付処理部２０２のフローチャートである。ソース同期指示受付処理部２０２の処理は、マスタDB３０４のバグ修正が完了し、単体試験が終了したタイミングおよび追加の仕様変更対応の製造と単体試験が終了したタイミングに実行される。追加の仕様変更対応やバグ対応はマスタDBサーバ３０４で実行されるので、マスタDB３０４に格納されているソースファイルは新しくなっていく。しかし、マスタDB以外のソース管理DB３０７，３１０では、基本的にソースファイルを更新しないので、マスタDB３０４と差分が発生する。開発者がマスタDB３０４で更新、追加、削除したソースファイルをソース同期指示に含み、ソース同期指示に基づいて、更新、追加、削除されたソースをマスタDB以外のソース管理DB３０７，３１０にコピーすることで、マスタDB３０４とマスタDB以外のソース管理D３０７，３１０B間の同期をとる。
【００２４】
ソース同期指示受付処理部２０２は、開発者からのソース同期指示を入力する。ソース同期指示は、マスタDB３０４で製造と単体試験が完了したタイミングで、１つのバグまたは１つの仕様変更単位で入力される（ステップ５０１）。したがって、図３のソース同期指示受付処理部２０２は、ソース同期指示が入力される毎に実行される。ソース同期指示受付処理部２０２は、ソース同期指示に含まれるソースファイルの所在を表すパス（ファイルパス）を参照して、マスタDB３０４にソースが存在するかを判定する（ステップ５０２）。マスタDB３０４にソースが存在しないパスの指定はエラーであり、ソース同期指示受付処理部２０２は、開発者に指示を修正させ（ステップ５０３）、ステップ５０１へ戻る。
【００２５】
ソース同期指示受付処理部２０２は、マスタDB３０４とマスタDB以外のソース管理DB３０７，３１０との指定されたパスのソースファイルの差分をチェックする（ステップ５０４）。差分がない場合、ソース同期指示は誤りであり、ソース同期指示受付処理部２０２は、エラーメッセージをメール等により開発者に向けて送信して（ステップ５０５）、処理を終了する。差分がある場合、ソース同期指示受付処理部２０２は、ソース同期指示をソース同期処理部２０３へ出力して（ステップ５０６）、処理を終了する。
【００２６】
図４は、ソース同期処理のフローチャートである。ソース同期指示を受付後に、マスタDB３０４とマスタDB以外のソース管理DB３０７、３１０の同期化処理を実行する。この処理によって、マスタD３０４BとマスタDB以外のソース管理DB３０７、３１０の差分がなくなる。
【００２７】
ソース同期指示からソース同期リスト（後述）を作成する（ステップ６０１）。
【００２８】
マスタDB３０４以外のソース管理DB３０７、３１０の数分（ここでは、２）のループ処理（ループ１）を実行する（ステップ６０２、ステップ６０６）。
【００２９】
ソース同期リストの行数（ソース同期指示の数）分のループ処理（ループ２）を実行する（ステップ６０３、ステップ６０５）。
【００３０】
同期元のマスタDB３０４からソース同期リストに記載のソースファイルを、ソース同期リストに記載のファイルパスを参照して、同期先のソース管理DBにコピーする。ここでは、１ループ目の処理でソース管理DB３０７にコピーし、２ループ目の処理でソース管理DB３１０にコピーする（ステップ６０４）。
【００３１】
ソース同期処理完了後、それぞれのソース管理DBが更新されるので、それぞれの試験実施環境でビルドサーバ３０５、３０８、３１１を通して、試験用資材を再作成し、試験サーバ３０６、３０９、３１２に資材再配置することで、それぞれの試験を再開する。
【００３２】
図５は、ソース管理DB間差分チェック処理のフローチャートである。ソース管理DB間の差分チェックは、マスタDB３０４とマスタDB以外のソース管理DB３０７，３１０との整合性を保つために、定期的に実行される。
【００３３】
マスタDB３０４以外のソース管理DB３０７、３１０の数分（ここでは、２）のループ処理（ループ１）を実行する（ステップ７０１、ステップ７０７）。
【００３４】
マスタDB３０４に格納されているソースファイルの数分のループ処理（ループ２）を実行する（ステップ７０２、ステップ７０６）。
【００３５】
マスタDB３０４に格納されているソースファイルとマスタDB以外のソース管理DB３０７，３１０に格納されているソースファイルとを比較する（ステップ７０３）。比較する２つのソースファイルは、同じファイルパスを持つ。
【００３６】
比較結果に差分が存在するかどうかを判定する（ステップ７０４）。差分が存在する場合は、ステップ７０５に移り、差分が存在しない場合は、ステップ７０６に移る。差分が存在する場合は、差分が存在するソースファイルを特定したメッセージを出力する（ステップ７０５）。メッセージは、開発者により確認され、対応される。
【００３７】
定期的にソース管理DB間の差分チェックを行うことで、ソース管理DB間の整合性をチェックし、ソース同期指示漏れなどの、試験に影響を与えるケースを検知し、安定的な試験の実行を保証する。
【００３８】
図６は、ソース管理DB３０４の構成例である。ソース管理DB３０４は、ソースファイル単位にファイル名９０２、ファイルパス９０３、ソースのバージョン番号９０４、作成者９０５、更新日付９０６などの情報を保持している。
【００３９】
図７は、ソース同期指示から作成するソース同期リストの例である。ソース同期リストにはファイル単位に、ファイル名１２０１、ファイルパス１２０２、修正区分１２０３、備考１２０４の項目を含む。
【００４０】
以上の説明では、ウォーターフォール開発モデルの試験工程において、複数の試験をパラレルに実行させるためのソース管理システムの一例を説明したが、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、システムの開発規模に合わせて、試験工程の定義が異なる場合、試験工程の単位に合わせて、ソース管理DBを設置すること、複数の試験をパラレルに実行できる。
【符号の説明】
【００４１】
１０１：ソース処理サーバ、２０１：初期構築処理部、２０２：ソース同期指示受付部、２０３：ソース同期処理部、２０４：差分チェック処理部、３０１：単体試験実施環境、３０２：結合試験実施環境、３０３：総合試験実施環境、３０４：製造・単体試験用ソース管理DBサーバ（マスタDB）、３０５：単体試験用ビルドサーバ、３０６：単体試験用試験サーバ、３０７：結合試験用ソース管理DBサーバ、３０８：結合試験用ビルドサーバ、３０９：結合試験用試験サーバ、３１０：総合試験用ソース管理DBサーバ、３１１：総合試験用ビルドサーバ、３１２：総合試験用試験サーバ。
【図１】
2016134021.tif 000003
【図２】
2016134021.tif 000004
【図３】
2016134021.tif 000005
【図４】
2016134021.tif 000006
【図５】
2016134021.tif 000007
【図６】
2016134021.tif 000008
【図７】
2016134021.tif 000009