以下に本発明の一実施形態について図面を参照して説明する。図1には、本実施形態の検証システム10の全体構成が示されている。図2、図3には、システム更改の対象となる本番環境下の旧システム、テスト環境下の新システムの構成がそれぞれ示されている。また、図4および図5は、テスト環境下の新システムに投入する投入電文の作成方法および投入方法の説明図である。さらに、図6には、検証システム10による検証処理の流れがフローチャートで示されている。
<検証システム10の構成の概略:図1>
図1において、検証システム10は、システム更改の際に新システムの動作をテストするために新システムと旧システムとの処理結果を比較検証する処理を実行するシステムであり、1台または複数台のコンピュータにより構成されている。この検証システム10は、本番環境下の旧システムから実際のデータを取得し、そのデータを利用してテスト環境下の新システムにおいて、本番環境で実行された処理内容(システムの動作)を再現し、新旧システムの処理結果を比較検証することにより、新システムの動作をチェックするものである。
なお、検証システム10は、例えば、1台または複数台のサーバと、検証処理の担当者が操作する担当者端末(クライアント)とを通信回線(社内LANやイントラネット等の内部ネットワークでもよく、インターネット等の広範な外部ネットワークでもよく、専用線でもよい。)で接続することにより構成してもよく、検証処理の担当者が操作するマウスやキーボード等の入力手段および液晶ディスプレイ等の表示手段を備えた1台のコンピュータにより構成してもよい。
この検証システム10は、本番環境情報収集手段20と、テスト環境情報収集手段30と、本番データ反映手段40と、マスキング手段41と、分類手段42と、投入手段43と、条件成否監視サーバ用スタブ44と、市場用スタブ45と、注文データ検証手段46と、応答電文検証手段47とを備えている。
これらの各手段20,30,40〜43,46,47および各スタブ44,45は、検証システム10を構成するコンピュータ本体の内部に設けられた中央演算処理装置(CPU)、およびこのCPUの動作手順を規定する1つまたは複数のプログラムにより実現される。なお、これらの各手段20,30,40〜43,46,47および各スタブ44,45の詳細は、後述する。
また、検証システム10は、本番投入電文記憶手段50と、本番応答電文記憶手段51と、業務開始時点本番データ記憶手段52と、業務終了時点本番データ記憶手段53と、テスト応答電文記憶手段54と、業務終了時点テストデータ記憶手段55と、再現電文記憶手段56と、投入用差分記憶手段57と、注文データ検証用差分記憶手段58と、応答電文検証用差分記憶手段59とを備えている。
これらの各記憶手段50〜59は、例えばハードディスクドライブ(HDD)やソリッドステートドライブ(SSD)等により好適に実現されるが、記憶容量やアクセス速度等に問題が生じない範囲であれば、例えば、DVD、CD、MO、磁気テープ等の他の記録媒体を採用してもよい。また、各記憶手段50〜59のデータ保存形式は、データベースでもよく、フラットファイル等のファイル形式でもよい。なお、これらの各記憶手段50〜59の詳細は、後述する。
<本番環境下の旧システムおよびその周辺システムの構成、およびこれらのシステムによる一連の業務処理の流れの概要:図2>
本実施形態では、システム更改の対象(すなわち、検証処理の対象)は、図2に示すように、一例として、株式の注文処理システムとする。従って、本実施形態の検証システム10は、顧客による株式の売買注文を受け付けて株式市場への発注を行う注文処理システムについて、更改に係る新旧のシステムの処理結果の比較検証を行うことにより、新システムが正常に動作するかを確認するためのテストを行う。
なお、本発明の検証システムによる検証処理の対象システム(システム更改の対象システム)は、株式の注文処理システムに限定されるものではなく、株式以外の金融商品の売買注文を取り扱う注文処理システムであってもよく、さらには、証券・金融システムに限定されるものでもなく、従って、市場への発注を行う注文処理システムに限定されるものでもない。但し、市場への発注を行う注文処理システムの場合には、その注文処理システムへの投入電文の入力経路について、少なくとも、顧客サイドからの入力経路と、市場サイドからの入力経路とが存在する状態となるので、本発明の効果が、より顕著に得られる。
図2において、検証システム10による検証処理の対象となる株式の注文処理システムは、図2中の一点鎖線で囲まれた部分であり、注文受付システム60と、注文管理システム70とにより構成されている。これらのシステム60,70は、いずれも大型汎用コンピュータにより構成された、いわゆるメインフレーム(ホストコンピュータ)である。なお、これらのシステム60,70は、1台のメインフレームにより構成してもよい。本実施形態では、一例として、これらのシステム60,70のうち、注文受付システム60についてシステム更改が行われ、注文管理システム70については、更改部分は無いものとする。但し、本実施形態では、注文管理システム70も含めて注文処理システムの全体(すなわち、注文受付システム60および注文管理システム70の結合状態)を、比較検証対象の新旧システムとして捉えるものとする。従って、本実施形態では、検証システム10は、注文処理システム(システム60,70の結合状態)への入力データを「投入電文」とし、注文処理システム(システム60,70の結合状態)からの出力データを「応答電文」として捉えるものとする。なお、更改部分である注文受付システム60に対する入出力データを収集することができる場合には、注文管理システム70を除いて注文受付システム60だけを、比較検証対象の新旧システムとして捉えてもよく、その場合には、注文受付システム60への入力データを「投入電文」とし、注文受付システム60からの出力データを「応答電文」として捉えることになるので、更改部分のない注文管理システム70は、比較検証対象の新旧システムの外部に配置される周辺システムという扱いになる。より一般的に言えば、ある業務を行う一連のシステムのうち、どこからどこまでの範囲を本発明の検証システムによる比較検証対象とするかは、データの収集容易性等から、ケース・バイ・ケースで選択することができ、要するに、更改部分が含まれるように比較検証対象を選択決定すればよい。
注文受付システム60の上流側には、注文受付サーバ90が設けられている。この注文受付サーバ90は、顧客が操作する顧客端末(不図示)とインターネットを介して接続されたウェブ・アプリケーションサーバであり、顧客端末からインターネットを介して送信されてくる顧客の注文データ(顧客識別情報、銘柄、売買区分、数量、単価、市場等を含む。)を受け付ける処理を実行するものである。また、注文受付サーバ90は、入力代行者(営業員やオペレータ)が操作する代行者端末(不図示)からネットワーク(社内LANやイントラネット等の内部ネットワークでもよく、インターネットでもよい。)を介して送信されてくる顧客の注文データを受け付ける処理を実行するものでもよい。
注文受付サーバ90は、注文受付手段91により、顧客端末または代行者端末からネットワークを介して送信されてくる顧客の注文データを受信すると、その注文に注文番号を自動付与し、注文電文(顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場等を含む。)を、通信回線を介して注文受付システム60へ送信する。この注文電文(注文受付サーバ90から注文受付システム60へ送信される電文)は、比較検証対象の注文処理システムに投入される投入電文である。なお、最終的に市場に送信する注文番号は、注文管理システム70により自動付与される番号であり、注文管理システム70よりも上流のシステムで付与される番号ではないが、各システムで付与される番号は関連付けられているので、本実施形態では、説明の便宜上、各システムで付与される番号を、市場に送信する注文番号で統一して説明を行う。
注文受付システム60では、投入電文である注文電文の受信があると、そのログ情報が注文ログ記憶手段65に記憶される。このログ情報には、注文電文の記録時刻(年月日、時分秒)が含まれる。
そして、注文受付手段61は、受信した注文電文の内容を、注文データ記憶手段64に記憶させるとともに、注文を受け付けた旨の注文応答電文(顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場等を含む。)を、通信回線を介して注文受付サーバ90へ送信する。この注文応答電文(注文受付システム60から注文受付サーバ90へ送信される電文)は、比較検証対象の注文処理システムから外部へ出ていく応答電文である。注文受付システム60では、注文応答電文の送信があると、そのログ情報が注文応答ログ記憶手段66に記憶される。このログ情報には、注文応答電文の記録時刻(年月日、時分秒)が含まれる。
また、注文受付手段61は、受信した注文電文の注文が、逆指値注文・デュアル指値注文・連続注文等のような条件付注文の場合には、条件の成否を監視する処理が必要となり、市場への発注をすぐに行うことはできないので、条件付注文電文(顧客識別情報、注文番号、銘柄、売買区分、数量、条件となる単価、市場等を含む。)を、通信回線を介して条件成否監視サーバ100へ送信する。この条件付注文電文(注文受付システム60から条件成否監視サーバ100へ送信される電文)は、比較検証対象の注文処理システムから外部へ出ていく応答電文である。注文受付システム60では、条件付注文電文の送信があると、そのログ情報が条件付注文ログ記憶手段67に記憶される。このログ情報には、条件付注文電文の記録時刻(年月日、時分秒)が含まれる。
条件成否監視サーバ100では、条件付注文受付手段101により、条件付注文電文を受信し、受信した条件付注文電文の内容を、条件付注文データ記憶手段103に記憶させる。そして、条件付注文発注手段102は、時価情報提供システム110(情報ベンダーのシステム、自社内の別のシステム、または市場システム130)から取得した金融商品の時価情報(本実施形態では、株価情報)を用いて、条件付注文データ記憶手段103に記憶されている各条件付注文についての条件の成否を監視し、条件が成立した条件付注文について、条件付注文データ記憶手段103に記憶された条件付注文のデータを用いて、条件付注文発注電文(顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場等を含む。)を作成し、通信回線を介して注文受付システム60へ送信する。この条件付注文発注電文(条件成否監視サーバ100から注文受付システム60へ送信される電文)は、比較検証対象の注文処理システムに投入される投入電文である。
注文受付システム60では、投入電文である条件付注文発注電文の受信があると、そのログ情報が条件付注文発注ログ記憶手段68に記憶される。このログ情報には、条件付注文発注電文の記録時刻(年月日、時分秒)が含まれる。そして、条件付注文受付手段62は、受信した条件付注文発注電文の内容を、注文データ記憶手段64に記憶させる。
なお、各種マスタ記憶手段63には、例えば、顧客情報(顧客の口座番号、パスワード、住所、氏名、電話番号等)や銘柄情報などが記憶され、注文受付手段61や条件付注文受付手段62の処理で必要な場合に参照される。
注文管理システム70では、発注手段71が、注文データ記憶手段64に記憶された注文データを用いて、市場への発注を行うための発注電文(顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場等を含む。)を作成し、通信回線を介して市場接続システム120へ送信するとともに、発注電文の内容を発注データ記憶手段73に記憶させる。この発注電文(注文管理システム70から市場接続システム120へ送信される電文)は、比較検証対象の注文処理システムから外部へ出ていく応答電文である。注文管理システム70では、発注電文の送信があると、そのログ情報が発注ログ記憶手段74に記憶される。このログ情報には、発注電文の記録時刻(年月日、時分秒)が含まれる。
市場接続システム120は、市場システム130との接続の異常検知を含め、市場システム130との間の電文の送受信の管理処理を実行するものである。この市場接続システム120は、注文管理システム70から受信した順番で発注キューに置かれた発注電文を、その順番で通信回線を介して市場システム130へ送出する。なお、市場接続システム120は、証券会社等の金融機関が設置するシステムであるが、本発明を説明するうえでは(検証システム10の機能を把握するうえでは)、市場サイドのシステムとして捉えてもよい。
市場システム130は、応答電文である発注電文を受信すると、その発注電文に応じた内容の通知電文(顧客識別情報、注文番号等を含む。)を、通信回線を介して市場接続システム120へ送信する。例えば、上流から見ると、注文受付サーバ90からの投入電文が、新規注文の注文電文、訂正の注文電文、取消の注文電文である場合には、注文管理システム70からは、それらの投入電文に対する応答電文として、新規注文の発注電文、訂正の発注電文、取消の発注電文が、市場接続システム120を介して市場システム130に送信されてくるので、市場システム130は、注文受付の通知電文、訂正完了の通知電文、取消完了の通知電文を、それぞれ通信回線を介して市場接続システム120へ送信する。
また、市場システム130は、市場において顧客の注文が約定した場合には、約定の通知電文(顧客識別情報、注文番号、銘柄、売買区分、約定数量、約定単価、市場等を含む。)を、通信回線を介して市場接続システム120へ送信する。
市場接続システム120は、市場システム130から送信されてくる通知電文を受信し、受信した通知電文を、通信回線を介して注文管理システム70へ送信する。この通知電文(市場接続システム120から注文管理システム70へ送信される電文)は、比較検証対象の注文処理システムに投入される投入電文である。
注文管理システム70では、投入電文である通知電文の受信があると、そのログ情報が通知ログ記憶手段75に記憶される。このログ情報には、通知電文の記録時刻(年月日、時分秒)が含まれる。
そして、注文管理システム70では、約定処理手段72により、受信した通知電文の内容に応じ、発注データ記憶手段73に記憶された発注データの更新処理を実行する。例えば、約定の通知電文を受信した場合には、約定数量や約定単価等を記憶させ、注文状況を示すステータスを「注文中」から「約定済」に変更する処理等を実行する。また、約定の情報を用いて、注文受付システム60の注文データ記憶手段64に記憶された注文データの更新処理も行われる。
<テスト環境下の新システムの構成および検証システム10との配置関係:図3>
図3において、テスト環境下の新システムである注文処理システムは、図3中の一点鎖線で示すように、注文受付システム80と注文管理システム70とにより構成されている。このうち、更改部分は、注文受付システム80だけであり、注文管理システム70については、更改はなく、図2の本番環境下と同じものである。従って、図2の本番環境下の旧システムを構成する注文受付システム60が、図3のテスト環境下の新システムを構成する注文受付システム80に変わっただけである。新システムの注文受付システム80を構成する各手段81,82および各記憶手段83〜88は、旧システムの注文受付システム60を構成する各手段61,62および各記憶手段63〜68に対応している。
そして、図3のテスト環境において、新システムである注文処理システム(注文受付システム80と注文管理システム70との結合状態)の上流側には、図2の注文受付サーバ90や条件成否監視サーバ100の代わりに、検証システム10の投入手段43や条件成否監視サーバ用スタブ44が配置され、下流側には、図2の市場接続システム120や市場システム130の代わりに、検証システム10の投入手段43や市場用スタブ45が配置されている。
<検証システム10の構成の詳細:図1、図3>
図1において、本番環境情報収集手段20は、本番環境から検証処理に必要なデータを収集する処理を行うものであり、本番投入電文取得手段21と、本番応答電文取得手段22と、業務開始時点本番データ取得手段23と、業務終了時点本番データ取得手段24とを含んで構成されている。
本番投入電文取得手段21は、本番環境下の旧システム(図2参照)の注文ログ記憶手段65に記憶された注文電文(投入電文)のログ情報、条件付注文発注ログ記憶手段68に記憶された条件付注文発注電文(投入電文)のログ情報、および通知ログ記憶手段75に記憶された通知電文(投入電文)のログ情報を取得し、取得した各ログ情報(電文データの記録時刻を含む。)を、本番投入電文記憶手段50に記憶させる処理を実行するものである。
本番応答電文取得手段22は、本番環境下の旧システム(図2参照)の注文応答ログ記憶手段66に記憶された注文応答電文(応答電文)のログ情報、条件付注文ログ記憶手段67に記憶された条件付注文電文(応答電文)のログ情報、および発注ログ記憶手段74に記憶された発注電文(応答電文)のログ情報を取得し、取得した各ログ情報(電文データの記録時刻を含む。)を、本番応答電文記憶手段51に記憶させる処理を実行するものである。
業務開始時点本番データ取得手段23は、本番環境下の旧システム(図2参照)の業務開始時点における各種マスタ記憶手段63に記憶された各種マスタ情報(顧客情報等)、注文データ記憶手段64に記憶された注文データ(顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場、注文状況を示すステータス等を含む。)、および発注データ記憶手段73に記憶された発注データ(注文データと同様な内容)を取得し、取得したデータを、業務開始時点本番データ記憶手段52に記憶させる処理を実行するものである。なお、業務開始時点における注文データや発注データを取得するのは、例えば、業務開始時点で、前日の夜間に発生したデータが残っている場合等があり、そのような状態をテスト環境に反映させてから検証処理を開始する必要があるからである。
業務終了時点本番データ取得手段24は、本番環境下の旧システム(図2参照)の業務終了時点における注文データ記憶手段64に記憶された注文データ、および発注データ記憶手段73に記憶された発注データを取得し、取得したデータを、業務終了時点本番データ記憶手段53に記憶させる処理を実行するものである。
テスト環境情報収集手段30は、テスト環境から検証処理に必要なデータを収集する処理を行うものであり、テスト応答電文取得手段31と、業務終了時点テストデータ取得手段32とを含んで構成されている。
テスト応答電文取得手段31は、テスト環境下の新システム(図3参照)の注文応答ログ記憶手段86に記憶された注文応答電文(応答電文)のログ情報、および条件付注文ログ記憶手段87に記憶された条件付注文電文(応答電文)のログ情報を取得し、取得した各ログ情報を、テスト応答電文記憶手段54に記憶させる処理を実行するものである。また、図1および図3には、市場用スタブ45が、注文番号をテスト環境下の番号から本番環境下の番号に変換し、発注電文(本番環境下の番号に変換後の注文番号を含む。)を、テスト応答電文記憶手段54に記憶させるように図示されているが、テスト応答電文取得手段31が、発注ログ記憶手段74に記憶された発注電文(応答電文)のログ情報を取得し、再現電文記憶手段56に記憶された二つの環境下の番号の関連付け情報を用いて、注文番号をテスト環境下の番号から本番環境下の番号に変換し、発注電文(本番環境下の番号に変換後の注文番号を含む。)を、テスト応答電文記憶手段54に記憶させる構成としてもよい。
業務終了時点テストデータ取得手段32は、テスト環境下の新システム(図3参照)の業務終了時点における注文データ記憶手段84に記憶された注文データ、および発注データ記憶手段73に記憶された発注データを取得し、取得したデータを、業務終了時点テストデータ記憶手段55に記憶させる処理を実行するものである。
本番データ反映手段40は、テスト環境下の新システム(図3参照)に対し、業務開始時点における本番環境のデータを反映させることにより、テスト環境下の新システムにおいて本番環境の業務開始時点の状況を再現する処理を実行するものであり、業務開始時点本番データ記憶手段52に記憶された各種マスタ情報(顧客情報等)、注文データ、および発注データを、テスト環境における各種マスタ記憶手段83、注文データ記憶手段84、および発注データ記憶手段73にそれぞれ格納する処理を実行する。
マスキング手段41は、本番投入電文記憶手段50に記憶された投入電文(注文電文、条件付注文発注電文、および通知電文)のログ情報の中に、暗証番号等の個人情報が含まれている場合には、その個人情報を代替情報に置き換える処理を実行するものである。なお、本実施形態では、顧客識別情報は、個人情報とはみなさないので、そのまま再現電文の構成データとして使用する。
分類手段42は、図4に示すように、本番投入電文記憶手段50に記憶された複数の入力経路の投入電文(注文電文、条件付注文発注電文、および通知電文)を、マスキング手段41による処理後に、記録時刻を用いて各投入電文の投入順序の通りに並べて統合し、統合した複数の入力経路の投入電文を、比較検証対象のシステム(本実施形態では、注文処理システム)の挙動が切り替わる複数の時間帯に合わせて、記録時刻を用いて複数の時間帯に分類し、分類後の投入電文を、再現電文記憶手段56に記憶させる処理を実行するものである。
ここで、複数の時間帯は、本実施形態では、一例として、注文処理システムを比較検証対象としているので、市場システム130(図2参照)との関係で予め設定されている時間帯であり、これらの複数の時間帯は、新システムである注文処理システム(図3の注文受付システム80および注文管理システム70)と、旧システムである注文処理システム(図2の注文受付システム60および注文管理システム70)との双方に共通するものである。このように時間帯による分類処理を行うのは、各時間帯でシステムの挙動が異なるので、テスト環境において本番環境と同じ挙動を再現し、両者を比較検証するためである。
より具体的には、複数の時間帯は、例えば、「市場開局前」の時間帯(1)=6:00〜8:00と、「市場開局後」の時間帯(2)=8:00〜9:00と、「前場」の時間帯(3)=9:00〜11:30と、「場間」の時間帯(4)=11:30〜12:05と、「後場受付」の時間帯(5)=12:05〜12:30と、「後場」の時間帯(6)=12:30〜15:30と、「受付停止」の時間帯(7)=15:30〜18:00と、「翌日注文」の時間帯(8)=18:00〜27:00とに分割された時間帯である。
なお、1日だけの投入電文の再現ではなく、連続する複数の日の投入電文を再現する場合には、ある日の時間帯(1),(2)…(8)、翌日の時間帯(1),(2)…(8)、さらにその次の日の時間帯(1),(2)…(8)のように、投入電文の分類処理が行われる。従って、例えば、同じ時間帯(1)であっても、日にちが異なっていれば、別々に分類される。
また、分類手段42は、本実施形態では、図4に示すように、複数の時間帯に分類された投入電文(注文電文、条件付注文発注電文、および通知電文)を、さらに顧客識別情報(口座番号等)を用いて顧客毎にグルーピングし、時間帯に分類され、かつ、顧客毎にグルーピングされた状態で、投入電文を再現電文記憶手段56に記憶させる処理を実行する。従って、再現電文記憶手段56には、時間帯(1)については、時間帯(1)の顧客Aの投入電文のグループ、時間帯(1)の顧客Bの投入電文のグループ、時間帯(1)の顧客Cの投入電文のグループ、…が記憶されている状態となる。他の時間帯(2)〜(8)についても同様であり、それぞれの時間帯に、顧客A,B,C,…のグループがある。そして、時間帯毎で、かつ、顧客毎の各々のグループ内では、同一の時間帯についての同一の顧客の投入電文だけが、記録時刻の順番に従って並べられている状態となる。
このように時間帯に分類し、さらに顧客毎にグルーピングする処理を行うのは、同一の時間帯の投入電文であっても、同一の顧客については、新規注文、訂正、取消の注文電文があり、それらの投入順序が保たれないと、処理結果が異なってしまうので、そのような事態を回避するためである。換言すれば、同一の顧客内での投入電文の投入順序(前後関係)を保ちさえすれば、同一の時間帯内で、異なる顧客間の投入電文の投入順序を崩しても、検証処理には影響は出ないので、顧客単位でのグルーピングを行う。
なお、一般には、先に市場への発注を行った顧客の注文が優先されて約定するので、異なる顧客間の投入電文の投入順序を変えれば、市場での処理は異なるものとなり、異なった処理結果が得られることになる。しかし、本実施形態の検証システム10は、市場システム130の処理を含めて検証を行うわけではなく(そのような検証は、市場の板の状態を再現することになるので、実質的に困難である。)、市場システム130の処理は、比較検証対象の注文処理システムの外部で行われる処理に相当する。従って、市場システム130の処理結果は、市場システム130からの通知電文(投入電文)という形で、検証処理に関わることになり、この通知電文は、本番環境から実際のデータを取得しているので、異なる顧客間の投入電文の投入順序を変えても、検証処理には影響は出ないことになる。
さらに、分類手段42は、複数の時間帯のそれぞれについて顧客毎に投入電文(注文電文、条件付注文発注電文、および通知電文)をグルーピングする際に、本番環境下の記録時刻が同時刻になっている投入電文については、注文電文、条件付注文発注電文、通知電文の順で予め定められた優先順位に従って、この優先順位の高い投入電文から順番にテスト環境下の新システムに対して投入されるように投入電文を並べる処理を実行する。
このように投入電文の入力経路に優先順位を付けるのは、記録時刻が同時刻になっていたとしても、本番環境における実際の処理では投入に時間差がある場合があり、この場合に、実際の投入順序が保たれないと、処理結果が異なってしまうことがあるので、そのような事態を回避するためである。例えば、市場接続システム120の発注キューでの滞留もなく、市場システム130からの返信も円滑に行われると、記録時刻の最小刻みに満たない時間差で、複数の入力経路からの投入が行われることがあり得る。
具体的には、注文電文と条件付注文発注電文との順序関係では、例えば、実際には、条件付注文である新規注文の注文電文の投入の後に、条件付注文発注電文の投入が行われるところ、それらの順序が逆転し、顧客から条件付注文の新規注文が出ていないのに、条件成否監視サーバ100から条件付注文の条件成立に伴う市場への発注指令が出るという事態があり得るので、そのような事態を回避するためである。
また、注文電文と通知電文との順序関係では、例えば、実際には、新規注文の注文電文の投入の後に、注文受付の通知電文の投入や、約定の通知電文の投入が行われるところ、それらの順序が逆転し、顧客から新規注文が出ていないのに、市場から注文受付の通知や、約定の通知があるという事態があり得るので、そのような事態を回避するためである。
さらに、条件付注文発注電文と通知電文との順序関係では、例えば、実際には、条件付注文発注電文の投入の後に、注文受付の通知電文の投入や、約定の通知電文の投入が行われるところ、それらの順序が逆転し、条件成否監視サーバ100から条件付注文の条件成立に伴う市場への発注指令が出ていないのに、市場から注文受付の通知や、約定の通知があるという事態があり得るので、そのような事態を回避するためである。
投入手段43は、複数の時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定した状態のテスト環境下の新システム(図3参照)に対し、再現電文記憶手段56に記憶された分類後の投入電文のうち、新システムに設定した仮想の時刻に対応する時間帯の投入電文を、通信回線を介して投入する処理を、複数の時間帯のそれぞれについて実行するものである。なお、新システムのシステム時刻を、仮想の時刻に設定する処理は、手動で行ってもよいが、本実施形態では、投入手段43により自動設定する。
より詳細には、投入手段43は、図5に示すように、テスト環境下の新システム(図3参照)に対し、複数の時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定するための仮想の時刻の設定指令を、通信回線を介して送信した後、当該仮想の時刻に対応する時間帯の投入電文を、通信回線を介して新システムに投入する処理を実行する。この際、各時間帯の投入電文は、顧客毎にグルーピングされているので、投入手段43は、顧客毎にグルーピングされた投入電文を、同一顧客内の投入電文の順序を保ったまま顧客毎のグループ単位で新システムに投入していく処理を実行する。そして、投入手段43は、このような仮想の時刻の設定指令の送信処理と、当該仮想の時刻に対応する時間帯の投入電文の投入処理とを、複数の時間帯について交互に繰り返す。
具体的には、投入手段43は、図5に示すように、親ドライバと、顧客毎のドライバ(顧客A用のドライバ、顧客B用のドライバ、顧客C用のドライバ、…)とにより構成されている。
親ドライバは、新システムである注文処理システムを構成する注文受付システム80および注文管理システム70(図3参照)のそれぞれに対し、時間帯(1)に対応する仮想の時刻6:00(時間帯(1)の開始時刻)の設定指令を、通信回線を介して送信した後に、顧客毎のドライバに対し、当該仮想の時刻6:00に対応する時間帯(1)の各顧客の投入電文のグループの投入指令を出す処理を実行する。そして、他の時間帯(2)〜(8)についても、このような新システムに対する仮想の時刻の設定指令の送信処理と、顧客毎のドライバに対する投入指令の処理とを繰り返すようになっている。
顧客毎のドライバは、親ドライバから時間帯(1)の投入電文の投入指令を受けたときに、各顧客の時間帯(1)の投入電文のグループを、通信回線を介して新システムに投入する処理を実行する。そして、他の時間帯(2)〜(8)についても同様に、親ドライバからの投入指令を受けたときに、指令に係る時間帯についての各顧客の投入電文のグループを、通信回線を介して新システムに投入する処理を実行する。
また、投入手段43は、再現電文記憶手段56に記憶された投入電文を投入する処理を実行するが、そのうちの通知電文の投入については、再現電文記憶手段56において注文番号についての本番環境の番号とテスト環境の番号との関連付けの更新処理が行われた後でないと、投入処理を実行しない。すなわち、投入手段43は、通知電文を新システム(図3参照)に投入する際には、本番環境で自動付与された注文番号を含む通知電文のままではなく、テスト環境で自動付与された注文番号を含む通知電文を投入する。なお、再現電文記憶手段56に記憶された通知電文に関する情報の更新処理(注文番号についての本番環境の番号とテスト環境の番号との関連付け情報の追加処理)は、後述するように、市場用スタブ45により実行される。
さらに、投入手段43は、新旧システムで投入電文の構成(形式または定義)に相違がある場合には、投入用差分記憶手段57に記憶された投入電文の形式または定義の差分情報を用いて、再現電文記憶手段56に記憶された分類後の投入電文を、新システム用の形式または定義に変換してから、新システムに投入する処理を実行する。
条件成否監視サーバ用スタブ44は、条件成否監視サーバ100(図2参照)の代用の処理を行うものであり、注文受付システム80から通信回線を介して送信されてくる条件付注文電文を受信する処理を実行する。
市場用スタブ45は、市場システム130(図2参照)の代用の処理を行うものであるが、注文番号について本番環境の番号とテスト環境の番号とを関連付ける処理も実行する。すなわち、注文管理システム70は、市場へ発注電文を送信する際に、注文番号を自動付与して送信するが、テスト環境下の注文管理システム70は、再現する発注電文(応答電文)に対し、本番環境下の注文管理システム70と同じ注文番号を付与しないので、市場用スタブ45は、注文管理システム70から、テスト環境で付与された注文番号を含む発注電文を受信することになる。この際、市場用スタブ45は、受信した発注電文について、注文番号以外の情報(顧客識別情報、銘柄、数量、単価等)から、いずれの注文の発注電文であるかを特定する処理を実行し、特定した注文についての本番環境の注文番号と、受信した発注電文に含まれるテスト環境の注文番号との関連付け情報を、再現電文記憶手段56に記憶させる。これにより、再現電文記憶手段56に記憶された通知電文は、本番環境から取得しているので、本番環境で付与された注文番号を含む通知電文であるが、テスト環境で付与された注文番号との関連付け情報を追加されることで、投入手段43がテスト環境の注文番号を含む通知電文を作成し、新システムに投入することが可能となる。
また、市場用スタブ45は、上記の関連付けを行った後に、受信した発注電文(テスト環境の注文番号を含む)を、発注電文(本番環境の注文番号を含む)に変換し、テスト応答電文記憶手段54に記憶させる処理も実行する。なお、テスト応答電文記憶手段54への発注電文(本番環境の注文番号を含む)の格納処理は、テスト応答電文取得手段31により、発注ログ記憶手段74に記憶された発注電文(テスト環境の注文番号を含む)のログ情報を変換することにより行ってもよい。
注文データ検証手段46は、業務終了時点本番データ記憶手段53に記憶された旧システム(図2参照)の注文データおよび発注データと、業務終了時点テストデータ記憶手段55に記憶された新システム(図3参照)の注文データおよび発注データとを比較することにより、新旧システムの動作が同じか否かを確認する検証処理を実行するものである。この際、注文データ検証手段46は、注文データおよび発注データの構成(形式または定義)が新旧システムで相違する場合には、注文データ検証用差分記憶手段58に記憶された差分情報を用いて変換処理を行うことにより形式または定義を統一してから、比較検証処理を実行する。
応答電文検証手段47は、本番応答電文記憶手段51に記憶された旧システム(図2参照)の応答電文(注文応答電文、条件付注文電文、発注電文)と、テスト応答電文記憶手段54に記憶された新システム(図3参照)の応答電文(注文応答電文、条件付注文電文、発注電文)とを比較することにより、新旧システムの動作が同じか否かを確認する検証処理を実行するものである。この際、応答電文検証手段47は、応答電文の構成(形式または定義)が新旧システムで相違する場合には、応答電文検証用差分記憶手段59に記憶された差分情報を用いて変換処理を行うことにより形式または定義を統一してから、比較検証処理を実行する。
本番投入電文記憶手段50は、本番環境下の旧システム(図2参照)から取得した投入電文(注文電文、条件付注文発注電文、通知電文)のログ情報(本番環境下での各電文の記録時刻を含む。)を記憶するものである。通知電文は、本番環境から取得しているので、本番環境で付与された注文番号を含んでいる。
本番応答電文記憶手段51は、本番環境下の旧システム(図2参照)から取得した応答電文(注文応答電文、条件付注文電文、発注電文)のログ情報(本番環境下での各電文の記録時刻を含む。)を記憶するものである。発注電文は、本番環境から取得しているので、本番環境で付与された注文番号を含んでいる。
業務開始時点本番データ記憶手段52は、本番環境下の旧システム(図2参照)の業務開始時点における各種マスタ情報(顧客情報等)、注文データ記憶手段64に記憶された注文データ(顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場、注文状況を示すステータス等を含む。)、および発注データ記憶手段73に記憶された発注データ(注文データと同様な内容)を記憶するものである。
業務終了時点本番データ記憶手段53は、本番環境下の旧システム(図2参照)の業務終了時点における注文データ記憶手段64に記憶された注文データ(顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場、注文状況を示すステータス等を含む。)、および発注データ記憶手段73に記憶された発注データ(注文データと同様な内容)を記憶するものである。
テスト応答電文記憶手段54は、テスト環境下の新システム(図3参照)から取得した応答電文(注文応答電文、条件付注文電文、発注電文)のログ情報を記憶するものである。但し、テスト環境下で作成された発注電文には、注文管理システム70により自動付与されたテスト環境の注文番号が含まれているが、本実施形態では、応答電文検証手段47による新旧システムの応答電文の比較検証処理を行うための準備として、市場用スタブ45によりテスト環境の番号から本番環境の番号への変換を行った後の注文番号を含む発注電文が、テスト応答電文記憶手段54に記憶されている。
なお、テスト応答電文記憶手段54にテスト環境の注文番号を含む発注電文を記憶しておき、新旧システムの応答電文の比較検証を行う際に、応答電文検証手段47により、再現電文記憶手段56に記憶された関連付け情報を用いてテスト環境の番号から本番環境の番号への注文番号の変換を行うようにしてもよい。また、テスト環境下の新システムの発注ログ記憶手段74(図3参照)には、テスト環境の注文番号を含む発注電文のログ情報が記憶されているので、これをテスト応答電文取得手段31により取得し、再現電文記憶手段56に記憶された関連付け情報を用いてテスト環境の番号から本番環境の番号への注文番号の変換を行ってからテスト応答電文記憶手段54に記憶させてもよく、あるいは、応答電文検証手段47により比較検証の際に注文番号の変換処理を行うことを前提として、テスト応答電文取得手段31により、発注ログ記憶手段74(図3参照)に記憶された発注電文(テスト環境の注文番号を含む)のログ情報を取得し、注文番号の変換処理を行うことなくテスト応答電文記憶手段54に記憶させてもよい。
業務終了時点テストデータ記憶手段55は、テスト環境下の新システム(図3参照)の業務終了時点における注文データ記憶手段84に記憶された注文データ(顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場、注文状況を示すステータス等を含む。)、および発注データ記憶手段73に記憶された発注データ(注文データと同様な内容)を記憶するものである。
再現電文記憶手段56は、図4に示すように、分類手段42により時間帯毎に分類され、かつ、顧客毎にグルーピングされた状態の投入電文(注文電文、条件付注文発注電文、通知電文)を記憶するものである。具体的には、再現電文記憶手段56には、時間帯(1)の投入電文として、時間帯(1)の顧客Aの投入電文のグループ、時間帯(1)の顧客Bの投入電文のグループ、時間帯(1)の顧客Cの投入電文のグループ、…が記憶され、時間帯(2)の投入電文として、時間帯(2)の顧客Aの投入電文のグループ、時間帯(2)の顧客Bの投入電文のグループ、時間帯(2)の顧客Cの投入電文のグループ、…が記憶され、時間帯(3)〜(7)も同様であり、そして、時間帯(8)の投入電文として、時間帯(8)の顧客Aの投入電文のグループ、時間帯(8)の顧客Bの投入電文のグループ、時間帯(8)の顧客Cの投入電文のグループ、…が記憶されている。
投入用差分記憶手段57は、システム更改に伴う新システムと旧システムとの投入電文の構成(形式または定義)の差分情報を記憶するものである。投入電文の構成(形式または定義)の差分情報とは、例えば、市場について、旧システムで「1=東京」、「2=大阪」となっていたのに対し、新システムでは「1=大阪」、「2=東京」となる場合等である。
注文データ検証用差分記憶手段58は、システム更改に伴う新システムと旧システムとの注文データや発注データのデータ保有管理構成(形式または定義)の差分情報を記憶するものである。ここでの差分情報は、システム内で保有管理されるデータベースやファイルの構成の差分情報であり、例えば、注文状況について、旧システムで「1=注文中」、「2=約定済」となっていたのに対し、新システムでは「1=約定済」、「2=注文中」となる場合等である。
応答電文検証用差分記憶手段59は、システム更改に伴う新システムと旧システムとの応答電文の構成(形式または定義)の差分情報を記憶するものである。応答電文の構成(形式または定義)の差分情報は、投入電文の場合の差分情報と同様である。
<検証システム10による検証処理の流れ:図6>
このような本実施形態においては、以下のようにして検証システム10により、検証処理が行われる。
図6において、先ず、本番環境情報収集手段20により、本番環境下の旧システムである注文処理システム(図2の注文受付システム60および注文管理システム70)から、検証処理に必要な各種の情報を収集する(ステップS1)。
具体的には、本番投入電文取得手段21により、本番環境下の旧システム(図2参照)の注文ログ記憶手段65に記憶された注文電文(投入電文)のログ情報、条件付注文発注ログ記憶手段68に記憶された条件付注文発注電文(投入電文)のログ情報、および通知ログ記憶手段75に記憶された通知電文(投入電文)のログ情報を取得し、取得した各ログ情報(電文データの記録時刻を含む。)を、本番投入電文記憶手段50に記憶させる。
また、本番応答電文取得手段22により、本番環境下の旧システム(図2参照)の注文応答ログ記憶手段66に記憶された注文応答電文(応答電文)のログ情報、条件付注文ログ記憶手段67に記憶された条件付注文電文(応答電文)のログ情報、および発注ログ記憶手段74に記憶された発注電文(応答電文)のログ情報を取得し、取得した各ログ情報(電文データの記録時刻を含む。)を、本番応答電文記憶手段51に記憶させる。
さらに、業務開始時点本番データ取得手段23により、本番環境下の旧システム(図2参照)の業務開始時点における各種マスタ記憶手段63に記憶された各種マスタ情報(顧客情報等)、注文データ記憶手段64に記憶された注文データ、および発注データ記憶手段73に記憶された発注データを取得し、取得したデータを、業務開始時点本番データ記憶手段52に記憶させる。
また、業務終了時点本番データ取得手段24により、本番環境下の旧システム(図2参照)の業務終了時点における注文データ記憶手段64に記憶された注文データ、および発注データ記憶手段73に記憶された発注データを取得し、取得したデータを、業務終了時点本番データ記憶手段53に記憶させる。
次に、本番データ反映手段40により、テスト環境下の新システム(図3参照)に対し、業務開始時点における本番環境のデータを反映させることにより、テスト環境下の新システムにおいて本番環境の業務開始時点の状況を再現する処理を実行する(図6のステップS2)。
具体的には、本番データ反映手段40により、業務開始時点本番データ記憶手段52に記憶された各種マスタ情報(顧客情報等)、注文データ、および発注データを、テスト環境下の新システムである注文処理システム(図3の注文受付システム80および注文管理システム70)における各種マスタ記憶手段83、注文データ記憶手段84、および発注データ記憶手段73にそれぞれ格納する。
続いて、テスト環境下の新システム(図3参照)で再現する投入電文(注文電文、条件付注文発注電文、および通知電文)の準備処理を実行する(図6のステップS3)。
具体的には、先ず、マスキング手段41により、本番投入電文記憶手段50に記憶された投入電文(注文電文、条件付注文発注電文、および通知電文)のログ情報の中に、暗証番号等の個人情報が含まれている場合には、その個人情報を代替情報に置き換える処理を実行する。
それから、分類手段42により、図4に示すように、マスキング手段41による処理を行った後の複数の入力経路の投入電文(注文電文、条件付注文発注電文、および通知電文)を、記録時刻を用いて各投入電文の投入順序の通りに並べて統合し、統合した複数の入力経路の投入電文を、比較検証対象のシステム(本実施形態では、注文処理システム)の挙動が切り替わる複数の時間帯に合わせて、記録時刻を用いて複数の時間帯に分類し(本実施形態では、一例として、市場システム130との送受信を行うために予め定められた8つの時間帯(1)〜(8)に分類し)、さらに顧客識別情報(口座番号等)を用いて顧客毎にグルーピングする。そして、時間帯に分類され、かつ、顧客毎にグルーピングされた状態で、投入電文を再現電文記憶手段56に記憶させる。
これにより、再現電文記憶手段56には、時間帯(1)の顧客Aの投入電文のグループ、時間帯(1)の顧客Bの投入電文のグループ、時間帯(1)の顧客Cの投入電文のグループ、…、時間帯(8)の顧客Aの投入電文のグループ、時間帯(8)の顧客Bの投入電文のグループ、時間帯(8)の顧客Cの投入電文のグループ、…が記憶されている状態となる。
そして、各時間帯の各顧客の投入電文のグループ内(1つ1つのグループ内)では、同一の時間帯についての同一の顧客の投入電文だけが、記録時刻の順番に従って並べられている状態となる。この際、各々のグループ内において、記録時刻について同時刻の投入電文が存在する場合には、分類手段42により、注文電文、条件付注文発注電文、通知電文の順で予め定められた優先順位に従って、この優先順位の高い投入電文から順番にテスト環境下の新システムに対して投入されるように投入電文を並べる。
図4の例では、時間帯(3)の顧客Aの投入電文のグループについては、新規注文の注文電文、注文受付の通知電文、訂正の注文電文、訂正完了の通知電文、約定の通知電文という順番で並べられ、この順に新システムに投入されるように再現電文記憶手段56に記憶されている。ここで、新規注文の注文電文と、注文受付の通知電文とは、記録時刻が同時刻であるが、入力経路の優先順位に従って、新規注文の注文電文が先となっている。また、訂正の注文電文と、訂正完了の通知電文とは、記録時刻が同時刻であるが、入力経路の優先順位に従って、訂正の注文電文が先となっている。
また、時間帯(3)の顧客Bの投入電文のグループについては、新規注文の注文電文、注文受付の通知電文、取消の注文電文、取消完了の通知電文という順番で並べられ、この順に新システムに投入されるように再現電文記憶手段56に記憶されている。
なお、顧客Bの新規注文の注文電文は、顧客Aの訂正の注文電文よりも、記録時刻が先であるが、顧客Aの投入電文のグループを投入した後に、顧客Bの投入電文のグループを投入した場合には、それらの投入順序は逆転することになる。しかし、同一顧客内での投入電文の投入順序が崩れなければ、新システムでの処理内容は変わらないので、検証処理に影響は出ない。
その後、投入手段43により、図5に示すように、複数の時間帯(1)〜(8)に従ってテスト環境下の新システム(図3参照)のシステム時刻を現実の時刻とは異なる仮想の時刻に設定し、システム時刻を仮想の時刻に設定する処理を行った後に、各時間帯に分類され、かつ、顧客毎にグルーピングされた状態で再現電文記憶手段56に記憶されている投入電文のうち、新システムに設定した仮想の時刻に対応する時間帯の投入電文を、通信回線を介して新システムに投入する。そして、このような処理を、複数の時間帯(1)〜(8)のそれぞれについて実行する(図6のステップS4)。
この際、新旧システムで投入電文の構成(形式または定義)に相違がある場合には、投入用差分記憶手段57に記憶された投入電文の形式または定義の差分情報を用いて、投入電文を新システム用の形式または定義に変換してから、新システムに投入する。
より詳細には、図5に示すように、投入手段43の親ドライバにより、新システムである注文処理システムを構成する注文受付システム80および注文管理システム70(図3参照)のそれぞれに対し、時間帯(1)に対応する仮想の時刻6:00(本実施形態では、一例として、時間帯(1)の開始時刻としている。)の設定指令を、通信回線を介して送信した後に、投入手段43の顧客毎のドライバ(顧客A用のドライバ、顧客B用のドライバ、顧客C用のドライバ、…)のそれぞれに対し、当該仮想の時刻6:00に対応する時間帯(1)の各顧客の投入電文のグループの投入指令を出す。そして、顧客毎のドライバは、親ドライバから時間帯(1)の投入電文の投入指令を受けたときに、自分の担当する顧客の時間帯(1)の投入電文のグループを、通信回線を介して新システムに投入する。なお、図5では、顧客A,B,Cの順に投入されているが、これらの顧客間の投入順序は任意であり、例えば、逆順で顧客C,B,Aの順に投入してもよく、同一顧客内での投入順序が保たれていれば、異なる顧客間の投入順序については制約はない。
続いて、投入手段43の親ドライバにより、新システムである注文処理システムを構成する注文受付システム80および注文管理システム70(図3参照)のそれぞれに対し、時間帯(2)に対応する仮想の時刻8:00(本実施形態では、一例として、時間帯(2)の開始時刻としている。)の設定指令を、通信回線を介して送信した後に、投入手段43の顧客毎のドライバ(顧客A用のドライバ、顧客B用のドライバ、顧客C用のドライバ、…)のそれぞれに対し、当該仮想の時刻8:00に対応する時間帯(2)の各顧客の投入電文のグループの投入指令を出す。そして、顧客毎のドライバは、親ドライバから時間帯(2)の投入電文の投入指令を受けたときに、自分の担当する顧客の時間帯(2)の投入電文のグループを、通信回線を介して新システムに投入する。
時間帯(3)〜(8)についても同様に、投入手段43の親ドライバにより、注文受付システム80および注文管理システム70(図3参照)のそれぞれに対する仮想の時刻の設定指令の送信処理と、投入手段43の顧客毎のドライバに対する投入指令の処理とを繰り返す。そして、顧客毎のドライバは、親ドライバから各時間帯の投入電文の投入指令を受けたときに、自分の担当する顧客の当該時間帯(親ドライバからの投入指令に係る時間帯)の投入電文のグループを、通信回線を介して新システムに投入する。
また、投入手段43は、通知電文の投入については、本番環境から取得した本番環境の注文番号を含む通知電文のままではなく、テスト環境の注文番号を含む通知電文を作成し、新システムに投入するので、その通知電文に係る注文番号について市場用スタブ45により本番環境の番号とテスト環境の番号との関連付け処理が行われ、再現電文記憶手段56においてその関連付け情報を追加する更新処理が行われた後に、投入処理を実行する。すなわち、注文電文や条件付注文発注電文(いずれも投入電文)を新システムに投入すると、それらの投入電文に対する応答電文として発注電文(テスト環境下で注文管理システム70により付与された注文番号を含む。)が作成され、新システムから出力されたその発注電文(テスト環境の注文番号を含む。)を市場用スタブ45が受信し、市場用スタブ45により、注文番号についてのテスト環境の番号と本番環境の番号との関連付け処理が行われ、再現電文記憶手段56にその関連付け情報を追加する更新処理が行われるので、そのタイミングで、投入手段43により、通知電文(テスト環境の注文番号を含む。)を新システムに投入する。
なお、新システムのシステム時刻として設定される仮想の時刻と、その仮想の時刻を新システムのシステム時刻に設定するタイミングである現実の時刻とは、全く無関係である。例えば、時間帯(3)=9:00〜11:30の開始時刻である9:00を仮想の時刻として新システムのシステム時刻に設定するタイミングは、現実の時刻では何時でもよく、例えば、午後の13:00等とすることができる。そして、現実の時刻が13:00のタイミングで、仮想の時刻9:00を設定したとすると、現実の時刻が13:05を進行中であれば、新システムのシステム時刻は、9:05を進行中ということになる。但し、現実の時刻が13:05になる前に、時間帯(3)の投入電文の投入処理が終了し、次の時間帯(4)の投入電文の投入処理を開始することができる場合には、新システムのシステム時刻は、大きくずれることになる。例えば、現実の時刻が13:04のタイミングで、次の時間帯(4)=11:30〜12:05の開始時刻である11:30を仮想の時刻として新システムのシステム時刻に設定したとすると、現実の時刻が13:05を進行中であれば、新システムのシステム時刻は、11:31を進行中ということになる。すなわち、新システムでは、時間帯の切替が行われたので、新システムのシステム時刻は、もはや時間帯(3)の9:05を進行中ということではなく、次の時間帯(4)の11:31を進行中ということになる。このように現実の時刻の進行に対し、新システムのシステム時刻は、時間帯の切替により急速に進行していくので、検証に要する処理時間の短縮を図ることができる。それぞれの時間帯内においては、現実の時刻の進行速度と、新システムのシステム時刻の進行速度とは、当然に同じであるが、新システムは、時間帯の切替が行われることにより、全体的に見れば、みかけ上、進行速度が速くなるという意味である。そして、以上は、時間帯の切替により、新システムのシステム時刻の進行速度を、みかけ上、速くすることができるという観点での説明であるが、これを実現するには、そもそも時間帯の切替を短い時間間隔で繰り返し行うことができることが前提となるので、下記の投入タイミングの圧縮が必須となる。
すなわち、投入手段43によるテスト環境下での各投入電文の投入処理は、本番環境下でのログへの各投入電文の記録時刻よりも圧縮したタイミングで実行する。例えば、時間帯(3)=9:00〜11:30における本番環境での各投入電文の投入処理は、現実の時刻で記録しているので、当然、2時間半かかっているが、テスト環境では、これを圧縮し、かなり短い時間で各投入電文の投入処理を終了させることができる。例えば、4分以内で時間帯(3)の全ての投入電文の投入処理を終了させることができるとすれば、時間帯(3)=9:00〜11:30の開始時刻である9:00を仮想の時刻として新システムのシステム時刻に設定し、その直後に投入処理を開始したとすると、新システムのシステム時刻が9:04になったときには、投入処理が終了していることになる。従って、投入タイミングの圧縮により、本番環境下で2時間半かけて投入されていた各投入電文について、テスト環境では、2時間半よりも、かなり短時間で投入処理を終了させることができるので、次の時間帯(4)への早期の切替が可能となり、このような投入タイミングの圧縮および時間帯の切替の繰り返しにより、検証に要する処理時間の短縮を図ることができる。
また、上記のように、投入タイミングの圧縮により、それぞれの時間帯の各投入電文について、かなり短時間で投入処理を終了させることができるので、新システムのシステム時刻として設定する仮想の時刻は、それぞれの時間帯の開始時刻である必要はない。例えば、4分以内で時間帯(3)の全ての投入電文の投入処理を終了させることができるとすれば、時間帯(3)=9:00〜11:30の開始時刻である9:00ではなく、例えば10:00を仮想の時刻として新システムのシステム時刻に設定してもよく、その場合でも、新システムのシステム時刻が10:04になったときには、時間帯(3)の全ての投入電文の投入処理が終了していることになり、すべて時間帯(3)の範囲内での投入処理となるので、システムの振る舞いは、開始時刻である9:00を仮想の時刻として設定した場合と同じである。
さらに、上記のように、投入タイミングの圧縮が行われるので、たとえそれぞれの時間帯の開始時刻を新システムのシステム時刻に設定して投入を開始したとしても、本番環境での各投入電文の投入の記録時刻(現実の時刻)と、テスト環境での各投入電文の投入時刻(新システムのシステム時刻、すなわち新システムで進行している仮想の時刻)とは一致しない。例えば、時間帯(3)の場合には、本番環境で丁度9:00(現実の時刻)に投入された投入電文については、テスト環境でも、丁度9:00(新システムのシステム時刻)に投入されることになるかもしれないが、それ以外の時刻に投入された投入電文については、一致しない。なお、ここでは、本番環境での記録時刻(現実の時刻)が、テスト環境での新システムのシステム時刻(仮想の時刻)による投入時刻と一致しないという説明をしており、テスト環境における現実の時刻が、これらとは全く無関係である(何時でもよい)ことは、前述した通りである。
そして、投入処理が完了した後に、テスト環境情報収集手段30により、テスト環境下の新システムである注文処理システム(図3の注文受付システム80および注文管理システム70)から、検証処理に必要な各種の情報を収集する(図6のステップS5)。
具体的には、テスト応答電文取得手段31により、テスト環境下の新システム(図3参照)の注文応答ログ記憶手段86に記憶された注文応答電文(応答電文)のログ情報、および条件付注文ログ記憶手段87に記憶された条件付注文電文(応答電文)のログ情報を取得し、取得した各ログ情報を、テスト応答電文記憶手段54に記憶させる。また、図1および図3には、市場用スタブ45により、注文番号をテスト環境下の番号から本番環境下の番号に変換し、発注電文(本番環境下の番号に変換後の注文番号を含む。)を、テスト応答電文記憶手段54に記憶させるように図示されているが、テスト応答電文取得手段31により、発注ログ記憶手段74に記憶された発注電文(応答電文)のログ情報を取得し、再現電文記憶手段56に記憶された二つの環境下の番号の関連付け情報を用いて、注文番号をテスト環境下の番号から本番環境下の番号に変換し、発注電文(本番環境下の番号に変換後の注文番号を含む。)を、テスト応答電文記憶手段54に記憶させてもよい。
また、業務終了時点テストデータ取得手段32により、テスト環境下の新システム(図3参照)の業務終了時点における注文データ記憶手段84に記憶された注文データ、および発注データ記憶手段73に記憶された発注データを取得し、取得したデータを、業務終了時点テストデータ記憶手段55に記憶させる。
続いて、注文データ検証手段46および応答電文検証手段47により、新旧システムの処理結果を比較し、新旧システムの動作が同じか否かを確認する検証処理を実行する(図6のステップS6)。
具体的には、注文データ検証手段46により、業務終了時点本番データ記憶手段53に記憶された旧システム(図2参照)の注文データおよび発注データと、業務終了時点テストデータ記憶手段55に記憶された新システム(図3参照)の注文データおよび発注データとを比較することにより、新旧システムの動作が同じか否かを確認する。この際、注文データおよび発注データの構成(形式または定義)が新旧システムで相違する場合には、注文データ検証手段46により、注文データ検証用差分記憶手段58に記憶された差分情報を用いて変換処理を行うことにより形式または定義を統一してから、比較検証処理を実行する。
また、応答電文検証手段47により、本番応答電文記憶手段51に記憶された旧システム(図2参照)の応答電文(注文応答電文、条件付注文電文、発注電文)と、テスト応答電文記憶手段54に記憶された新システム(図3参照)の応答電文(注文応答電文、条件付注文電文、発注電文)とを比較することにより、新旧システムの動作が同じか否かを確認する。この際、応答電文の構成(形式または定義)が新旧システムで相違する場合には、応答電文検証手段47により、応答電文検証用差分記憶手段59に記憶された差分情報を用いて変換処理を行うことにより形式または定義を統一してから、比較検証処理を実行する。
<本実施形態の効果>
このような本実施形態によれば、次のような効果がある。すなわち、検証システム10は、分類手段42により、テスト環境下での再現に使用する投入電文を複数の時間帯に分類しておき、投入手段43により、複数の時間帯のそれぞれについて、テスト環境下の新システムについてのシステム時刻を仮想の時刻に設定した状態で、その仮想の時刻に対応する時間帯の投入電文を新システムに投入する構成とされているので、投入電文の投入タイミング(投入間隔)を圧縮しても、新システムで進行している仮想の時刻で見た場合には、投入電文は、投入すべき時間帯に新システムに投入されていることになるため、新システムにおいて、投入電文に対する適正な挙動(本番環境で実行された処理を再現する挙動)を得ることができる。
このため、1日の再現を1日かけて実施する必要はなく、新システムへの投入電文の投入タイミング(投入間隔)を圧縮することにより、1日の再現を短時間で実行することができ、検証処理の時間短縮を図ることができる。
また、再現したい日が大量にある場合でも、新システムへの投入電文の投入タイミング(投入間隔)の圧縮を、日を超えて行うことにより、テストに要する日数が本番環境と同じ日数分だけ発生してしまうことを回避することができ、検証処理の時間短縮を図ることができる。
また、投入手段43は、仮想の時刻の設定指令の送信処理と、当該仮想の時刻に対応する時間帯の投入電文の投入処理とを連動させ、自動的に繰り返す構成とされているので(図5参照)、仮想の時刻の設定指令の送信タイミングや、当該仮想の時刻に対応する時間帯の投入電文の投入開始タイミングの管理を手動で行う場合に比べ、省力化(再現テストの担当者の負荷軽減や、再現テストにかかる要員の削減)を図ることができるとともに、複数の時間帯に跨っての投入電文の投入タイミング(投入間隔)の圧縮を、より一層確実に行うことができ、検証処理の時間短縮を効果的に図ることができる。さらに、再現の自動化により、夜間の再現テストも可能になる。そして、この効果は、同じ日の再現を何回も実施する場合や、複数の日(本番環境下における複数の日)の再現を実施する場合には、より顕著に得ることができる。
さらに、分類手段42は、複数の入力経路の各投入電文を、時間帯で分類し、かつ、顧客毎にグルーピングする構成とされ(図4参照)、投入手段43は、各時間帯に分類され、かつ、顧客毎にグルーピングされた状態の投入電文を、同一顧客内の投入電文の順序を保ったまま顧客毎のグループ単位で新システムに投入していくので(図5参照)、本番環境を適正に再現することができる。すなわち、注文処理システムでは、投入電文として、新規注文、注文の訂正、および注文の取消のケースを含む注文電文と、市場システム130からの通知電文とがあるので、投入電文を時間帯で分類し、かつ、システム時刻への仮想の時刻の設定を行ったとしても、同一顧客内の投入電文の順序が本番環境の通りに保たれないと、新システムで所望の挙動(本番環境での処理を再現する挙動)を得られないことがあるが、このような問題の発生を回避することができる。例えば、本番環境で、注文の訂正があった後に、約定していた場合に、テスト環境で、訂正の注文電文と約定の通知電文との投入順序が入れ替われば、注文の訂正がないのに、訂正された状態での約定通知を受けることになってしまうが、このような事態を回避することができる。
そして、分類手段42は、複数の入力経路についての記録時刻が同時刻になったときに、予め定められた入力経路の優先順位に従って各投入電文を並べる構成とされているので、本番環境で生じた状況を正しく再現することができ、新システムで所望の挙動(本番環境での処理を正しく再現する挙動)を得ることができる。すなわち、複数の入力経路についての本番環境下の記録時刻が同じ時刻になっていたとしても、本番環境における実際の処理には時間差があり、順番がある場合があるので、それらの処理の順序が逆転してしまうと、エラーが発生する等、新システムで所望の挙動(本番環境での処理を再現する挙動)を得られないことがあるが、このような問題の発生を回避することができる。
また、検証システム10は、投入用差分記憶手段57を備えているので、投入手段43は、この投入用差分記憶手段57に記憶された投入電文の形式または定義の差分情報を用いて、再現電文記憶手段56に記憶された投入電文を、新システム用の形式または定義に変換してから新システムに投入することができる。このため、新旧システムの投入電文の形式または定義に差分があるときであっても、本番環境から取得した投入電文を用いて、テスト環境下の新システムに投入する投入電文を自動的に作成することができるので、検証処理の準備作業を容易に行うことができ、省力化を図ることができる。
さらに、検証システム10は、注文データ検証用差分記憶手段58および応答電文検証用差分記憶手段59を備えているので、テスト環境下で、本番環境を再現する投入電文の投入処理を終了した後に、注文データ検証手段46および応答電文検証手段47により、注文データや発注データ、および応答電文について、新旧システムの処理結果を比較する検証処理を行う段階でも、これらの注文データや発注データ、および応答電文について、新旧システム間で、形式または定義に差分があれば、その差分を考慮して自動変換を行ってから比較検証処理を実行することができる。このため、比較検証の段階でも、検証作業を容易に行うことができ、省力化を図ることができる。
<変形の形態>
なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。
例えば、前記実施形態では、検証システム10による比較検証対象が、一例として、株式の注文処理システムとされていたが、本発明の検証システムによる比較検証対象は、株式の注文処理システムに限定されるものではなく、株式以外の金融商品の注文処理システムであってもよく、さらには、市場への発注を行う注文処理システムに限定されるものでもなく、要するに、時間帯によりシステムの挙動が切り替わるシステムであれば、本発明の適用対象となり得る。但し、市場が関与し、それにより複数の入力経路が形成されるシステムであれば、本発明の効果が、より一層顕著に得られる。
また、前記実施形態では、投入手段43は、新システムのシステム時刻を仮想の時刻に設定するための設定指令の送信処理と、その仮想の時刻に対応する時間帯の各投入電文の投入処理とを連動させ、自動的に繰り返す構成とされていたが(図5参照)、仮想の時刻の設定指令の送信タイミングや、各時間帯の投入電文の投入開始タイミングを、人が管理し、各処理を手動操作で開始させる構成としてもよい。但し、これらの処理を連動させ、自動的に繰り返す構成としておけば、省力化を図ることができるとともに、検証処理の時間短縮を、より一層確実に図ることができる。