1. Computing and SE II Chapter 13: Software Maintenance
Er-Yu Ding
Software Institute, NJU

2. Main Contents What is software maintenance?
Life cycles and maintenance
Problems of software maintenance
The maintenance process
Legacy Systems, Reverse Engineer and Re-engineering

3. 1. What is Software Maintenance?
Software Evolution
‘Software development does not stop when a system is delivered but continues throughout the lifetime of the system’ . (Sommerville, 2004)
The system changes relate to changing business and user needs
The system evolves throughout its lifetime through a seamless process
The process is a spiral process involving requirements, design & implementation throughout the lifetime of the system

4. 1. What is Software Maintenance?
IEEE91 Definition:
the process of modifying the software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a change in the environment.
SM is concerned with modifying software once it is delivered to a customer

5. 1. What is Software Maintenance?
Four categories:
Perfective maintenance: changes required as a result of user requests (a.k.a. evolutive maintenance)
Adaptive maintenance: changes needed as a consequence of operated system, hardware, or DBMS changes
Corrective maintenance: the identification and removal of faults in the software
Preventative maintenance: changes made to software to make it more maintainable
The majority of SM is concerned with evolution deriving from user requested changes.

6. 1. What is Software Maintenance?

7. 2. Life cycles and maintenance

8. 2. Life cycles and maintenance

9. 2. Life cycles and maintenance

10. 2. Life cycles and maintenance ---Initial development
first version of the software system is developed
may be lacking some features
software architecture is established
likely to persist thought the rest of the life of the program
in one documented instance, we studied a program that underwent substantial changes during its 20 years of existence, but it still possesses the architecture of the original first version.
programming team acquires the knowledge of
application domain, user requirements, role of the application in the business process, solutions and algorithms, data formats, strengths and weaknesses of the program architecture, operating environment, etc.
crucial prerequisite for the next phase of evolution.

11. 2. Life cycles and maintenance --- challenges for initial development
To build evolvable software
in the evolvable architecture, ‘the cost of making the change is proportional to the size of the change, not to the size of the overall software system’
evolvable software can handle unanticipated changes
‘design for change’ should be predominantly aimed at strategic evolution, not code level servicing

12. 2. Life cycles and maintenance --- Design for change
A strategy to set a certain rules during the Software development.
It eases the maintainability of the system
Three main Factors that we have to ensure during the design of the Software:
Understandability,
Modifiability,
Stability.

13. 2. Life cycles and maintenance --- Evolution
goals
to adapt the application to the ever-changing user and operating environment
to correct the faults in the application
to respond to both developer and user learning
inevitability of evolution [Lehman]
program grows during evolution [Lehner, Lehman]
business setting of evolution
user demand is strong
the organization is supportive
return on investment is excellent
both software architecture and software team knowledge make evolution possible

14. 2. Life cycles and maintenance ---Servicing
the program is no longer evolvable
changes are limited to patches and wrappers
they are less costly
they further deteriorate the architecture.
Senior designers and architects do not need to be available
Tools and processes are very different from evolution
A typical engineer will be assigned only part of the software to support
will have partial knowledge of the system.

15. 2. Life cycles and maintenance --- Phase-out and close down stages
no more servicing is being undertaken, but the system still may be in production
the users must work around known deficiencies
close-down
the software use is disconnected
the users are directed towards a replacement.
business issues:
Can any of the software be re-used?
‘exit strategy’ is needed.
once an organization commits to a system, changing to another is expensive, technically difficult, and time consuming.
What to do with corporate data?

16. 2. Life cycles and maintenance --- System Assessment
To determine whether a business still needs a system the system needs to be assessed for:
business value and system quality
Low quality, low business value
– system should be scrapped
Low quality, high business value
– should be re-engineered or replaced
High quality, low business value
– normal maintenance unless maintenance expensive then scrap
High quality, high business value
– normal maintenance
Refer Sommerville figure 21.13

17. 2. Life cycles and maintenance --- Strategic Guidelines for Implementing Alternatives
Scrap the system completely
The system is not making an effective contribution to business processes
Leave the system unchanged and continue with regular maintenance
Choose when the system is still required, is relatively stable and has few change requests

18. 2. Life cycles and maintenance --- Strategic Guidelines for Implementing Alternatives
Complete redesign and rewrite
Use when:
more than 20% of the program must be changed
program is being upgraded to new technology
Do not use when:
the design and function of the program is not known
Restructuring to improve maintainability
use on highly maintenance prone programs

19. 2. Life cycles and maintenance --- Strategic Guidelines for Implementing Alternatives
Partial restructuring integrated with adaptive maintenance
use for orderly improvement with each system release
Retirement of the system and complete redevelopment
Use when:
moving to a new technology
the costs of maintaining the software and the hardware exceed the cost of re-development

