特許 5965264 プログラム開発統合管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5965264

(24)【登録日】2016年7月8日

(45)【発行日】2016年8月3日

(54)【発明の名称】プログラム開発統合管理システム

(51)【国際特許分類】

   G06F 9/44 20060101AFI20160721BHJP

   G06F 9/445 20060101ALI20160721BHJP

【ＦＩ】

   G06F9/06 620K

   G06F9/06 610Q

【請求項の数】6

【全頁数】16

(21)【出願番号】特願2012-208060(P2012-208060)

(22)【出願日】2012年9月21日

(65)【公開番号】特開2014-63352(P2014-63352A)

(43)【公開日】2014年4月10日

【審査請求日】2015年8月5日

(73)【特許権者】

【識別番号】000155469

【氏名又は名称】株式会社野村総合研究所

(74)【代理人】

【識別番号】100080001

【弁理士】

【氏名又は名称】筒井 大和

(74)【代理人】

【識別番号】100093023

【弁理士】

【氏名又は名称】小塚 善高

(74)【代理人】

【識別番号】100117008

【弁理士】

【氏名又は名称】筒井 章子

(72)【発明者】

【氏名】木闇 憲一

(72)【発明者】

【氏名】佐藤 信夫

(72)【発明者】

【氏名】並河 英二

(72)【発明者】

【氏名】白石 祐

【審査官】 衣川 裕史

(56)【参考文献】

【文献】 特開２００８−２２５７６２（ＪＰ，Ａ）

【文献】 特開２００９−０９８９６３（ＪＰ，Ａ）

【文献】 特開２００１−２１６２８０（ＪＰ，Ａ）

【文献】 特開２００８−１５２４７５（ＪＰ，Ａ）

【文献】 特開平０５−１７３８６６（ＪＰ，Ａ）

【文献】 特開２００６−３０２０６６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４４

Ｇ０６Ｆ ９／４４５

(57)【特許請求の範囲】

【請求項1】

複数種類のシステム環境からなる本番環境に対してリリースする実行モジュールを、対応するシステム環境を有する開発環境においてそれぞれ作成するプログラム開発において、ソースコードもしくは関連ファイルもしくは生成された前記実行モジュールである管理物件についてのライブラリ管理と、前記本番環境に対する前記実行モジュールのリリース管理とを行うプログラム開発統合管理システムであって、
前記各管理物件を管理するライブラリにおいて、前記各管理物件についての適用対象のシステム環境、所在場所のサーバ種別、所在場所のパス、および前記管理物件のファイル名の各情報を含む管理物件特定情報を保持する管理テーブルと、
前記管理テーブルの前記管理物件特定情報の内容に基づいて、前記ライブラリから同一の前記ソースコードを適用対象の前記各開発環境に対してチェックアウトし、前記開発環境において前記ソースコードから生成された前記実行モジュールを、システム環境毎に前記ライブラリにそれぞれチェックインして前記管理テーブルを更新するモジュール管理部と、
前記各開発環境において生成された前記実行モジュールを、対応するシステム環境を有する前記本番環境にそれぞれリリースする本番リリース部とを有することを特徴とするプログラム開発統合管理システム。

【請求項2】

請求項１に記載のプログラム開発統合管理システムにおいて、
前記管理テーブルは、さらに、前記各管理物件についての配布先のシステム環境、前記配布先のシステム環境における運用環境の種類、および前記配布先のシステム環境におけるサーバの種類の各情報を含む配布関連情報を保持し、
前記管理テーブルの前記配布関連情報の内容に基づいて、前記モジュール管理部は前記管理物件を対応する前記開発環境に配布し、前記本番リリース部は前記管理物件を対応する前記本番環境に配布することを特徴とするプログラム開発統合管理システム。

【請求項3】

請求項１または２に記載のプログラム開発統合管理システムにおいて、
さらに、プログラム開発の案件をテーマとして登録し、前記テーマに関連する前記管理物件と作業可能な開発者を含む情報を登録し、前記開発者が前記管理物件にアクセスしようとする際に、前記管理物件が対象の前記テーマに含まれるか否か、および前記開発者が前記テーマにおいて作業可能であるか否かによってアクセスの可否を判断するアクセス制御を行うテーマ管理部を有することを特徴とするプログラム開発統合管理システム。

【請求項4】

請求項１〜３のいずれか１項に記載のプログラム開発統合管理システムにおいて、
さらに、前記各本番環境に対する前記実行モジュールのリリースの可否についての承認情報、リリース先のシステム環境と運用環境、およびリリース日を含む情報を受け付けるリリース承認プロセスを実行する工程管理部を有し、
前記本番リリース部は、前記工程管理部による前記リリース承認プロセスによってリリース可能とされた前記実行モジュールについてのみ前記本番環境にリリースすることを特徴とするプログラム開発統合管理システム。

【請求項5】

請求項１〜４のいずれか１項に記載のプログラム開発統合管理システムにおいて、
さらに、前記各本番環境に対応するシステム環境をそれぞれ有する複数種類のテスト環境に対して、対応するシステム環境を有する前記開発環境において生成された前記実行モジュールをそれぞれ配布するテスト環境配布部を有することを特徴とするプログラム開発統合管理システム。

【請求項6】

