Adolph96 |
PublicReengineering Wiki |
|
| Interesting case study about the reengineering a rail scheduling legacy. He feels the project enemy is risk from staff competency, changing requirements, tool
capability, target platform availability and the reliability of 2rd part software. A flawed assumption is that reengineering is easier than new system development
because the legacy is a core competency. This is only true if the development staff are intimately familiar with the legacy.
The problems with the legacy (originally installed in 1971) were that it was difficult to hire staff interested and competent in its archaic programming language, the
hardware was difficult to maintain, demands on the system were increasing, much redundant code in the legacy and it had performance and memory limitations.
The reengineering project was predominantly staffed by external people with only a limited number of people had experience of the legacy. They had 12
incremental development phases, the first two were relatively simple and were intended as pilots to test tools and methodology. It later transpired that these pilots
were not large enough to fully test the approach and serious flaws were only discovered as the project was ramped up.
The first problem discovered was that effort estimates were overly optimistic. implementationThey had been arrived at by experienced personnel who assumed
that the developers were familiar with the the legacy, methodology & CASE tool and domain.
The original code was designed to squeeze the best out of the limited memory of the old hardware. This means it incorporates coding tricks which makes finding
useful domain specific logic difficult.
The author also found that a significant number of design packets failed their reviews because they did not capture all the functional requirements contained in the
legacy code. This was due to the documentation being out of date and the code being difficult and tedious to read. Programmers have a natural reluctance to read
old code. Their solution was to make all staff read the code and to make this part of their job performance review. A senior developer painfully mapped the legacy
and lunchtime seminars were provided on the theory and history of the railways signalling and the legacy itself. A train set was even purchased to help demonstrate
principals.
Yet another problem was that the designer wanted to add flash new features or redesign inelegant algorithms. This introduced delays and risk since they were
adding untried complexity and throwing away 20 years of operating experience. It also meant creating new test plans. This happened but was nipped in the bud by
providing a project directive that no features of the legacy were to be changed unless they reduced the cost of .
They had used Cadre's Teamwork CASE tool for analysis and design. It was deployed on PCs since more staff were familiar with these than UNIX systems (this
was early 1990s). Unfortunately the PC version at that time wasn't as good as the UNIX version. Overall, they found the use of the tool invaluable for coordinating
the design work of the 15 man team. However, they found that they could not achieved the expected productivity gains due to most staff being unfamiliar with the
tools and techniques, despite having been on training courses. They needed front line experience with the tool to appreciate the pit falls.
They also found problems producing reports from the CASE database - presumably a function of this early 1990 version.
They recommend having a dedicated toolsmith to maintain the CASE tool rather than erode the output of a designer.
The project was late and over budget, however the product was "high quality", met customer requirements and was able to be deployed in operation quickly.
Related pages: Bibliography
|
| This page last edited on 5 January 2000 |