20. 3. Problems of software maintenance ---Software Maintenance is important
Direct software costs
Major economic importance: 40 – 90% of the total lifecycle costs
50-80% of the time of an estimated one million programmers or programming managers spent on maintenance. ... [Corbi89]
for every $1 allocated for a new development project, $9 will be spent on maintenance for the life cycle of the project. [Mit] …

21. 3. Problems of software maintenance ---Software Maintenance is important
It is necessary to add, to the direct cost of maintenance, the consequences of the maintenance...
Deterioration of software
Lost of software structure because of maintenance
May imply software “death” and its benefits
May have catastrophic consequences
Client dissatisfaction
Difficulty to deal with all the modification requests
Even if indirect costs are difficult to estimate, they often play a major role

22. 3. Problems of software maintenance --- Software maintenance is problematic
a neglected topic !
Too many factors
Maintainability is difficult to measured
Requirements is volatile

23. 3. Problems of software maintenance --- A neglected topic
No interest
Industry
Do you want to work in a software maintenance project ?
Few resources devoted to software maintenance teams
90% of managers complain about the employees lack of interest
Research
Projects focus on development
Only few conferences and books on software maintenance
University
Almost no courses on software maintenance

24. 3. Problems of software maintenance ---Too many factors
What Influences Maintainability?
Application type
System novelty
Turnover of maintenance staff
System life span
Hardware characteristics
Design, code, documentation, and testing

25. 3. Problems of software maintenance --- Maintainability is difficult to measured
Respect of Metrics
Software maintenance should be measured and managed using metrics to reach a quality software.
However, we don't know how to measure maintainability because it’s a service.

26. 3. Problems of software maintenance --- Requirements is volatile
Requirements are the foundation of the software release process.
Changing requirements during the software maintenance process impacts the cost, schedule, and quality of the resulting product.
Build model to make planning of customer communications (predictions).
A focus is made on non volatile requirements.

27. 4. The Maintenance Process
begins
when a request for change is initiated by a user
ends
when the system passes testing, is accepted by the user and is released for operation
in between
there are many activities that must be planned and co-ordinated by use of
Change Management

28. 4. The Maintenance Process
Seven-step approach [IEEE-1219]:
Step 1 - Problem/modification identification, classification, and prioritization.
Change Management
Step 2 - Analysis
Step 2.1 feasibility analysis
Impact Analysis
Step 2.2 detailed analysis
System Release Planning
Step 3 – Design (the Changes)
Step 4 - Implementation
Code the Changes
Step 5 - Regression/system testing
Step 6 - Acceptance testing.
Step 7 - Delivery
System Release
Sommerville figure 21.7
Refer Jan’s diagram from Software Evolution text by Arthur

29. 4. The Maintenance Process ---Step 1 - Change Management
to uniquely identify, describe and track the status of each requested change
in an organisation
change requests are recorded and tracked through all stages of the maintenance process in a Change Management Tracking System
Project Management and the Quality Assurance team receive information about the status of the Change Requests

30. 4. The Maintenance Process --- Step 1 - Change Management …
Change Request
basic tool (manual or electronic) of change management
documents all information about changes
updated throughout the maintenance process
to help manage the system release
for the analysis of the types and frequency of defects
to communicate to maintainers, managers and clients
Show a change request

31. 4. The Maintenance Process --- Step 2.1 - Impact Analysis
An Impact Analysis
identifies all systems/system products affected by a change request
develops an estimate of the resources needed to accomplish the change
Steps:
Evaluate Change Requests
Estimate Resources

32. 4. The Maintenance Process --- Step 2.1 - Impact Analysis ...
Aims:
to determine the scope of the requested change for planning and implementation of the change
to develop accurate estimates of resources
to analyse cost/benefits of the change
to communicate the complexity of the change

33. 4. The Maintenance Process --- Step 2.1 - Impact Analysis ...
Evaluate Change Requests
look for potential impact on:
- existing systems, other systems, hardware, documentation, data structures and humans
without analysis of the changes the change may insert defects that are not immediately apparent
Problems:
documentation doesn’t exist and must be created
documentation is out of date or incorrect leading to incorrect design decisions

34. 4. The Maintenance Process --- Step 2.1 - Impact Analysis ...
Estimate Resources
In an organisation, a project manager must estimate:
Number of people required to complete the system
The equipment required eg PCs, printers, copiers etc
Other facilities such as offices, support staff etc
Cost of the system etc

35. 4. The Maintenance Process --- Step 2.1 - Impact Analysis ...
To Estimate Resources need to know:
Size of required changes measured as
LOC and/or
Function Points and/or
Proxies such as classes and routines
(Impact Analysis will give this information)
Historical information
eg Productivity Rate, Average LOC per Routine
Time required to complete the system changes
Size of system and productivity rate

