(57)【要約】【課題】プログラム開発において、プログラムのリリース時にリリース対象となるプログラムのうちのいくつかをリリースし忘れたり、リリース対象となるプログラムとリリース対象でないプログラムとを取り違えてリリースしたりといったことが頻繁に発生している。通常このようなミスは甚大なシステム障害を引き起こす。【解決手段】プログラム開発管理装置１００において、テーマ別プログラムテーブル１０は、開発すべきプログラムとリリース条件とを開発テーマごとに管理する。ディレクトリ生成部１３０は、テーマ別プログラムテーブル１０を参照し、リリース条件が同一のプログラムをひとつのリリース単位として抽出し、リリース単位のディレクトリをリリース記憶領域１７０に生成し、抽出したリリース単位のプログラムを当該ディレクトリに格納する。これによりリリース条件別にプログラムを管理することができる。【選択図】図２
2009244974.tif 000002
【特許請求の範囲】
【請求項１】
開発すべきプログラムとリリース条件とを開発テーマごとに管理するためのテーマ別プログラムテーブルと、
前記テーマ別プログラムテーブルを参照し、リリース条件が同一のプログラムをひとつのリリース単位として抽出し、リリース単位のディレクトリを生成し、抽出したリリース単位のプログラムを当該ディレクトリに格納するディレクトリ生成部と、を備えることを特徴とするプログラム開発管理装置。
【請求項２】
リリース単位でリリース承認を受けつけるリリース承認部をさらに備え、
前記リリース承認部が承認を受けつけたリリース単位に限って、ディレクトリ生成部にそのリリース単位についてのディレクトリの生成とそのディレクトリへのプログラムの格納を実行せしめることを特徴とする請求項１に記載のプログラム開発管理装置。
【請求項３】
前記テーマ別プログラムテーブルはプログラムの更新完了を示すフラグを含み、
前記リリース承認部は、前記テーマ別プログラムテーブルを参照し、リリース単位のプログラムのうちひとつでも更新完了を示すフラグがたっていないプログラムがあれば前記リリース単位のリリースの承認を受けつけないことを特徴とする請求項２に記載のプログラム開発管理装置。
【請求項４】
前記テーマ別プログラムテーブルはプログラムの更新完了を示すフラグを含み、
前記リリース承認部は、前記テーマ別プログラムテーブルを参照し、承認を受けつけたリリース単位のプログラムのなかに更新完了を示すフラグがたっていないプログラムがあれば警告を表示することを特徴とする請求項２に記載のプログラム開発管理装置。
【請求項５】
前記テーマ別プログラムテーブルはプログラムの更新完了を示すフラグを含み、
前記リリース承認部は、前記テーマ別プログラムテーブルを参照し、承認を受けつけたリリース単位のプログラムのなかに更新完了を示すフラグがたっていないプログラムがあれば、そのプログラムのリリース条件をあらかじめ定められた規則に従って変更し、そのプログラムを前記リリース単位から外すことを特徴とする請求項２に記載のプログラム開発管理装置。
【請求項６】
プログラムＩＤと、プログラムのパスまたは他のプログラムＩＤもしくはその両方とを関連付けて記憶するプログラムＩＤ別テーブルをさらに備えることを特徴とする請求項１に記載のプログラム開発管理装置。
【請求項７】
開発すべきプログラムとリリース条件とを開発テーマごとに管理するためのテーマ別プログラムテーブルを生成する機能と、
前記テーマ別プログラムテーブルを参照し、リリース条件が同一のプログラムをひとつのリリース単位として抽出し、リリース単位のディレクトリを生成し、抽出したリリース単位のプログラムを当該ディレクトリに格納する機能と、をコンピュータに実現させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム開発を管理する装置に関する。
【背景技術】
【０００２】
業務システムなどを構築するプログラムの開発更新を管理するために、バージョン管理システムが一般的に用いられている。このシステムでは、管理者は例えば開発テーマごとに開発対象プログラムの更新履歴等を管理できる。さらにこのシステムでは、開発者はプログラムを更新し、運用担当者は更新が完了したプログラムをリリースする。
【特許文献１】特開２００８−００３９８５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
通常、更新が完了したプログラムをリリースする際に開発テーマごとにリリースすることはほとんど無い。なぜならば、ある開発テーマに属するプログラムの間でも納期やリリース先のサーバ等のリリース条件が異なることが非常に多いからである。
【０００４】
したがって、リリース時にリリース対象となるプログラムを運用担当者がリリース会議の資料等に基づいて手作業で集めていた。このためリリース対象となるプログラムのうちのいくつかをリリースし忘れる「リリース漏れ」や、リリース対象となるプログラムとリリース対象でないプログラムとを取り違えてリリースする「リリース間違い」等が頻繁に発生する。通常このようなミスは甚大なシステム障害を引き起こす。
【０００５】
さらに、更新が完了していないプログラムをリリースしてしまうミスが発生した時に、それが運用側のミスなのか開発側のミスなのかを判断することは非常に煩雑である。
【０００６】
本発明はこうした課題に鑑みてなされたものであり、その目的は、プログラムのリリースを円滑に行うためのプログラム開発管理装置の提供にある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様のプログラム開発管理装置は、開発すべきプログラムとリリース条件とを開発テーマごとに管理するためのテーマ別プログラムテーブルと、テーマ別プログラムテーブルを参照し、リリース条件が同一のプログラムをひとつのリリース単位として抽出し、リリース単位のディレクトリを生成し、抽出したリリース単位のプログラムを当該ディレクトリに格納するディレクトリ生成部と、を備える。
【０００８】
この態様によると、テーマごとに管理されていたプログラムは、リリース条件ごとのディレクトリに格納されて管理される。運用担当者はそのディレクトリごとにリリースすることができ、リリース時におけるプログラムのリリース漏れやリリース間違い等を大幅に軽減することができる。
【０００９】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明に係るプログラム開発管理装置によれば、プログラムのリリースを正確に行うことができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。また、実施の形態は、発明を限定するものではなく例示であって、実施の形態に記述されるすべての特徴やその組み合わせは、必ずしも発明の本質的なものであるとは限らない。
【００１２】
本発明の実施の形態は、プログラム開発過程において開発テーマ単位で管理されていたプログラムをその更新後にリリース単位のディレクトリに格納し、そのディレクトリごとにリリースするプログラム開発管理装置を提供する。これによりリリース時におけるプログラムのリリース漏れやリリース間違い等を大幅に軽減することができる。
【００１３】
図１は、実施の形態に係るプログラム開発管理装置１００を含むプログラム開発システム１０００を示すシステム構成図である。プログラム開発システム１０００はプログラム開発管理装置１００と、開発用端末２００ａ、…、２００ｂと、開発リーダ端末３００と、運用担当端末４００と、顧客サーバ６００ａ、…、６００ｂとを含む。プログラム開発管理装置１００は、開発更新部１１０と、リリース承認部１２０と、ディレクトリ生成部１３０と、リリース実行部１４０と、記憶装置１５０を含む。
【００１４】
プログラム開発管理装置１００は、開発用端末２００ａ、…、２００ｂと、開発リーダ端末３００と、運用担当端末４００とイントラネット、インターネット等を介して接続される。ここでは特にプログラム開発管理装置１００をサーバとし、残りをクライアントとするクライアント・サーバ方式によって接続されてもよい。プログラム開発管理装置１００は、顧客サーバ６００ａ、…、６００ｂとインターネット等を介して接続される。
【００１５】
図２は、実施の形態に係るプログラム開発管理装置１００の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【００１６】
記憶装置１５０は、テーマ記憶領域１６０と、リリース記憶領域１７０を含む。テーマ記憶領域１６０にはテーマ別プログラムテーブル１０および開発対象のプログラムが記憶されている。リリース記憶領域１７０にはリリース別プログラムテーブル２０およびリリース対象のプログラムが記憶されている。
【００１７】
開発更新部１１０は開発リーダ端末３００や開発用端末２００ａ、…、２００ｂを通じて開発側とのインタフェースの役割を果たすとともに、テーマ記憶領域１６０内の開発対象プログラムを管理する。
【００１８】
リリース承認部１２０はリリース単位でリリース承認を受けつけ、テーマ別プログラムテーブル１０からそのリリース単位のプログラムＩＤを抽出し、リリース別プログラムテーブル２０に登録する。
【００１９】
ディレクトリ生成部１３０は、リリース別プログラムテーブル２０の情報に基づいてリリース記憶領域１７０にリリース単位のディレクトリを作成し、そこへプログラムを格納する。
【００２０】
リリース実行部１４０は、リリース単位に対するリリース命令を受けつけると、そのリリース単位のリリース条件が満たされるまでそのリリース単位のディレクトリをロックする。このようなディレクトリのロックは、例えば当該ディレクトリをクリック不可とすることで実現されてもよいし、当該ディレクトリを開くために所定のパスワードの入力を要求することで実現されてもよい。そしてリリース条件が満たされると、リリース単位のディレクトリごとに自動的に顧客サーバへプログラムをコピーする。以下図２の構成を具体例を挙げながら更に詳しく説明する。
【００２１】
開発更新部１１０：
開発更新部１１０は、開発リーダ端末３００から開発テーマを受けつけ、テーマ記憶領域１６０に開発テーマごとのディレクトリを作成し、そこにその開発テーマによって開発対象とされたプログラムを格納する。その後開発更新部１１０は、テーマ別プログラムテーブル１０に開発テーマの内容を登録する。
【００２２】
本実施の形態においては、開発更新部１１０はまずテーマ記憶領域１６０に「ｔｈｅｍｅ０１」という名前のディレクトリを作成する。そしてそのディレクトリに「ＪＡＶＡ（登録商標）」という名前のディレクトリを格納し、その「ＪＡＶＡ」という名前のディレクトリに「ｃｌａｓｓ」という名前のディレクトリを格納し、その「ｃｌａｓｓ」という名前のディレクトリにそれぞれ「ａｂｃ．ｃｌａｓｓ」、「ｇｈｉ．ｃｌａｓｓ」、「ｕｖｗ．ｃｌａｓｓ」、「ｘｙｚ．ｃｌａｓｓ」という名前のプログラムを格納する。以降「／ｔｈｅｍｅ０１／ＪＡＶＡ／ｃｌａｓｓ／」を「（ｔｈｅｍｅ）／」と略記する。
【００２３】
図３は、図２のテーマ別プログラムテーブル１０およびリリース別プログラムテーブル２０のデータ構造図である。テーマ別プログラムテーブル１０は、開発テーマごとに与えられる開発テーマＩＤと、プログラムごとに与えられそのプログラムを一意に特定するプログラムＩＤと、リリース条件と、更新完了フラグと、を関連付けて、開発テーマＩＤ別に記憶する。本実施の形態では、特にプログラムＩＤとしてプログラムのパスを採用し、リリース条件としてプログラムの納期を採用する。
【００２４】
リリース別プログラムテーブル２０は、リリースＩＤとプログラムＩＤとを関連付けてリリースＩＤ別に記憶する。ここでリリースＩＤとは、納期が同一のプログラムをひとつのリリース単位としたときにそのリリース単位ごとに与えられるＩＤである。
【００２５】
本実施の形態では、図３で示されるテーマ別プログラムテーブル１０に見られるとおり、開発テーマＩＤ「Ｔｈｅｍｅ０１」にプログラムＩＤ「（ｔｈｅｍｅ）／ａｂｃ．ｃｌａｓｓ」と、プログラムＩＤ「（ｔｈｅｍｅ）／ｇｈｉ．ｃｌａｓｓ」と、プログラムＩＤ「（ｔｈｅｍｅ）／ｕｖｗ．ｃｌａｓｓ」と、プログラムＩＤ「（ｔｈｅｍｅ）／ｘｙｚ．ｃｌａｓｓ」とが関連付けられる。
【００２６】
プログラムＩＤ「（ｔｈｅｍｅ）／ａｂｃ．ｃｌａｓｓ」およびプログラムＩＤ「（ｔｈｅｍｅ）／ｘｙｚ．ｃｌａｓｓ」に対応するプログラムの納期として１月１５日が登録され、プログラムＩＤ「（ｔｈｅｍｅ）／ｇｈｉ．ｃｌａｓｓ」およびプログラムＩＤ「（ｔｈｅｍｅ）／ｕｖｗ．ｃｌａｓｓ」に対応するプログラムの納期として２月１５日が登録される。
【００２７】
本実施の形態では、図３で示されるリリース別プログラムテーブル２０に見られるとおり、リリースＩＤ「ｒｅｌｅａｓｅ０１１５」にプログラムＩＤ「（ｔｈｅｍｅ）／ａｂｃ．ｃｌａｓｓ」と、プログラムＩＤ「（ｔｈｅｍｅ）／ｘｙｚ．ｃｌａｓｓ」とが後述するリリース承認部１２０によって関連付けられる。図３中の点線の矢印は、テーマ別プログラムテーブル１０中のどのプログラムＩＤがリリース承認部１２０によってリリース別プログラムテーブル２０中のリリースＩＤと関連付けられたかを示す矢印である。
【００２８】
図２に戻り開発更新部１１０について説明を続ける。次に開発更新部１１０は開発用端末２００ａ、…、２００ｂからプログラムの更新を受けつける。この更新受けつけは例えば以下の態様であってもよい。開発更新部１１０は記憶装置に作業用記憶領域を設け、そこへ開発対象のプログラムをテーマ記憶領域１６０からコピーする。開発用端末２００ａ、…、２００ｂにその作業用記憶領域内のプログラムを更新させる。そして更新の完了が通知されたプログラムを作業用記憶領域からテーマ記憶領域１６０へ上書きコピーをするとともにテーマ別プログラムテーブル１０のそのプログラムに対し更新完了フラグを立てる。開発更新部１１０は以上の態様によってプログラムの更新を受けつけてもよい。
【００２９】
開発更新部１１０はさらに開発リーダ端末３００からの求めに応じて、プログラムの開発状況を開発リーダ端末３００に表示させてもよい。これは例えば開発更新部１１０がテーマ別プログラムテーブル１０を参照した上で、更新完了フラグがたっているプログラムには「更新完了」の文言を対応付け、たっていないプログラムには「更新未完」の文言を対応付けたプログラムリストを表示させることによって実行されてもよい。
【００３０】
リリース承認部１２０：
リリース承認部１２０は、開発リーダ端末３００の求めに応じて、リリース承認画面８０を開発リーダ端末３００に表示させる。
図４は、リリース承認画面８０の画面図である。リリース承認画面８０は、納期欄７４と、リリースＩＤ欄７６と、承認ボタン欄７８を備える。納期欄７４には納期が表示され、リリースＩＤ欄７６にはその納期に対応するリリース単位のリリースＩＤを入力するスペースが設けられ、承認ボタン欄７８にはそのリリース単位のリリースの承認に関する押し下げ可能な承認ボタンまたは押し下げ不可な承認ボタンが表示される。ここで押し下げ不可な承認ボタンとはユーザによるクリックを受けつけないボタンである。
【００３１】
リリース承認部１２０は開発リーダ端末３００からの求めがあった後リリース承認画面８０を表示する前にテーマ別プログラムテーブル１０を参照し、プログラムの更新完了フラグを検索する。その結果リリース単位のプログラムのうちひとつでも更新完了を示すフラグがたっていないプログラムがあればそのリリース単位に対応する承認ボタン欄７８には押し下げ不可な承認ボタンを表示し、そうでなければ押し下げ可能な承認ボタンを表示する。
【００３２】
本実施の形態では、開発リーダ端末３００からリリース承認画面８０表示の求めがあった時点で、図３に示されるとおりの更新状況であるとする。つまり、プログラムＩＤ「（ｔｈｅｍｅ）／ａｂｃ．ｃｌａｓｓ」およびプログラムＩＤ「（ｔｈｅｍｅ）／ｇｈｉ．ｃｌａｓｓ」およびプログラムＩＤ「（ｔｈｅｍｅ）／ｘｙｚ．ｃｌａｓｓ」には更新完了フラグがたっているが、プログラムＩＤ「（ｔｈｅｍｅ）／ｕｖｗ．ｃｌａｓｓ」には更新完了フラグがたっていない状況である。
【００３３】
したがってリリース承認部１２０は、リリース承認画面８０において１月１５日納期のリリース単位に対応する承認ボタン欄７８には押し下げ可能な承認ボタン７０を表示し、２月１５日納期のリリース単位に対応する承認ボタン欄７８には押し下げ不可な承認ボタン７２を表示する。開発リーダは１月１５日納期分のプログラムのリリースを承認するために、リリースＩＤ欄７６の入力スペースにリリースＩＤである「ｒｅｌｅａｓｅ０１１５」を入力し、押し下げ可能な承認ボタン７０をクリックする。
【００３４】
図２に戻る。するとリリース承認部１２０はテーマ別プログラムテーブル１０を参照し、承認された１月１５日納期分のプログラムＩＤを読み出す。そのプログラムＩＤであるプログラムＩＤ「（ｔｈｅｍｅ）／ａｂｃ．ｃｌａｓｓ」およびプログラムＩＤ「（ｔｈｅｍｅ）／ｘｙｚ．ｃｌａｓｓ」と、リリースＩＤ「ｒｅｌｅａｓｅ０１１５」とをリリース別プログラムテーブル２０に登録する。その後ディレクトリ生成部１３０に対してそのリリースＩＤ「ｒｅｌｅａｓｅ０１１５」を送信する。
【００３５】
ディレクトリ生成部１３０：
ディレクトリ生成部１３０は、リリース承認部１２０によって送信されたリリースＩＤ「ｒｅｌｅａｓｅ０１１５」を受信する。するとまずディレクトリ生成部１３０はリリース記憶領域１７０の「ＲＥＬＥＡＳＥ」という名前のディレクトリ内に「ｒｅｌｅａｓｅ０１１５」という名前のディレクトリを作成する。次にリリース別プログラムテーブル２０を参照し、リリースＩＤ「ｒｅｌｅａｓｅ０１１５」に関連付けられたプログラムＩＤであるプログラムＩＤ「（ｔｈｅｍｅ）／ａｂｃ．ｃｌａｓｓ」およびプログラムＩＤ「（ｔｈｅｍｅ）／ｘｙｚ．ｃｌａｓｓ」を取得する。その後そのプログラムＩＤによって特定されるテーマ記憶領域１６０内のプログラム「ａｂｃ．ｃｌａｓｓ」とプログラム「ｘｙｚ．ｃｌａｓｓ」を読み出し、上記の「ｒｅｌｅａｓｅ０１１５」という名前のディレクトリに格納する。
【００３６】
リリース実行部１４０：
リリース実行部１４０は運用担当端末４００からの求めに応じてリリース記憶領域１７０を検索し、ディレクトリが設けられリリース可能なリリースＩＤの一覧を運用担当端末４００に表示させる。その後運用担当端末４００からリリースＩＤ「ｒｅｌｅａｓｅ０１１５」に対するリリース実行命令を受信する。するとリリース実行部１４０は、リリースＩＤ「ｒｅｌｅａｓｅ０１１５」に対応するリリース単位の納期である１月１５日まで、「ｒｅｌｅａｓｅ０１１５」という名前のディレクトリをクリック不可とする。納期である１月１５日になるとリリース実行部１４０は、「ｒｅｌｅａｓｅ０１１５」という名前のディレクトリに格納されたプログラムを全て取り出し、リリース先の顧客サーバ６００ａ〜６００ｂへコピーする。以上でプログラム開発の一連の処理が終了する。
【００３７】
以下、プログラム開発管理装置１００における処理の流れをフローチャートにて説明する。
図５は、プログラム開発管理における一連の処理を示すフローチャートである。開発リーダは開発リーダ端末３００からプログラム開発管理装置１００へ開発テーマを送信する（Ｓ９００）。その開発テーマによって開発対象とされたプログラムをテーマ記憶領域１６０へコピーする（Ｓ９０２）。テーマ別プログラムテーブル１０へ開発テーマＩＤと、プログラムＩＤと、納期とを登録する（Ｓ９０４）。開発担当者からのプログラムの更新を受けつける（Ｓ９０６）。
【００３８】
開発リーダは開発リーダ端末３００からリリース承認部１２０へリリース承認要求を送信する（Ｓ９０８）。リリース承認部１２０はテーマ別プログラムテーブル１０を参照し、納期ごとの更新完了フラグを読み出す（Ｓ９１０）。納期に対応する全てのプログラムが更新されていない場合（Ｓ９１２のＮ）、リリース承認画面８０のその納期に対応する承認ボタン欄７８には押し下げ不可な承認ボタンが表示され（Ｓ９１６）、それを開発リーダが確認し、Ｓ９０６の処理へ戻る。納期に対応する全てのプログラムが更新されている場合（Ｓ９１２のＹ）、リリース承認画面８０のその納期に対応する承認ボタン欄７８には押し下げ可能な承認ボタンが表示され（Ｓ９１４）、開発リーダがそのボタンをクリックすることで対応する納期のリリース単位のリリースを承認する（Ｓ９１８）。
【００３９】
リリース承認部１２０はテーマ別プログラムテーブル１０を参照し、承認されたリリース単位のプログラムＩＤを取得し、それとそのリリース単位に与えられたリリースＩＤとを関連付けてリリース別プログラムテーブル２０に登録する（Ｓ９２０）。リリース承認部１２０はそのリリースＩＤをディレクトリ生成部１３０へ送信する（Ｓ９２２）。ディレクトリ生成部１３０はそのリリースＩＤを受信し、リリース記憶領域１７０にそのリリースＩＤに対応するディレクトリを作成する（Ｓ９２４）。ディレクトリ生成部１３０はリリース別プログラムテーブル２０を参照し（Ｓ９２６）、そのリリースＩＤに関連付けられたプログラムＩＤに対応するプログラムをテーマ記憶領域１６０からそのリリースＩＤに対応するディレクトリへコピーする（Ｓ９２８）。
【００４０】
運用担当者はあらかじめ開発リーダから納期と対応するリリースＩＤを受け取る。納期が来ると運用担当者は運用担当端末４００からリリース実行部１４０へそのリリースＩＤを送信し、リリース実行部１４０はそのリリースＩＤに対応するディレクトリに格納されたプログラムを一括してリリースする（Ｓ９３０）。
【００４１】
本実施の形態に係るプログラム開発管理装置１００によれば、開発テーマごとに管理されていたプログラムは、それが更新された後に納期ごとのディレクトリに格納されて管理され、そのディレクトリごとにリリースされる。したがって、リリース時におけるプログラムのリリース漏れやリリース間違い等を大幅に軽減することができる。さらにリリース対象のプログラムを集めるスピードが向上する。
【００４２】
また、リリース実行部１４０はリリース実行命令を受け取った後、その実行命令を受けたリリース単位の納期までそのディレクトリをクリック不可とする。したがって運用担当者が誤って納期前にリリースしてしまうミスを防ぐことができる。さらに操作ミス等により上記リリース単位のディレクトリ内のプログラムが破壊されること防ぐことができる。また、納期になると人手を介さずにリリース単位でプログラムをリリースするのでより確実に納期を守ることができる。
【００４３】
また、リリース承認部１２０によってリリースの承認が受けつけられたリリース単位に限って対応するディレクトリがリリース記憶領域１７０に作成される。したがって、万が一更新が完了していないプログラムがリリースされたとしても、その責任は運用側ではなく開発側にあることをはっきりさせることができる。つまり監査証跡実現する。
【００４４】
また、リリース承認画面８０において更新完了フラグのたっていないプログラムを含むリリース単位に対しては承認ボタンを押し下げることができない。したがって、開発リーダのミスによって更新完了フラグがたっていないプログラムがリリースされることを防ぐことが可能となる。
【００４５】
図６は、リリース条件の変形例に係るテーマ別プログラムテーブル１６およびリリース別プログラムテーブル２４のデータ構造図である。リリース条件は開発を依頼する顧客の要望などの状況に応じて定めてもよい。例えば顧客がサーバＡにリリースするプログラムをできるだけ早く更新してほしい、という要望を持つときは図６のテーマ別プログラムテーブル１６に示すとおり、リリース条件をサーバとする。すると開発リーダはリリース承認画面にて更新状況を確認し、サーバＡにリリースするプログラムの更新が済み次第サーバＡへのリリースを実行することにより顧客の要望を満足することができる。本変形例によれば、以上のような柔軟な顧客への対応を実現できる。
【００４６】
図７は、リリース承認部１２０の第１の変形例に係る警告画面８２の画面図である。本変形例では、リリース承認部１２０は開発リーダ端末３００の求めに応じて、テーマ別プログラムテーブル１０を参照することなくリリース承認画面を開発リーダ端末３００に表示させる。このリリース承認画面では全ての納期に対して押し下げ可能な承認ボタンが表示される。つまり本変形例では図４に示されるリリース承認画面８０において、２月１５日納期分に対しては押し下げ不可な承認ボタン７２の代わりに押し下げ可能な承認ボタン７０が表示される。
【００４７】
そしてその２月１５日納期分に対応する押し下げ可能な承認ボタンがクリックされると、リリース承認部１２０はテーマ別プログラムテーブル１０を参照する。その結果２月１５日納期分のプログラムのなかに更新完了フラグがたっていないプログラムがあることを認識し、図７に示される警告画面８２を開発リーダ端末３００に表示させる。その後リリース承認部１２０は２月１５日納期分に対応する承認ボタンのクリックを無効とする処理を行いリリース承認画面を閉じる。
【００４８】
本変形例によれば、ある納期をもつプログラムについて開発リーダにその更新が完了していないことを警告画面を通じて知らせることができる。また、開発リーダのミスによって更新が完了していないプログラムがリリースされることを防ぐことができる。
【００４９】
図８は、リリース承認部１２０の第２の変形例に係る注意画面８４の画面図である。図９は、リリース承認部１２０の第２の変形例に係るテーマ別プログラムテーブル１２、１４およびリリース別プログラムテーブル２２のデータ構造図である。本変形例では、あらかじめ決められた期間、例えば１ヶ月、が開発リーダによってプログラム開発管理装置１００に登録される。これは例えばリリース承認部１２０が開発リーダ端末３００に表示させるリリース承認画面に「延長期間」の項目および対応する入力スペースを設け、そこに入力された値をテーマ記憶領域１６０内の適切なファイルに保存することによって実現されてもよい。
【００５０】
また本変形例では、リリース承認部１２０は納期ごとの承認日の登録を受けつける。これは例えばリリース承認画面に承認日の欄をさらに設け、その欄に納期ごとの承認日を入力するスペースを設けることで実現されてもよい。
【００５１】
本変形例では図８で示されるテーマ別プログラムテーブル１２に見られるとおり、開発テーマＩＤ「Ｔｈｅｍｅ０１」にプログラムＩＤ「（ｔｈｅｍｅ）／ａｂｃ．ｃｌａｓｓ」と、プログラムＩＤ「（ｔｈｅｍｅ）／ｇｈｉ．ｃｌａｓｓ」と、プログラムＩＤ「（ｔｈｅｍｅ）／ｕｖｗ．ｃｌａｓｓ」と、プログラムＩＤ「（ｔｈｅｍｅ）／ｘｙｚ．ｃｌａｓｓ」とが関連付けられる。全てのプログラムの納期として１月１５日が登録される。
【００５２】
本変形例では、１月１５日納期分に対して入力された承認日が来ると、リリース承認画面を開発リーダ端末３００に表示させる。そのリリース承認画面では１月１５日納期分に対して押し下げ可能な承認ボタンが表示される。そのボタンがクリックされると、リリース承認部１２０はテーマ別プログラムテーブル１２を参照する。その結果１月１５日納期分のプログラムＩＤのなかに更新完了フラグがたっていないプログラムＩＤがあることを認識する。本変形例ではプログラムＩＤ「（ｔｈｅｍｅ）／ｇｈｉ．ｃｌａｓｓ」に対応する更新完了フラグがたっていないことを認識する。
【００５３】
するとリリース承認部１２０は図９に示されるとおり、そのプログラムＩＤに対応するプログラムの納期を上記あらかじめ決められた期間、例えば１ヶ月、延長してテーマ別プログラムテーブル１４に登録し直す。その後、残りの１月１５日納期分のプログラムのプログラムＩＤとリリースＩＤとを関連付けてリリース別プログラムテーブル２２に登録する。
【００５４】
本変形例によれば、更新の完了していないプログラムのリリースを防ぐことができるとともに、納期にその開発が間に合わなかったプログラムがリリースの対象から外れてしまうことを防ぐことができる。
【００５５】
図１０は、プログラム開発管理装置１００の変形例に係るディレクトリ構成図である。本変形例では、「／ｊａｖａ／ｓｒｃ／ａｂｃ．ｊａｖａ」というパスをもつプログラム（以降単に「ａｂｃ．ｊａｖａ」と表記）をコンパイルすることにより「／ｊａｖａ／ｓｒｃ／ｃｌａｓｓ／ａｂｃ．ｃｌａｓｓ」というパスをもつプログラム（以降単に「ａｂｃ．ｃｌａｓｓ」と表記）が生成される（Ｒ２）。また、「／ｊａｖａ／ｓｒｃ／ｄｅｆ．ｊａｖａ」というパスをもつプログラム（以降単に「ｄｅｆ．ｊａｖａ」と表記）をコンパイルすることにより「／ｊａｖａ／ｃｌａｓｓ／ｄｅｆ．ｃｌａｓｓ」というパスをもつプログラム（以降単に「ｄｅｆ．ｃｌａｓｓ」と表記）が生成される（Ｒ４）。また、「／ｊａｖａ／ｓｒｃ／ｌｉｂ／ｇｈｉ＿ｌｉｂ．ｊａｖａ」というパスをもつプログラム（以降単に「ｇｈｉ＿ｌｉｂ．ｊａｖａ」と表記）をコンパイルすることにより「／ｊａｖａ／ｓｒｃ／ｃｌａｓｓ／ｌｉｂ／ｇｈｉ＿ｌｉｂ．ｃｌａｓｓ」というパスをもつプログラム（以降単に「ｇｈｉ＿ｌｉｂ．ｃｌａｓｓ」と表記）が生成される（Ｒ６）。「ａｂｃ．ｃｌａｓｓ」は「ｇｈｉ＿ｌｉｂ．ｃｌａｓｓ」を参照する（Ｒ８）。「ａｂｃ．ｃｌａｓｓ」は「ｄｅｆ．ｃｌａｓｓ」を参照する（Ｒ１０）。
また、「ｇｈｉ＿ｌｉｂ．ｃｌａｓｓ」は、複数のプログラムが共用するプログラム（ライブラリ）であり、「ａｂｃ．ｃｌａｓｓ」以外の他の多くのプログラムによっても参照される。
【００５６】
図１１は、図１０の変形例に係るプログラムＩＤ別テーブル６０を示すデータ構造図である。本変形例では、プログラム開発管理装置１００はその記憶装置１５０内にプログラムＩＤ別テーブル６０をさらに備える。プログラムＩＤ別テーブル６０は、互いに関係のある複数のプログラムのパスと、その関係を一意に特定するプログラムＩＤとを関連付けて記憶する。また、このプログラムのパスは他のプログラムＩＤを含んでもよい。その場合、元のプログラムＩＤを親、その親プログラムＩＤに関連付けれられたプログラムＩＤを子プログラムＩＤとしてプログラムＩＤの間でいわゆる親子関係を定めることができる。
【００５７】
本変形例において、「ａｂｃ．ｃｌａｓｓ」を更新のため登録する場合などでは、そのプログラムの登録時に上記Ｒ２、Ｒ８およびＲ１０の関係があるプログラムを同時に登録できれば便利である。そこでプログラムＩＤ別テーブル６０に、プログラムＩＤ「ＡＢＣ」と、パス「／ｊａｖａ／ｓｒｃ／ａｂｃ．ｊａｖａ」、パス「／ｊａｖａ／ｓｒｃ／ｃｌａｓｓ／ａｂｃ．ｃｌａｓｓ」、プログラムＩＤ「ＤＥＦ」およびプログラムＩＤ「ＧＨＩ＿ＬＩＢ」とを関連付けて記憶させる。ここでプログラムＩＤ「ＤＥＦ」は上記Ｒ４の関係があるプログラムのパスに関連付けられたプログラムＩＤであり、プログラムＩＤ「ＧＨＩ＿ＬＩＢ」は上記Ｒ６の関係があるプログラムのパスに関連付けられたプログラムＩＤである。プログラムＩＤ「ＤＥＦ」および「ＧＨＩ＿ＬＩＢ」は親プログラムＩＤ「ＡＢＣ」の子プログラムＩＤとなる。
【００５８】
プログラムＩＤ「ＡＢＣ」がプログラム開発管理装置１００のいずれかの構成によって指定された場合、その構成はプログラムＩＤ別テーブル６０を参照し、プログラムＩＤ「ＡＢＣ」に関連付けられたパス「／ｊａｖａ／ｓｒｃ／ａｂｃ．ｊａｖａ」、パス「／ｊａｖａ／ｓｒｃ／ｃｌａｓｓ／ａｂｃ．ｃｌａｓｓ」、プログラムＩＤ「ＤＥＦ」およびプログラムＩＤ「ＧＨＩ＿ＬＩＢ」を読み出し、さらにプログラムＩＤ「ＤＥＦ」に関連付けられたパス「／ｊａｖａ／ｓｒｃ／ｄｅｆ．ｊａｖａ」およびパス「／ｊａｖａ／ｃｌａｓｓ／ｄｅｆ．ｃｌａｓｓ」を読み出し、さらにプログラムＩＤ「ＧＨＩ＿ＬＩＢ」に関連付けられたパス「／ｊａｖａ／ｓｒｃ／ｌｉｂ／ｇｈｉ＿ｌｉｂ．ｊａｖａ」およびパス「／ｊａｖａ／ｓｒｃ／ｃｌａｓｓ／ｌｉｂ／ｇｈｉ＿ｌｉｂ．ｃｌａｓｓ」を読み出す。
【００５９】
本変形例によれば、あらかじめプログラム間の関係にプログラムＩＤを割り振ることにより、プログラムをそれらの間の関係も含めて管理することができる。したがって、開発対象のプログラムの登録時にはその登録漏れを防ぐことができ、また、リリース時にもそのリリース漏れを防ぐことができる。
【００６０】
また、「ａｂｃ．ｃｌａｓｓ」を修正する際にはＲ１０の関係があるので「ｄｅｆ．ｃｌａｓｓ」も同時に登録する必要がある。この時はプログラムＩＤ「ＡＢＣ」を指定する。「ｄｅｆ．ｃｌａｓｓ」のみを修正する際には親プログラムＩＤ「ＡＢＣ」を指定するのではなくその子プログラムＩＤ「ＤＥＦ」を指定すればよい。このように本変形例においてはプログラムＩＤに親子関係を持たせることにより、一方向の参照関係がある場合などでもプログラムを効率的に管理できる。
【００６１】
また、プログラムＩＤ「ＧＨＩ＿ＬＩＢ」はプログラムＩＤ「ＡＢＣ」以外のプログラムＩＤの子プログラムＩＤとして登録されてもよい。とくに「ｇｈｉ＿ｌｉｂ．ｃｌａｓｓ」を参照するプログラムに関連付けられたプログラムＩＤの子プログラムＩＤとして登録されると便利である。このようにプログラムＩＤの親子関係を定めることにより、複数のプログラムが共用するプログラム(ライブラリ)を用いたシステムを開発する場合に、効率的にプログラムを管理できる。
【００６２】
以上、実施の形態にもとづき本発明を説明したが、実施の形態は、本発明の原理、応用を示しているにすぎないことはいうまでもなく、実施の形態には、請求の範囲に規定された本発明の思想を逸脱しない範囲において、多くの変形例や配置の変更が可能であることはいうまでもない。
【図面の簡単な説明】
【００６３】
【図１】実施の形態に係るプログラム開発管理装置を含むプログラム開発システムを示すシステム構成図である。
【図２】実施の形態に係るプログラム開発管理装置の機能および構成を示すブロック図である。
【図３】図２のテーマ別プログラムテーブルおよびリリース別プログラムテーブルのデータ構造図である。
【図４】リリース承認画面の画面図である。
【図５】プログラム開発管理における一連の処理を示すフローチャートである。
【図６】リリース条件の変形例に係るテーマ別プログラムテーブルおよびリリース別プログラムテーブルのデータ構造図である。
【図７】リリース承認部の第１の変形例に係る警告画面の画面図である。
【図８】リリース承認部の第２の変形例に係る注意画面の画面図である。
【図９】リリース承認部の第２の変形例に係るテーマ別プログラムテーブル、およびリリース別プログラムテーブルのデータ構造図である。
【図１０】プログラム開発管理装置の変形例に係るディレクトリ構成図である。
【図１１】図１０の変形例に係るプログラムＩＤ別テーブルを示すデータ構造図である。
【符号の説明】
【００６４】
１  テーマ別プログラムテーブル、  ８０  リリース承認画面、  １００  プログラム開発管理装置、  １１０  開発更新部、  １２０  リリース承認部、  １３０  ディレクトリ生成部、  １４０  リリース実行部、  １５０  記憶装置。
【図１】
2009244974.tif 000003
【図２】
2009244974.tif 000004
【図３】
2009244974.tif 000005
【図４】
2009244974.tif 000006
【図５】
2009244974.tif 000007
【図６】
2009244974.tif 000008
【図７】
2009244974.tif 000009
【図８】
2009244974.tif 000010
【図９】
2009244974.tif 000011
【図１０】
2009244974.tif 000012
【図１１】
2009244974.tif 000013