8/11/2019 Chapter 13 Software Maintenance
1/51
Computing and SE II
Chapter 13: Software Maintenance
Er-Yu Ding
Software Institute, NJU
8/11/2019 Chapter 13 Software Maintenance
2/51
8/11/2019 Chapter 13 Software Maintenance
3/51
1. What is Software
Maintenance? Software EvolutionSoftware development does not stop whena system is delivered but continues
throughout the lifetime of the system.
(Sommerville, 2004)
The system changes relate to changing businessand user needs
The system evolves throughout its lifetimethrough a seamless process
The process is a spiral process involvingrequirements, design & implementation
throughout the lifetime of the system
8/11/2019 Chapter 13 Software Maintenance
4/51
1. What is Software
Maintenance? IEEE91 Definition: the process of modifying the software
system or component after delivery to
correct faults, improve performance orother attributes, or adapt to a change in
the environment.
SM is concerned with modifyingsoftware once it is delivered to a
customer
8/11/2019 Chapter 13 Software Maintenance
5/51
1. What is Software
Maintenance? Four categories:1. Perfective maintenance:changes required as
a result of user requests (a.k.a. evolutivemaintenance)
2. Adaptive maintenance:changes needed as aconsequence of operated system, hardware,or DBMS changes
3. Corrective maintenance:the identification
and removal of faults in the software4. Preventative maintenance:changes made to
software to make it more maintainable
The majority of SM is concerned withevolution deriving from user requested
8/11/2019 Chapter 13 Software Maintenance
6/51
1. What is Software
Maintenance?
8/11/2019 Chapter 13 Software Maintenance
7/51
8/11/2019 Chapter 13 Software Maintenance
8/51
2. Life cycles and
maintenance
8/11/2019 Chapter 13 Software Maintenance
9/51
2. Life cycles and
maintenance
8/11/2019 Chapter 13 Software Maintenance
10/51
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 changesduring its 20 years of existence, but it still
possesses the architecture of the original firstversion.
programming team acquires the knowledgeof application domain, user requirements, role of
the application in the business process,solutions and al orithms data formats
8/11/2019 Chapter 13 Software Maintenance
11/51
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 theoverall software system
evolvable software can handleunanticipated changes
design for change should bepredominantly aimed at strategicevolution, not code level servicing
8/11/2019 Chapter 13 Software Maintenance
12/51
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.
8/11/2019 Chapter 13 Software Maintenance
13/51
8/11/2019 Chapter 13 Software Maintenance
14/51
2. Life cycles and maintenance
---Servicing the program is no longer evolvable
changes are limited to patches andwrappers
they are less costly they further deteriorate the architecture.
Senior designers and architects do not needto be available
Tools and processes are very different fromevolution
A typical engineer will be assigned only partof the software to support
will have partial knowledge of the system.
8/11/2019 Chapter 13 Software Maintenance
15/51
2. Life cycles and maintenance
--- Phase-out and close down
stages phase-out 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, changingto another is expensive, technically difficult, andtime consuming.
What to do with corporate data?
8/11/2019 Chapter 13 Software Maintenance
16/51
2. Life cycles and maintenance
--- System Assessment
To determine whether a business still needs a systemthe 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
8/11/2019 Chapter 13 Software Maintenance
17/51
2. Life cycles and maintenance
--- Strategic Guidelines for Implementing
Alternatives Scrap the system completelyThe 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 changerequests
8/11/2019 Chapter 13 Software Maintenance
18/51
.--- 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
8/11/2019 Chapter 13 Software Maintenance
19/51
.--- 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
8/11/2019 Chapter 13 Software Maintenance
20/51
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 onemillion 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]
8/11/2019 Chapter 13 Software Maintenance
21/51
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
8/11/2019 Chapter 13 Software Maintenance
22/51
3. Problems of software
maintenance
--- Software maintenance is
problematic
Problems of software maintenance
a neglected topic !
Too many factors
Maintainability is difficult to measured
Requirements is volatile
8/11/2019 Chapter 13 Software Maintenance
23/51
3. Problems of software
maintenance
--- A neglected topic No interest Industry
Do you want to work in a software maintenanceproject ?
Few resources devoted to softwaremaintenance teams
90% of managers complain about theemployees lack of interest
Research Projects focus on development
Only few conferences and books on softwaremaintenance
University
8/11/2019 Chapter 13 Software Maintenance
24/51
8/11/2019 Chapter 13 Software Maintenance
25/51
3. Problems of software
maintenance
--- Maintainability is difficult to
measured Respect of Metrics
Software maintenance should be
measured and managed using metrics toreach a quality software.
However, we don't know how to
measure maintainability because its a
service.
8/11/2019 Chapter 13 Software Maintenance
26/51
3. Problems of software
maintenance
--- Requirements is volatile Requirements are the foundation ofthe software release process.
Changing requirements during the
software maintenance process impactsthe cost, schedule, and quality of theresulting product.
Build model to make planning of
customer communications (predictions). A focus is made on non volatile
requirements.
8/11/2019 Chapter 13 Software Maintenance
27/51
4. The Maintenance Process
begins
when a request for change is initiated by a user
endswhen the system passes testing, is accepted by theuser and is released for operation
in between
there are many activities that must be planned and
co-ordinated by use of
Change Management
8/11/2019 Chapter 13 Software Maintenance
28/51
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
8/11/2019 Chapter 13 Software Maintenance
29/51
4. The Maintenance Process
---Step 1 - Change Management
to uniquely identify, describe and trackthe status of each requested change
in an organisation
change requestsare recorded and trackedthrough all stages of the maintenanceprocess in a Change Management TrackingSystem
Project Management and the QualityAssurance team receive information aboutthe status of the Change Requests
8/11/2019 Chapter 13 Software Maintenance
30/51
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
8/11/2019 Chapter 13 Software Maintenance
31/51
8/11/2019 Chapter 13 Software Maintenance
32/51
4. The Maintenance Process
---Step 2.1 - Impact Analysis ...
Aims:
to determine the scopeof the requested change forplanning and implementation of the change
to develop accurate estimates of resources
to analyse cost/benefitsof the change
to communicate the complexityof the change
h
8/11/2019 Chapter 13 Software Maintenance
33/51
4. The Maintenance Process
---Step 2.1 - Impact Analysis...
1. Evaluate Change Requests
look for potential impacton:- existing systems, other systems, hardware, documentation,
data structures and humans
without analysis of the changes the change may insertdefects that are not immediately apparent
Problems: documentation doesnt exist and must be created
documentation is out of date or incorrect leading toincorrect design decisions
8/11/2019 Chapter 13 Software Maintenance
34/51
4. The Maintenance Process
---Step 2.1 - Impact Analysis...
2. 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
8/11/2019 Chapter 13 Software Maintenance
35/51
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
4 Th M i t P
8/11/2019 Chapter 13 Software Maintenance
36/51
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
4 Th M i t P
8/11/2019 Chapter 13 Software Maintenance
37/51
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
8/11/2019 Chapter 13 Software Maintenance
38/51
4 Th M i t P
8/11/2019 Chapter 13 Software Maintenance
39/51
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 testingEvery solution causes new problems
4 Th M i t P
8/11/2019 Chapter 13 Software Maintenance
40/51
4. The Maintenance Process
---Design Changes ...
For Adaptive Maintenance:
Aimsto evolve systems to meet user and business needs
Essentially the same as a new development exceptthat system understanding is needed first
Requirements then Design: - Systems, Data, Program and
Module
At each stageconduct design and code reviews.
4 Th M i t P
8/11/2019 Chapter 13 Software Maintenance
41/51
4. The Maintenance Process
--- Design Changes ...
For Perfective Maintenance ...
includes all efforts to polish or refine thequality of the software or the
documentation
includes re-engineering
rewriting and upgrading documentation
restructuring poorly written code
important that the improvementreduces the system maintenance costs
4 Th M i t P
8/11/2019 Chapter 13 Software Maintenance
42/51
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
4 The Maintenance Process
8/11/2019 Chapter 13 Software Maintenance
43/51
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)
4 The Maintenance Process
8/11/2019 Chapter 13 Software Maintenance
44/51
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
8/11/2019 Chapter 13 Software Maintenance
45/51
5. Legacy Systems, Reverse Engineer and Re-
engineering
---Legacy Systems Legacy problems a legacy system istypically:
very old and large
has been heavily modified
based on the old technology
documentation not be available
none of the original members of the softwaredevelopment 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 hugeexpense.
Dealing with legacy system is very hard and
there are some solutions.
8/11/2019 Chapter 13 Software Maintenance
46/51
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 acomponent of a new larger system;
carrying on maintaining the system foranother period;
modifying the system to give it anotherlease of life
Reverse Engineer the legacy system anddevelop a new software suite.the mostfruitful solution!
8/11/2019 Chapter 13 Software Maintenance
47/51
5. Legacy Systems, Reverse Engineer and Re-
engineering
--- Reverse Engineering Definition: Reversing Engineering The process of analyzing a subject system to
identify the systems components and their inter-relationships, and to create representations of thesystem in another form or at higher levels of
abstraction.( by Chikofsky & Cross)
Two types of Reverse Engineering:
1. Redocumentation: the creation or revision of asemantically equivalent representation within thesame relative abstraction layer;
2. Design Recovery: involves identifying meaningfulhigher level abstractions beyond those obtaineddirectly by examining the system itself.
The main motivation is to provide help in program
comprehension
8/11/2019 Chapter 13 Software Maintenance
48/51
5. Legacy Systems, Reverse Engineer and Re-
engineering
--- Reverse Engineering reverse engineering has been successfullyapplied 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 andwrapping legacy code
8/11/2019 Chapter 13 Software Maintenance
49/51
5. Legacy Systems, Reverse Engineer and Re-
engineering
--- Re-engineering Software Re-engineering is any activity that: (1) improves
ones 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
8/11/2019 Chapter 13 Software Maintenance
50/51
5. Legacy Systems, Reverse Engineer and Re-
engineering
---Reverse engineering and re-engineering.
8/11/2019 Chapter 13 Software Maintenance
51/51
The End
Recommend papers
software maintenance
The next lecture
Project Management
Top Related