Kutscha98

PublicReengineering Wiki

He's essentially talking about how we should look at what we've got before we reengineer. The task-artifact cycle is a little bit of a red herring. He's a consultant. He makes the point that most companies rely on existing software, so this should be taken into account when designing the new systems. He feels he has learned 3 lessons from real reengineering projects: 1. every project has a reverse engineering component. 2. reverse & forward engineering functions should be integrated. 3. don't neglect the semantic analysis of the legacy. To support "1" he reports that a german automobile manufacturer and their consultants started a successful project by reverse engineering the legacy to get at requirements and continued with reverse engineering throughout the project. He estimates that 30-40% of the requirement engineering budget should be allocated to reverse engineering. Moreover, exceptions found in the legacy were used as test cases for the new system. For point "2": In the same project the debated whether to have separate teams - one for legacy and one for new system - or one integrated team. They opted for for the integrated team. In another project for a savings bank they opted for separate teams and only discovered late on that they need to make large scale changes to the legacy system. For point "3": In the savings bank example, the new data structure was deigned without a knowledge of the legacy one. Late in the project it became obvious that a coexistence of the legacy and new system was inevitable for a time. This necessitated a mapping between the two data structures which proved extremely difficult.

Continuing the semantics theme, he reports that it is necessary to combine the soft facts provided by interviews with the hard facts provided by studying the existing systems, eg analysis of databases and files; job flow analysis; and compiling cross-reference tables. He mentions that the hard facts often make the interviews easier and that they are a deliverable since the in-house team may never have bothered to make these investigations.

• Start Here in this Web
• Categories
• Index
• Recent Changes
• FAQ