(57)【要約】【課題】  プログラムのリリースの実施によって、プログラムの属性から新規登録等されたことを容易に確認することができること。【解決手段】  リリースされたプログラムをチェックするチェック装置であって、現時点におけるプログラムの第１属性を記録した今回登録簿記憶部１５と、前回のチェック時におけるプログラムの第２属性を記録した前回登録簿記憶部１６と、前記第１属性と、前記第２属性とを比較した結果を出力するプログラム登録簿比較部１０と、前記プログラム登録簿比較部１６で出力された結果に基づいて、変更分リストを作成するプログラム変更リスト作成部１２と、から構成されることを特徴とするチェック装置。【選択図】  図３
2005267341.tif 000002
【特許請求の範囲】
【請求項１】
リリースされたプログラムをチェックするチェック装置であって、
現時点におけるプログラムの第１属性を記録した今回登録簿記憶部と、
前回のチェック時におけるプログラムの第２属性を記録した前回登録簿記憶部と、
前記第１属性と、前記第２属性とを比較した結果を出力するプログラム登録簿比較部と、
前記プログラム登録簿比較部で出力された結果に基づいて、変更分リストを作成するプログラム変更リスト作成部と、
から構成されることを特徴とするチェック装置。
【請求項２】
前記第１属性及び前記第２属性は、少なくともプログラム識別子と最新更新日時とが含まれていることを特徴とする請求項１に記載のチェック装置。
【請求項３】
前記プログラム登録簿比較部は、前記第１属性と、前記第２属性とを比較して、プログラムの状態を判断することを特徴とする請求項１及び請求項２のいずれか１項に記載のチェック装置。
【請求項４】
請求項１記載のチェック装置において、リリースされたプログラムをチェックする方法であって、
前記チェック装置が、
ａ）現時点におけるプログラムの第１属性を前記今回登録簿記憶部に記録するステップと、
ｂ）前回のチェック時におけるプログラムの第２属性を前記前回登録簿記憶部に記録するステップと、
ｃ）前記第１属性と、前記第２属性とを比較した結果を出力するステップと、
ｄ）当該出力された結果に基づいて、変更分リストを作成するステップと、
を実行することを特徴としたプログラムリリースチェック方法。
【請求項５】
請求項１記載のチェック装置に用いられるプログラムであって、
前記チェック装置に、
ａ）現時点におけるプログラムの第１属性を前記今回登録簿記憶部に記録するステップと、
ｂ）前回のチェック時におけるプログラムの第２属性を前記前回登録簿記憶部に記録するステップと、
ｃ）前記第１属性と、前記第２属性とを比較した結果を出力するステップと、
ｄ）当該出力された結果に基づいて、変更分リストを作成するステップと、
を実行させることを特徴としたプログラムリリースチェックプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リリースが行われたプログラムに関して属性を自動的にチェックするチェック装置及び方法及びプログラムに関する。
【背景技術】
【０００２】
従来、基幹システムサーバへプログラムをリリースする場合、社内で決められたリリース手続を踏み、プログラムのリリースを行っていた。具体的なリリース手続としては、以下の（１）から（４）までの手続を順次行っていた。
【０００３】
（１）リリース実施者はリリース手続書を起票して、基幹システムサーバにおいて、新規登録するプログラム、変更するプログラム、削除するプログラム等の属性を当該リリース手続書に記載する。
【０００４】
（２）リリース実施者はリリース手続書をリリース実施者が属するリリースチームのチームリーダや基幹システムサーバ管理者等の関係者に提示、回覧等して、当該リリース手続書にチームリーダより承認印をもらう。
【０００５】
（３）リリース実施者又はチームリーダはリリース手続書をチームリーダの上司に提示して、当該リリース手続書に承認印をもらう。
【０００６】
（４）リリース実施者はプログラムのリリースを基幹システムサーバへ実施する。
【０００７】
そして、リリース実施者、チームリーダ、上司、基幹システムサーバの管理者等の関係者は、リリース手続書に基づいて、リリースの実施された内容を現実に、新規登録、変更又は削除されたプログラム等の属性を確認することができる。
【０００８】
しかしながら、上記関係者は、リリースの実施された内容を現実に、新規登録、変更又は削除されたプログラム等の属性を確認することはできない場合もあった。このため、次のような二次的な問題も発生していた。
【０００９】
〔緊急リリース後における障害の原因究明〕
【００１０】
従来、基幹システムサーバに緊急な障害等が発生した際に、リリース実施者が、上記リリース手続を省略して、緊急な障害に対応した新たなプログラムをリリースする場合があった（以下、緊急リリースという。）。この場合、緊急リリースに対応するリリース手続書は緊急リリースが実施された後に作成されていた。このため、リリース手続書が作成される前に緊急リリースに起因する別の障害が発生した場合には、リリース手続書が存在しないので、緊急リリースによって新規登録、変更、又は削除されたプログラムを確認することもできず、障害の原因究明に多大な時間と労力がかかっていた。
【００１１】
〔リリース手続書を作成しない不正なプログラムリリース〕
【００１２】
従来、故意又は過失により、上記リリース手続を省略して、基幹システムサーバにプログラムをリリースした場合、関係者はその事実を認知することができなかった。
【００１３】
これらに関して、記述された先行技術文献を出願人は知らない。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明は、プログラムのリリースの実施によって、プログラムの属性から新規登録等されたことを容易に確認することができることを課題とする。
【課題を解決するための手段】
【００１５】
上記課題を解決するため、本発明では次のような構成を採っている。
【００１６】
請求項１記載の発明は、リリースされたプログラムをチェックするチェック装置である。当該チェック装置は、現時点におけるプログラムの第１属性を記録した今回登録簿記憶部と、前回のチェック時におけるプログラムの第２属性を記録した前回登録簿記憶部と、前記第１属性と、前記第２属性とを比較した結果を出力するプログラム登録簿比較部と、前記プログラム登録簿比較部で出力された結果に基づいて、変更分リストを作成するプログラム変更リスト作成部と、から構成されることを特徴とする。ここで、属性とは、プログラムを識別するために必要な情報であって、例えば、本実施形態にあっては新規、更新、削除を判断するにあたって必要な情報のことである。特に、今回登録簿記憶部に記録した属性を第１属性といい、前回登録簿記憶部に記録した属性を第２属性という。
【００１７】
請求項２記載の発明は、第１属性及び第２属性は、少なくともプログラム識別子と最新更新日時とが含まれていることを特徴とする請求項１に記載のチェック装置である。
【００１８】
請求項３記載の発明は、プログラム登録簿比較部は、第１属性と、第２属性とを比較して、プログラムの状態を判断することを特徴とする請求項１及び請求項２のいずれか１項に記載のチェック装置である。
【００１９】
請求項４記載の発明は、請求項１記載のチェック装置において、リリースされたプログラムをチェックする方法である。当該方法は、チェック装置が、現時点におけるプログラムの第１属性を前記今回登録簿記憶部に記録するステップと、前回のチェック時におけるプログラムの第２属性を前回登録簿記憶部に記録するステップと、第１属性と、第２属性とを比較した結果を出力するステップと、当該出力された結果に基づいて、変更分リストを作成するステップと、を実行することを特徴とする。
【００２０】
請求項５記載の発明は、請求項１記載のチェック装置に用いられるプログラムである。当該プログラムは、チェック装置に、現時点におけるプログラムの第１属性を今回登録簿記憶部に記録するステップと、前回のチェック時におけるプログラムの第２属性を前回登録簿記憶部に記録するステップと、第１属性と、第２属性とを比較した結果を出力するステップと、当該出力された結果に基づいて、変更分リストを作成するステップと、を実行させることを特徴とする。
【発明の効果】
【００２１】
プログラムのリリースの実施によって、プログラムの属性から新規登録等されたことを容易に確認することができる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の一実施形態を図１乃至図６に基づいて説明する。
【００２３】
図１は、本発明を適用したプログラムリリースチェックシステムの全体構成図である。このプログラムリリースチェックシステムは、基幹システムサーバ１０（チェック装置とも言う）と、メール配信サーバ２０と、関係者端末３０と、コンピュータネットワーク４０とを備えて構成されている。
【００２４】
このうち、基幹システムサーバ１０は、関係者端末３０から送信されたプログラムのリリースを管理するコンピュータである。また、メール配信サーバ２０は、プログラムリリースに関する情報を基幹システムサーバ１０から受信し、この情報を関係者端末３０にメール配信するコンピュータである。また、関係者端末３０は、プログラムリリースに関するリリース実施者及びチームリーダを含むリリースチーム、上司等を含むリリース承認者、又は基幹システムサーバ１０の管理者等が使用するコンピュータである。この関係者端末３０は、リリースするプログラム及びその属性（この属性はプログラムと一体となっているものでも、別体となっているものでも良い）を基幹システムサーバ１０に送信する機能と、メール配信サーバ２０から電子メールを受信する機能とを備えている。ここで、プログラムとは、ソースプログラムでも、オブジェクトプログラムのいずれであっても良いが、本実施形態では主にオブジェクトプログラムの場合について説明する。また、ここで、属性とは、プログラムを識別するために必要な情報であって、例えば、本実施形態にあっては新規、更新、削除を判断するにあたって必要な情報のことである。また、コンピュータネットワーク４０は、インターネットやイントラネットを利用し、基幹システムサーバ１０、メール配信サーバ２０及び関係者端末３０が相互にデータ通信可能になっていればよい。
【００２５】
基幹システムサーバ１０及びメール配信サーバ２０は、一般的なコンピュータのハードウェア構成を採っており、図２に示すように、処理装置（ＣＰＵ）と、記憶装置としての主記憶（ＭＥＭ）及び補助記憶（ＨＤＤ）と、通信装置としてのコンピュータネットワーク４０への通信インタフェース（ＮＩＣ）とがバスに接続されている。
【００２６】
基幹システムサーバ１０及びメール配信サーバ２０は、上記ＣＰＵが所定のプログラムを実行することにより、プログラムリリースの管理機能と、プログラムリリースに関する情報の配信機能とを実現するようになっている。
【００２７】
図３は、基幹システムサーバ１０及びメール配信サーバ２０の機能ブロック図である。基幹システムサーバ１０は、プログラム登録簿比較部１１と、プログラム変更リスト作成部１２と、リスト転送部１３と、その他の処理部１４とを備えている。これらの各部は、基幹システムサーバ１０のＣＰＵが所定のプログラムを実行することによって実現される。また、これらの各部が動作するために必要な情報が各記憶部に格納されるようになっており、今回登録簿記憶部１５と、前回登録簿記憶部１６と、変更分リスト記憶部１７とを備えている。
【００２８】
まず、各記憶部に格納される情報の内訳を説明する。今回登録簿記憶部１５には、「今回登録簿」が格納される。基幹システムサーバ１０のＣＰＵは、ＮＩＣを介して関係者端末３０からリリース対象のプログラムを受信する毎に、そのプログラムの属性を今回登録簿記憶部１５に記録する。今回登録簿記憶部１５のデータ構造は図４に示す構造となっており、レコードの通番（Ｎｏ．）と、以下の項目が、例えば、プログラムの属性として、プログラム識別子（プログラム名）と、そのプログラムの記述言語（言語）と、そのプログラムの登録日と、そのプログラムの最新更新日時と、そのプログラムの更新者識別子（更新者ＩＤ）と、そのプログラムのプログラムサイズとが関連付けて記録されるようになっている。図４では、「状態」フィールドを図示しているが、このフィールドは今回登録簿記憶部１５には必要が無く、後の説明の便宜のために図示したものである。基幹システムサーバ１０のＣＰＵは、関係者端末３０からリリース対象のプログラムを受け付ける毎に、上記項目を属性の情報として今回登録簿記憶部１５に記録する。
【００２９】
また、今回登録簿記憶部１５の記録データは、後で説明するプログラムリリースのチェック処理に用いられるのだが、このチェック処理に一度用いられた後は、今回登録簿記憶部１５の記録データが履歴として前回登録簿記憶部１６にバックアップされるようになっている。「今回登録簿」を「前回登録簿」としてバックアップした後に、引き続き「今回登録簿」が更新されてゆくと、その後のプログラムリリースのチェック処理の際に、その時点の「今回登録簿」と「前回登録簿」とを比較すれば、所定期間内に更新されたプログラムだけを抽出することができるからである。このために、前回登録簿記憶部１６が設けられており、前回登録簿記憶部１６のデータ構造は、先に述べた今回登録簿記憶部１５のデータ構造と同一である。
【００３０】
また、基幹システムサーバ１０のＣＰＵは、プログラムリリースのチェック処理により更新されたプログラム（新規登録されたプログラム及び削除されたプログラムを含む）を検出すると、検出された当該プログラムの内訳を変更分リストに書き出すようになっている。このため、変更分リスト記憶部１７に記憶されているが設けられている。変更分リスト記憶部１７に記憶されている変更分リストのデータ構造は、基本的には、今回登録簿又は前回登録簿のデータ構造と共通であるが、図４に示す「状態」フィールドのデータも関連付けて記憶するようになっている。この「状態」フィールドには、更新を検出したプログラムについて、その更新内容がプログラムの「新規」登録であったか、既登録プログラムの「更新」であったか又は既登録プログラムの「削除」であったかのフラグを記録するようになっている。これらの記憶部を利用しつつ、基幹システムサーバ１０のコンピュータ処理が進められる。
【００３１】
一方、メール配信サーバ２０は、リスト受信部２１と、メール作成部２２と、メール送信部２３と、その他の処理部２４とを備えている。これらの各部は、メール配信サーバ２０のＣＰＵが所定のプログラムを実行することによって実現される。また、これらの各部が動作するために必要な情報が各記憶部に格納されるようになっており、変更分リスト記憶部２５と、メール雛型記憶部２６と、完成メール記憶部２７と、メール宛先記憶部２８とを備えている。
【００３２】
変更分リスト記憶部２５は、リスト受信部２１が基幹システムサーバ１０から受信した変更分リストを格納するようになっている。メール雛型記憶部２６は、メール作成部２２が電子メールのデータを作成する際に利用するメール雛型を予め格納している。また、完成メール記憶部２７は、メール作成部２２が作成した電子メールのデータを格納するようになっている。そして、メール宛先記憶部２８は、リリース実施者、チームリーダ、上司、基幹システムサーバ管理者等の関係者のメールアドレスを予め記録している。これらの記憶部を利用しつつ、メール配信サーバ２０のコンピュータ処理が進められる。
【００３３】
次に、本願システムの動作について説明する。
【００３４】
基幹システムサーバ１０の行うコンピュータ処理は大きく２つに分かれるが、一つは、リリース対象のプログラムを関係者端末３０から受信する毎に、当該プログラムの属性を前述の今回登録簿に記録する処理及び当該プログラムをユーザに向けてリリースする処理である。この処理により、今回登録簿の内容は随時更新されてゆく。即ち、図４に示したＮｏ、プログラム名、言語、登録日、最新更新日時、更新者ＩＤ及びプログラムサイズが随時更新されてゆく。
【００３５】
以下、プログラムを新規登録する、プログラムを更新する、プログラムを削除する場合について、今回登録簿記憶部１５の更新について詳細に説明する。
【００３６】
〔プログラムを新規登録する場合〕
【００３７】
基幹システムサーバ１０のＣＰＵは、関係者端末３０からＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）等により、プログラムを受信してＨＤＤに記録する。続いて、基幹システムサーバ１０のＣＰＵは、当該ＨＤＤに記録したプログラムのプログラム名をＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）の提供する機能を利用して取得する。なお、本実施形態では、ＯＳの提供する機能を利用して属性を取得しているが、属性を取得する機能を専用に設けても良いことは言うまでもない。そして、基幹システムサーバ１０のＣＰＵは、当該取得したプログラム名が、今回登録簿記憶部１５に記録されていない場合に、次の処理を行う。基幹システムサーバ１０のＣＰＵは、ＯＳの提供する機能等を利用して、上記ＨＤＤに記録したプログラムの、言語、登録日、最新更新日時、更新者ＩＤ、及びプログラムサイズを取得する。次に、基幹システムサーバ１０のＣＰＵは、新たなＮｏ（通番）を発行すると共に、当該発行したＮｏ（通番）と、ＯＳの機能を利用して取得した、プログラム名と、言語と、登録日と、最新更新日時と、更新者ＩＤと、プログラムサイズとを関連付けて新たなレコードとして今回登録簿記憶部１５に記録する。
【００３８】
〔プログラムを更新する場合〕
【００３９】
基幹システムサーバ１０のＣＰＵは、関係者端末３０からＦＴＰ等により、プログラムを受信してＨＤＤに記録する。ここで、基幹システムサーバ１０のＣＰＵは、関係者端末３０から受信したプログラムと同一のプログラム名を有するプログラムがＨＤＤに既に格納されている場合には、関係者端末３０から受信したプログラムを既に格納されているプログラムに上書きして記録する。続いて、基幹システムサーバ１０のＣＰＵは、当該ＨＤＤに記録したプログラムのプログラム名をＯＳの提供する機能を利用して取得する。そして、基幹システムサーバ１０のＣＰＵは、当該取得したプログラム名が、今回登録簿記憶部１５に記録されている場合に、次の処理を行う。基幹システムサーバ１０のＣＰＵは、ＯＳの提供する機能を利用して、上記ＨＤＤに記録したプログラムの最新更新日時、更新者ＩＤ、及びプログラムサイズを取得する。次に、基幹システムサーバ１０のＣＰＵは、今回登録簿記憶部１５においてプログラム名フィールドの値がＯＳの提供する機能等を利用して取得したプログラム名と同一のレコードに対して、最新更新日時、更新者ＩＤ、及びプログラムサイズを更新する。
【００４０】
〔プログラムを削除する場合〕
【００４１】
基幹システムサーバ１０のＣＰＵは、関係者端末３０からＴＥＬＮＥＴ等により、プログラムの削除命令及び削除対象のプログラム名を受信する。そして、基幹システムサーバ１０のＣＰＵは、当該削除命令に基づいて、削除対象のプログラム名に対応するプログラムを削除する。続いて、基幹システムサーバ１０のＣＰＵは、今回登録簿においてプログラム名フィールドの値が削除対象のプログラム名と同一のレコードを削除する。
【００４２】
一方、基幹システムサーバ１０が実行するもう一つの重要な処理は、（これは所定の時期が訪れる毎に実行されるのだが、）プログラムリリースのチェック処理である。このチェック処理について、図３の機能ブロックを参照しつつ説明してゆく。
【００４３】
プログラムリリースのチェック処理が指示されると、プログラム登録簿比較部１１は、その時点における今回登録簿のデータを今回登録簿記憶部１５から読み出すとともに、その時点における前回登録簿のデータを前回登録簿記憶部１６から読み出す。そして、両方の登録簿を比較し、変更点、つまり不一致箇所を検出する。この変更点は、プログラム変更リスト作成部１２に引き渡され、プログラム変更リスト作成部１２が、変更点だけをリストした変更分リストを変更分リスト記憶部１７に作成する。この処理を図５のフローチャートに沿って説明する。
【００４４】
基幹システムサーバ１０のＣＰＵは、所定の時刻に、今回登録簿記憶部１５から今回登録簿を読み出すと共に、前回登録簿記憶部１６から前回登録簿を読み出す（Ｓ１）。そして、基幹システムサーバ１０のＣＰＵは、今回登録簿のレコードと、前回登録簿のレコードを相互に比較して、次の処理を行う（Ｓ２）。
【００４５】
（１）今回登録簿に新しいプログラム名が登録された場合
【００４６】
今回登録簿のレコードのプログラム名と同一のプログラム名を有するレコードが前回登録簿に記録されていない場合に、基幹システムサーバ１０のＣＰＵは、当該今回登録簿のレコードと、状態フラグ「新規」とを関連付けてＭＥＭに記録する。
【００４７】
（２）今回登録簿からプログラム名が削除された場合
【００４８】
前回登録簿のレコードのプログラム名と同一のプログラム名を有するレコードが今回登録簿に記録されていない場合に、基幹システムサーバ１０のＣＰＵは、当該前回登録簿のレコードと、状態フラグ「削除」とを関連付けてＭＥＭに記録する。
【００４９】
（３）今回登録簿及び前回登録簿に同一のプログラム名が記録されている場合
【００５０】
今回登録簿のレコードのプログラム名と同一のプログラム名を有するレコードが前回登録簿に記録され、かつ、当該今回登録簿のレコードの最新更新日時が当該前回登録簿のレコードの最新更新日時と異なる場合に、基幹システムサーバ１０のＣＰＵは、当該今回登録簿のレコードと、状態フラグ「更新」とを関連付けてＭＥＭに記録する。
【００５１】
そして、基幹システムサーバ１０のＣＰＵは、上記（１）乃至（３）の処理を、今回登録簿及び前回登録簿の全レコードに対して繰り返す（Ｓ３）。なお、本実施形態では、今回登録簿のレコードと、前回登録簿のレコードとを相互に比較することで変更点を判断したが、他の方法でも良い。例えば、予め今回登録簿及び前回登録簿に状態を示すフラグを入力するフィールドを設けておく。そして、今回登録簿の各レコードと一致するプログラムが前回登録簿のレコードに無ければ、新規の状態を示すフラグを今回登録簿のフィールドに入力する。また、今回登録簿の各レコードと一致するプログラムが前回登録簿にあり、最新更新日時が異なっている場合は、更新の状態を示すフラグを今回登録簿と前回登録簿のフィールドに入力する。さらに、前回登録簿の状態を示すフィールドにフラグが入力されていない場合は、削除されたプログラムとして判断を行う。このような処理がなされた後に、基幹システムサーバ１０のＣＰＵは、今回登録簿及び前回登録簿の状態を示すフラグの中から「新規」、「更新」、「削除」とされるフラグを持つレコードの情報をＭＥＭに記録しても変更点を導くことができる。
【００５２】
その後、プログラム登録簿比較部１１は、上記今回登録簿記憶部１５に記憶されている今回登録簿を前回登録簿として前回登録簿記憶部１６に記録する。そして、プログラム変更リスト作成部１２は、上記（１）乃至（３）の処理によって今回登録簿又は前回登録簿のレコードと、その状態フラグとがＭＥＭに記録されている場合に、変更分リスト記憶部１７に変更分リストを新規作成し、ＭＥＭに記録されたレコード及び当該レコードに関連付けられた状態フラグとを変更分リスト記憶部１７の変更分リストに記録する。続いて、リスト転送部１３は、変更分リスト記憶部１７から当該変更分リストを取り出してメール配信サーバ２０に転送する。
【００５３】
一方、メール配信サーバ２０は次の処理を行う。リスト受信部２１は、基幹システムサーバ１０から送信された変更分リストを受信すると共に、当該受信した変更分リストを変更分リスト記憶部２５に格納する。次に、メール作成部２２は、メール雛型記憶部２６に格納されたメール雛型及び変更分リスト記憶部２５に格納された変更分リストに基づいて、当該変更分リストをその内容とする電子メールのデータを作成する。図６は、当該電子メールの内容の一例である。続いて、メール作成部２２は、当該作成した電子メールのデータを、完成メール記憶部２７に格納する。そして、メール送信部２３は、メール宛先記憶部２８に予め格納されているメール宛先に基づいて、完成メール記憶部２７に格納された電子メールのデータをリリース実施者、チームリーダ、上司、基幹システムサーバ管理者等の関係者に送信する。
【００５４】
これによると、チェック装置が、今回登録簿記憶部に記録された現時点のプログラムの属性と、前回登録簿記憶部に記録された前回のチェック時におけるプログラムの属性とを比較して、変更リストを作成するので、プログラムのリリースの実施によって、プログラムの属性から新規登録等されたことを容易に確認することができる。
【００５５】
以上説明した本実施形態によれば、変更をプログラムのリリースだけで確認することができる。さらに、本実施形態によればメール配信サーバは、基幹システムサーバが作成した変更分リストをその内容とする電子メールを関係者に送信するので、関係者は、リリースの実施によって現実に、新規登録、変更又は削除されたプログラム等の属性を確認することができる。
【００５６】
これによると、緊急リリースに対応するリリース手続書がなくても、緊急リリースによって新規登録、変更、又は削除されたプログラムを上記メールの内容によって特定することができるので、障害の原因究明に多大な時間と労力を要しない。また、関係者は、上記電子メールの内容が最新のリリース手続書の内容と相違している場合に、リリース手続書を作成しない不正なプログラムリリースが実施されたことを認知することができる。この場合、上司等は、リリース実施者にリリース手続書の作成を事後的に指示することも可能であり、リリース手続書を作成しない不正なプログラムリリースを防止することができる。さらに、関係者は、上記電子メールの内容によりリリース情報を共有することができる。
【００５７】
本発明の範囲は、上記実施形態の範囲に限られず、種々の変更が可能である。例えば、基幹システムサーバがメール配信手段を具備し、当該サーバが上記通知メールを配信してもよい。また、基幹システムサーバは、プログラムリリースがされたことを検知する検知手段を有し、検知ごとに都度メールを配信するようにしてもよい。また、プログラム登録簿ではなくソースプログラム自体を比較し、変更プログラムリストの内容を、新規・変更・削除者のＩＤ、プログラムの変更内容（ソースコード変更箇所及び変更内容を並列に記載）等含んでいてもよい。
【図面の簡単な説明】
【００５８】
【図１】プログラムリリースチェックシステムの全体構成図である。
【図２】基幹システムサーバ及びメール配信サーバの構成図である。
【図３】基幹システムサーバ及びメール配信サーバの機能ブロック図である。
【図４】今回登録簿のデータ構造図である。
【図５】プログラムリリースのチェック処理のフローチャートである。
【図６】電子メールの内容の一例である。
【符号の説明】
【００５９】
１０  基幹システムサーバ
１１  プログラム登録簿比較部
１２  プログラム変更リスト作成部
１３  リスト転送部
１４  その他の処理部
１５  今回登録簿記憶部
１６  前回登録簿記憶部
１７  変更分リスト記憶部
２０  メール配信サーバ
２１  リスト受信部
２２  メール作成部
２３  メール送信部
２４  その他の処理部
２５  変更分リスト記憶部
２６  メール雛型記憶部
２７  完成メール記憶部
２８  メール宛先記憶部
３０  関係者端末
４０  コンピュータネットワーク
【図１】
2005267341.tif 000003
【図２】
2005267341.tif 000004
【図３】
2005267341.tif 000005
【図４】
2005267341.tif 000006
【図５】
2005267341.tif 000007
【図６】
2005267341.tif 000008