Olsem98 |
PublicReengineering Wiki |
|
| The paper describes the advantages of incremental reengineering over cold-turkey. It provides a 15 step methodology for successful reengineering based on the
author's own experience and evidence from literature.
Support tools available are mentioned, as well as a wish list for other tools.
He reckons that the US DoD? will spent $7.5-15 bill. fixing Y2K.
He reckons 80% of an organisations software budget is spent on maintaining legacies.
He highlight four options to tackle legacies: leave alone; retire system, redevelop it; and reengineer it. He prefers reengineering.
He says the reengineering consists of: reverse & forward engineering; redocumentation; restructuring; retargeting, translating source code; and data
reengineering.
He sees the perceived risk of reengineering as being a barrier to people adopting the strategy.
He distinguishes between "system reengineering" (ie cold turkey) and incremental reengineering (chicken little). He sides with the latter for the usual reasons, eg
risk, changing requirements...
He states that legacies are comprised of code, data, hardware and interfaces. He recognises that gateways are necessary when these individual components of the
legacy are reengineered. He distinguishes between intraclass (between the same types of components)and interclass (between different types of component)
gateways.
He talks about the types of decomposition decisions that can be made: reengineer by hardware components; by function; by how much coupling a component has;
by data first to id redundancies; or by a combination of the others.
He also recognises that decomposition is sometimes difficult and requires encapsulation/wrapping.
He says that the two stumbling block to successful reengineering are the lack of support tools and the lack of methodologies.
His 15 step methodology is: have a strategic plan from which to develop reengineering objectives; form a team; develop a tactical plan; perform risk, impact and
resource analysis; employ a configuration management process; design and install target environment; decide on metrics to measure success; collect
documentation and define dependencies between all the project artifacts; develop testing strategy (white box); decide on support tools; train people; produce pilot;
design documentation; finally reengineer components; and then migrate.
He goes on to mention some available tools and some tools he would like to see.
Related pages: Bibliography |
| This page last edited on 29 October 1999 |