Reengineering an Existing System

By Russ Finney

既存システムの再構築

If the task at hand is to take an existing system and turn it into a new and improved version - watch out! This is a recipe for wild promises, incredible claims, and generally career ending commitments. Just because the system already exists doesn't mean that fantastic time savings will occur during its redevelopment. Time savings are completely dependent on:
手掛けている仕事が、既存システムに手を加え、新規改良バージョンにする事であったら--ご用心！これは、無茶な約束、無理な要求、そして、よく退職の原因になる公約の処方箋である。システムが存在するというだけでは、再構築の時間が劇的に短くなる事はない。時間削減は、以下の要素にかかっている。：

• the complexity of the system
• the familiarity of the team with the system
• the required modifications
• the time needed to specify the modifications
• the time needed to understand the system itself.


• システムの複雑度
• チームのシステムに対する精通度
• 要求されている変更点
• 変更点の具体化に要する時間
• システム自体を理解するのに要する時間

The last item on the list is the real show stopper! Nine times out of ten, the team starts by basing their changes on system assumptions and perceptions. And in many cases, it takes about as much time to figure out what a specific program is doing as it would have taken to specify a new program to replace it (and even these conclusions can turn out to be nothing more than informed guesses on the part of the analyst)!
このリストの最後の項目が、肝心な部分だ！ 十中八九、チームは、システムに対する推測や思い込みに基づいて変更点を考える事から始める。大抵、特定のプログラムが何をしているか調べるには、入替え用の新規プログラムの仕様を決めるのと同じ位の時間がかかる; (その結果もアナリストの知見による推測以外の何物でもない!)

So where is all the hype coming from? Do miracle re-engineering tools really exist? The answer is yes and no. Redevelopment aids do exist and many of them are quite powerful - but they do not replace analyst and programmer thinking (the most time consuming part). What these tools do provide is structural and visual aids which make comprehension easier. These may be in the form of CASE tool knowledge base (dictionary) loaders, program restructuring utilities, or system documentation generators.
ならば、すべての誤解は何が原因か？ 奇跡の再構築ツールは本当に存在するのか? 答えは、Yesであり、Noである。再構築支援ツールは存在し、それらの多くはかなり強力である - しかし、それらは、アナリストやプログラマの思考(最も時間を食う部分)の替わりにはならない。これらのツールが提供するのは、理解を容易にしてくれる構造化と視覚化支援機能である。これらはCASEツール知識ベース(辞書)ローダ、プログラム再構築ユーティリティ、またはシステム文書ジェネレータに含まれているだろう。

Probably the most effective redevelopment tools currently available are the various data base management system data definition language conversion programs. These can take data definitions for one DBMS and translate them into the required form for a new DBMS. This can truly be a time saver if the team's mission is to merely convert the processing from one database manager to another (but even in this situation every program may require modifications to incorporate the correct database access calls).
多分、現在利用可能で最も有効な再開発ツールは、種々のデータベース管理システムのデータ定義言語変換プログラムである。これらは、あるDBMSのデータ定義を、新しいDBMSに合わせた形式に翻訳してくれる。 チームの役割が、単に、ある処理をひとつのDBMSから別のDBMSに移し替える事であれば、大きく時間が節約出来る。 (この場合でも、データベース・アクセスコールを正しく書き換える為、全部のプログラムに変更が必要かもしれない)。

The moral here is to plan for a complete analysis, design, and construction based approach. The business clients will probably need to be involved to assist in identifying the required business functionality changes during the analysis phase. An iterative prototyping approach may be required to validate proposed screen changes during the design phase. Some form of modification specifications will need to be created to identify the program changes during the construction phase. In addition, the required review and testing time must be considered.
ここのポイントは、分析、設計、構築をカバーする手法に合わせて計画を作成する、という事だ。分析フェーズでは、業務機能の変更が必要な部分を見つけるのに、多分エンドユーザーの支援が必要になるだろう。設計フェーズでは、提案された画面の変更を確認するのに、反復プロトタイピング手法が必要だろう。構築フェーズでは、プログラムの変更を記述する変更仕様の様式を作成する必要が出てこよう。また、検証とテストの時間を計算に入れておかなければならない。

Hopefully, all of the available tools were used to make the process of creating a new forward based design easier. This will especially be true if the current system functionality can be captured as visual models in CASE tools for examination and eventual redesign.
出来れば、どのツールを使っても、新しい将来を見越した設計が簡単に作れればいいのだが。CASEツールで現行システムの機能が視覚モデルで表現され調査と再設計に使える場合は、そのケースである。

Copyright © 1999, Russ Finney, All Rights Reserved