JP2009245066A - ソフトウェアマイグレーションシステム及び方法 - Google Patents

Abstract

【課題】マイグレーション対象のソフトウェアの業務要件のヒアリングや説明を不要としたソフトウェアマイグレーション技術を提供する。
【解決手段】旧言語のソフトウェアを構成する各ＦＵ（Functional Unit）のソースコードが分析され、その分析の結果を基に、旧言語のＦＵ間の呼出し依存関係が把握される。そして、把握された呼出し依存関係に基づいて、旧言語のＦＵから新言語のＦＵへのＦＵ変換と、正しくＦＵ変換が行われたかどうかの内部レベル（ソースコードレベル）のテストが行われる。各ＦＵ変換についての各内部レベルのテストの結果が異常無しであれば、新言語のＦＵとそれに対応する旧言語のＦＵに対して、ソフトウェアの外部（例えばスクリーン或いはバッチ）から情報を入力し同じ振舞いが行われたかどうかの外部レベルのテストが行われる。外部レベルのテストの結果も異常無しであれば、ソフトウェアマイグレーションの完了となる。
【選択図】図５

Description

本発明は、ソフトウェアのマイグレーションに関する。

アプリケーションプログラム等のソフトウェアのマイグレーションの依頼をクライアントからサプライヤが受けて、サプライヤがクライアントに代わってソフトウェアマイグレーションを行うサービスが知られている。「ソフトウェアマイグレーション」とは、或る言語で記述されているマイグレーション対象のソフトウェアが有する全ての機能を引き継いだ、別の言語で記述されたソフトウェアを構築することである。以下、マイグレーション対象のソフトウェアを、「旧ソフトウェア」と言い、旧ソフトウェアを記述した第一の言語を「旧言語」と言う。それに対し、旧ソフトウェアの機能が引き継がれたソフトウェアを「新ソフトウェア」と言い、新ソフトウェアを記述した第二の言語を「新言語」と言う。なお、「旧」や「新」といった言葉は、便宜上使用している言語であって、マイグレーション対象のソフトウェアを記述した言語が必ずしも年代的に古く（例えばCobol或いはVisual Basic）、マイグレーション後のソフトウェアを記述した言語が必ずしも年代的に新しい（例えばJava（登録商標）.NET）というわけではない。

ソフトウェアマイグレーションでは、通常、サプライヤが、旧ソフトウェアでどんな業務が実行されるかといった業務要件をクライアントからヒアリングし、クライアントから聞いた業務要件に基づいて、新ソフトウェアを構築する（例えば非特許文献１）。

http://www.systems-inc.co.jp/migration/index.htm#001

従来のソフトウェアマイグレーションでは、サプライヤがクライアントから旧ソフトウェアの業務要件をヒアリングすることは、重要且つ必須である。なぜなら、ソフトウェアマイグレーションでは、旧ソフトウェアで行われる業務を新ソフトウェアで行うことができるかどうか（言い換えれば、全ての機能が正しく引き継がれたかどうか）を検証する必要があるが、クライアントから業務要件をヒアリングできていないと、上述のことを検証することができないためである。従って、サプライヤにとって、クライアントへの依存度が大きい。また、クライアントにとってみれば、旧ソフトウェアの業務要件をサプライヤに伝えることは、負担の大きい作業である。

また、上記のヒアリングの目的は、全ての機能が正しく引き継がれたかどうかを検証することに加えて、どんな機能を有したソフトウェアを新言語で記述したら良いかの指針を知ることにある。つまり、従来のソフトウェアマイグレーションでは、マイグレーションと言っても、クライアントから聞いた業務要件に従って、新ソフトウェアを作成しており、新規開発となんら変わりが無い。

また、ソフトウェアマイグレーションを外国（例えばインド或いは中国）で行うサプライヤもいる。外国でソフトウェアマイグレーションを行うためには、サプライヤ或いはクライアントが、オフショアの人間（典型的には外国人）に、クライアントから聞いた業務要件を説明し理解してもらう必要がある。しかし、それは、負担の大きい作業である。その大きな理由として、日本語と外国語という言語の違いや、日本と外国との間での文化の違いがある。例えば、旧ソフトウェアが、金融に関するソフトウェアの場合、旧ソフトウェアが有する業務要件をオフショアの人間に説明する前に、日本の金融システムについて説明し理解してもらう必要がある場合がある。その際、日本語と外国語という言語の違いから、日本の金融システムや、旧ソフトウェアが有する業務要件を、オフショアの人間に正確に伝えるのが難しい場合がある。

従って、本発明の目的は、マイグレーション対象のソフトウェアの業務要件のヒアリングや説明を不要としたソフトウェアマイグレーション技術を提供することにある。

旧言語のソフトウェアを構成する各ＦＵ（Functional Unit）のソースコードが分析され、その分析の結果を基に、旧言語のＦＵ間の呼出し依存関係が把握される。そして、把握された呼出し依存関係に基づいて、旧言語のＦＵから新言語のＦＵへのＦＵ変換と、正しく変換が行われたかどうかの内部レベル（ソースコードレベル）のテストが行われる。各ＦＵ変換についての各内部レベルのテストの結果が異常無しであれば、新言語のＦＵとそれに対応する旧言語のＦＵに対して、ソフトウェアの外部（例えばスクリーン或いはバッチ）から情報を入力し同じ振舞いが行われたかどうかの外部レベルのテストが行われる。外部レベルのテストの結果も異常無しであれば、ソフトウェアマイグレーションの完了となる。

図１は、本発明の一実施形態に係るソフトウェアマイグレーションシステムのハードウェア構成の一例を示す。

通信ネットワーク６０に、サーバ１００と１又は複数の作業者端末５０とが接続されている。

作業者端末５０は、作業者が使用する計算機である。作業者端末５０は、例えば、入力装置５１と、表示装置５３と、ＣＰＵ（Central Processing Unit）５５と、記憶装置５７と、ネットワークＩ／Ｆ（Interface）５９とを備えている。なお、「作業者」とは、ソフトウェアマイグレーションに関わる作業を行う人間である。

サーバ１００は、作業者端末５０に種々のサービスを提供する計算機である。サーバ１００は、例えば、ＣＰＵ１０７と、記憶装置１０５と、ネットワークＩ／Ｆ１１１とを備えている。記憶装置１０５は、例えば、主記憶装置（例えばメモリ）及び／又は補助記憶装置（例えば不揮発性の記憶メディアのドライブ）である。ネットワークＩ／Ｆ１１１は、通信ネットワーク６０を介した通信を行うための通信装置（例えばＮＩＣ（Network Interface Card））である。

本実施形態に係るソフトウェアマイグレーションは、多数の処理から構成されているが、それら多数の処理は、５つのフェーズに分類することができる。

図２は、本実施形態に係るソフトウェアマイグレーションにおける５つのフェーズの遷移図である。

この図に示すように、ソフトウェアマイグレーションにおけるフェーズとして、下記の５つ、
Ｐ１０００：現行システム分析；
Ｐ２０００：変換方式設計；
Ｐ３０００：技術差異分析；
Ｐ４０００：継続的インテグレーション；及び
Ｐ５０００：新旧稼動比較テスト
がある（ここでの「Ｐ」は、Phaseの頭文字を表す）。以下、これら５つのフェーズの概要を説明する。

Ｐ１０００：現行システム分析
現行システム分析では、旧ソフトウェア（マイグレーション対象のソフトウェア）に含まれている各ＦＵ（Functional Unit）のキャプチャが行われる（以下、旧ソフトウェア内のＦＵを「旧ＦＵ」と言う）。具体的には、旧ソフトウェアのソースコードが分析され、ＦＵ間の呼出し依存関係（以下、「ＦＵ呼出し依存関係」と言う）が算出される。そして、算出されたＦＵ呼出し依存関係を基に、どの旧ＦＵをいつ新ＦＵ（新言語で記述されたＦＵ）に変換するかのＦＵ変換スケジュールが作成される。ここで重要な点は、旧ソフトウェアのソースコード分析では、旧ソフトウェアの業務要件を知る必要は全く無いことである。なお、「ＦＵ」とは、何かしらの振舞いを行う、プログラムの最小単位（最小振舞い単位）であり、典型的には、プロシージャ、サブルーチン、或いは関数と呼ばれるモジュールである。

Ｐ２０００：変換方式設計
旧ソフトウェアのソースコードを新ソフトウェアのソースコードに変換するためにどんな言語変換ツール（コンピュータプログラム）を用いるかの選定が行われる。また、言語変換ツールのテストランやテストラン結果の検証も行われる。その結果、旧ソフトウェアの何パーセントを自動で言語変換できるかがわかる。旧ソフトウェアの自動で言語変換できないパートについては、手動で言語変換する必要がある。

Ｐ３０００：技術差異分析
旧ソフトウェアの手動で言語変換する必要のあるパートについて、このフェーズが実行される。具体的には、旧ソフトウェアに関する技術（以下、「旧技術」と言う）と新ソフトウェアに関する技術（以下、「新技術」と言う）との比較が行われ、その比較の結果を基に、Ｐ４０００（継続的インテグレーション）においてどのような処理を行うかのガイドラインを表す情報（以下、「ガイドライン情報」と言う）が決定される。例えば、旧技術ではサポートされているが新技術でサポートされていない仕様がある場合には、継続的インテグレーションにおいてどのような処理を行うかが決定される。

Ｐ４０００：継続的インテグレーション
Ｐ１０００（現行システム分析）で作成されたＦＵ変換スケジュールは、依存度の低い旧ＦＵほど先に新ＦＵへと変換するスケジュールとなっている。このフェーズでは、そのスケジュールに従って（必要に応じて、Ｐ３０００（技術差異分析）で作成されたガイドライン情報が更に参酌されて）、依存度の低い旧ＦＵから先に、以下の（処理１）〜（処理３）、
（処理１）旧ＦＵから新ＦＵへの変換（ＦＵの言語変換、以下、「ＦＵ変換」と言う）、
（処理２）ＦＵ変換が正しく行われたか否かのテスト、
（処理３）テストの結果が異常無しであり、且つ、（処理１）で得られた新ＦＵより依存度が低い新ＦＵが存在する場合に、その新ＦＵに（処理１）で得られた新ＦＵをインテグレートする処理、
が行われる。全ての旧ＦＵについて（処理１）〜（処理３）が行われることで、新ソフトウェアが構築される。このフェーズで、旧ソフトウェアから新ソフトウェアへのマイグレーションが暫定的に完了したことになる。この後に、Ｐ５０００（新旧稼働比較テスト）が実行され、異常が無ければ、ソフトウェアマイグレーションが完全に完了したことになる。具体的には、Ｐ４０００（継続的インテグレーション）では、ＦＵ変換の都度に、そのＦＵ変換が正しく行われたか否かがテストされるが、そのテストは、内部レベルのテスト（ソースコードレベルのテスト）であり、次のＰ５０００（新旧稼働比較テスト）で、外部レベルのテストが実行される。内部レベルのテストと外部レベルのテストの両方で異常が無ければ、ソフトウェアマイグレーションが正しく行われたことになる。

