トップ :: G 物理学 :: G06 計算;計数




【発明の名称】 リリース管理装置、リリース管理方法、プログラム
【発明者】 【氏名】嶋田 大祐
【要約】 【課題】ソースコード管理は、開発作業後とリリース依頼との間の管理がない。このため、開発作業とリリース作業の間が手作業となり、リリース時のミス、リリース依頼時にミスが発生した。スケジュール、バージョン管理、リリースを別々に管理するため管理が複雑であり手作業が入ることによるミスが発生した。

【解決手段】スケジュール管理機能１、物件の払い出し払い戻し機能２、リリース依頼機能３から構成され、各機能を管理するスケジュール管理テーブル群１１、払い出し払い戻しテーブル群２１、リリース依頼テーブル群３１と物件の払い出し払い戻し機能２で用いる物理ディレクトリ５を有する。各テーブル群は同一データベース４上に存在する。各機能がリリースフェーズをキーとしてデータベース４上をデータの受け渡しをおこない、各機能に沿ったデータへ変換していくことにより、各機能がデータベース４上ですべて管理し、結びつきを行う。
【特許請求の範囲】
【請求項１】 ソフトウエアの開発を管理するシステムであって、前期開発のスケジュール管理、前記ソフトウエア物件の払い出し、払い戻しとリリース依頼を一つの管理システムとして同一のデータベース上で実装し、前記スケジュール管理から前記リリース依頼までの前記開発に必要なデータ整合性の保証と前期開発の作業の効率化を実現したことを特徴とするリリース管理装置。
【請求項２】 開発のスケジュール管理、ソフトウエア物件の払い出し、払い戻しとリリース依頼を同一データベース上で実装しソフトウエアの開発を管理するシステムであって、リリースフェーズ毎の納期と前記物件のデータをスケジュール管理テーブル群へ登録するスケジュール管理機能と、払い出し、払い戻し依頼時に登録される依頼内容と物件の払い出し払い戻し状況を調査するための払い出し払い戻し管理テーブルと、払い出し、払い戻し処理のすべての履歴を管理する払い出し払い戻し履歴管理テーブルと、ソースファイルのディレクトリを有し、払い出し、払い戻しが前記スケジュール管理機能に登録されているか整合を検査する払い出し払い戻し機能と、スケジュールとリリース依頼に関連性を持たせるリリーステーブルと、任意のリリース日でリリースされる物件一覧が登録されるファイル単位リリース依頼テーブルテーブルとを有し、前記リリースが前記スケジュール管理機能に登録されているか整合を検査するリリース依頼機能を有し、前記スケジュール管理機能と払い出し払い戻し機能とリリース依頼機能は、それぞれがリリースフェーズを有し、前記リリースフェーズによりにより前記各機能間で前記データの受け渡しを行うことを特徴とするリリース管理装置。
【請求項３】 前記スケジュール管理テーブル群は、使用追加番号とバグ表を作業番号で管理する作業番号テーブルと、機能毎につけられた枝番を管理する枝番テーブルと、前記枝番に属するファイルを管理する枝番毎ファイル番号テーブルと前記枝番毎と前記作業番号毎のリリースフェーズを管理するスケジュールファイル管理テーブルから構成され、前記払い出し、払い戻し履歴テーブルは払い出し者、払い出し日、払い戻し日、ファイルサイズ、ファイル作成日、前記リリースフェーズ、枝番、ファイルを保持し、前記リーステーブルは、リリース日とリリースフェーズ、枝番とを関連付けることを特徴とする請求項２記載のリリース管理装置。
【請求項４】 スケジュールデータを入力し、前記データが一意性、外部参照性のデータ整合性を満たしているかを調査する第１のステップと、前記データをスケジュール管理テーブル群へスケジュールを登録する第２のステップと、スケジュール登録された前記データをもとに払い出し依頼をおこなう第３のステップと、前記依頼を、払い出し払い戻し管理テーブルに一時的に登録する第４のステップと、前記払い出し払い戻し管理テーブル群に登録されたデータを、前記スケジュール管理テーブル群のデータを参照し、払い出し要求の物件すべてがスケジュール登録されているかを調査する第５ステップと、払い出し要求の物件が同一リリーススケジュール、枝番で払い出されていないかを調査し、前記調査の条件を満たす物件のみ払い出しが許可され、払い出し払い戻し履歴管理テーブルへ依頼を登録する第６のステップと、前記第６のステップでの登録完了後、対象とな前記物件をソースマスタより、コピーし、開発に使用する第７のステップと、前記開発終了後、前記払い出し払い戻し管理テーブルへ一度登録後スケジュール登録されているか、払い出されているファイルかの条件を調査し、前記条件が満たされた時のみ払い戻し処理を行う第８のステップと、払い戻し専用のディレクトリ上に払い戻しの前記物件が転送され、払い戻し処理を行い、前記物件は前記ソースマスタにコピーされる第９のステップと、前記スケジュール管理テーブルと前記リリーステーブルを結合させてるリリース依頼を行う第１０のステップと、前記リリース依頼時に前記払い出し払い戻し履歴管理テーブルを参照し、払い戻し完了物件か、物理ファイルが存在するかを調査する第１１のステップと、前記調査の後、ファイル単位リリース依頼テーブルへ前記物件を登録する第１２のステップと、前記リリース時には、前記ファイル単位リリース依頼テーブルと払い出し、払い戻しを構成する物理ディレクトリを参照し前記ソースマスタからリリースを行う第１３のステップとからなることを特徴とするリリース管理方法。
【請求項５】 コンピュータに、スケジュールデータを入力し、前記データが一意性、外部参照性のデータ整合性を満たしているかを調査する第１のステップと、前記データをスケジュール管理テーブル群へスケジュールを登録する第２のステップと、スケジュール登録された前記データをもとに払い出し依頼をおこなう第３のステップと、前記依頼を、払い出し払い戻し管理テーブルに一時的に登録する第４のステップと、前記払い出し払い戻し管理テーブル群に登録されたデータを、前記スケジュール管理テーブル群のデータを参照し、払い出し要求の物件すべてがスケジュール登録されているかを調査する第５ステップと、払い出し要求の物件が同一リリーススケジュール、枝番で払い出されていないかを調査し、前記調査の条件を満たす物件のみ払い出しが許可され、払い出し払い戻し履歴管理テーブルへ依頼を登録する第６のステップと、前記第６のステップでの登録完了後、対象とな前記物件をソースマスタより、コピーし、開発に使用する第７のステップと、前記開発終了後、前記払い出し払い戻し管理テーブルへ一度登録後スケジュール登録されているか、払い出されているファイルかの条件を調査し、前記条件が満たされた時のみ払い戻し処理を行う第８のステップと、払い戻し専用のディレクトリ上に払い戻しの前記物件が転送され、払い戻し処理を行い、前記物件は前記ソースマスタにコピーされる第９のステップと、前記スケジュール管理テーブルと前記リリーステーブルを結合させてるリリース依頼を行う第１０のステップと、前記リリース依頼時に前記払い出し払い戻し履歴管理テーブルを参照し、払い戻し完了物件か、物理ファイルが存在するかを調査する第１１のステップと、前記調査の後、ファイル単位リリース依頼テーブルへ前記物件を登録する第１２のステップと、前記リリース時には、前記ファイル単位リリース依頼テーブルと払い出し、払い戻しを構成する物理ディレクトリを参照し前記ソースマスタからリリースを行う第１３のステップを処理させることを特徴とするプログラム。
【請求項６】 スケジュールデータを入力し、前記データが一意性、外部参照性のデータ整合性を満たしているかを調査する第１の手段と、前記データをスケジュール管理テーブル群へスケジュールを登録する第２の手段と、スケジュール登録された前記データをもとに払い出し依頼をおこなう第３の手段と、前記依頼を、払い出し払い戻し管理テーブルに一時的に登録する第４の手段と、前記払い出し払い戻し管理テーブル群に登録されたデータを、前記スケジュール管理テーブル群のデータを参照し、払い出し要求の物件すべてがスケジュール登録されているかを調査する第５手段と、払い出し要求の物件が同一リリーススケジュール、枝番で払い出されていないかを調査し、前記調査の条件を満たす物件のみ払い出しが許可され、払い出し払い戻し履歴管理テーブルへ依頼を登録する第６の手段と、前記第６の手段での登録完了後、対象とな前記物件をソースマスタより、コピーし、開発に使用する第７の手段と、前記開発終了後、前記払い出し払い戻し管理テーブルへ一度登録後スケジュール登録されているか、払い出されているファイルかの条件を調査し、前記条件が満たされた時のみ払い戻し処理を行う第８の手段と、払い戻し専用のディレクトリ上に払い戻しの前記物件が転送され、払い戻し処理を行い、前記物件は前記ソースマスタにコピーされる第９の手段と、前記スケジュール管理テーブルと前記リリーステーブルを結合させてるリリース依頼を行う第１０の手段と、前記リリース依頼時に前記払い出し払い戻し履歴管理テーブルを参照し、払い戻し完了物件か、物理ファイルが存在するかを調査する第１１の手段と、前記調査の後、ファイル単位リリース依頼テーブルへ前記物件を登録する第１２の手段と、前記リリース時には、前記ファイル単位リリース依頼テーブルと払い出し、払い戻しを構成する物理ディレクトリを参照し前記ソースマスタからリリースを行う第１３の手段とからなることを特徴とするリリース管理装置。
【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明はソフトウエアの開発管理に関し、特に開発からリリースまでのソースコードの管理を同一のデータベースによりおこなう方式に関する。
【０００２】
【従来の技術】従来のリリース管理は、ソースコードの払い出し、払い戻し、バージョン管理に特記した管理方法のみでリリースまでを大きく管理する方法がなかった。
【０００３】従来のシステム一例が特開平７−９３１４２「長期プロジェクト向きソースコード管理方式」に記載されている。
【０００４】
【発明が解決しようとする課題】従来技術には、次のような問題点があった。長期プロジェクトにおけるソースコード管理方式は開発作業効率を向上させることを目的とのみしているため、開発作業後とリリース依頼との間の管理がない点である。リリース依頼までの管理がないことは、開発作業とリリース作業の間が手作業となり、リリース時のミスまたは、リリース依頼時でのミスの発生原因となった。
【０００５】本発明の目的は、以上の問題点を解決するために開発からリリースまでの管理をすべて同一データベース上で実装するリリース管理装置を提供する。
【０００６】
【課題を解決するための手段】本発明第一のリリース管理装置は、ソフトウエアの開発を管理するシステムであって、前期開発のスケジュール管理、前記ソフトウエア物件の払い出し、払い戻しとリリース依頼を一つの管理システムとして同一のデータベース上で実装し、前記スケジュール管理から前記リリース依頼までの前記開発に必要なデータ整合性の保証と前期開発の作業の効率化を実現した。
【０００７】本発明第二のリリース管理装置は、開発のスケジュール管理、ソフトウエア物件の払い出し、払い戻しとリリース依頼を同一データベース上で実装しソフトウエアの開発を管理するシステムであって、リリースフェーズ毎の納期と前記物件のデータをスケジュール管理テーブル群へ登録するスケジュール管理機能と、払い出し、払い戻し依頼時に登録される依頼内容と物件の払い出し払い戻し状況を調査するための払い出し払い戻し管理テーブルと、払い出し、払い戻し処理のすべての履歴を管理する払い出し払い戻し履歴管理テーブルと、ソースファイルのディレクトリを有し、払い出し、払い戻しが前記スケジュール管理機能に登録されているか整合を検査する払い出し払い戻し機能と、スケジュールとリリース依頼に関連性を持たせるリリーステーブルと、任意のリリース日でリリースされる物件一覧が登録されるファイル単位リリース依頼テーブルテーブルとを有し、前記リリースが前記スケジュール管理機能に登録されているか整合を検査するリリース依頼機能を有し、前記スケジュール管理機能と払い出し払い戻し機能とリリース依頼機能は、それぞれがリリースフェーズを有し、前記リリースフェーズによりにより前記各機能間で前記データの受け渡しを行う。
【０００８】本発明第三のリリース管理装置は、本発明第二のリリース管理装置における、スケジュール管理テーブル群は、使用追加番号とバグ表を作業番号で管理する作業番号テーブルと、機能毎につけられた枝番を管理する枝番テーブルと、前記枝番に属するファイルを管理する枝番毎ファイル番号テーブルと前記枝番毎と前記作業番号毎のリリースフェーズを管理するスケジュールファイル管理テーブルから構成され、前記払い出し、払い戻し履歴テーブルは払い出し者、払い出し日、払い戻し日、ファイルサイズ、ファイル作成日、前記リリースフェーズ、枝番、ファイルを保持し、前記リーステーブルは、リリース日とリリースフェーズ、枝番とを関連付ける。
【０００９】本発明のリリース管理方法は、スケジュールデータを入力し、前記データが一意性、外部参照性のデータ整合性を満たしているかを調査する第１のステップと、前記データをスケジュール管理テーブル群へスケジュールを登録する第２のステップと、スケジュール登録された前記データをもとに払い出し依頼をおこなう第３のステップと、前記依頼を、払い出し払い戻し管理テーブルに一時的に登録する第４のステップと、前記払い出し払い戻し管理テーブル群に登録されたデータを、前記スケジュール管理テーブル群のデータを参照し、払い出し要求の物件すべてがスケジュール登録されているかを調査する第５ステップと、払い出し要求の物件が同一リリーススケジュール、枝番で払い出されていないかを調査し、前記調査の条件を満たす物件のみ払い出しが許可され、払い出し払い戻し履歴管理テーブルへ依頼を登録する第６のステップと、前記第６のステップでの登録完了後、対象とな前記物件をソースマスタより、コピーし、開発に使用する第７のステップと、前記開発終了後、前記払い出し払い戻し管理テーブルへ一度登録後スケジュール登録されているか、払い出されているファイルかの条件を調査し、前記条件が満たされた時のみ払い戻し処理を行う第８のステップと、払い戻し専用のディレクトリ上に払い戻しの前記物件が転送され、払い戻し処理を行い、前記物件は前記ソースマスタにコピーされる第９のステップと、前記スケジュール管理テーブルと前記リリーステーブルを結合させてるリリース依頼を行う第１０のステップと、前記リリース依頼時に前記払い出し払い戻し履歴管理テーブルを参照し、払い戻し完了物件か、物理ファイルが存在するかを調査する第１１のステップと、前記調査の後、ファイル単位リリース依頼テーブルへ前記物件を登録する第１２のステップと、前記リリース時には、前記ファイル単位リリース依頼テーブルと払い出し、払い戻しを構成する物理ディレクトリを参照し前記ソースマスタからリリースを行う第１３のステップとからなる。
【００１０】本発明のプログラムは、コンピュータに、スケジュールデータを入力し、前記データが一意性、外部参照性のデータ整合性を満たしているかを調査する第１のステップと、前記データをスケジュール管理テーブル群へスケジュールを登録する第２のステップと、スケジュール登録された前記データをもとに払い出し依頼をおこなう第３のステップと、前記依頼を、払い出し払い戻し管理テーブルに一時的に登録する第４のステップと、前記払い出し払い戻し管理テーブル群に登録されたデータを、前記スケジュール管理テーブル群のデータを参照し、払い出し要求の物件すべてがスケジュール登録されているかを調査する第５ステップと、払い出し要求の物件が同一リリーススケジュール、枝番で払い出されていないかを調査し、前記調査の条件を満たす物件のみ払い出しが許可され、払い出し払い戻し履歴管理テーブルへ依頼を登録する第６のステップと、前記第６のステップでの登録完了後、対象とな前記物件をソースマスタより、コピーし、開発に使用する第７のステップと、前記開発終了後、前記払い出し払い戻し管理テーブルへ一度登録後スケジュール登録されているか、払い出されているファイルかの条件を調査し、前記条件が満たされた時のみ払い戻し処理を行う第８のステップと、払い戻し専用のディレクトリ上に払い戻しの前記物件が転送され、払い戻し処理を行い、前記物件は前記ソースマスタにコピーされる第９のステップと、前記スケジュール管理テーブルと前記リリーステーブルを結合させてるリリース依頼を行う第１０のステップと、前記リリース依頼時に前記払い出し払い戻し履歴管理テーブルを参照し、払い戻し完了物件か、物理ファイルが存在するかを調査する第１１のステップと、前記調査の後、ファイル単位リリース依頼テーブルへ前記物件を登録する第１２のステップと、前記リリース時には、前記ファイル単位リリース依頼テーブルと払い出し、払い戻しを構成する物理ディレクトリを参照し前記ソースマスタからリリースを行う第１３のステップを処理させる。
【００１１】本発明第四のリリース管理装置は、スケジュールデータを入力し、前記データが一意性、外部参照性のデータ整合性を満たしているかを調査する第１の手段と、前記データをスケジュール管理テーブル群へスケジュールを登録する第２の手段と、スケジュール登録された前記データをもとに払い出し依頼をおこなう第３の手段と、前記依頼を、払い出し払い戻し管理テーブルに一時的に登録する第４の手段と、前記払い出し払い戻し管理テーブル群に登録されたデータを、前記スケジュール管理テーブル群のデータを参照し、払い出し要求の物件すべてがスケジュール登録されているかを調査する第５手段と、払い出し要求の物件が同一リリーススケジュール、枝番で払い出されていないかを調査し、前記調査の条件を満たす物件のみ払い出しが許可され、払い出し払い戻し履歴管理テーブルへ依頼を登録する第６の手段と、前記第６の手段での登録完了後、対象とな前記物件をソースマスタより、コピーし、開発に使用する第７の手段と、前記開発終了後、前記払い出し払い戻し管理テーブルへ一度登録後スケジュール登録されているか、払い出されているファイルかの条件を調査し、前記条件が満たされた時のみ払い戻し処理を行う第８の手段と、払い戻し専用のディレクトリ上に払い戻しの前記物件が転送され、払い戻し処理を行い、前記物件は前記ソースマスタにコピーされる第９の手段と、前記スケジュール管理テーブルと前記リリーステーブルを結合させてるリリース依頼を行う第１０の手段と、前記リリース依頼時に前記払い出し払い戻し履歴管理テーブルを参照し、払い戻し完了物件か、物理ファイルが存在するかを調査する第１１の手段と、前記調査の後、ファイル単位リリース依頼テーブルへ前記物件を登録する第１２の手段と、前記リリース時には、前記ファイル単位リリース依頼テーブルと払い出し、払い戻しを構成する物理ディレクトリを参照し前記ソースマスタからリリースを行う第１３の手段とからなる。
【００１２】
【発明の実施の形態】次に、本発明の実施の形態について図面を参照して詳細に説明する。図１は、本発明実施の形態のリリース管理装置の概略を示す図である。図１を参照すると、本実施例は、スケジュール管理機能１、物件の払い出し払い戻し機能２、リリース依頼機能３、の３つの機能を含む。各機能は、それぞれ各機能を管理するスケジュール管理テーブル群１１、払い出し払い戻しテーブル群２１、リリース依頼テーブル群３１と物件の払い出し払い戻し機能２で用いる物理ディレクトリ５から構成されている。スケジュール管理テーブル群１１、払い出し払い戻しテーブル群２１、リリース依頼テーブル群３１は同一データベース４上に存在する。
【００１３】図１において、各機能は、リリースフェーズをキーとして、同一データベース４で結びついている。各機能には、必ずリリースフェーズが存在する。リリースフェーズは、ある任意の納期目標又は、工事目標（４次開発、５次開発リリース１等）である。開発は各リリースフェーズに従いスケジュールをたて、リリースフェーズにしたがって、物件の払い出し、開発を行う。開発後は、リリースフェーズにしたがって、物件の払い戻しを行う。開発者は、リリース依頼時にリリースフェーズに沿った依頼を行い、リリース作業実施者（コンパイル、転送作業者）は、各リリースフェーズ毎にリリース物件の管理を行う。
【００１４】以上により、各機能がリリースフェーズをキーとしてデータベース４上をデータの受け渡しをおこない、各機能に沿ったデータへ変換していくことにより、各機能がデータとしてデータベース４上ですべて管理でき、結びつきを行っている。例えば、スケジュール登録されていないファイルは、払い出し、払い戻し不可能となり又、リリース依頼も不可能となる。よって、リリース依頼とスケジュールとを関連付けることによって、開発物件とリリース物件との差異がとれるようになっている。
【００１５】まずはじめにスケジュール管理機能１について説明する。図１において、スケジュール管理機能１は、各開発者がリリースフェーズ毎の納期物件を登録する機能である。この機能によりリリースフェーズに対する物件一覧がデータベース４上に登録される。
【００１６】払い出し払い戻し機能２は、物件の払い出し、払い戻しは、各開発者が立てたスケジュール管理テーブル群１１内のデータに従って、払い出し依頼、払い戻し依頼を行う機能である。払い出し、払い戻し依頼は、スケジュール管理テーブル群１１内のデータに沿っておこなわれるため、スケジュールにない物件は依頼不可能となる。つまり、払い出し、払い戻し物件がスケジュール管理上に存在するデータかの整合性調査をおこなっている。
【００１７】リリース依頼機能３は、リリース依頼機能３は、各開発者が立てたスケジュール管理テーブル群１１内の払い出し、払い戻し機能データに従いリリース依頼を行う機能である。リリース依頼機能３では、リリース依頼時にスケジュール管理上、払い出し払い戻し機能２に登録されているデータベース４上のデータを参照し、すべての物件が払い戻し状態であるかを調査し、リリース依頼用のテーブルへデータ登録を行う機能である。
【００１８】次に各部の構成の詳細について説明する。まず、スケジュール管理機能１の詳細について説明する。図２は、本発明実施の形態のリリース管理装置のスケジュール管理機能１を構成するスケジュール管理テーブル群１１と親子関係についての構成を示す図である。
【００１９】スケジュール管理テーブル群１１は次にあげる４種のテーブルにより構成されている。作業番号テーブル１１１、枝番テーブル１１２、枝番毎ファイル番号テーブル１１３、スケジュールファイル管理テーブル１１４である。各テーブルで管理するデータを、以下に述べる。作業番号テーブル１１１は、仕様追加番号、バグ票番号等を管理するテーブルであり、管理者によって一意に登録される。
【００２０】枝番テーブル１１２は、各作業番号に対する各開発者が機能毎につけた任意の番号を管理し、各作業番号に対して複数の枝番が存在する。つまり、作業番号：枝番 ＝１：ｎ の関係をもつ。枝番毎ファイル番号テーブル１１３は、各枝番（機能）に属するファイル一覧（物件一覧）を管理し、各枝番に対して複数のファイル（物件）が存在する。つまり、枝番：ファイル＝１：ｎ の関係をもつ。
【００２１】スケジュールファイル管理テーブル１１４は、各枝番と作業番号毎のリリースフェーズを管理している。スケジュールファイル管理テーブル１１４の構成は、リリースフェーズ：（作業番号、枝番）＝１：ｎである。後で説明するリリース依頼、払い出し、払い戻し機能は、すべて枝番毎（機能毎）に行われるため、このテーブルには、ファイル（物件）との直接的な関連はない。各開発者は、枝番、枝番毎ファイル番号をスケジュールファイル管理テーブル１１４へ各自登録を行う。スケジュール登録を行うことにより、各リリースフェーズでのリリース予定物件一覧がデータベース４上に構築される。スケジュール管理テーブル群１１で構成されたデータは、機能に必要な物件一覧など各開発者、リリース作業実施者の情報共有が可能となる。
【００２２】払い出し払い戻し機能２の詳細について説明する。図３は、本発明実施の形態のリリース管理装置の払い出し払い戻しテーブル群２１と物理ディレクトリ５を示す図である。図３において、物件の払い出し払い戻し機能２は、次にあげる２種のテーブル群と物理ディレクトリ５によって構成されている。２種のテーブルは、払い出し払い戻し管理テーブル２１１、払い出し払い戻し履歴管理テーブル２１２である。払い出し払い戻し管理テーブル２１１は、払い出し、払い戻し依頼時に登録される依頼内容と物件の払い出し払い戻し状況を調査するための一時表である。払い出し払い戻し履歴管理テーブル２１２は、払い出し、払い戻し処理のすべての履歴を管理し、払い出し払い戻し管理テーブル２１１での調査対象となる。又、払い出し者、払い出し日、払い戻し日、ファイルサイズ、ファイル作成日のデータを保持し、各人の責任の所在を明確にする。払い出し払い戻し管理テーブル群２１へ登録されたデータがすべての調査に対して整合性が満たされていた場合にこのテーブルへ登録される。
【００２３】上記２種のテーブルには、スケジュール管理テーブル群１１の項目のリリースフェーズ、枝番、ファイルが存在する。これらの項目で、スケジュール管理テーブル群１１と結合することによって、スケジュールと払い出し払い戻し状況が確認できる。物理ディレクトリ５は、物件の保管を実施する機能を有する。物理ディレクトリ５は、ソースマスタ群２２（物理ファイルが存在する物理ディレクトリ５）と、フェーズソースマスタ２２１（リリースフェーズごとのソースマスタ２２２、リリース後のソースマスタ２２２へ反映される）によって構成される。フェーズソースマスタ２２１は、各リリースフェーズ毎に存在し複数のリリースフェーズを管理することができる。上記ソースマスタ群２２は、各開発者には参照権のみ与えられる。
【００２４】リリース依頼機能３の詳細について説明する。図４は、本発明実施の形態のリリース管理装置のリリース依頼テーブル群３１を示す図である。図４において、リリース依頼機能３は、次の2種のテーブルにより構成されている。リリーステーブル３１１、ファイル単位リリース依頼テーブル３１２である。リリーステーブル３１１は、リリース日とリリースフェーズ、枝番とを関連付けるテーブルである。これにより、スケジュールとしてのデータとリリース依頼としてデータに関連性を持たせる。ファイル単位リリース依頼テーブル３１２は、任意のリリース日でリリースされる物件一覧が登録されるテーブルである。このテーブルは、スケジュール管理テーブル群１１を参照し、リリーステーブル３１１とを結合させてデータ投入が行われる。ファイル単位リリース依頼テーブル３１２にデータ登録されることでリリースが可能となる。ファイル単位リリース依頼テーブル３１２に登録する際には、払い出し払い戻しテーブル群２１内のデータも参照しファイル情報関係のデータも取得する。リリース依頼機能３は、スケジュール管理データとの整合性を常に満たしながら、スケジュール管理データをリリースで必要とされるデータへ遷移させる。すべての機能には、リリースフェーズが存在し、それにより各機能のデータの受け渡しが可能となっている。
【００２５】以上詳細に実施例の構成を述べたが、各機能のデータベースは、同一データベース４上でも別データベース上でも可能である。
【００２６】次に、本発明の実施の形態のリリース管理装置の動作について図面を参照して説明する。図５は、本発明実施の形態のリリース管理装置のシステム構築時の概略フローを示す図である。スケジュール登録によって登録されたデータは、スケジュール管理テーブル群１１（枝番、枝番毎ファイル番号、スケジュールファイル管理）へ登録され、図２のようなデータの構成になる（ステップＳ１）。データ登録時には、一意性、外部参照性のデータ整合性を満たしているかを調査する。データの整合性が満たされているデータのみ登録が可能となる。スケジュール管理テーブル群１１を参照することによって、開発作業での物件一覧が取得でき、リリース依頼、払い出し、払い戻し時での物件漏れを防ぐことができる。
【００２７】各開発者は、スケジュール登録されたデータをもとに払い出し依頼をおこなう（ステップＳ２）。払い出し依頼の単位は、枝番毎とする。依頼内容は、払い出し払い戻し管理テーブル２１１に一時的に登録される。払い出し払い戻し管理テーブル群２１に登録されたデータは、スケジュール管理テーブル群１１のデータを参照し、払い出し要求の物件すべてがスケジュール登録されているかを調査する（ステップＳ３）。次に払い出し要求の物件が同一リリーススケジュール、枝番で払い出されていないかを調査する。本実施例では、同一ソースコードの同時修正を禁止する。上記調査の条件を満たす物件のみ払い出しが許可され、払い出し払い戻し履歴管理テーブル２１２へ依頼が登録される（ステップＳ４）。登録完了後依頼者は、対象となる物件をソースマスタ２２２より、コピーし、開発に使用する（ステップＳ５）。
【００２８】開発終了後、払い戻し処理を実施する。払い戻しの単位は、枝番毎とする。払い戻し処理は、払い出し払い戻し管理テーブル２１１へ一度登録後（ステップＳ６）、スケジュール登録されているか、払い出されているファイルかを調査する。上記条件が満たされた時のみ払い戻し処理が実行される。各開発者は、払い戻し専用のディレクトリ上に払い戻し物件を転送し、払い戻し処理を行い、物件は、フェーズソースマスタ２２１上に自動的にコピーされる（ステップＳ７）。フェーズソースマスタ２２１（リリースフェーズ毎）は、ソースマスタ２２２への反映前状態のディレクトリであり、対象物件がリリース後ソースマスタ２２２へ反映される。払い出し依頼は、フェーズソースマスタ２２１からも可能である。
【００２９】払い戻し完了後、各開発者により、リリース依頼が可能となる。リリース依頼時（ステップＳ８）には、各開発者が立てたスケジュール管理テーブルとリリーステーブル３１１を結合させて行われる（ステップＳ９）。リリース依頼の単位は、枝番毎（機能毎）であり、すでに払い戻し完了物件のみとする。リリース依頼時に払い出し払い戻し履歴管理テーブル２１２を参照し（ステップＳ１０）、払い戻し完了物件か、物理ファイルが存在するかを調査する。調査後、ファイル単位リリース依頼テーブル３１２へデータが登録される（ステップＳ１１）。このテーブルへ登録されることにより、スケジュール管理、払い出し払い戻しでのデータが、リリース依頼のデータとなる。リリース時には、ファイル単位リリース依頼テーブル３１２と払い出し、払い戻しを構成する物理ディレクトリ５を参照しリリースを行う（ステップＳ１２）。これにより、開発に使用した物件とリリース時の物件での整合性をとることが可能となる。
【００３０】次にデータの流れについて説明する。図６は、本発明実施の形態のリリース管理装置のデータフロー概略を示す図である。スケジュール管理テーブル群１１は、あくまでスケジュールとしてのテーブルであり、リリースについての概念は存在しない。スケジュール管理テーブル群１１の枝番配下のファイルを払い出し払い戻しをおこなう際、スケジュール管理テーブル群１１上のリリースフェーズ、枝番、ファイル名が払い出し、払い戻し機能テーブル群２１上へデータ遷移する。遷移したデータには、属項目として、払い出した又は払い戻ししたファイルの情報、払い出し又は、払い戻し日時、依頼者が登録される。
【００３１】払い出し払い戻しテーブル群２１へデータ登録されることにより、スケジュール管理のデータが主にファイル毎のサイズや状況を保持するデータに遷移する。
【００３２】リリース依頼機能３は、スケジュール管理テーブル群１１群にリリース日という概念を持たせることにある。その目的のため、リリースフェーズ、枝番とリリース日を結びつけるテーブルであるリリーステーブル３１１が存在する。リリーステーブル３１１により、スケジュール管理テーブル群１１内のリリースフェーズ、リリース日、枝番と、払い出し払い戻しテーブル群２１内のファイルの情報、日時、依頼者をリリース依頼テーブル群３１データへ変換でき、変換されたファイルの情報、日時、依頼者がファイル単位リリース依頼テーブル３１２へ登録される。ファイル単位リリース依頼テーブル３１２は、リリース日にリリースを行うファイル一覧（ファイルの物理ディレクトリ５、ファイル情報）を管理するのみのテーブルである。
【００３３】以上により、スケジュール管理データを元にデータが各機能で必要とされるデータへ遷移し、データベース４上で一つの管理として結びつけている。
【００３４】上述の各ステップはコンピュータ６０のプログラムにより実現できる。図７は、本発明実施の形態のリリース管理方法を実行するコンピュータ６０とそのプログラムが記録された記録媒体６１を示す図である。
【００３５】
【発明の効果】以上説明したように、本発明においては、以下に記載するような効果を奏する。第１の効果は、スケジュール管理、払い出し、払い戻し管理、リリース依頼、を同一データベースにおいてリリースフェーズというキーによって融合より、関連付けを持たせることにより、作業の複雑さを克服するものである。従来での各機能毎の管理に対して、機能を関連付けしデータベース上にすべて実装することにより、データの整合性をデータベースで行うことが可能となり、従来よりも作業効率化ができ、又ミスを減らすことができる。
【００３６】第２の効果はすべての機能が同じデータベース上に存在するため、機能毎、または、機能間の帳票出力が可能である。必要とされるデータをいつでも参照できることである。
【００３７】第３の効果は、リリース漏れ、リリース物件違い等のミスを防ぐことができる。つまり、各機能のデータをデータベース上でデータの整合性を確認することができ、手作業での管理を必要としないと共に複数のリリースフェーズ管理ができる。又、各必要なデータはすべてデータベース上に存在するため各機能毎又は機能間での帳票出力も可能である。
【出願人】 【識別番号】０００００４２３７
【氏名又は名称】日本電気株式会社
【出願日】 平成１３年４月１８日（２００１．４．１８）
【代理人】 【識別番号】１０００８２９３５
【弁理士】
【氏名又は名称】京本 直樹 （外２名）
【公開番号】 特開２００２−３１２１６９（Ｐ２００２−３１２１６９Ａ）
【公開日】 平成１４年１０月２５日（２００２．１０．２５）
【出願番号】 特願２００１−１１９６７５（Ｐ２００１−１１９６７５）