 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||
|
||||||||||||||
| 変換ツールの種類 | ||||||||||||||
|
変換ツールと一口にいっても、主流であるCOBOL言語以外の4GL（第四世代言語）／アセンブラ／ユーティリティ類の変換については、そのサポートレベルは様々である。 4GLは種類によりサポートされているもの／されていないものがマイグレーションベンダーによって異なる。アセンブラについて研究を重ねているベンダーもあるが、現時点では外部仕様から再構築する場合がほとんどである。 ユーティリティ類は、一般に移行先で保有しているものへ置き換えることになる。しかし、サードベンダー製品やユーザにて独自に開発したものをすべて変換ツール類に取り込むことは困難なことが多く、Rehostといいながらも機能の見直しを検討しなければならない場合も発生する。 |
||||||||||||||
| 現行保証という落とし穴 | ||||||||||||||
|
Rehost型マイグレーションが登場しはじめた頃、現状のバグもそのまま移行されるというような説明がなされることもあった。大筋においてはその通りであるが、「逆に今まで顕在化しなかったバグが顕在化してしまう」というようなケースも発生する。 メインフレームからオープン系へ移行したことにより、演算に用いる中間エリアの桁数精度があがる。そのことによって、浮動小数点を用いた演算がより正確に計算され、現行と違った結果となってしまうというケースがあるのだ。 ユーザにいわせれば以前の計算結果は不正確だったかもしれないが、今までそれでうまくいっているのだから現行の仕様を保証してほしいということになる。 このようなコンパイラが異なることによる非互換部分の検証はいかに行うべきなのか、変換ツールによる自動コーディングはどこまで信用し、どこまで検証しなければいけないのかということが問題となる。 マイグレーションベンダーは通常、経験を基にしてどこが要注意ポイントになるかというチェックリストを所有している。しかし、チェックリストによるチェックのみでは品質を確保したとはいえない。そこで、一般的に実施されているテスト方法が新旧比較の照合テストである。 それは移行元の入力データを使用して移行後環境で実行し、次の点について移行元の処理結果と比較して一致することを検証する。
表2：マイグレーションのテストで行う比較事項 この時、ユーザ企業にはテストデータの準備とテスト結果の受け入れ検査が求められることになり、移行対象が多い場合はテストケース、テストシナリオの選定とデータの準備に負荷がかかる。既存システムの機能を正確にあらわすドキュメントが存在せず、ユーザ自身もその機能を正確にすべて把握していない場合には特に大変になる。 その対策として、ソースコードから仕様書を作成するリバース工程を設けることもあるが、対象アプリケーションの1本1本についてリバースし、それらすべてを総合してテストケースを作成することには多大な時間とコストを要する。現実にはリバースの対象は一部の重要機能のみという限定的範囲で行うのが一般的である。 |
||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