Ｐ５０００：新旧稼動比較テスト
前述したように、外部レベルのテストが実行される。外部レベルのテストでは、旧ソフトウェア内の旧ＡＲ（Action Receiver）と、新ソフトウェア内の新ＡＲ（その旧ＡＲから得られた新ＡＲ）が、ソフトウェアの外部から同じ入力（以下、外部からの入力を「外部入力」と言う）を受ける。新旧のソフトウェアが、その外部入力に応答したアクションを行い、それらのアクションが同じか否かが検証される。このような検証は、新旧のソフトウェアにアクションが行われる都度に実行される。ここで、「ＡＲ」とは、外部入力を受け付けるＦＵのこと（つまり一種のＦＵ）である。ＦＵがＡＲであるか否かは、Ｐ１０００（現行システム分析）で把握される。また、「外部」とは、例えば、スクリーン（ＡＲのユーザに対するインタフェース、典型的にはＧＵＩ（Graphical User Interface））、又はバッチプログラムである。従って、外部入力は、例えば、ユーザからスクリーンに対して情報が入力されて特定の操作が行われたことに起因してスクリーンから入力されるパラメータ値、或いは、バッチプログラムから入力されるパラメータ値がある。

以上が、本実施形態に係るソフトウェアマイグレーションの概要である。ソフトウェアのマイグレーションでは、人間によって行われる処理もあれば、コンピュータプログラムによって行われる処理もある。

図３は、本実施形態で実行される代表的なコンピュータプログラムを示す。なお、図３には、ソフトウェアマイグレーションの前に存在するコンピュータプログラムを実線で示しており、ソフトウェアマイグレーションの過程で追加されるコンピュータプログラムを点線で示している。

本実施形態で実行される代表的なコンピュータプログラムとして、例えば、循環的複雑度算出プログラム１２１、旧テストプログラム１２２、新テストプログラム１３２、チェックポイント結果チェッカー１２３、ロガーフレームワーク１２４、ログチェッカー１２５、前バッチプログラム１２６、後バッチプログラム１２７、スクリーン遷移アナライザ１２８、チェックポイント外部化プログラム群１２９、言語変換ツール１３０、ＦＵ変換スケジューラ１３１及び比較プログラム１３３がある。これらのコンピュータプログラム１２１〜１３３は、サーバ１００の記憶装置１０５に記憶され、記憶装置１０５からＣＰＵ１０７にロードされ、ＣＰＵ１０７にて実行される。以下の説明において、コンピュータプログラムが主語になる処理は、実際にはそのコンピュータプログラムを実行するＣＰＵ１０７によって行われる。

循環的複雑度算出プログラム１２１は、旧ＦＵ毎に、旧ＦＵに対応したセクション関係に基づいて、循環的複雑度を算出する。なお、「セクション」とは、ＦＵを構成する要素であり、ＦＵの実行の際の分岐となる最小単位である。「セクション関係」とは、複数のセクションと各セクション間のリンクとで構成された関係を意味する。

旧テストプログラム１２２は、旧ソフトウェアに所定の入力情報（値）をセットし対象の旧ＦＵを呼び出すプログラムである。対象の旧ＦＵが呼び出されると、後に詳述する仕組みによって、一つのログファイルが作成される。一つの旧ＦＵに対応する旧テストプログラムの数は、旧ＦＵの循環的複雑度と同数である。このため、一つの旧ＦＵにつき、その旧ＦＵの循環的複雑度と同数のログファイルが作成されることになり、それ故、旧ソフトウェアについて多数のログファイルが作成されることになる。旧テストプログラム１２２は、Ｐ１０００（現行システム分析）で用意されて実行される。

新テストプログラム１３２は、例えば旧テストプログラム１２２が変換されたプログラムであり、旧テストプログラム１２２と１対１で対応している。新テストプログラム１３２は、新ソフトウェアに所定の入力情報（値）をセットし対象の新ＦＵを呼び出す。対象の新ＦＵが呼び出されると、一つのログファイルが作成される。新テストプログラム１３２は、Ｐ４０００（継続的インテグレーション）で実行される。具体的には、ＦＵ変換の都度に行われる内部レベルテストにおいて、新テストプログラム１３２が実行されて、ログファイルが作成される。内部レベルテストでは、新ＦＵのログファイル（以下、「新ログファイル」と言う）が、その新ＦＵに対応した旧ＦＵのログファイル（以下、「旧ログファイル」と言う）と比較される。新ログファイルの中身と旧ログファイルの中身が実質的に同じであれば、異常無しと判断される。なお、内部レベルテストで参照される旧ログファイルは、Ｐ１０００（現行システム分析）で作成されたファイルである。また、新旧のテストプログラム１２２、１３２は、いわゆる「イン・プロセス」として動作する（すなわち、新旧のソフトウェアの一つのプロセスとして動作する）。従って、旧テストプログラム１２２は、旧ソフトウェアと同じ言語で記述され、新テストプログラム１３２は、新ソフトウェアと同じ言語で記述される。それに対し、前バッチプログラム１２６及び後バッチプログラム１２７は、いわゆる「アウト・プロセス」とし動作する（すなわち、サーバ１００の図示しないオペレーティングシステム（ＯＳ）上の、新旧のソフトウェアとは全く別のプロセス、として動作する）。

チェックポイント結果チェッカー１２３には、チェックポイントとして取得すべき項目が定義されている。チェックポイント結果チェッカー１２３は、テストプログラム１２２又は１３２の実行の結果として旧ソフトウェア又は新ソフトウェアにセットされたチェックポイント結果値を、チェックする。

ロガーフレームワーク１２４には、コンピュータプログラムが組み込まれている。ロガーフレームワーク１２４は、組み込まれているコンピュータプログラムにより、ログファイルを準備したり、チェックポイント結果チェッカー１２３によるチェックポイント結果値のチェックの結果を表すファイルを作成したりする。

ログチェッカー１２５は、作成された多数の旧ログファイルの入力を受けて、それら多数のログファイルを分析することで、ＦＵ呼出し依存関係を特定したり、各内部レベルテストのテスト結果の良し悪しをチェックしたりする。

前バッチプログラム１２６は、前バッチ処理が定義されたプログラムである。前バッチ処理とは、テストプログラム１２２又は１３２によって対象の旧ＦＵ又は新ＦＵが呼び出される前に実行すべきバッチ処理のことである。

後バッチプログラム１２７は、後バッチ処理が定義されたプログラムである。後バッチ処理とは、対象の旧ＦＵ又は新ＦＵが呼び出されて旧ログファイル又は新ログファイルの作成が完了した後に実行すべきバッチ処理のことである。

スクリーン遷移アナライザ１２８は、作成された多数の旧ログファイル又は新ログファイルの入力を受けて、それら多数の旧ログファイル又は新ログファイルを分析することで、旧ソフトウェア又は新ソフトウェアでのスクリーンの遷移の流れを特定する。

言語変換ツール１３０は、ＦＵ変換（つまりＦＵの言語変換）を行うプログラムである。

ＦＵ変換スケジューラ１３１は、ログチェッカー１２５に特定されたＦＵ呼出し依存関係に基づいて、ＦＵ変換スケジュールを作成する。

比較プログラム１３３は、各種の比較を実行する。比較プログラム１３３は、比較の種類毎に設けられていても良い。

チェックポイント外部化プログラム群１２９は、チェックポイントの外部化を実現する複数のコンピュータプログラムの集合である。「チェックポイントの外部化」とは、本実施形態における一つの特徴的なコンセプトである。具体的には、チェックポイントをどこにするかを人間任せにするのではなく（例えば、個々の作業者のスキルレベルに依存するのではなく）、機械的且つ包括的にチェックポイントを取得することで、ヒューマンレベルでの見落としを防ぐことである。チェックポイント外部化プログラム群１２９は、主に、外部レベルテストの際に実行される（一部のコンピュータプログラムは、外部レベルテストと内部レベルテストの両方で実行される）。外部レベルテストでは、前述したように、新旧のソフトウェアが、新旧のＡＲが受けた同一の外部入力に応じたアクションを行う。以下、新旧のＡＲが同一の外部入力を受ける前のことを「外部入力受領前」と言い、新旧のソフトウェアが同一の外部入力に応答したアクションを行うことを「アクション実行」と言い、新旧のソフトウェアがそのアクションを行った後のことを「アクション実行後」と言う。

図４は、チェックポイント外部化プログラム群１２９に含まれる複数のコンピュータプログラムを示す。

それら複数のコンピュータプログラムとして、例えば、データベース（ＤＢ）比較プログラム１２９１、ファイル状況差分検出プログラム１２９２、ネットワークリクエスト検出プログラム１２９３、ＤＢ接続検出プログラム１２９４及び変数値差分検出プログラム１２９５がある。

ＤＢ比較プログラム１２９１は、旧ソフトウェアがアクセスするＤＢ（以下、「旧ＤＢ」と言う）内の全レコードと、新ソフトウェアがアクセスするＤＢ（以下、「新ＤＢ」と言う）内の全レコードとの比較（以下、「全レコード比較」と言う）を行う。ＤＢ比較プログラム１２９１は、外部レベルテストで実行される。ＤＢ比較プログラム１２９１は、この比較を、アクション実行後の都度に行う。

なお、新旧のソフトウェアの種類によっては、新旧のＤＢの更新の際に、更新時刻が新旧のＤＢに書き込まれることになる。同一の外部入力が新旧のＡＲで受領されたことに応答した新旧のＤＢの更新を、正確に同じ時刻に行うことは困難であり、通常、新旧のＤＢの更新時刻は異なる。そうすると、ソフトウェアマイグレーションが正しく行われているとしても、全レコード比較では、不一致のレコードが存在することとなる。更新時刻に限らず、レコードの種類によって、レコードが新旧で同じにならないこともある。

そこで、ＤＢ比較プログラム１２９１が、設定ファイルに基づいて動作を制御する構成とされ、その設定ファイルに、全レコード比較での対象から除外するレコードのカラムを表す情報（例えばテーブル名とカラム名との組み合わせ）が設定される。これにより、ＤＢ比較プログラム１２９１は、除外対象のカラムに属するレコード以外の全レコードを新旧で比較することになる。

また、ＤＢ比較プログラム１２９１が、新旧のＤＢを特定するための情報を検出したならば、新旧のＤＢに属する全てのテーブルに関する情報（例えばテーブル名）を自動で取得する構成とされる。これにより、作業者が、設定ファイルに、新旧のＤＢを特定するための情報（例えば、新旧のＤＢの位置情報）を設定しておきさえすれば、新旧のＤＢに属する各テーブルに関する情報を設定しなくても、ＤＢ比較プログラム１２９１は、新旧のＤＢに属する全てのテーブルに関する情報を取得することができる。