請求項１〜５のいずれか１項に記載のプログラム開発統合管理システムにおいて、
さらに、前記モジュール管理部と、前記各開発環境においてユーザが使用するユーザ端末の双方がアクセス可能であり、システム環境の種類毎に設けられた第１の記憶領域、および各システム環境で共通に設けられた第２の記憶領域を有する記憶装置を有し、
前記モジュール管理部は、前記管理物件を前記各開発環境に対してチェックアウトする際に、前記ソースコードを含む、各システム環境において共通に適用する前記管理物件については、前記記憶装置上の前記第２の記憶領域に複写し、各システム環境に固有に適用する前記管理物件については、前記記憶装置上における対応するシステム環境についての前記第１の記憶領域にそれぞれ複写し、
前記ユーザ端末に対して、前記記憶装置上における対応するシステム環境についての前記第１の記憶領域、および前記第２の記憶領域をそれぞれマウントし、マウントされた記憶領域上に所在する前記各管理物件をユーザにより参照可能とすることを特徴とするプログラム開発統合管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アプリケーションプログラムの開発におけるソースコードやモジュールなどの管理技術に関し、特に、複数種類のシステム環境におけるライブラリやリリースの管理を行うプログラム開発統合管理システムに適用して有効な技術に関するものである。

【背景技術】

【0002】

情報処理システムやアプリケーションプログラムなどのソフトウェア開発、特に大規模なソフトウェア開発では、ソースコードやモジュールの数、開発者の人数なども多数となり、管理負荷が大きくなることから、ソースコードやモジュールについてのバージョン管理などを含むいわゆるライブラリ管理や、本番環境へのリリース管理などを情報処理システムとして支援する仕組みが検討され、提案されている。

【0003】

ライブラリ管理に関する技術としては、各ベンダーが提供している製品等の他に、例えば、特開平１１−１１０１９５号公報（特許文献１）には、登録依頼コマンドによるソースファイルのチェックイン要求に対しては、責任者に整合性の認証を依頼し、ソースファイル参照要求コマンドによる認証要求に対しては、認証コマンドにより責任者により他のソースファイルとの整合性が認証された最新版数のソースファイル群より渡すよう制御する版数管理システムが記載されている。これにより、各開発者が個別にソースファイルをチェックインした後に変更が生じた場合のソースファイル間の不一致による障害を回避することができる。

【0004】

また、リリース管理に関する技術としては、例えば、特開２００９−２４４９７４号公報（特許文献２）には、開発すべきプログラムとリリース条件とを開発テーマごとに管理するテーマ別プログラムテーブルと、テーマ別プログラムテーブルを参照し、リリース条件が同一のプログラムをひとつのリリース単位として抽出し、リリース単位のディレクトリをリリース記憶領域に生成し、抽出したリリース単位のプログラムを当該ディレクトリに格納するディレクトリ生成部を有するプログラム開発管理装置が記載されている。これにより、リリース条件別にプログラムを管理することができ、リリース対象となるプログラムのうちのいくつかをリリースし忘れたり、リリース対象となるプログラムとリリース対象でないプログラムとを取り違えてリリースしたりといったことを防止することができる。

【0005】

また、例えば、特開２０１１−５９８４７号公報（特許文献３）には、開発側領域および本番側領域に区画された記憶装置と制御部を備えたネットワーク接続ストレージと、開発者端末と、承認者端末と、ライブラリアン端末と、リリース端末と、本番機と、転送サーバと、リリースサーバとを備えたリリース管理システムが記載されている。ここでは、転送サーバは、ライブラリアン端末からのコマンド入力に基づいて、開発側領域に格納された特定のプログラムを本番側領域に転送させるコマンドを制御部に発行し、リリースサーバは、リリース端末からのコマンド入力に基づいて、本番側領域に格納されたプログラムを取得するコマンドを制御部に発行し、取得したプログラムを本番機に転送する。これにより、最終的なリリース操作を開発者に委ねつつも、悪意の開発者による不正リリースを有効に防止することができる。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開平１１−１１０１９５号公報

【特許文献2】特開２００９−２４４９７４号公報

【特許文献3】特開２０１１−５９８４７号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

近年、企業等では、情報処理システムの構築や運用における効率化やコスト削減、また、顧客の利便性などの観点から、情報処理システムにより提供する業務処理を業界内等で標準化することなどが検討される場合がある。このような状況では、例えば、企業等が情報処理システムをそれぞれ独自に開発・運用するという形態から、業界内の同種の複数の企業等が、共同や相乗り等によって同一もしくは同様の情報処理システムやアプリケーションプログラムを開発・運用等する、もしくはＩＴベンダー等がこのようなシステムやアプリケーションを開発してサービスとして提供するなどにより、軽微なカスタマイズ等のみで、標準化された業務処理を提供するという形態がとられる場合がある。

【0008】

このような形態の情報処理システムやアプリケーションプログラムを構築するには、例えば、ソースコードを一本化して、当該ソースコードから生成された同一のモジュールを各企業独自の環境にそれぞれリリースして実行するという手法が考えられる。しかしながら、この場合は各企業独自のシステム環境がそれぞれＯＳ（Operating System）やミドルウェアなどのプラットフォームのレベルで同一もしくは互換性を有することが前提となるところ、適用する企業（システム環境）の数が多くなるとこのような統一を図ることは困難となる。

【0009】

同一もしくは同様のプログラムにより情報処理システムやアプリケーションプログラムを構築する企業（システム環境）の数が多くなると、例えば、システム環境間でのハードウェアやソフトウェアのリプレースサイクルの相違などから、異なるバージョンのプラットフォームが混在する場合が生じ得る。これに対し、一本化されたソースコードを各システム環境（の開発環境）においてそれぞれ個別にビルドして実行モジュールを生成し、それぞれの本番環境にリリースするという構成をとることも可能である。

【0010】