36. 4. The Maintenance Process --- Step 2.2 - System Release Planning
Aims:
to establish the schedule of system releases
to determine the contents of a system release
System Release/Version Description Document
describes the contents / timing of a system release
communicates between maintainers and users
used by operations to plan hardware, operational procedures and backup procedures

37. 4. The Maintenance Process --- Step 3 - Design Changes
Aims:
to develop a revised logical and physical design
analyse and design the changes
update the documentation
update the configuration management system
update the change request for management
to design the changes for each of the different types of maintenance

38. 4. The Maintenance Process --- Design Changes …
For Corrective Maintenance:
includes all repairs of defects in an existing system
Defects can stem from:
requirements specification errors
design errors
coding errors
About 80% of all problems stem from requirements and design

39. 4. The Maintenance Process --- For Corrective Maintenance …
Problems repairing defects:
cleanly repairing a defect
repairing a defect has a 20-50% change of introducing another defect
because:
Ripple-effect may be overlooked
person who makes the repair is not generally the person who wrote the code
increased testing
Every solution causes new problems

40. 4. The Maintenance Process --- Design Changes ...
For Adaptive Maintenance:
Aims to evolve systems to meet user and business needs
Essentially the same as a new development except that system understanding is needed first
Requirements then Design: - Systems, Data, Program and Module
At each stage conduct design and code reviews.

41. 4. The Maintenance Process --- Design Changes ...
For Perfective Maintenance ...
includes all efforts to polish or refine the quality of the software or the documentation
includes re-engineering
rewriting and upgrading documentation
restructuring poorly written code
important that the improvement reduces the system maintenance costs

42. 4. The Maintenance Process --- Step 4 – Code the Changes
Aim: to clarify existing code and simplify changing it
Re-Engineering Source Code
Restructuring
Redesign and rewrite code
Remember design and code reviews

43. 4. The Maintenance Process --- Step 5,6 – Test the Changes
Maintenance / Development Differences
For Maintenance:
only changes need to be reviewed
only new test cases that exercise the changes need to be developed
existing and new test cases are required to test the changes
test results are compared against previous test results (Regression Testing)

44. 4. The Maintenance Process --- Step 7 - System Release
Aims:
package the system for release including:
documentation
software
training
other products
hardware
deliver the system to the user
install with backup procedures

45. 5. Legacy Systems, Reverse Engineer and Re-engineering ---Legacy Systems
Legacy problems – a legacy system is typically:
very old and large
has been heavily modified
based on the old technology
documentation not be available
none of the original members of the software development team may still be around
often support very large quantities of live data
the software is often at the core of the business and replacing it would be a huge expense.
Dealing with legacy system is very hard and there are some solutions.

46. 5. Legacy Systems, Reverse Engineer and Re-engineering --- Legacy Systems
Solutions for the legacy system:
discarding the legacy system and building a replacement system;
freezing the system and using it as a component of a new larger system;
carrying on maintaining the system for another period;
modifying the system to give it another lease of life
Reverse Engineer the legacy system and develop a new software suite.  the most fruitful solution!

47. 5. Legacy Systems, Reverse Engineer and Re-engineering --- Reverse Engineering
Definition: Reversing Engineering
The process of analyzing a subject system to identify the system’s components and their inter-relationships, and to create representations of the system in another form or at higher levels of abstraction.( by Chikofsky & Cross)
Two types of Reverse Engineering:
Redocumentation: the creation or revision of a semantically equivalent representation within the same relative abstraction layer;
Design Recovery: involves identifying meaningful higher level abstractions beyond those obtained directly by examining the system itself.
The main motivation is to provide help in program comprehension

48. 5. Legacy Systems, Reverse Engineer and Re-engineering --- Reverse Engineering
reverse engineering has been successfully applied include
identifying reusable assets
finding objects in procedural programs
discovering architectures
deriving conceptual data models
detecting duplications
transforming binary programs into source code
renewing user interfaces
parallelizing sequential programs
Translating, downsizing, migrating and wrapping legacy code

49. 5. Legacy Systems, Reverse Engineer and Re-engineering --- Re-engineering
“Software Re-engineering is any activity that: (1) improves one’s understanding of software, or (2) prepares or improves the software itself, usually for increased maintainability, reusability, or evolvability.”
Re-engineering can involve:
Re-documenting
Organising and restructuring the system
Translating to a more modern programming language
Modifying the structure of the data
The old system forms the specification for the new system
Sommerville p 502 – 509 including figures

50. 5. Legacy Systems, Reverse Engineer and Re-engineering ---Reverse engineering and re-engineering.

51. The End Recommend papers The next lecture 《software maintenance》
Project Management