さて、ファイル状況差分検出プログラム１２９２は、旧ソフトウェアについてのファイル状況差分（以下、「旧ファイル状況差分」と言う）と、新ソフトウェアについてのファイル状況差分（以下、「新ファイル状況差分」と言う）とを検出する。ここで、「ファイル状況」とは、所定の記憶空間（例えば、サーバ１００のファイルシステムにおけるルートディレクトリ以下の空間）にどんなファイルが存在しているかであり、具体的には、例えば、所定の記憶空間に存在するファイルのファイル名のリストである。ファイル状況差分検出プログラム１２９２は、外部レベルテストと内部レベルテストの両方で実行される。従って、「ファイル状況差分」は、内部ファイル状況差分と、外部ファイル状況差分の２種類がある。「内部ファイル状況差分」とは、対象ＦＵが呼び出される前のファイル状況と、対象ＦＵが呼び出されてログファイルが作成された後のファイル状況との差分である。「外部ファイル状況差分」とは、外部入力受領前のファイル状況と、アクション実行後のファイル状況との差分である。ファイル状況差分検出プログラム１２９２は、内部レベルテストでは、対象ＦＵの呼び出し前とログファイルの作成後の都度に実行され、外部レベルテストでは、外部入力受領前とアクション実行後の都度に実行される。なお、内部レベルテストと外部レベルテストの各々では、比較プログラム１３３によって、旧ファイル状況差分と新ファイル状況差分が比較され、互いに実質的に一致するか否かが判定される。

ネットワークリクエスト検出プログラム１２９３は、ネットワークＩ／Ｆ１１１を通じて何らかのリクエストが流れているか否かを監視し、流れていたらそのリクエストを検出する。ネットワークリクエスト検出プログラム１２９３は、外部入力受領前からアクション受領後にかけて監視を行う。ネットワークリクエスト検出プログラム１２９３は、外部レベルテストと内部レベルテストの両方で実行される。なお、内部レベルテストと外部レベルテストの各々では、比較プログラム１３３によって、新旧のソフトウェアについての監視の結果が比較される。

ＤＢ接続検出プログラム１２９４は、旧ソフトウェアの旧ＤＢに対するコネクションと新ソフトウェアの新ＤＢに対するコネクションとがそれぞれアクション実行後に切断されたか否かを検出する。ＤＢ接続検出プログラム１２９４は、外部レベルテストで実行される。ＤＢ接続検出プログラム１２９４は、ＤＢ差分検出プログラム１２９１と同様に、アクション実行後の都度に、コネクションの切断の有無を検出する。

変数値差分検出プログラム１２９５は、旧ソフトウェアについての全変数値差分（以下、「旧全変数値差分」と言う）と、新ソフトウェアについての全変数値差分（以下、「新全変数値差分」と言う）とを検出する。ここで、「全変数値」とは、サーバ１００内に存在する全ての変数値のことである。変数値差分検出プログラム１２９５は、外部レベルテストと内部レベルテストの両方で実行される。従って、「全変数値差分」は、内部全変数値差分と、外部全変数値差分の２種類がある。「内部全変数値差分」とは、対象ＦＵが呼び出される前の全ての変数値と、対象ＦＵが呼び出されてログファイルが作成された後の全ての変数値との差分である。「外部全変数値差分」とは、外部入力受領前に存在する全ての変数値と、アクション実行後に存在する全ての変数値との差分である。変数値差分検出プログラム１２９５は、内部レベルテストでは、対象ＦＵの呼び出し前とログファイルの作成後の都度に実行され、外部レベルテストでは、外部入力受領前とアクション実行後の都度に実行される。なお、内部レベルテストと外部レベルテストの各々では、比較プログラム１３３によって、旧全変数値差分と新全変数値差分が比較され、互いに実質的に一致するか否かが判定される。

以下、図５を参照して、本実施形態に係るソフトウェアマイグレーションで行われる処理の流れを説明する。なお、図５において、作業者（例えばオフショアの人間）によって行われる処理を表すボックスの線を細くし、コンピュータによって行われる処理を表すボックスの線を太くしている。また、図５における「Ｓ」は、Stepの頭文字を表す。図５に記載の各ステップの番号は、図２に記載の各フェーズの番号に対応する。例えば、１０００番台のステップに対応した処理は、Ｐ１０００（現行システム分析）に所属する処理であり、４０００番台のステップに対応した処理は、Ｐ４０００（継続的インテグレーション）に所属する処理であり、５０００番台のステップに対応した処理は、Ｐ５０００（新旧稼動比較テスト）に所属する処理である。

Ｓ１１００：
旧ソフトウェアから複数の旧ＦＵが把握される。具体的には、入力された旧ソフトウェアソースコードから複数の旧ＦＵソースコードが把握される。ここで重要なことは、図６に例示するように、旧ソフトウェアソースコード２０１を所定の規則に従って形式的に区切ることで、結果として、旧ＦＵソースコード２０１から複数の旧ＦＵソースコードが特定されることである。従って、旧ソフトウェアが有する業務要件を理解して旧ソフトウェアソースコード２０１を旧ソフトウェアの業務要件単位で区切る（つまり意味的に区切る）ことは、全く必要ない。つまり、旧ソフトウェアがどんな業務要件を有するかということは全く考慮する必要が無い。このＳ１１００の処理は、作業者によって行われるが、それに代えて、例えば、コンピュータプログラムが、上記の所定の規則に従って旧ソフトウェアソースコード２０１から複数の旧ＦＵソースコードを把握することも可能である。なお、上記の所定の規則としては、例えば、第一種の所定のコード（例えば“Sub”）と第二種の所定のコード（例えば“End Sub”）との間を一つの旧ＦＵソースコードとするという規則を採用することができる。

各旧ＦＵ（各旧ＦＵソースコード）について、下記Ｓ１２００乃至Ｓ１６００が行われる。以下、処理の対象となる旧ＦＵを、「対象旧ＦＵ」と言い、対象旧ＦＵのソースコードを、「対象旧ＦＵソースコード」と言う。

Ｓ１２００：旧ＦＵソースコードの分析
対象旧ＦＵから複数のセクションが把握される。具体的には、対象旧ＦＵソースコードから、複数のセクションソースコードが把握される。ここでも、対象旧ＦＵソースコードが意味的に区切られるのではなく（すなわち、対象旧ＦＵの機能を理解し機能毎に区切らえるのではなく）、形式的に区切られる（すなわち、所定の規則に従って区切られる）ことで、結果として、対象旧ＦＵソースコードから複数のセクションソースコードが把握されることになる。Ｓ１２００も、Ｓ１１００と同様、作業者によって行われるが、それに代えて、例えば、コンピュータプログラムが、所定の規則に従って対象旧ＦＵソースコードを複数のセクションソースコードに区切ることも可能である。

Ｓ１３００：セクション関係の構築
作業者が、セクション関係を構築する。すなわち、セクションとセクションとの関連付けが行われる。この結果、図７に例示するように、どのセクションがどのセクションに対して関連するかが定義される。図７では、丸が、セクションを表しており、矢印が、リンクを表している。図７から分かるように、セクションとセクションとの関連付けにより、多数通りのパスができる。パスは、リンクで結ばれた一連のセクションで構成される。セクション間の関連付けは、対象旧ＦＵソースコードを基に機械的に行うことができる。つまり、ここでも、対象旧ＦＵソースコードが有する機能が何であるかを理解する必要は無い。なお、Ｓ１３００では、セクション関係情報（どのセクションがどのセクションにリンクを張られているかを表す情報）を基に、循環的複雑度分析プログラム１２１が、図７に例示したようなセクション関係を表すセクション関係情報を、作業者端末５０の表示装置５３に表示することができる。この場合、作業者端末５０で実行される図示しないブラウザが、そのセクション関係情報が表すセクション関係（つまり図７に示す関係）を、表示装置５３のディスプレイ画面に表示することができる。

Ｓ１４００：循環的複雑度の算出
循環的複雑度分析プログラム１２１が、セクション関連情報から、セクション数及びリンク数を把握し、把握したセクション数及びリンク数を用いて、循環的複雑度を算出する。循環的複雑度を算出する目的は、対象旧ＦＵについて幾つの旧テストプログラム１２２を作成したら良いかを知るためである。備循環的複雑度数の計算式は、下記（式１）、
循環的複雑度＝リンク数−セクション数＋（１＋リーフ数（終点セクション数））・・（式１）、
である。

Ｓ１５００：旧テストプログラム１２２の作成
作業者が、算出された循環的複雑度に基づく数の旧テストプログラム１２２を作成する。「循環的複雑度に基づく数」とは、循環的複雑度を考慮して決定された数のことであり、循環的複雑度と同じ数であっても異なる数であっても良い。本実施形態では循環的複雑度と同じ数とする。旧テストプログラム１２２は、複数のパスのうちの対象とするパスを経由させる情報を対象旧ＦＵに入力することで、旧ソフトウェアのプロセスの結果としてのログファイルを出力させるためのコンピュータプログラムである。旧テストプログラム１２２の作成においても、旧ソフトウェアがどんな業務要件を有しているかを作業者は全く知らなくてよい。すなわち、本実施形態では、旧ソフトウェアの業務要件を把握することなく、いきなり、業務が有するプロセスを調べることになる。ちなみに、本実施形態の説明では、旧テストプログラム１２２（又は新テストプログラム１２３）が対象の旧ＦＵ（又は新ＦＵ）を呼び出すことで行われる振舞いのことを「プロセス」と言い、ＡＲが外部入力を受けることで行われる振舞いのことを「アクション」と言う。

Ｓ１６００：対象の旧ＦＵに対応した全ての旧テストプログラムの実行
対象旧ＦＵに対応した全ての旧テストプログラム１２２が実行される。旧テストプログラム１２２が実行されると、旧ソフトウェアのプロセスの結果として旧ログファイルが作成される。一つの旧テストプログラム１２２の実行につき、一つの旧ログファイルが作成されるので、このＳ１６００では、対象旧ＦＵの循環的複雑度と同数の旧ログファイルが作成される。作成された旧ログファイルは記憶装置１０５に格納される。

Ｓ１７００：スケジューラ用テキストの作成
全ての旧ＦＵについてＳ１２００〜Ｓ１６００が実行されると、旧ソフトウェアについて多数の旧ログファイルが作成されていることになる。ログチェッカー１２５が、それら多数の旧ログファイルを入力し、多数の旧ログファイルを分析して、スケジューラ用テキストを作成する。「スケジューラ用テキスト」とは、ＦＵ変換スケジューラ１３１に入力されるテキストファイルである。このテキストファイルには、複数のＦＵ呼出し関係が記録されている。「ＦＵ呼出し関係」とは、どの旧ＦＵからどの旧ＦＵが呼び出されたかの関係である。