このとき、ライブラリ管理上はソースコードとしては１つだが、これが異なる開発環境に対してそれぞれチェックアウトされ、各開発環境で個別にビルドされてモジュールが作成された後、それぞれチェックインされることになる。チェックインされた各モジュールは、同一のソースコードから生成されているためファイル名等の外観は同じだが、バイナリレベルでの内容は異なるものとなる。

【0011】

このように生成されたモジュールを、対応するシステム環境（テスト環境、本番環境）に適切に配布、リリースするよう管理するとともに、対応するシステム環境に属するユーザからのみアクセス可能となるようにアクセス制御を行う必要が生じるが、従来技術のライブラリ管理やリリース管理の仕組みは、このような環境における管理や制御を想定したものとはなっていない。また、開発時のソースコード等に対するライブラリ管理の仕組みと、開発案件の工程管理や生成されたモジュールのリリース管理等の仕組みとの間のシステム的な連携についても十分に考慮されたものとはなっていない。

【0012】

そこで本発明の目的は、同一のソースコードを複数のシステム環境において利用し、各システム環境において作成されたモジュールを当該ソースコードと合わせてライブラリにて管理するとともに、管理する各モジュールを対応するシステム環境に対して適切に配布もしくはリリースすることを可能とするプログラム開発統合管理システムを提供することにある。

【0013】

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

【課題を解決するための手段】

【0014】

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

【0015】

本発明の代表的な実施の形態によるプログラム開発統合管理システムは、複数種類のシステム環境からなる本番環境に対してリリースする実行モジュールを、対応するシステム環境を有する開発環境においてそれぞれ作成するプログラム開発において、ソースコードもしくは関連ファイルもしくは生成された前記実行モジュールである管理物件についてのライブラリ管理と、前記本番環境に対する前記実行モジュールのリリース管理とを行うプログラム開発統合管理システムであって、以下の特徴を有するものである。

【0016】

すなわち、プログラム開発統合管理システムは、前記各管理物件を管理するライブラリにおいて、前記各管理物件についての適用対象のシステム環境、所在場所のサーバ種別、所在場所のパス、および前記管理物件のファイル名の各情報を含む管理物件特定情報を保持する管理テーブルと、前記管理テーブルの前記管理物件特定情報の内容に基づいて、前記ライブラリから同一の前記ソースコードを適用対象の前記各開発環境に対してチェックアウトし、前記開発環境において前記ソースコードから生成された前記実行モジュールを、システム環境毎に前記ライブラリにそれぞれチェックインして前記管理テーブルを更新するモジュール管理部と、前記各開発環境において生成された前記実行モジュールを、対応するシステム環境を有する前記本番環境にそれぞれリリースする本番リリース部とを有することを特徴とするものである。

【発明の効果】

【0017】

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

【0018】

すなわち、本発明の代表的な実施の形態によれば、同一のソースコードを複数のシステム環境において利用し、各システム環境において作成されたモジュールを当該ソースコードと合わせてライブラリにて管理するとともに、管理する各モジュールを対応するシステム環境に対して適切に配布もしくはリリースすることが可能となる。

【図面の簡単な説明】

【0019】

【図1】本発明の一実施の形態であるプログラム開発統合管理システムの構成例について概要を示した図である。

【図2】本発明の一実施の形態における同一のソースコードから複数のシステム環境にそれぞれ対応したモジュールを作成する際の処理の例について概要を示した図である。

【図3】本発明の一実施の形態におけるライブラリにおいて管理情報を保持するテーブルのデータ構成の例について概要を示した図である。

【図4】本発明の一実施の形態における複数のシステム環境でのソースコード等の一本化の例について概要を示した図である。

【図5】本発明の一実施の形態における複数のシステム環境でのソースコード等の一本化の例について処理の概要を示した図である。

【図6】従来技術における複数のシステム環境にそれぞれ対応したモジュールを作成する際の処理の例について概要を示した図である。

【図7】従来技術における同一のソースコードから複数のシステム環境にそれぞれ対応したモジュールを作成する際の処理の例について概要を示した図である。

【発明を実施するための形態】

【0020】

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

【0021】

＜概要＞
例えば、ＩＴベンダー等が、複数の企業等に対して、同様の業務処理を提供するシステム環境を構築して提供する場合、各企業における要件や仕様の相違等に対応するため、従来は、個別にソースコードを作成して独立性を保つ構成をとるのが一般的であった。

【0022】

図６は、従来技術における複数のシステム環境にそれぞれ対応したモジュールを作成する際の処理の例について概要を示した図である。図６の例では、まず、ソースコードや実行モジュールなどを保持・管理するライブラリ１０から、対象のソースコード２１や図示しないＭａｋｅｆｉｌｅ等の関連ファイルを、対象の企業等の各開発環境２（図６の例では開発環境Ａ（２Ａ）〜Ｃ（２Ｃ））に対してそれぞれチェックアウトする（新規開発の場合は新規作成する）。

【0023】

各開発環境２では、ソースコード２１（図６の例ではソースコードＡ（２１Ａ）〜Ｃ（２１Ｃ））からＭａｋｅｆｉｌｅ等を利用して所定の手順によりコンパイルやリンク等の処理を行なって実行モジュール２２（図６の例では実行モジュールＡ（２２Ａ）〜Ｃ（２２Ｃ））をそれぞれ生成（ビルド）する。その後、単体テストや連結テスト等を行い、完了すると、更新後のソースコード２１や関連ファイル、実行モジュール２２などをライブラリ１０にそれぞれチェックインする（図示しない）。

【0024】

