今は仕様検討の段階で、RD1,RD2を経てUIの段階です。
お客様に結果を報告するファイルを作成するプログラムがあり、ベンダーが解析した結果、プログラム数は相当あるものの、似通ったコード(機械解析した結果、類似度が80%以上)のものが多数を占めています。
これは、顧客側で導入されているシステムがファイルフォーマットは統一されているものの、そのフィールドの仕様定義はシステムに任されているからです。
顧客の仕様に合わせて結果報告ファイルを作成しようとすると、その細かな相違について対応しなければなりません。 フィールドは数十あり、その其々に些細な違いがあります。例えば10フィールドで2種類ずつのヴァリエーションが存在した場合、1024通りのプログラムが必要となります
そして、現在までに作られてきたプログラムは1024ではありませんが、凡そその半分ほどの数に上っています。
これらのプログラムコードをベンダーが機械解析したところ、大半が基本ロジックは同じ、些細な違いばかりのプログラムが多数存在と言う事が分かりました。
ここで、『なんで、キチンと管理出来てないんだ? 些細な違いならば、マスターを作成し、それに登録すれば、そのマスターに従い結果報告ファイルを作成すれば、プログラムは一本だけでよかったんでは?』と言う疑問が湧きます。
ただ、独自に進化してきた『私の会社のプログラム構成』も似たようなものです。言語こそ違え(グループ会社はWindowsアプリで、Visual C/Basic.netなどで開発されています。 私の会社はIBM AS/400の RPG400です。)同じ様な道筋をたどってきています。
私の会社でもプログラム数は、百数十本ですが、やはりプログラム中で顧客コードによりフィールドに設定する内容を変更したりしていますが、基本的には元のプログラムをコピーし、別の顧客用に少しの改修を加えて新しいプログラムとする・・・事を繰り返してきました
これは、ヴァリエーションがいっぱいあり、新しい顧客の要件に合う既存のプログラムを探すより、似たのを探してコピーして改修した方が手っとり早いからです
グループ会社でも同じような状況から同じ様なプログラムがワサワサ出来あがっているんでしょう。
なんと無く、全然別の地域にいる動物が、その環境が良く似ている為良くにた性質になっているのと同じ感じがしました。
ねっ
と、言うことは・・・
同じように進化してきたと言うことは・・・
【このカテゴリーの最新記事】
-
no image
-
no image
-
no image
-
no image
-
no image