Transcript Corrective maintenance

Computing and SE II
Chapter 13: Software Maintenance
Er-Yu Ding
Software Institute, NJU
Main Contents
1.
2.
3.
4.
5.
What is software maintenance?
Life cycles and maintenance
Problems of software maintenance
The maintenance process
Legacy Systems, Reverse Engineer
and Re-engineering
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
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
•
1. What is Software
Maintenance?
Four categories:
1. Perfective maintenance: changes required as
a result of user requests (a.k.a. evolutive
maintenance)
2. Adaptive maintenance: changes needed as a
consequence of operated system, hardware,
or DBMS changes
3. Corrective maintenance: the identification
and removal of faults in the software
4. Preventative maintenance: changes made to
software to make it more maintainable
•
The majority of SM is concerned with
evolution deriving from user requested
1. What is Software
Maintenance?
2. Life cycles and
maintenance
2. Life cycles and
maintenance
2. Life cycles and
maintenance
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,
2. Life cycles and maintenance
--- challenges for initial
• To build evolvable
software
development
– 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
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.
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
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.
2. Life cycles and maintenance
--- Phase-out and close down
• phase-out
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?
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
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
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
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

3. Problems of software
maintenance
---Software
Maintenance is
• Direct
software costs
– Major economic
importance: 40 – 90%
important
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]
•
3. Problems of software
maintenance
It ---Software
is necessary to add,
to the direct costisof
Maintenance
maintenance, the consequences of the
important
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
3. Problems of software
maintenance
--- Software
maintenance
is
• Problems
of software
maintenance
– a neglected
topic !
problematic
– Too many factors
– Maintainability is difficult to measured
– Requirements is volatile
3. Problems of software
maintenance
No interest
--- A neglected topic
•
• 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
3. Problems of software
maintenance
• What Influences
Maintainability?
---Too many
factors
– Application type
– System novelty
– Turnover of maintenance staff
– System life span
– Hardware characteristics
– Design, code, documentation, and
testing
3. Problems of software
maintenance
--- Maintainability is difficult to
• Respect of Metrics
measured
– 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.
3. Problems of software
maintenance
• Requirements
are the foundation
--- Requirements
is volatileof
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.
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 coordinated by use of
Change Management
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
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
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

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:
1. Evaluate Change Requests
2. Estimate Resources
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
4. The Maintenance Process
--- Step 2.1 - Impact Analysis ...
1. 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
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
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. 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. 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
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
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
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.
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
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
--- 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
--- 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
5. Legacy Systems, Reverse Engineer and Reengineering
---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.
5. Legacy Systems, Reverse Engineer and Reengineering
--- 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!
5. Legacy Systems, Reverse Engineer and Reengineering
•
--Reverse
Engineering
Definition: Reversing Engineering
– The process of analyzing a subject system to
identify the system’s components and their interrelationships, and to create representations of the
system in another form or at higher levels of
abstraction.( by Chikofsky & Cross)
•
Two types of Reverse Engineering:
1. Redocumentation: the creation or revision of a
semantically equivalent representation within the
same relative abstraction layer;
2. 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
5. Legacy Systems, Reverse Engineer and Reengineering
•
--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
5. Legacy Systems, Reverse Engineer and Reengineering
--- 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
5. Legacy Systems, Reverse Engineer and Reengineering
---Reverse engineering and reengineering.
The End
• Recommend papers
– 《software maintenance》
• The next lecture
– Project Management