データ項目の計算式を把握するところから、作業を始めていきます。
例えば、プログラム内で以下のような計算式が記述されていたとします。
COMPUTE SALE_ORDER_AMOUNT = SALE_UNIT_PRICE * SALE_ORDER_GTY
これを、
受注金額 = 受注単価 * 受注数量
と書き換えるわけです。
プログラム内では任意の名称が付与されて記述されている計算式を、標準のデータ項目名称で再記述するということです。
この再記述した計算式を、データ項目単位に、意味定義と共に管理していきます。
これらの計算式を明らかにするということは、レガシーシステム内に埋没しているビジネスルールや導出ルールを明確にすることであり、それだけでも大きな意味を持ちます。
しかし、データ整備の立場から見ると、これだけでは計算元の項目から計算結果項目を検索することが困難であり、課題を残します。
そこで、計算元項目と計算結果項目の間に計算式をおき、計算式経由で、計算元から計算結果を検索できるようにしておきます。
こうしておけば、逆に計算結果から計算元を検索することも容易に実現できます。
計算式を一種の関数のように見立てて、計算元が入力パラメータ、計算結果が出力パラメータになるイメージです。
ただし、レガシーシステム内で、計算式が独立したモジュールとして定義されているとは限りません。
あくまで、データ項目同士の論理的な関係を把握することが目的であり、実際のプログラム構造と同じである必要はありません。
実際のプログラム構造とは異なっていたとしても、入力・出力の項目が画面や帳票、外部インタフェースと関連つけられていれば、保守作業の「調査」工数を削減できるはずです。
例えば、プログラム内で以下のような計算式が記述されていたとします。
COMPUTE SALE_ORDER_AMOUNT = SALE_UNIT_PRICE * SALE_ORDER_GTY
これを、
受注金額 = 受注単価 * 受注数量
と書き換えるわけです。
プログラム内では任意の名称が付与されて記述されている計算式を、標準のデータ項目名称で再記述するということです。
この再記述した計算式を、データ項目単位に、意味定義と共に管理していきます。
これらの計算式を明らかにするということは、レガシーシステム内に埋没しているビジネスルールや導出ルールを明確にすることであり、それだけでも大きな意味を持ちます。
しかし、データ整備の立場から見ると、これだけでは計算元の項目から計算結果項目を検索することが困難であり、課題を残します。
そこで、計算元項目と計算結果項目の間に計算式をおき、計算式経由で、計算元から計算結果を検索できるようにしておきます。
こうしておけば、逆に計算結果から計算元を検索することも容易に実現できます。
計算式を一種の関数のように見立てて、計算元が入力パラメータ、計算結果が出力パラメータになるイメージです。
ただし、レガシーシステム内で、計算式が独立したモジュールとして定義されているとは限りません。
あくまで、データ項目同士の論理的な関係を把握することが目的であり、実際のプログラム構造と同じである必要はありません。
実際のプログラム構造とは異なっていたとしても、入力・出力の項目が画面や帳票、外部インタフェースと関連つけられていれば、保守作業の「調査」工数を削減できるはずです。
※コメント投稿者のブログIDはブログ作成者のみに通知されます