Ｓ１８００：ＦＵ変換スケジュールの作成
ＦＵ変換スケジューラ１３１が、入力されたスケジューラ用テキストを基に（例えば、複数のＦＵ呼出し関係を基に）、ＦＵ呼出し依存関係を把握する。ＦＵ呼出し関係に対し、「ＦＵ呼出依存関係」とは、ＦＵの呼出しの向きとＦＵの依存度とによって定まるＦＵ間の関係である。ＦＵ呼出し依存関係の一例を図１２に示す。図１２の矢印の向きは、呼び出しの向きである。従って、例えば、ＦＵ１１からＦＵ１０が呼び出され、ＦＵ１０からＦＵ２が呼び出され、ＦＵ２からＦＵ１が呼び出される場合には、図１２に示すような関係になる。末端（木構造におけるリーフ）に近いほど、依存度が低く、先端に近いほど（末端から遠いほど）、依存度が高いということになる。従って、ＦＵ１，ＦＵ３，ＦＵ５，ＦＵ７，ＦＵ１２が、最も依存度が低く、ＦＵ２，ＦＵ４，ＦＵ８，ＦＵ９が、２番目に依存度が低く、ＦＵ６，ＦＵ１０が、３番目に依存度が低く、ＦＵ１１が、４番目に依存度が低い（つまり最も依存度が高い）、ということになる。図１２では、ＦＵ４は、一つのＦＵ３にのみ依存し、ＦＵ８は、二つのＦＵ５及びＦＵ７に依存し、この結果、ＦＵ８の方がＦＵ４よりも依存度が高いように見えるが、末端ＦＵからの距離が同じため、依存度も同じである。ＦＵ変換スケジューラ１３１は、把握されたＦＵ呼出し依存関係を基に、依存度の低い旧ＦＵからＦＵ変換を行うことを表したＦＵ変換スケジュールを作成する。

Ｓ１８００の終了が、Ｐ１０００（現行システム分析）の終了である。この後、Ｐ２０００（変換方式設計）が行われる。すなわち、複数の言語変換ツール１３０の中からこのソフトウェアマイグレーションでのＦＵ変換に使用される言語変換ツール１３０が選定される。また、旧ソフトウェアの何パーセントを自動で言語変換できるかが特定される。旧ソフトウェアの自動で言語変換できないパートがあれば、そのパートについて、Ｐ３０００（技術差異分析）が行われる。その後、Ｐ４０００（継続的インテグレーション）が行われる。

Ｐ４０００（継続的インテグレーション）では、ＦＵ変換スケジュールに従って、依存度の低い旧ＦＵから、以下のＳ４１００〜Ｓ４３００が行われる。

Ｓ４１００：ＦＵ変換
対象の旧ＦＵから新ＦＵへのＦＵ変換が行われる。

Ｓ４２００：内部レベルテスト
対象の旧ＦＵに対応する旧テストプログラム１２２を基に（例えば、旧テストプログラム１２２の言語が旧言語から新言語に言語変換ツール１３０を使用して変換されることにより）、新テストプログラム１３２が作成される（新テストプログラム１３２は、継続的インテグレーションの前に作成されていても良い）。そして、内部レベルテストが行われる。具体的には、例えば、対象の新ＦＵ（変換後の新ＦＵ）に対応した新テストプログラム１３２が実行されることで、対象の新ＦＵに対応した新ログファイルが作成される。また、対象の新ＦＵに対応した旧ＦＵの旧ログファイルが記憶装置１０５から読み出される。そして、作成された新ログファイルが、読み出された旧ログファイルと比較される。それらのログファイルの内容が実質的に同じであれば、正しくＦＵ変換が行われたということであり、故に、次のＳ４３００（インテグレーション処理）が行われる。それらのログファイルの内容が実質的に違っていれば、手動で、新ＦＵが編集される。

Ｓ４３００：インテグレーション処理
Ｓ４２００で得られた新ＦＵの呼出し先の新ＦＵが既にあれば（Ｓ４２００で得られた新ＦＵよりも依存度の低い新ＦＵが取得済みであれば）、その呼び出し先の新ＦＵに、Ｓ４２００で得られた新ＦＵがインテグレートされる。

以上のように、ＦＵ変換の都度に、内部レベルテストが実行され、内部レベルテストの結果に異常が無ければ、ＦＵ変換で得られた新ＦＵが依存度のより低い新ＦＵにインテグレートされる。図１２の例で言えば、ＦＵ１が先にＦＵ変換されており、その後に、ＦＵ２がＦＵ変換され、ＦＵ２についての内部レベルテストの結果が異常無しであれば、ＦＵ２がＦＵ１にインテグレートされる。

以上の一連の処理で、旧ソフトウェアから新ソフトウェアへのソフトウェアマイグレーションが暫定的に完了する。この後に、Ｐ５０００（新旧稼働比較テスト）で外部レベルテストが実行され、外部レベルテストの結果も異常無しであれば、旧ソフトウェアから新ソフトウェアへのソフトウェアマイグレーションが完全に完了する。Ｐ５０００（新旧稼働比較テスト）では、以下のＳ５１００及びＳ５２００が行われる。

Ｓ５１００：スクリーン入力ケースデータの作成
複数のスクリーン入力ケースデータが作成される。「スクリーン入力ケースデータ」とは、作業者がどのスクリーンに対してどんなスクリーン入力を行うか（例えばどんな値を入力してどんなボタンを押すか）のケースを規定したデータである。一つのＡＲにつき、そのＡＲの循環的複雑度と同数のスクリーン入力ケースデータが作成される。また、スクリーン入力ケースデータは、新旧のＡＲについてそれぞれ作成される。以下、旧ＡＲに対応したスクリーン入力ケースデータを「旧スクリーン入力ケースデータ」と言い、新ＡＲに対応したスクリーン入力ケースデータを「新スクリーン入力ケースデータ」と言う。

全ての新旧のスクリーン入力ケースデータについて、Ｓ５２００が実行される。

Ｓ５２００：外部レベルテストの実行
新旧のスクリーン入力ケースデータに従うスクリーン入力が新旧のスクリーンに対して行われると、新旧のＡＲが、新旧のスクリーンから同一の外部入力を受ける。その外部入力に応じたアクションを、新旧のソフトウェアが実行する。また、新旧のアクションに関して、チェックポイント外部化プログラム群１２９も実行される。

全ての新旧のスクリーン入力ケースデータについて、Ｓ５２００が行われ、その結果、異常無しであれば、本実施形態に係るソフトウェアマイグレーションが完全に終了する。

以下、図５を参照して説明した流れにおけるＳ１５００以降について、詳細に説明する。

＜Ｓ１５００（旧テストプログラム１２２の作成）＞。

前述したように、構築されたセクション関係には、多数のパスが存在する。一つのパスは、リンクで結ばれている一連のセクションで構成されている。旧テストプログラム１２２は、対象の旧ＦＵについて対象のパスの経由が実行される（対象のパスを構成するセクションの並び順にセクションが呼び出されるようにする）ためのプログラムである。対象パスの経由の実行は、対象の旧ＦＵにセットされる入力情報で定義される。入力情報は、旧テストプログラム１２２がセットする。従って、対象の旧ＦＵの循環的複雑度と同数の旧テストプログラム１２２を作成するということは、対象の旧ＦＵにおける多数のパスのうちの、その循環的複雑度と同数のパスが経由されるということ（別の言い方をすれば、その循環的複雑度と同数の異なる種類の入力情報を作成するということ）である。

作業者は、テスティングフレームワークを土台とし、テスティングフレームワークにコンピュータプログラムを組み込むことで、旧テストプログラム１２２を作成する。本実施形態では、テスティングフレームワークとして、ｘＵｎｉｔコンセプトをベースとしたフレームワークが利用される。なぜなら、年代的に古い言語（例えば、FORTRAN、Cobol、Visual Basic）、では、フレームワークが無いが、ｘＵｎｉｔコンセプトをベースとしたフレームワークにコンピュータプログラムを組み込むことで作成された旧テストプログラム１２２であれば、そのような年代的に古い言語で記述されている対象旧ＦＵに対しても、テストを実行することが可能であるためである。各旧テストプログラム１２２には、例えば、処理の実行手順が記述される。

＜Ｓ１６００（旧テストプログラム１２２の実行）＞。

図８は、旧ソフトウェアの構成と、旧テストプログラム１２２から呼び出された後の旧ソフトウェアのプロセスの概要を示す。

旧ソフトウェア１２０は、複数のＳＣを有する。「ＳＣ」とは、Structural Componentの略であり、一又は複数の旧ＦＵの論理的な入れ物である。ＳＣは、例えば、旧言語がビジュアルベーシックの場合、拡張子が“.frm”であるソースコードであり、旧言語がコボルの場合、拡張子が“.cbl”であるソースコードである。

旧テストプログラム１２２の実行よりも前に、作業者によって、各旧ＦＵに、ロガー３０１が設定される（すなわち、各旧ＦＵソースコードに、ロガーステートメントが記述される）。ロガー３０１は、例えば、各旧ＦＵのセクション毎に設定される。ロガー３０１の役割は、そのロガー３０１を有するセクションが呼び出されたことのログ（そのセクションがどのＳＣ内のどの旧ＦＵ内のセクションであるかのログ）を旧ログファイルに書き込むことである。ロガー３０１は、旧ログファイルにログを書き込む前に、旧ログファイルの排他制御のために旧ログファイルにロックをかけ、その後に、旧ログファイルにログを書き込み、ログを書き込んだ後に、ロックを解除する。

一つの旧テストプログラム１２２の結果として一つの旧ログファイルが作成されるが、その流れの概要は、例えば下記の通りである。

まず、旧テストプログラム１２２が、対象の旧ＦＵ１１に、その旧テストプログラム１２２に定義されている入力情報をセットする（Ｓ１）。

次に、旧テストプログラム１２２が、ロガーフレームワーク１２４に、旧ログファイルの準備を要求する（Ｓ２）。ロガーフレームワーク１２４は、その要求に応答して、旧ログファイル＃１１を準備する（Ｓ３）。

次に、旧テストプログラム１２２は、対象の旧ＦＵ１１を呼び出す（Ｓ４）。この結果、Ｓ１でセットされた入力情報に応じたセクション、例えばセクションＡが起動する。起動したセクションＡに設定されているログステートメントＡが、セクションＡが呼び出されたことのログ（例えば、セクションＡの名称と、セクションＡを有する旧ＦＵ１１の名称と、旧ＦＵ１１を有するＳＣ１の名称とで構成されたログ）を書くことを、ロガーフレームワーク１２４に要求する。その要求に応答して、ロガーフレームワーク１２４によって、ログステートメントＡが有する値（旧ＳＣ２内の旧ＦＵ１におけるセクションＡを表す情報）が、旧ログファイル＃１１に書き込まれる（Ｓ５）。