その後、複数の本番環境４（図６の例では本番環境Ａ（４Ａ）〜Ｃ（４Ｃ））にそれぞれ対応する、図示しないテスト環境において、対応する開発環境２で生成された実行モジュール２２を適用して総合テスト等を行った上で、対応する各本番環境４に対して実行モジュール２２をそれぞれリリースする。このような手法では、各システム環境における要件や仕様の相違等に対して個別に柔軟に対応することが可能であるものの、ソースコード２１を各システム環境に対応した形で複数種類保持する必要があり、同様の機能について複数種類のソースコード２１を保持・管理するためのメンテナンスコストや、開発の反映漏れ等に伴う障害誘発のリスクが大きくなってしまう。

【0025】

そこで、上述したように、例えば、開発・保守の効率化やコスト削減のため、また、業界内で標準化された業務処理を複数のシステム環境において提供するため、ソースコード２１を一本化し、そこから複数のシステム環境に対応した実行モジュール２２を生成して各システム環境にそれぞれリリースするという手法が考えられる。

【0026】

図７は、従来技術における同一のソースコードから複数のシステム環境にそれぞれ対応したモジュールを作成する際の処理の例について概要を示した図である。図７の例では、まず、ライブラリ１０から、対象のソースコード２１や図示しないＭａｋｅｆｉｌｅ等の関連ファイルを開発環境２に対してチェックアウトする（新規開発の場合は新規作成する）。開発環境２では、ソースコード２１からＭａｋｅｆｉｌｅ等を利用して所定の手順によりコンパイルやリンク等の処理を行なって実行モジュール２２を生成（ビルド）する。その後、単体テストや連結テスト等を行い、完了すると、更新後のソースコード２１や関連ファイル、実行モジュール２２などをライブラリ１０にチェックインする（図示しない）。

【0027】

その後、図６の例と同様に、複数の本番環境４（図７の例では本番環境Ａ（４Ａ）〜Ｃ（４Ｃ））にそれぞれ対応する、図示しないテスト環境において、開発環境２で生成された実行モジュール２２を適用して総合テスト等を行った上で、各本番環境４に対して実行モジュール２２をそれぞれリリースする。上述したように、このような手法では、同一の実行モジュール２２が各本番環境４にそれぞれコピーされたのと同様の状態となることから、各本番環境４のシステム環境が同一もしくは互換性を有することが前提となる。しかしながら、このようなシステム環境の統一を図ることは実際上困難である。

【0028】

そこで、本発明の一実施の形態であるプログラム開発統合管理システムでは、一本化された同一のソースコード２１を各システム環境に対応する開発環境２においてそれぞれ個別にビルドして実行モジュール２２を生成し、対応する本番環境４にそれぞれリリースするという構成をとる。

【0029】

図２は、本実施の形態における同一のソースコードから複数のシステム環境にそれぞれ対応したモジュールを作成する際の処理の例について概要を示した図である。図２の例では、まず、ライブラリ１０から、対象のソースコード２１や図示しないＭａｋｅｆｉｌｅ等の関連ファイル（各開発環境２によって内容が異なる場合があり得る）を各開発環境２（図２の例では開発環境Ａ（２Ａ）〜Ｃ（２Ｃ））に対してそれぞれチェックアウトする（新規開発の場合は新規作成する）。

【0030】

各開発環境２では、同一のソースコード２１からＭａｋｅｆｉｌｅ等を利用して所定の手順によりコンパイルやリンク等の処理を行なって実行モジュール２２（図２の例では実行モジュールＡ（２２Ａ）〜Ｃ（２２Ｃ））をそれぞれ生成（ビルド）する。ここでは、ソースコード２１としては同一だが、ＯＳ等のプラットフォームが異なる開発環境２Ａ〜２Ｃでそれぞれ個別にビルドした結果、生成された実行モジュール２２Ａ〜２２Ｂは、ファイル名等の外観は同じだが、バイナリレベルでの内容は異なるものが生成される。

【0031】

その後、単体テストや連結テスト等を行い、完了すると、更新後のソースコード２１や関連ファイル、実行モジュール２２などをライブラリ１０にそれぞれチェックインする。ライブラリ１０での管理上は、ソースコード２１はシステム環境に依存しない同一のものとして管理するが、実行モジュール２２はシステム環境毎に異なるものとして管理する。なお、異なるシステム環境間でソースコード２１を一本化するため、システム環境間で異なる処理を実現する必要がある場合には、例えば、ソースコード２１やＭａｋｅｆｉｌｅ等に記載するコードや命令において、実行時に自身が稼働するシステム環境を識別するための情報（例えば、環境変数等）を取得し、その内容に応じて処理内容を振り分けるようにコードや命令等を記載するというような手法をとることができる。

【0032】

このような構成により、同一のソースコード２１を複数のシステム環境に対して提供し、各システム環境においてそれぞれ当該システム環境に適合した実行モジュール２２を生成するとともに、生成された実行モジュール２２をソースコード２１と合わせてライブラリ１０にて管理することができる。

【0033】

＜システム構成＞
図１は、本発明の一実施の形態であるプログラム開発統合管理システムの構成例について概要を示した図である。プログラム開発統合管理システム１は、各企業等に対して標準化された業務処理を提供するためのアプリケーションプログラムの開発や保守を支援するシステムであり、例えば、ＰＣ（Personal Computer）やサーバ機器などの情報処理装置により構成され、社内ＬＡＮ（Local Area Network）等の閉じたネットワーク７を介して、ライブラリ１０の管理を行うライブラリアンが使用する情報処理装置であるライブラリアン端末５や、開発者等が使用する情報処理装置であるユーザ端末６が接続される構成を有する。

