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