次に、セクションＡは、Ｓ１でセットされた入力情報に基づき、旧ＳＣ１内の旧ＦＵ６におけるセクションＣを呼び出す（Ｓ６）。このセクションＣに設定されているログステートメント（図示せず）が、旧ＳＣ１内の旧ＦＵ６におけるセクションＣが呼び出されたことのログを書くことを、ロガーフレームワーク１２４に要求する。その要求に応答して、ロガーフレームワーク１２４によって、ログステートメントが有する値（旧ＳＣ１内の旧ＦＵ６におけるセクションＣを表す情報）が、旧ログファイル＃１１に書き込まれる（Ｓ７）。

次に、旧ＦＵ６内のセクションＣは、Ｓ１でセットされた入力情報に基づき、旧ＳＣ３内の旧ＦＵ８におけるセクションＤを呼び出す（Ｓ８）。このセクションＤに設定されているロガー（図示せず）が、旧ＳＣ３内の旧ＦＵ８におけるセクションＤが呼び出されたことのログを書くことを、ロガーフレームワーク１２４に要求する。その要求に応答して、ロガーフレームワーク１２４によって、ログステートメントが有する値（旧ＳＣ１内の旧ＦＵ６におけるセクションＣを表す情報）が、旧ログファイル＃１１に書き込まれる（Ｓ９）。

以降、Ｓ１でセットされた入力情報に基づき、セクションから別のセクションへの呼出しと、呼び出されたセクションのことを示すログの旧ログファイル＃１１に対する書き込みとが繰り返される。これにより、一つの旧テストプログラム１２２に対応した一つの旧ログファイル＃１１が作成される。

図９は、旧テストプログラム１２２の実行に起因して呼び出される各種コンピュータプログラムと、作成される各種ファイルの一例を示す。なお、この図には、Ｓ１６００の詳細に加えて、Ｓ１７００（スケジューラ用テキストの作成）及びＳ１８００（ＦＵ変換スケジュールの作成）で行われる処理も示されている。

ロガーフレームワーク６０１には、コンピュータプログラムとして、例えば、セクションロガー６０３及びチェックポイント結果ライタ６０５が組み込まれている。セクションロガー６０３は、旧テストプログラム１２２（又は新テストプログラム１３２）からの要求に応答して、旧ログファイル２０３（又は新ファイル）をオープン（準備）したりクローズしたりする。チェックポイント結果ライタ６０５は、旧テストプログラム１２２（又は新テストプログラム１３２）の実行によって旧ソフトウェア２００（又は新ソフトウェア）に発生したチェックポイント結果値を、チェックポイント結果ファイル４３０に書き込む。

例えば、旧テストプログラム１２２には、処理の実行手順として、以下の（１）〜（５）の順番、
（１）初期値（入力情報）の設定、
（２）前バッチプログラム１２６の呼び出し、
（３）旧ログファイル（セクションログファイル）の作成、
（３−１）旧ログファイルのオープン（準備）、
（３−２）対象旧ＦＵの呼び出し、
（３−３）旧ログファイルのクローズ、
（４）チェックポイント結果チェッカー１２３の呼び出し、
（５）後バッチプログラム１２７の呼び出し、
で処理を実行することが定義されている。なお、（３−１）の処理定義に関連して、準備された旧ログファイル２０３に書き込むべき情報、すなわち、ＦＵフルネーム（ＳＣ名及びＦＵ名で構成された名称）、テストケース番号及び対象のパスの構成が書き込まれている。

以下、各処理を説明する。

＜＜（１）初期値（入力情報）設定＞＞
旧テストプログラム１２２は、図示しない所定の初期値（入力情報）を、旧ソフトウェア２００に設定する。

＜＜（２）前バッチプログラム１２６の呼び出し＞＞
旧テストプログラム１２２は、前バッチプログラム１２６を呼び出す。

前バッチプログラム１２６は、呼び出されると、以下の３つの処理、
・ファイル状況差分検出プログラム（FileDiffDetector）１２９２の呼び出し、
・ネットワークリクエスト検出プログラム（NetworkReqDetector）１２９３の開始、
・変数値検出プログラム（VariableDiffDetector）１２９５の呼び出し、
を実行する。

ファイル状況差分検出プログラム１２９２は、呼び出されると、呼び出された時点（ここでは、旧ログファイルの作成前）のファイル状況（所定の記憶空間に存在するファイルのファイル名のリスト）を検出し、検出されたファイル状況を表す結果ファイル４００Ｂを作成する。

ネットワークリクエスト検出プログラム１２９３は、開始されると、ネットワークＩ／Ｆ１１１を通じて何らかのリクエストが流れているか否かを定期的にチェックし、チェックの都度に、チェックの結果を、結果ファイル４１０に書き込む。

変数値差分検出プログラム１２９５は、呼び出されると、呼び出された時点（ここでは、旧ログファイルの作成前）に存在する全ての変数情報（変数名と変数値とのペア）を検出し、検出された全ての変数情報を記録した結果ファイル５００Ｂを作成する。

＜＜（３−１）旧ログファイルの準備＞＞
旧テストプログラム１２２が、このプログラム１２２に記述されているＦＵフルネーム及びテストケース番号を使用して、ロガーフレームワーク６０１に組み込まれているセクションロガー６０３を呼び出す。それにより、ＦＵフルネーム及びテストケース番号を持った、ロガーのインスタンスが、サーバ１００内の主記憶装置に展開される。旧テストプログラム１２２が、セクションロガー６０３に、旧ログファイルの準備を要求する。その際、旧テストプログラム１２２は、このプログラム１２２に記述されている対象パスの構成を、セクションロガー６０３に渡す。セクションロガー６０３は、旧テストプログラム１２２からの準備要求に応答して、ＦＵフルネーム及びテストケース番号に基づいて作成したファイル名の旧ログファイル２０３を準備する（例えば、メモリ等の主記憶装置に旧ログファイル２０３を展開する）。そして、セクションロガー６０３は、ＦＵフルネーム、テストケース番号及び対象パスの構成を、準備された旧ログファイル２０３に書き込む（図１０の１〜３行目を参照）。

＜＜（３−２）対象旧ＦＵの呼び出し＞＞
次に、旧テストプログラム１２２が、ＦＵフルネームから特定される対象の旧ＦＵを呼び出す。これにより、図８を参照して説明したように、セクションが次々に呼び出される。具体的には、対象パスを構成する複数のセクションが、対象パスを構成するセクションの並び順で呼び出される。セクションが呼び出される都度に、呼び出されたセクションに埋め込まれているログステートメントがセクションロガー６０３を使用する（セクションロガー６０３に要求を出す）ことによって、呼び出されたセクションを表す情報（つまりそのセクションが呼び出されたことのログ）が旧ログファイル２０３に書き込まれる。図９の例は、対象の旧ＦＵに存在する二つのセクションＡ及びＢがセクションＡ、Ｂの順で呼び出され、セクションＡに埋め込まれているログステートメント内の値（セクションＡを表す情報）と、セクションＢに埋め込まれているログステートメント内の値（セクションＢを表す情報）が、セクションロガー６０３によってログファイル２０３に書き込まれたことを表す。

＜＜（３−３）旧ログファイルのクローズ＞＞
対象パスを構成する全てのセクションが呼び出されたならば、旧テストプログラム１２２が、ロガーフレームワーク６０１に組み込まれているセクションロガー６０３に、クローズを要求する。セクションロガー６０３は、旧テストプログラム１２２からのクローズ要求に応答して、旧ログファイル２０３をクローズする（例えば、主記憶装置から補助記憶装置にログファイル２０３を書き出し、主記憶装置からそのログファイル２０３を削除する）。これにより、作成された旧ログファイル２０３が記憶装置１０５に保存される。その際、そのクローズ要求を受けたセクションロガー６０３がサーバ１００内の主記憶装置から消去されても良いし、消去されずに後でパラメータ（ＦＵフルネーム及びテストケース番号）が設定され直されても良い。

＜＜チェックポイント結果チェッカー１２３の呼び出し＞＞
旧テストプログラム１２２が、チェックポイント結果チェッカー１２３を呼び出す。呼び出されたチェックポイント結果チェッカー１２３は、まず、ロガーフレームワーク６０１に組み込まれているチェックポイント結果ライタ６０５に、チェックポイント結果ファイルの準備を要求する。チェックポイント結果ライタ６０５は、チェックポイント結果チェッカー１２３からの準備要求に応答して、チェックポイント結果ファイル４３０を準備する。次に、チェックポイント結果チェッカー１２３は、旧テストプログラム１２２の実行結果として旧ソフトウェアに発生したチェックポイント結果値を参照し、参照したチェックポイント結果値の書込みを、チェックポイント結果ライタ６０５に依頼する。チェックポイント結果ライタ６０５は、その依頼に応答して、チェックポイント結果値を、チェックポイント結果ファイル４３０に書き込む。最後に、チェックポイント結果チェッカー１２３は、チェックポイント結果ライタ６０５に、チェックポイント結果ファイルのクローズを要求する。チェックポイント結果ライタ６０５は、チェックポイント結果チェッカー１２３からのクローズ要求に応答して、チェックポイント結果ファイル４３０をクローズする。これにより、チェックポイント結果ファイル４３０が、記憶装置１０５に格納される。

＜＜（５）後バッチプログラム１２７の呼び出し＞＞
旧テストプログラム１２２は、後バッチプログラム１２７を呼び出す。

後バッチプログラム１２７は、呼び出されると、以下の３つの処理、
・ファイル状況差分検出プログラム１２９２の呼び出し、
・ネットワークリクエスト検出プログラム１２９３の終了、
・変数値検出プログラム１２９５の呼び出し、
を実行する。

ファイル状況差分検出プログラム１２９２は、呼び出されると、呼び出された時点（ここでは、旧ログファイル作成後）のファイル状況を取得し、取得されたファイル状況を表す結果ファイル４００Ａを作成する。なお、この時点で、ファイル状況差分検出プログラム１２９２は、この結果ファイル４００Ａと、旧ログファイルの作成前の上述の結果ファイル４００Ｂとを比較することにより旧内部ファイル状況差分を取得し、旧内部ファイル状況差分を表すファイルを作成して記憶装置１０５に格納しても良い。

ネットワークリクエスト検出プログラム１２９３が終了されると、ネットワークＩ／Ｆ１１１を通じて何らかのリクエストが流れているか否かの監視が行われなくなる。

変数値差分検出プログラム１２９５は、呼び出されると、呼び出された時点（ここでは、旧ログファイル作成後）に存在する全ての変数情報を検出し、検出された全ての変数情報を記録した結果ファイル５００Ａを作成する。なお、この時点で、変数値差分検出プログラム１２９５は、この結果ファイル５００Ａと、旧ログファイルの作成前の上述の結果ファイル５００Ｂとを比較することにより旧内部全変数値差分を取得し、旧内部全変数値差分を表すファイルを作成して記憶装置１０５に格納しても良い。