【0034】

また、図示しない個別のネットワークや中継サーバ等を介して、開発環境２、テスト環境３、および本番環境４においてそれぞれ実行モジュール２２を展開するサーバ等の機器に接続することが可能である。なお、これらの各環境は、上述したように、使用する企業等のシステム環境に応じてそれぞれ複数種類のものが存在し得る。

【0035】

プログラム開発統合管理システム１は、例えば、ソフトウェアにより実装されたユーザ管理部１１、テーマ管理部１２、工程管理部１３、運用管理部１４、ユーザインタフェース部１５、リポジトリ管理部１６、モジュール管理部１７、テスト環境配布部１８、および本番リリース部１９などの各部を有する。また、ソースコード２１や関連ファイル、実行モジュール２２などを保持・管理するデータベースやファイル等からなるリポジトリとしてのライブラリ１０を有する。

【0036】

ユーザ管理部１１は、プログラム開発統合管理システム１にアクセスするユーザ（ライブラリアンや開発者等）についての情報を管理する機能を有する。これには例えば、社内システム等と連携した各ユーザやグループについてのアカウント情報の管理や、ユーザ認証、グループやチーム間での情報の連携機能などが含まれる。

【0037】

テーマ管理部１２は、アプリケーションプログラムの開発案件（テーマ）を個別に管理する機能を有する。例えば、開発案件を開始する際、対象となるアプリケーションプログラムの機能やサービス等の指定と合わせて、ライブラリ１０として管理されているソースコード２１等のうち、当該テーマに関連するものの指定等の情報を受けてこれをテーマとして図示しないデータベース等に登録する。また、対象のテーマや、これに含まれるサブシステム、機能、ソースコード２１等について、作業を行う開発者やグループ等を割り当てることが可能である。これにより、後述するように、開発作業やリリース時には、テーマ毎に該当するソースコード２１や実行モジュール２２等を特定し、これらに対してのみアクセス可能とするなどのアクセス制御を行うことができる。

【0038】

工程管理部１３は、開発中の案件（テーマ）について、各開発工程でのプロジェクト管理に係る業務フローを実現するとともに、複数のシステム環境間での開発工程の調整を行う機能を有する。各開発工程での処理には、例えば、進捗状況の管理や、レビューの実施等のイベントの管理、リリースの承認プロセスなどが含まれる。また、ソースコード２１を一本化して一元管理するために、例えば、複数のシステム環境に対する並行開発の管理や、リリースタイミングの調整などの処理も含まれる。複数の開発者等の間での情報の共有や処理の受け渡しには、例えば、公知のグループウェア等の仕組みを適用することができる。

【0039】

運用管理部１４は、プログラム開発統合管理システム１の全体の運用について管理する機能を有する。例えば、プログラム開発統合管理システム１上で用いられるデータの登録や更新等の機能や、定期的もしくは所定のタイミングで実行されるプログラム等の実行の管理機能などが含まれる。

【0040】

ユーザインタフェース部１５は、プログラム開発統合管理システム１にアクセスするライブラリアン端末５やユーザ端末６に対して、情報を参照したり各種の操作を行ったりするためのユーザインタフェースを提供する機能を有する。例えば、図示しないＷｅｂサーバプログラムを有し、ライブラリアン端末５やユーザ端末６上の図示しないＷｅｂブラウザ等を介してユーザがプログラム開発統合管理システム１の各機能にアクセスすることを可能とする。

【0041】

リポジトリ管理部１６は、ライブラリ１０についてのリポジトリ管理機能を有する。例えば、公知の技術を利用して、ライブラリ１０が巨大化することを想定したバックアップの高速化やアクセスの効率化などを行う機能が含まれる。なお、リポジトリには、例えば、開発段階での成果物を管理する開発リポジトリと、本番環境へのリリース対象物を管理する本番リポジトリとが含まれる。

【0042】

モジュール管理部１７は、各開発環境２からのライブラリ１０に対するソースコード２１や実行モジュール２２等のチェックアウト／チェックインの処理など、開発環境２でのモジュールの管理機能を有する。図２において示したように、ソースコード２１については、原則として複数の開発環境２の全てに対して同一のものをチェックアウトすることが可能であり、当該ソースコード２１等に基づいて各開発環境２でそれぞれ実行モジュール２２がビルド／生成される。特定の開発環境２にしかチェックアウトされないソースコード２１等があってもよい。

【0043】

本実施の形態では、モジュール管理部１７は、各開発環境２のユーザ（開発者）がソースコード２１等をチェックアウト／チェックインしようとする際に、当該ユーザが当該ソースコード２１等をチェックアウト／チェックインする権限を有するか否かを判定するアクセス制御を行う。ここでは、例えば、対象のソースコード２１等に基づくアクセス制御として、当該ソースコード２１等が、テーマ管理部１２より登録された開発中のテーマに関連するものであるか否か等を判定する。

【0044】

また、対象のユーザに基づくアクセス制御として、当該ユーザが対象のテーマやその対象物（例えば、サブシステムや機能、ソースコード２１など）、もしくは対象の開発環境２における開発者として割り当てられているか否か等を判定する。これにより、ユーザに対して、自身がアクセスすることができるソースコード２１等についてのみチェックアウト／チェックインすることを許容できる。各開発環境２では、ライブラリ１０からチェックアウトしたソースコード２１に対して、ユーザ端末６等を介してユーザ（開発者）が修正等を行い、Ｍａｋｅｆｉｌｅ等に基づいてビルドを行なって実行モジュール２２を生成する。また、生成した実行モジュール２２の単体テストや連結テストなどを行い、完了したソースコード２１等をライブラリ１０にチェックインする。

