This is one chapter of a training manual originally prepared for Strong Funds by Dr. George Corliss. Other chapters:
Introduction
Planning
Design
Implementation
Exercise
on testing
Testing
Production
Maintenance
References
Most of the focus of software engineering is on techniques to reduce maintenance costs. What is MAINTENANCE?
References: Pfleeger, Software Engineering, Chapter 10,
Pressman, Software Engineering: A Practitioner's Approach, Chapter 13
Why is maintenance necessary?
What
are the tasks of
maintenance?
What are the types of
maintenance?
Why is maintenance so hard?
How
can maintenance productivity
be improved?
What are the milestones?
What
tools
are available to help you?
"Maintenance" refers to modifications to the software, hardware, or documentation of a system after it is operational.
Maintenance of existing software can account for 50 - 80% of all the effort expended during the total lifecycle.
Software maintenance is not like hardware maintenance; WHILE loops do not wear out and semicolons do not fall off the end of PL/I statements. Software systems are built to incorporate change.
Exercise: What changes are likely to occur in one of your projects after installation?
Diagnosis and correction of errors
Testing will not uncover all
errors
Emergency vs long-term fixes
Examples?
Changes required by changes in other parts
Interface with changing
environment
Do not correct errors, but adapt to other changes
Hardware, software, or operational changes
Examples?
New capabilities
Modifications to existing functions
Improve
performance
Enlarge capacity
General enhancements
Results from
changes to problem or requirements
Measure of success
Documentation
Examples?
Improve maintainability or reliability
Better basis for future
enhancements
Examples?
Describe a system in terms of its relationship to its environment. The real world contains uncertainties and concepts we do not understand completely. The more dependent a system is on the real world for its requirements, the more likely it is to change.
Formally defined by and derivable from a specification
Concern is not
with correctness of solution, but with correctness of the implementation
Problem does not change
Changes in real world may require solution of a
new problem
Examples: math problems - matrix algebra, integration
Maintenance:
Theoretical solution exists
Real world situation is stable
Implementation is impractical
Implement an approximation to the
theoretical solution, or a solution to an approximation to the problem
Solution is based on a practical abstraction of the problem
Requirements
are based on an approximation
Solution is acceptable if the results make
sense in the real world
Examples: chess program
Maintenance:
Incorporates the changing nature of the real world
Embedded in the world
and changes as the world does
Problem addressed cannot be completely
specified
Characterized by almost constant enhancements
Good candidate
for rapid prototyping
Examples: economic model
--- Both parameters and
the model itself change
Maintenance:
Exercise: Choose one of your current projects. Which type of system is it? Why?
When changes are made, what documents are affected?
| Stage of Development | Effect of Changes |
| Requirements Analysis | Specifications |
| System Design | Conceptual Design Specification Technical Design Specification |
| Program Design | Program Design Specification |
| Program Implementation | Program Code Program Documentation |
| Unit Testing | Test Plans Test Scripts |
| System Testing | Test Plans Test Scripts |
| System Installation User | Documentation Training Aids Operator Documentation System Guide Programmer Guide Training Classes |
Development focuses on producing code which implements the requirements and which works correctly. Development involves looking back to earlier stages to review current products.
Maintenance looks
Maintenance encompasses more than development.
There is more to keep track of.
A wider variety of skills are required.
Maintenance is more difficult than development.
That fact is rarely recognized.
Understand the problem as expressed in the user's language
Generate a request for modification
Understand the system
Locate information in the system documentation
Keep the system documentation up to date
Extend existing functions to accommodate new or changing requirements
Add new functions
Find the source of errors in the system
Correct errors in the system
Answer questions about the way the system works
Restructure the design and code
Delete obsolete design and code modules
Manage the changes
Attempt to learn from our experiences
Simple maintenance log:
Module name
Problem
Modification
User generated maintenance request form:
How the system works now:
--- Complete description of circumstances
leading to error
How the user wants the system to work:
---
Requirements specification
Internally generated software change report:
Magnitude of effort required
Nature of changes required
Relative
priority
History:
After-the-fact data about the modification:
Look back at how we did
Rarely done
How else can we learn?
Some questions:
Given the current situation, what aspects of analysis, design, code, test, or documentation could have been done differently?
What maintenance resources should have been available and were not?
What were the major (and minor) stumbling blocks for this effort?
Is preventive maintenance indicated by the types of request being reported?
How will we address these issues next time?
How well are we doing? Here are some quantitative measures:
Average number of processing failures per program run
Total number of person-hours spent in each maintenance category
Average number of program changes made per program, per language, per maintenance type
Average number of person hours spent per source statement added or deleted
Average person hours spent per language
Average turn-around time for a request
Percentage of maintenance requests by type
Exercise: What use might be made of each of these measures?
How do we spend our maintenance time?
| Enhancements & Maintenance Task |
Modifications | Corrections |
| Define and understand change | 18% | 25% |
| Review documentation | 6 | 4 |
| Trace logic | 23 | 33 |
| Implement change | 19 | 15 |
| Test change | 28 | 20 |
| Update documentation | 6 | 3 |
Balance the need for change with the need for keeping a system accessible to users
Limited understanding
By users of problem and system
By maintenance team of users and system
Importance of clear and complete documentation
Importance of clear and
complete training
Importance of good people skills
Management priorities often override technical ones
Should they?
Pressure from management to repair the old system vs pressure from users for new features or new system
My experience is the opposite:
Exercise: What are the relative priorities for your client?
When documentation and code is not clear, it is often hard to tell whether the design can handle proposed changes.
Design may be flawed or inflexible
Example: Year 2000, 9 digit ZIP code
Machine access
Unreliable hardware, software, or data
Maintenance side effects:
Coding side effects
Example:
DO 10 I = 1.10 vs DO 10 I = 1,10 (Fortran)
in spacecraft flight
control software
Opportunities for side effects abound
Particularly error prone
modifications:
Design changes translate into major code changes
Changes to boundary
tests
Importance of low coupling
Importance of high cohesion
Exercise: What is your favorite war story about coding side effects?
Data side effects
Data itself may change
Maintenance of data structures
Software may
no longer fit the data
Particularly error prone modifications:
Importance of modularization
Importance of data abstraction
Dangers
of "tramp" data structures
Importance of internal documentation
Exercise: What is your favorite war story about data side effects?
Documentation side effects
Exercise: What is your favorite war story about documentation side effects?
Often second-class status of maintenance team
See Management priorities above
TOTALLY INAPPROPRIATE
Maintenance team must be skilled at
Rotate personnel
Balance one set of goals against another
Example: system available for users
vs implementation of corrections
& improvements
Principles of software engineering to compete with
expediency, and appear to compete with cost
Long-term vs
short-term savings
Which is better?
Quick fix vs "right" way
Quick
fix often makes system more difficult to maintain in the future
Maintenance team must develop a philosophy about the way in which maintenance will be performed
Factors affecting cost
Type of applications, e.g.. real-time
Turnover in maintenance staff
Lifespan of the system
Dependence on changing environment
Characteristics of the hardware
Quality of the design
Quality of
the code
Quality of the documentation
Quality of the testing
Model of maintenance effort M = p + K^{c-d}
M = total maintenance effort over entire lifecycle
p = productive
efforts: analysis, design, code, test
"wheel-spinning:"
c = complexity
due to lack of structured design and documentation
d = degree of
familiarization with the system
K = empirically determined constant
Reference: Strong/Corneliuson Project Life Cycle
The Maintenance Log continues to track the project after it has been installed in production. Its purposes are
For each requested change, the Maintenance Log typically contains