以上の一連の処理により、一つの旧テストプログラム１２２につき一つの旧ログファイル２０３が作成される。全ての旧ＦＵについて全ての旧テストプログラム１２２が実行されると、多数のログファイル２０３が作成される。

スクリーン遷移アナライザ１２８は、多数の旧ログファイル２０３（又は多数の新ログファイル）を分析することで、旧ソフトウェア２００（又は新ソフトウェア）のスクリーンの遷移の流れを把握し、把握したスクリーン遷移を表す情報を、結果ファイル４５０に書き込む。

以上、図８及び図９を参照して、旧テストプログラム１２２の実行と旧ログファイル２０３の作成とを説明したが、この説明は、新テストプログラム１３２の実行と新ログファイルの作成にも適用される説明である。すなわち、ロガー３０１付きの旧ＦＵをＦＵ変換すると、ロガー付きの新ＦＵが得られる。このため、新テストプログラム１３２が実行されると、新ＦＵに埋め込まれているロガーによって、新ログファイルにログが書き込まれることになる。また、後に説明する図１０は、或る旧テストプログラム１２２の実行により作成された旧ログファイル２０３の中身の具体例を示しているが、その旧テストプログラム１２２に対応する新テストプログラム１３２の実行により作成される新ログファイルの中身も、図１０に例示した中身と実質的に同じとなる。

＜Ｓ１７００（スケジューラ用テキストの作成）＞。

ログチェッカー１２５は、多数の旧ログファイル２０３を分析して、以下の（１）及び（２）、
（１）各対象パスが正確に経由されたかを検出し、検出の結果を表す情報を、結果ファイル４２０に書き込む、
（２）各ＦＵ呼び出し関係を記録したスケジューラ用テキスト４４０を作成する、
を実行する。

例えば、図１０に示す旧ログファイル２０３の中身の具体例によれば、ログチェッカー１２５は、８個のログ（７〜１４行目の８行のログ）があることから、テストケース＃１に対応した旧テストプログラム１２２によって対象旧ＦＵが呼び出された場合に８個のセクションが呼び出されたことがわかる。また、８個のログにおけるＳＣ名及びＦＵ名の組合せとＦＵフルネームとの比較から、ログチェッカー１２５は、対象旧ＦＵ内にあるセクションに対応したログは、７行目及び１１〜１４行目の計５個であることがわかる。また、ログチェッカー１２５は、その５個のログの並び順から、対象旧ＦＵでのセクションの呼び出し順序（つまり達成されたパス）が、Ａ，Ｃ，Ｄ，Ｅ及びＧであることを特定でき、対象パスの構成（Ａ、Ｃ、Ｄ、Ｅ及びＧ）との比較により、対象パスの構成通りにセクションが呼び出された（つまり達成されたパスは正しい）ことを検出することができる。更に、ログチェッカー１２５は、８〜１０行目のログから、対象旧ＦＵが別の旧ＦＵを呼び出すというＦＵ呼出し関係がわかる。

各旧ログファイル２０３について上記のような分析をすることで、ログチェッカー１２２は、旧ソフトウェアにおける多数のＦＵ呼出し関係を把握する。

また、図１１に示すように、ログチェッカー１２５は、多数の旧ログファイル２０３に加えて、以下の２つのパラメータ値、
（Ａ）各旧ＦＵに対応した循環的複雑度、
（Ｂ）作業者の人数、
を参照することで、図１１に示すスケジューラ用テキスト４４０を作成する。

このスケジューラ用テキスト４４０によれば、各行が、各旧ＦＵに対応しており、各行における要素は、左から、旧ＦＵのＩＤ、旧ＦＵの名称、人日数、ＦＵ変換開始日、ＦＵ変換終了日、呼出し先旧ＦＵのＩＤ、担当作業者ＩＤである。

人日数は、一人で旧ＦＵのＦＵ変換を担当した場合に要する時間を意味する。具体的には、例えば、旧ＦＵ１の循環的複雑度が“２６”であり、作業者の人数が“２０”である場合、ログチェッカー１２５は、旧ＦＵ１の人日数を、２６÷２０＝１．３人日、と計算する。

ＦＵ変換開始日及びＦＵ変換終了日は、本例では全てが同じ値のデフォルト値となっている。ＦＵ変換開始日及びＦＵ変換終了日は、ＦＵ呼出し依存関係、各旧ＦＵの人日数及び担当作業者ＩＤに基づいて、ＦＵ変換スケジューラ１３１によって自動で調整される。

呼出し先旧ＦＵのＩＤが記録されていない行に対応した旧ＦＵは、呼び出す旧ＦＵが存在しないため、依存度の最も低い旧ＦＵである。

旧ＦＵに対応した担当作業者は、例えば、Ｐ１０００（現行システム分析）でその旧ＦＵのソースコードの分析を担当した作業者である。

上記（Ａ）及び（Ｂ）のパラメータ値や、旧ＦＵのＩＤと担当作業者ＩＤとの対応関係は、例えば、或る記憶装置（例えば、サーバ１００内の記憶装置１０５、又は、サーバ１００と通信可能な遠隔の記憶装置）に登録される。ログチェッカー１２５は、上記或る記憶装置から、登録されている（Ａ）及び（Ｂ）のパラメータ値や、旧ＦＵのＩＤと担当作業者ＩＤとの対応関係を読み出すことで、（Ａ）及び（Ｂ）のパラメータ値を入力したり、各旧ＦＵに対応する担当作業者ＩＤを把握したりすることができる。

＜Ｓ１８００（ＦＵ変換スケジュールの作成）＞。

スケジューラ用テキスト４４０には、呼出し先旧ＦＵのＩＤが旧ＦＵ毎に記録されていることから、多数のＦＵ呼出し依存関係が記録されていることになる。

ＦＵ変換スケジューラ１３１が、スケジューラ用テキスト４４０を解釈することで、多数のＦＵ呼出し関係をまとめたＦＵ呼出し依存関係（例えば図１２に例示する木構造の関係）を把握する。ＦＵ変換スケジューラ１３１は、ＦＵ呼出し依存関係と、各旧ＦＵに対応した人日数及び担当作業者ＩＤに基づいて、ＦＵ変換スケジュールを作成する。ＦＵ変換スケジューラ１３１は、作成したＦＵ変換スケジュールを表す情報を、作業者端末５０に送信する。これにより、例えば図１３に示すように、作業者端末５０が有する表示装置５３のディスプレイ画面に、ＦＵ変換スケジュールが表示される。

なお、図１３において、各色付きブロックの横幅は、各旧ＦＵのＦＵ変換に要する作業期間を意味し、矢印の向きは、旧ＦＵの変換順序を意味する。作業期間は、例えば、その旧ＦＵの人日数に担当作業者の人数を除算して得られた値である。ＦＵ変換スケジューラ１３１にスタート日時（例えば１０月１日月曜日の６時）が設定されると、ＦＵ変換スケジューラ１３１が、各旧ＦＵの依存度に基づいて、旧ＦＵの変換順序を決定したり、各旧ＦＵの人日数及び担当作業者ＩＤを基に、各旧ＦＵについての作業期間（変換開始日時及び変換終了日時）を決定したりすることができる。その際、ＦＵ変換スケジューラ１３１は、同一の作業者が同じ時間帯に複数の旧ＦＵの作業期間が重ならないよう各旧ＦＵの作業期間を調整することができる。また、図示しないが、ＦＵ変換スケジューラ１３１は、指定された担当作業者のＩＤをキーにして、指定された担当作業者についてのスケジュールのみを抽出して表示することもできる。

＜Ｓ４２００（内部レベルテスト）＞。

内部レベルテストでは、前述したように、対象の新ＦＵに対応した全ての新テストテストプログラム（対象の新ＦＵの循環的複雑度と同数の新テストプログラム）１３２が実行されることで、対象の新ＦＵの循環的複雑度と同数の新ログファイルが作成される。また、新テストプログラム１３２が実行されると、図９を参照して説明した旧テストプログラム１２２の実行と同様に前バッチプログラム１２６及び後バッチプログラム１２７が呼び出される。このため、一つの新テストプログラム１３２につき、以下の（１）〜（５）の結果ファイル、
（１）新ログファイル作成前の新ファイル状況を表す結果ファイル、
（２）新ログファイル作成後の新ファイル状況を表す結果ファイル、
（３）ネットワークリクエストの検出結果を表す結果ファイル、
（４）新ログファイル作成前の新全変数値を表す結果ファイル、
（５）新ログファイル作成後の新全変数値を表す結果ファイル、
が作成される。

ファイル状況差分検出プログラム１２９２は、上記（１）と（２）の結果ファイルを比較することにより、新内部ファイル状況差分を取得する。また、ファイル状況差分検出プログラム１２９２は、図９に示した結果ファイル４００Ｂと４００Ａとを比較することにより、旧内部ファイル状況差分を取得する（なお、旧内部ファイル状況差分は、Ｓ１６００以降前もって取得されても良い）。

変数値差分検出プログラム１２９５は、上記（４）と（５）の結果ファイルを比較することにより、新内部全変数値差分を取得する。また、変数値差分検出プログラム１２９５は、図９に示した結果ファイル５００Ｂと５００Ａとを比較することにより、旧内部全変数値差分を取得する（なお、旧内部全変数値差分は、Ｓ１６００以降前もって取得されても良い）。

内部レベルテストでは、一つの新テストプログラム１３２と、その新テストプログラム１３２に対応する一つの旧テストプログラム１２２につき、以下の（ａ）〜（ｄ）の処理、
（ａ）ログチェッカー１２５が、新ログファイルを旧ログファイルと比較する処理、
（ｂ）比較プログラム１３３が、新内部ファイル状況差分を旧内部ファイル状況差分と比較する処理、
（ｃ）比較プログラム１３３が、ネットワークリクエストの検出結果を表す新旧の結果ファイル（具体的には、上記（３）の結果ファイルと、図９に示した結果ファイル４１０）を比較する処理、
（ｄ）比較プログラム１３３が、新内部全変数値差分を旧内部全変数値差分と比較する処理、
が実行される。

上記（ａ）〜（ｄ）での比較の結果、いずれでも異常が無ければ、ＦＵ変換が正しく行われたということになる。

＜Ｓ５１００（スクリーン入力ケースデータの作成）＞。

前述したように、Ｐ１０００（現行システム分析）が行われることで、どの旧ＦＵが旧ＡＲであるかが特定される。そのため、多数の旧テストプログラムのうち、どれが旧ＡＲを対象旧ＦＵとした旧テストプログラムであるかの特定が可能である。また、どの新ＦＵが新ＡＲであるかも特定することができるため、多数の新テストプログラム１３２のうち、どれが新ＡＲを対象新ＦＵとした新テストプログラム１３２であるかの特定も可能である。