【0045】

なお、開発環境２における開発作業や後述するテスト環境３でのテストの実施、および本番環境４でのリリース作業などについては、実施の内容をログデータとして図示しないデータベース等に記録しておく。これにより、監査等の際に証跡の情報としてこれらのデータを用いることができるとともに、工程管理部１３での管理を行う際の実績データとして用いることも可能である。

【0046】

テスト環境配布部１８は、各開発環境２において生成された実行モジュール２２や関連ファイル等を、対応するテスト環境３に配布する機能を有する。ここでは例えば、ユーザが、配布する案件（テーマ）、および配布する日付や曜日等と、配布先のテスト環境３（もしくはサーバ等）を指定することで、テスト環境配布部１８が所定の領域に配布対象の実行モジュール２２等を配置し、自動的に配布を行うことができる。

【0047】

なお、配布対象の実行モジュール２２等のライブラリ１０からの払い出しや、テスト環境３への配布については、モジュール管理部１７の場合と同様にアクセス制御を行うことができる。また、後述する本番環境４へのリリース時と同様に、工程管理部１３における承認プロセスを経たものについてのみ配布可能としてもよい。各テスト環境３では、テスト環境配布部１８を介して配布された実行モジュール２２に基づいて、システム全体についての総合テストや、サブシステム間の連結等を対象としたテストを実施する。

【0048】

本番リリース部１９は、各テスト環境でのテストが完了した実行モジュール２２や関連ファイルについて、対応する本番環境４にリリースする機能を有する。ここでは例えば、工程管理部１３において所定の管理者による承認プロセスを経た案件（テーマ）について、本番環境４へのリリースを管理する特定のライブラリアンのみが、当該テーマとリリースする日付や曜日等、およびリリース先の本番環境４（もしくはサーバ等）を指定する。これにより、従来技術と同様に、本番リリース部１９が、図示しない中継サーバ等の所定の領域にリリース対象の実行モジュール２２等を配置し、自動的にリリースを行うことができる。

【0049】

このように、開発者と本番環境４へのリリースを行う担当者（特定のライブラリアン）の職責や権限をシステム的に分離することにより、セキュリティを確保して内部統制を図ることができる。なお、本番環境４へのリリースだけではなく、テスト環境３への配布や、開発環境２からのチェックアウト／チェックインについても特定のライブラリアンを介して行うようにするのが望ましい。

【0050】

＜データ構成＞
図３は、ライブラリ１０において管理情報を保持するテーブルのデータ構成の例について概要を示した図である。管理テーブル１０ａは、ライブラリ１０にて管理するソースコード２１や実行モジュール２２等の管理物件についての管理情報を保持するテーブルであり、例えば、サブシステムＩＤ、管理物件特定キー、管理物件ＩＤ、管理物件名称、配布先システム、配布先環境、および配布先サーバなどの項目を有する。キー項目は管理物件特定キーと管理物件ＩＤの複合キーである。

【0051】

サブシステムＩＤの項目は、対象の管理物件（ソースコード２１等）が属する、アプリケーションプログラムにおけるサブシステムを識別するＩＤの情報を保持する。管理物件特定キーの項目は、対象の管理物件の所在と適用するシステム環境の情報を識別する情報を保持する。例えば、先頭のエントリの“ＣＭＮ：ＭＡＫＥ／ｓｒｃ／ｂｔ／ｍａｉｎ”というデータでは、適用するシステム環境が、複数のシステム環境で共通に適用可能であることを示す“ＣＭＮ”であり、所在場所のサーバ種別が“ＭＡＫＥ”、所在場所のパスが“／ｓｒｃ／ｂｔ／ｍａｉｎ”であることを示している。また、次のエントリの“ＥｎｖＡ：ＤＢ／ＭＡＫＥ／ｓｒｃ”というデータでは、適用するシステム環境が“環境Ａ”であることを示す“ＥｎｖＡ”であり、所在場所のサーバ種別が“ＤＢ”、所在場所のパスが“／ＭＡＫＥ／ｓｒｃ”であることを示している。

【0052】

管理物件ＩＤの項目は、対象の管理物件を識別するＩＤ（本実施の形態ではファイル名）の情報を保持する。本実施の形態では、上述したように、各システム環境でソースコード２１等は共通のものを用いるため、ビルドされて生成される実行モジュール２２についてはバイナリレベルでは異なるものの、外観（ファイル名）は同じものになる。従って、図３の例では、説明の便宜上、ファイル名を、適用するシステム環境の種類（上述した管理物件特定キーの項目で指定されている）に応じて異なる種類の図形で囲むことで、ファイル名が同じでも実体が異なるものであることを示している。管理物件名称の項目は、対象の管理物件の名称等、管理物件の内容を簡潔に説明する文言の情報を保持する。

【0053】

なお、上記の項目のうち、サブシステムＩＤ、管理物件特定キー、管理物件ＩＤの３つの項目は、管理物件を一意に特定することができる管理物件特定情報としての意義を有する。従って、バイナリレベルでの実体が異なる実行モジュール２２について、管理物件ＩＤ（ファイル名）が同じであっても、管理物件特定情報としては異なるものとして把握することが可能である。

【0054】

