Planning the Reengineering of Legacy Systems, by Harry M.

SneedReviewed by Odd Petter N.

Slyngstad for DT8100, 27/1/2005

Overview

• Looks at the following aspects of re-engineering:– Cost-effectiveness– Preferability

• Provides a method to quantify costs & prove benefits of reengineering – as a method to improve existing software prod’s and proc’s

Planning overview

• 5-step procedure:– Project justification (increased quality,

efficiency etc)– Portfolio analysis (prioritize candidate apps)– Cost estimation (include all sw components)– Cost-Benefit analysis (reengineering –

maintenance cost + value increase)– Contracting (max level of distribution, avoid

bottlenecks)(total planning estimated at 6 months)

Project justification

• Prove that it will reduce maintenance cost, improve quality by– Introducing a measurement program– Analyzing software quality– Analyzing maintenance costs– Assessing the software’s business value

Portfolio Analysis

• Plots applications in terms of business value and technical quality (ex: iso9126)

• Use chi-square chart (see article)

Cost Estimation

• Cost of the actual reengineering – must be lower than the benefits for specific projects...

Reengineering – definitions and objectives

• Business-process reengineering– Business process administration, supported by computer

processes

• Data reengineering– Restructuring existing databases

• Software reengineering– Renovation of applications and software artifacts (map

descriptions, job-control procedures, data structure views etc.)

• Recycling– Differs from reengineering in the sense that the result is a

collection of reusable components, not a fully working system...

Cost-Benefit analysis

• Not just benefits of reengineering, also compare with benefits of redevelopment and....the benefits of doing nothing...

• And other factors such as unavailability, system lifetime, user satisfaction (the list goes on)...

• Example: A number of factors selected by UBS (annual maintenance, annual operations etc. etc. etc. see article for full list)

Contracting

• By time/material or by result (turnkey)• Task definition

– Derived from the list of objects needing reengineering (restructuring, conversion, testing, postdocumentation, system testing, configuration mgmt, system documentation etc.)

• Effort distribution– Recommendations on how and where to carry out the

actual work (testing effort, component reengineering etc.)

Summary

• ”Reengineering is NOT easy to sell”

• Must be justified not only with technical concerns, but also with business issues.

• Questions, comments ??