このＳ５１００では、図１４に示すように、各旧ＡＲに対応した全ての旧テストプログラム１２２が、旧スクリーン入力ケースデータ８３０に変換される。具体的には、旧テストプログラム１２２のソースコードに基づいて、旧スクリーン入力を表すデータ８３０が作成される。「旧スクリーン入力」とは、旧スクリーン（旧ＡＲの作業者に対するインタフェース）に対するスクリーン入力であり、例えば、“旧ＡＲ１のスクリーン１に値Ａを入力してスクリーン１上の実行ボタンを押す」である。

同様に、各新ＡＲに対応した全ての新テストプログラム１３２が、新スクリーン入力ケースデータ８４０に変換される。新テストプログラム１３２は旧テストプログラムと１対１に対応しているため、新スクリーン入力ケースデータ８４０も旧スクリーン入力ケースデータ８３０と１対１に対応している。「新スクリーン入力」とは、新スクリーン（新ＡＲの作業者に対するインタフェース）に対するスクリーン入力であり、例えば、上記具体例の旧スクリーン入力に対応する操作であれば、“新ＡＲ１のスクリーン１に値Ａを入力してスクリーン１上で実行ボタンを操作する」のように、対応する旧スクリーン入力と実質的に同じ操作である。

＜Ｓ５２００（外部レベルテストの実行）＞。

例えば、図１５に示すように、新旧のスクリーン入力ケースデータ８３０、８４０を表示する或いは印刷するなどの方法により、作業者は、新旧のスクリーン入力を把握する。互いに対応している新旧のスクリーン入力ケースデータ８３０、８４０であれば、対象のＡＲやスクリーンも互いに対応している（例えば、新旧のＡＲは共に“ＡＲ１”であり、新旧のスクリーンも共に“スクリーン１”である）。スクリーンは、作業者端末５０の表示装置５３に表示される。

図示していないが、本実施形態では、前述した前バッチプログラム１２６と後バッチプログラム１２７の他に、外部レベルテスト用の前バッチプログラムと、外部レベルテスト用の後バッチプログラムとが、サーバ１００内の記憶装置１０５に記憶されている。外部レベルテスト用の前バッチプログラム及び後バッチプログラムは、前述した前バッチプログラム１２６と後バッチプログラム１２７のように新旧のテストプログラム１２２、１３２から呼び出されるのではなく、外部レベルテストの際にスクリーンから情報を入力する作業者から呼び出される。外部レベルテスト用の前バッチプログラムは、呼び出された場合、例えば、ファイル状況差分検出プログラム１２９２及び変数値差分検出プログラム１２９５を呼び出し、ネットワークリクエスト検出プログラムを開始する。一方、外部レベルテスト用の後バッチプログラムは、呼び出された場合、例えば、ＤＢ比較プログラム１２９１、ファイル状況差分検出プログラム１２９２、ＤＢ接続検出プログラム１２９４、変数値差分検出プログラム１２９５及び比較プログラム１３３を呼び出し、ネットワークリクエスト検出プログラムを終了する。

作業者は、外部レベルテスト用の前バッチプログラムを呼び出し、その後で、新旧のスクリーン１に、新旧のスクリーン入力（実質的に同一のスクリーン入力）を行う。それにより、新旧のスクリーン１から同一の外部入力が新旧のＡＲ１に与えられ、新旧のソフトウェア１２０、８２０においてそれぞれアクションが実行される。具体的には、例えば、新旧のＡＲ１が外部入力を受けると、新旧のソフトウェア１２０、８２０においてＦＵ間の呼び出しが次々に行われ、その結果として、例えば新旧のソフトウェア１２０、８２０が新旧のＤＢ９１０、９２０をそれぞれ更新する。新旧のソフトウェア１２０、８２０のアクション実行後に、作業者は、外部レベルテスト用の後バッチプログラムを呼び出す。

従って、例えば、新旧のソフトウェアによるアクション実行後に、ＤＢ比較プログラム１２９１によって、旧ＤＢ内の全レコードと、新ＤＢ内の全レコードとが比較される。一つでも互いに不一致のレコードがあれば、外部レベルテストの結果が異常有りとなる。

アクション実行後の都度に作業者から外部レベルテスト用の後バッチプログラムが呼び出されるため、ＤＢ比較プログラム１２９１は、前述したように、このような全レコード比較を、アクション実行後の都度（言い換えれば、新旧のスクリーン入力が行われる都度）、実行する。例えば、図１７に示す外部レベルテストの別の例によれば、新旧のスクリーン入力が新旧のスクリーン１〜３に行われ、新旧のＡＲ１〜３によってアクション１〜３が行われる。ＤＢ比較プログラム１２９１は、アクション１の後に全レコード比較を実行し、アクション２の後にも全レコード比較を実行し、アクション３の後にも全レコード比較を実行する。

外部レベルテストでは、チェックポイント外部化プログラム群１２９に含まれている他のコンピュータプログラム、すなわち、ファイル状況差分検出プログラム１２９２、ネットワークリクエスト検出プログラム１２９３、ＤＢ接続検出プログラム１２９４及び変数値差分検出プログラム１２９５も実行される。

具体的には、図１５で言えば、ファイル状況差分検出プログラム１２９２は、新旧のＡＲ１について、以下の（１）〜（３）の処理、
（１）外部入力受領前の新旧のファイル状況を取得する、
（２）アクション実行後の新旧のファイル状況を取得する、
（３）外部入力受領前の新旧のファイル状況と、アクション実行後の新旧のファイル状況とを比較することにより、旧外部ファイル状況差分と、新外部ファイル状況差分とを取得する、
を実行する。そして、比較プログラム１３３が、新外部ファイル状況差分を旧外部ファイル状況差分と比較する。この比較の結果、不一致があれば、外部レベルテストの結果が異常有りということになる。

ネットワークリクエスト検出プログラム１２９３は、新旧のＡＲ１の外部入力受領前からアクション受領後にかけて、ネットワークＩ／Ｆ１１１を通じて何らかのリクエストが流れているか否かを監視する。比較プログラム１３３は、新旧のソフトウェア１２０、８２０についての監視結果を互いに比較し、比較の結果、不一致があれば、外部レベルテストの結果が異常有りということになる。

ＤＢ接続検出プログラム１２９４は、ＤＢ比較プログラム１２９１と同様に、アクション実行後の都度に、新旧のソフトウェアが新旧のＤＢ９１０、９２０に接続されているか否かを検出する。比較プログラム１３３は、新旧のソフトウェア１２０、８２０についての検出結果を互いに比較し、比較の結果、不一致があれば、外部レベルテストの結果が異常有りということになる。

変数値差分検出プログラム１２９５は、新旧のＡＲ１について、以下の（１）〜（３）の処理、
（１）外部入力受領前の新旧の全変数値を取得する、
（２）アクション実行後の新旧の全変数値を取得する、
（３）外部入力受領前の新旧の全変数値と、アクション実行後の新旧の全変数値とを比較することにより、旧外部全変数値差分と、新外部全変数値差分とを取得する、
を実行する。そして、比較プログラム１３３が、新外部全変数値差分を旧外部全変数値差分と比較する。この比較の結果、不一致があれば、外部レベルテストの結果が異常有りということである。

従来のソフトウェアマイグレーションは、旧ソフトウェアの業務要件に依存したマイグレーションであり、マイグレーションの最後に行われるいわゆる総合テストでは、業務要件に従う業務の流れに依存したテストが行われる。具体的には、図１６に示すように、予め業務の流れ（シナリオ）が決まっており、その業務の流れに従って一通りの操作が行われる。その後で、例えばＤＢが適切に更新されたか否かがチェックされる。

本実施形態では、クライアントから旧ソフトウェアの業務要件をヒアリングする必要は無く、それを実現する一工夫として、旧ソフトウェアのソースコードの分析が行われる。しかし、ソースコードからは、業務の流れは分からないし、そもそも、本実施形態では、業務要件に全く頼っていないので、業務の流れを知る必要もない。そのため、従来のような総合テストはできない。

そこで、本実施形態では、前述したようなチェックポイント外部化プログラム群１２９が用意され、そのプログラム群１２９に含まれる各コンピュータプログラム１２９１〜１２９５が、Ｐ４０００（継続的インテグレーション）の後のＰ５０００において適切なタイミングで実行される。そのため、Ｐ４０００（継続的インテグレーション）の後に、従来のような総合テストに代わる新規観点のテスト（外部レベルテスト）を行うことができる。

以上、本発明の幾つかの実施例を説明したが、これらの実施例は本発明の説明のための例示にすぎず、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。

本発明の一実施形態に係るソフトウェアマイグレーションシステムが適用された計算機システムの構成図である。 本発明の一実施形態に係るソフトウェアマイグレーションのフェーズ遷移図である。 本発明の一実施形態で実行される代表的なコンピュータプログラムを示す。 チェックポイント外部化プログラム群が有する複数のコンピュータプログラムを示す。 本発明の一実施形態に係るソフトウェアマイグレーションで行われる処理の流れを示す。 旧ソフトウェアソースコードと旧ＦＵソースコードとセクションとの関係の説明図である。 一つの旧ＦＵにおける複数のセクションとセクション間の関係の一例を示す。 旧ソフトウェアの構成と、旧テストプログラムから呼び出された後の旧ソフトウェアの振舞いの概要を示す。 旧テストプログラムの実行に起因して呼び出される各種コンピュータプログラムと作成される各種ファイルの一例を示す。 旧ログファイルの中身の具体例を示す。 ログチェッカーに入力される情報とログチェッカーに作成されるスケジューラ用テキストの具体例を示す。 ＦＵ呼出し依存関係の一例を示す。 ＦＵ変換スケジューラからの出力の一例を示す。 新旧のテストプログラムと外部レベルテストケースとの関係を示す。 本発明の一実施形態に係るソフトウェアマイグレーションでのスクリーンからのテストの一例を示す。 従来のソフトウェアマイグレーションでのスクリーンからのテストの説明図である。 スクリーンからのテストの別の一例を示す。

符号の説明

５０…作業者端末 １００…サーバ

Claims (9)