配布先システムの項目は、テスト環境３への配布もしくは本番環境４へのリリースの対象となるシステム環境を示す情報を保持する。従って、データが設定・保持されるのは配布やリリースの対象となる実行モジュール２２等のみとなる。図３の例では、“環境Ａ”についての実行モジュール２２（３番目のエントリの“ＡＢＣ１００．ｅｘｅ”）に対しては、“環境Ａ”を示す“ＥｎｖＡ”と“環境Ｃ”を示す“ＥｎｖＣ”が設定されている（すなわち、“環境Ｃ”においては、“環境Ａ”と同様の実行モジュール２２が動作可能である）ことを示している。また、“環境Ｂ”についての実行モジュール２２（５番目のエントリの“ＡＢＣ１００．ｅｘｅ”）に対しては、“環境Ｂ”を示す“ＥｎｖＢ”が設定されていることを示している。

【0055】

配布先環境の項目は、対象の管理物件の配布先のシステム環境に複数種類の運用環境が存在する場合は、その対象の運用環境の情報を保持する。例えば、図３の例では、アクセスする日が平日であるか休日であるかによってアクセス先の運用環境が異なるというような場合に、対象の管理物件が平日用の運用環境と休日用の運用環境のいずれ（もしくは双方）に配布されるのかの情報が設定されていることを示している。配布先サーバの項目は、対象の管理物件の配布先のサーバ（論理サーバや物理サーバ）の情報を保持する。

【0056】

なお、上記の配布先システム、配布先環境、および配布先サーバの３つの項目は、テスト環境３や本番環境４に対して管理物件を配布する際の制御に係る配布関連情報としての意義を有する。これらの情報は、例えば、工程管理部１３によるリリース承認プロセスや、テーマ間での調整処理等によって設定／承認され、これらの情報に基づいて、テスト環境配布部１８や本番リリース部１９が配布／リリース先等を自動で制御することが可能となる。

【0057】

上述の図３で示したテーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。例えば、配布関連情報として、さらに、リリース日や本番リポジトリへの反映予定日などの情報を有して、各システム環境への配布やリリースのタイミングを制御可能となるようにしてもよい。

【0058】

＜ソースコード等の一本化手法＞
図４は、本実施の形態における複数のシステム環境でのソースコード２１等の一本化の例について概要を示した図である。テーマ管理部１２を介して登録された開発案件（テーマ）について、開発者等のユーザがユーザ端末６により、ユーザ管理部１１や工程管理部１３等を介して、ライブラリアンに対して管理物件であるソースコード２１（“ＡＢＣ１００．ｃｂｌ”）の更新（修正や新規追加など）の要求を行うと、ライブラリアンは、ライブラリアン端末５によりモジュール管理部１７を介して対象の管理物件に対する更新登録を行う。

【0059】

このとき、テーマ管理部１２等により、対象の管理物件が対象のテーマに含まれるものか否か、対象のユーザが対象のテーマについての開発者として対象の管理物件にアクセスする権限を有しているか否か、対象のユーザが対象のシステム環境で開発作業を行う権限を有しているか否か等を判定して、対象の管理物件に対するアクセスの可否を判定するアクセス制御を行なってもよい。

【0060】

モジュール管理部１７は、ユーザから指定された管理物件であるソースコード２１（“ＡＢＣ１００．ｃｂｌ”）および対象のテーマの中でこれに関連するファイル（Ｍａｋｅｆｉｌｅ（“ＡＢＣ１００．ｍｋ”）や、生成された実行モジュール２２（“ＡＢＣ１００．ｅｘｅ”））を、図３に示した管理テーブル１０ａの内容に基づいて、対象となる開発環境２に対して払い出してチェックアウトする。

【0061】

図４の例では開発環境Ａ（２Ａ）とＢ（２Ｂ）に対して払い出すため、管理テーブル１０ａを参照して、開発環境Ａ（２Ａ）には、各システム環境で共通のソースコード２１（“ＡＢＣ１００．ｃｂｌ”）と開発環境Ａ（２Ａ）用のＭａｋｅｆｉｌｅ（“ＡＢＣ１００．ｍｋ”）および実行モジュール２２（“ＡＢＣ１００．ｅｘｅ”）を払い出し、開発環境Ｂ（２Ｂ）には、各システム環境で共通のソースコード２１（“ＡＢＣ１００．ｃｂｌ”）と開発環境Ｂ（２Ｂ）用のＭａｋｅｆｉｌｅ（“ＡＢＣ１００．ｍｋ”）および実行モジュール２２（“ＡＢＣ１００．ｅｘｅ”）を払い出すことになる。すなわち、ソースコード２１（“ＡＢＣ１００．ｃｂｌ”）については各システム環境に対して共通に払い出す。

【0062】

その後、各開発環境２で開発（ソースコード２１等の作成・更新）、ビルド、および単体テスト、連結テストなどが行われる。これらの作業が完了すると、ユーザからの指示に基づいてモジュール管理部１７は、各モジュールについて指定された管理物件特定キーおよび管理物件ＩＤの項目をもとにライブラリ１０にチェックインする。このとき、例えば、作成された実行モジュール２２が管理テーブル１０ａに登録されていない場合等は、管理テーブル１０ａの内容を更新する。

【0063】

単体テスト、連結テスト等のテストにおいては、ソースコード２１が各システム環境に対して共通である、すなわち業務ロジックについては同一であることから、例えば重複するテスト項目を１回のテスト実施で確認することができるなど、テストにかかる工数を大きく削減し、効率化を図ることができる。また、各システム環境で一元化された直近のソースコード２１がライブラリ１０に格納されているため、ソースコード２１の修正ミスや、先祖返り等の品質劣化を防ぐことが容易となる。

【0064】