1. 第一言語で記述された第一ソフトウェアを第二言語で記述された第二ソフトウェアにマイグレーションする方法であって、
   （Ａ）前記第一ソフトウェアのソースコードに含まれている各第一ファンクショナルユニット（ＦＵ）のソースコードについて、以下の（ａ１）及び（ａ２）、
   （ａ１）対象の第一ＦＵにおけるセクションの数とリンクの数とに基づいて循環的複雑度を算出する処理、
   （ａ２）算出された循環的複雑度に基づく数の作成された第一テストプログラムの各々が前記対象の第一ＦＵを呼び出すことで呼び出された第一ＦＵを表す情報を記述した、各前記第一テストプログラムに対応した各第一ログファイルを作成する処理、
   を実行し、
   （Ｂ）前記第一ソフトウェアについて作成された複数の第一ログファイルを基に、ＦＵ間の呼出しの向きとＦＵの依存度とによって定まるＦＵ呼出し依存関係を把握し、
   （Ｃ）把握されたＦＵ呼出し依存関係において依存度の低い前記第一ＦＵから順に、以下の（ｃ１）乃至（ｃ３）、
   （ｃ１）前記第一ＦＵを第二言語で記述された第二ＦＵに変換することであるＦＵ変換、
   （ｃ２）各前記第一テストプログラムに対応する各第二テストプログラムが前記（ｃ１）で得られた第二ＦＵを呼び出すことで呼び出された第二ＦＵを表す情報を記述した、前記各第二テストプログラムに対応した各第二ログファイルを作成し、前記各第二ログファイルを、前記各第一のテストプログラムに対応した前記各第一ログファイルと比較する内部レベルテスト、
   （ｃ３）前記内部レベルテストの結果に異常が無く、前記（ｃ１）で得られた前記第二ＦＵの呼出し先の第二ＦＵが既に存在する場合に、前記得られた第二ＦＵを前記呼出し先の第二ＦＵにインテグレートする処理、
   を実行し、
   （Ｄ）全ての前記第一ＦＵについて前記（Ｃ）が実行されることにより得られた前記第二ソフトウェアと、前記第一ソフトウェアとの両方について、ユーザからの情報入力を受け付けるスクリーン及び／又はバッチで実行されるコンピュータプログラムである外部からの入力に従うテストである外部レベルテストを実行する、
   ソフトウェアマイグレーション方法。
2. 前記外部レベルテストでは、以下の（ｄ１）乃至（ｄ３）のうちの少なくとも一つ、
   （ｄ１）前記外部からの入力に従う前記第一ソフトウェアのアクション後の所定種類の対象の状況と、前記外部からの入力に従う前記第二ソフトウェアのアクション後の所定種類の対象の状況とを比較する、
   （ｄ２）前記第一ソフトウェアについての、前記外部からの入力の前から前記アクション後までの所定種類の監視結果と、前記第二ソフトウェアについての前記外部からの入力の前から前記アクション後までの所定種類の監視の結果とを比較する、
   （ｄ３）前記第一ソフトウェアについての、前記外部からの入力前の所定種類の対象の状況と前記アクション後の所定種類の対象の状況との差分と、前記第二ソフトウェアについての、前記外部からの入力前の所定種類の対象の状況と前記アクション後の所定種類の対象の状況との差分とを、比較する、
   ことが実行される、
   請求項１記載のソフトウェアマイグレーション方法。
3. 前記第一テストプログラムが実行されると、以下の（ｐ１）及び／又は（ｐ２）、
   （ｐ１）前記対象の第一ＦＵの呼出し前の所定種類の対象の状況Ａを取得し、且つ、前記第一ログファイルが作成された後の前記所定種類の対象の状況Ｂを取得し、
   （ｐ２）前記対象の第一ＦＵの呼出し前から前記第一ログファイル作成後まで所定種類の対象を監視し、
   が実行され、
   前記第一テストプログラムに対応する第二テストプログラムが実行されると、以下の（ｑ１）及び／又は（ｑ２）、
   （ｑ１）前記対象の第二ＦＵの呼出し前の所定種類の対象の状況Ｃを取得し、且つ、前記第二ログファイルが作成された後の前記所定種類の対象の状況Ｄを取得し、
   （ｑ２）前記対象の第二ＦＵの呼出し前から前記第二ログファイル作成後まで所定種類の対象を監視し、
   が実行され、
   前記内部レベルテストでは、以下の（ｒ１）及び／又は（ｒ２）、
   （ｒ１）前記状況Ａと前記状況Ｂとの差分と、前記状況Ｃと前記状況Ｄとの差分を比較する、
   （ｒ２）前記（ｐ２）の監視の結果と前記（ｑ２）の監視の結果とを比較する、
   が実行される、
   請求項１又は２記載のマイグレーション方法。
4. 前もって各第一ＦＵのソースコードにログステートメントが設定され、ログステートメントにより、前記第一ログファイルに、呼び出された第一ＦＵを表すログが記録される、
   請求項１乃至３のうちのいずれか一項に記載のマイグレーション方法。
5. 第一ソフトウェアのソースコードにおける各第一ＦＵのソースコードにロガーステートメントを設定しておき、
   前記第一ソフトウェアのソースコードに含まれている各第一ＦＵのソースコードについて、以下の（ａ１）及び（ａ２）、
   （ａ１）対象の第一ＦＵにおけるセクションの数とリンクの数とに基づいて循環的複雑度を算出する処理、
   （ａ２）算出された循環的複雑度に基づく数の作成された第一テストプログラムの各々が、前記対象の第一ＦＵを呼び出すことで、呼び出された第一ＦＵの前記ロガーステートメントが前記呼び出された第一ＦＵを表す情報を記述した、各前記第一テストプログラムに対応した各第一ログファイルを作成する処理、
   を実行する、
   ＦＵ呼出し依存関係の把握を支援する方法。
6. 第一言語で記述された第一ソフトウェアがそれのソースコードの分析結果を基にマイグレーションされたものである、第二言語で記述された第二ソフトウェアが、前記第一ソフトウェアの正しいマイグレーションであるか否かのテストの方法であって、
   前記第二ソフトウェアと前記第一ソフトウェアとの両方について、ユーザからの情報入力を受け付けるスクリーン及び／又はバッチで実行されるコンピュータプログラムである外部からの入力に従うテストである外部レベルテストを実行し、
   前記外部レベルテストでは、以下の（ｄ１）乃至（ｄ３）のうちの少なくとも一つ、
   （ｄ１）前記外部からの入力に従う前記第一ソフトウェアのアクション後の所定種類の対象の状況と、前記外部からの入力に従う前記第二ソフトウェアのアクション後の所定種類の対象の状況とを比較する、
   （ｄ２）前記第一ソフトウェアについての、前記外部からの入力の前から前記アクション後までの所定種類の監視結果と、前記第二ソフトウェアについての前記外部からの入力の前から前記アクション後までの所定種類の監視の結果とを比較する、
   （ｄ３）前記第一ソフトウェアについての、前記外部からの入力前の所定種類の対象の状況と前記アクション後の所定種類の対象の状況との差分と、前記第二ソフトウェアについての、前記外部からの入力前の所定種類の対象の状況と前記アクション後の所定種類の対象の状況との差分とを、比較する、
   ことが実行される、
   ソフトウェアマイグレーションの成否をテストする方法。
7. 第一言語で記述された第一ソフトウェアを第二言語で記述された第二ソフトウェアにマイグレーションするコンピュータシステムであって、
   前記第一ソフトウェアのソースコードに含まれている各第一ファンクショナルユニット（ＦＵ）のソースコードについて、各第一ＦＵにおけるセクションの数とリンクの数とに基づいて各循環的複雑度を算出する循環的複雑度算出部と、
   各第一ＦＵに対応した、算出された循環的複雑度に基づく数の第一テストプログラムと、
   各第一テストプログラムに対応した各第二テストプログラムと、
   前記第一ソフトウェアのソースコードに含まれている各第一ファンクショナルユニット（ＦＵ）に設定されたロガーと、
   内部レベルテスト部と、
   外部レベルテスト部と、
   を備え、
   各第一テストプログラムが対象の第一ＦＵを呼び出し、その後に呼び出された第一ＦＵに設定されているロガーが、第一ログファイルに、前記呼び出された第一ＦＵを表す情報を書き込み、それにより、各第一テストプログラムに対応した各第一ログファイルが作成され、
   前記第一ソフトウェアについての複数の第一ログファイルに基づいて把握されたＦＵ呼出し依存関係に基づく順番で第一ＦＵから得られた第二ＦＵを、前記各第二プテストログラムが呼び出し、その後に呼び出された第二ＦＵに設定されているロガーが、第二ログファイルに、前記呼び出された第二ＦＵを表す情報を書き込み、それにより、各第二テストプログラムに対応した各第二ログファイルが作成され、
   前記内部レベルテスト部が、前記各第一ログファイルと前記各第二ログファイルを比較し、
   前記外部レベルテスト部が、前記第二ソフトウェアと前記第一ソフトウェアとの両方について、ユーザからの情報入力を受け付けるスクリーン及び／又はバッチで実行されるコンピュータプログラムである外部からの入力に従うテストである外部レベルテストを実行する、
   ソフトウェアマイグレーションシステム。
8. 第一言語で記述された第一ソフトウェアのソースコードに含まれている各第一ファンクショナルユニット（ＦＵ）のソースコードについて、各第一ＦＵにおけるセクションの数とリンクの数とに基づいて各循環的複雑度を算出する循環的複雑度算出部と、
   各第一ＦＵに対応した、算出された循環的複雑度に基づく数の第一テストプログラムと、
   前記各第一ＦＵに設定されたロガーと
   を備え、
   各前記第一テストプログラムが、そのプログラムの対象の第一ＦＵを呼び出すことで、呼び出された第一ＦＵの前記ロガーが、前記呼び出された第一ＦＵを表す情報を、第一のログファイルに記録する、
   ＦＵ呼出し依存関係の把握を支援するコンピュータシステム。
9. 第一言語で記述された第一ソフトウェアがそれのソースコードの分析結果を基にマイグレーションされたものである、第二言語で記述された第二ソフトウェアが、前記第一ソフトウェアの正しいマイグレーションであるか否かをテストするコンピュータシステムであって、
   前記第二ソフトウェアと前記第一ソフトウェアとの両方について、ユーザからの情報入力を受け付けるスクリーン及び／又はバッチで実行されるコンピュータプログラムである外部からの入力に従うテストである外部レベルテストを実行する外部レベルテスト部、
   を備え、
   前記外部レベルテスト部は、以下の（ｄ１）乃至（ｄ３）のうちの少なくとも一つ、
   （ｄ１）前記外部からの入力に従う前記第一ソフトウェアのアクション後の所定種類の対象の状況と、前記外部からの入力に従う前記第二ソフトウェアのアクション後の所定種類の対象の状況とを比較する、
   （ｄ２）前記第一ソフトウェアについての、前記外部からの入力の前から前記アクション後までの所定種類の監視結果と、前記第二ソフトウェアについての前記外部からの入力の前から前記アクション後までの所定種類の監視の結果とを比較する、
   （ｄ３）前記第一ソフトウェアについての、前記外部からの入力前の所定種類の対象の状況と前記アクション後の所定種類の対象の状況との差分と、前記第二ソフトウェアについての、前記外部からの入力前の所定種類の対象の状況と前記アクション後の所定種類の対象の状況との差分とを、比較する、
   を実行する、
   ソフトウェアマイグレーションの成否をテストするシステム。

Images