図５は、本実施の形態における複数のシステム環境でのソースコード２１等の一本化の例について処理の概要を示した図である。モジュール管理部１７がライブラリ１０から管理物件であるソースコード２１（“ＡＢＣ１００．ｃｂｌ”）およびこれに関連するファイル（Ｍａｋｅｆｉｌｅ（“ＡＢＣ１００．ｍｋ”）や、生成された実行モジュール２２（“ＡＢＣ１００．ｅｘｅ”））を払い出す際、例えば、各開発環境２からアクセス可能なＮＡＳ（Network Attached Storage）８上の所定の領域に各ファイルをコピーすることで払い出す。

【0065】

具体的には、例えば、開発環境Ａ（２Ａ）とＢ（２Ｂ）に対して払い出す場合、ＮＡＳ８上に開発環境Ａ（２Ａ）用の領域とＢ（２Ｂ）用の領域、および各システム環境に共通の領域を設定する。開発環境Ａ（２Ａ）用の領域には開発環境Ａ（２Ａ）用のＭａｋｅｆｉｌｅ（“ＡＢＣ１００．ｍｋ”）および実行モジュール２２（“ＡＢＣ１００．ｅｘｅ”）をコピーし、開発環境Ｂ（２Ｂ）用の領域には開発環境Ｂ（２Ｂ）用のＭａｋｅｆｉｌｅ（“ＡＢＣ１００．ｍｋ”）および実行モジュール２２（“ＡＢＣ１００．ｅｘｅ”）をコピーする。そして、共通の領域には共通で用いられるソースコード２１（“ＡＢＣ１００．ｃｂｌ”）をコピーする。

【0066】

このとき、開発環境Ａ（２Ａ）のユーザ端末６からは、開発環境Ａ（２Ａ）用の領域と共通の領域のみマウント可能とし、開発環境Ｂ（２Ｂ）のユーザ端末６からは、開発環境Ｂ（２Ｂ）用の領域と共通の領域のみマウント可能とする。これにより、開発環境Ａ（２Ａ）のユーザ端末６からは共通のソースコード２１（“ＡＢＣ１００．ｃｂｌ”）と開発環境Ａ（２Ａ）用のＭａｋｅｆｉｌｅ（“ＡＢＣ１００．ｍｋ”）および実行モジュール２２（“ＡＢＣ１００．ｅｘｅ”）のみが参照可能となり、開発環境Ｂ（２Ｂ）のユーザからは、共通のソースコード２１（“ＡＢＣ１００．ｃｂｌ”）と開発環境Ｂ（２Ｂ）用のＭａｋｅｆｉｌｅ（“ＡＢＣ１００．ｍｋ”）および実行モジュール２２（“ＡＢＣ１００．ｅｘｅ”）のみが参照可能となるよう制御することができる。

【0067】

各開発環境２での開発および単体テスト、連結テスト等が完了すると、ＮＡＳ８上の対象のモジュール等をライブラリ１０にチェックインするとともに、ＮＡＳ８上の各領域への各ユーザ端末６からのマウントを解除し、各領域の内容をクリアする等の後処理を行う。

【0068】

以上に説明したように、本発明の一実施の形態であるプログラム開発統合管理システム１によれば、一本化された同一のソースコード２１を各システム環境に対応する開発環境２においてそれぞれ個別にビルドして実行モジュール２２を生成し、テスト環境３でのテストを経た後、対応する本番環境４にそれぞれリリースするという構成をとる。これにより、同一のソースコード２１を複数のシステム環境に対して共通に提供することで開発やテストにかかる負荷を低減することができる。また、各システム環境においてそれぞれ当該システム環境に適合した実行モジュール２２を生成することで、例えば、標準的な機能やサービスを提供する大規模なシステム環境を多数有するようなデータセンター等での構成においても、システム環境毎の対応を柔軟に行うことが可能となる。

【0069】

また、開発者と、開発環境や本番環境に対するリリースを行えるライブラリアンとで、職責や権限をシステム的に分離するとともに、各システム環境に対応する開発環境２において、対応可能な開発者からのみアクセス可能となるようアクセス制御を行うことができる。また、生成された実行モジュール２２を、対応するテスト環境３、本番環境４の適切なサーバ等に適切な権限を有するライブラリアンが適切なタイミングで配布、リリースするよう管理することが可能となるなど、内部統制を強化しつつ、ライブラリ管理の仕組みと、開発案件（テーマ）の工程管理や生成された実行モジュール２２のリリース管理等の仕組みとを統合して管理することが可能となる。

【0070】

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

【産業上の利用可能性】

【0071】

本発明は、複数種類のシステム環境におけるライブラリやリリースの管理を行うプログラム開発統合管理システムに利用可能である。

【符号の説明】

【0072】

１…プログラム開発統合管理システム、２、２Ａ〜Ｃ…開発環境（Ａ〜Ｃ）、３…テスト環境、４、４Ａ〜Ｃ…本番環境（Ａ〜Ｃ）、５…ライブラリアン端末、６…ユーザ端末、７…ネットワーク、８…ＮＡＳ、
１０…ライブラリ、１０ａ…管理テーブル、１１…ユーザ管理部、１２…テーマ管理部、１３…工程管理部、１４…運用管理部、１５…ユーザインタフェース部、１６…リポジトリ管理部、１７…モジュール管理部、１８…テスト環境配布部、１９…本番リリース部、
２１、２１Ａ〜Ｃ…ソースコード（Ａ〜Ｃ）、２２、２２Ａ〜Ｃ…実行モジュール（Ａ〜Ｃ）。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】