Chapter 2: Software Maintenance

Omar Meqdadi

SE 3860 Lecture 2

Department of Computer Science and Software Engineering University of Wisconsin-Platteville

2

Topic Covered

System Types Software Change Strategies Maintenance Team Maintenance Problems Maintenance Cost

3

Software Changes

Software change is unavoidable New requirements emerge when the software is used The business environment changes Errors must be repaired New equipment must be accommodated The performance or reliability may have to be improved

A key problem for organisations is implementing and managing change to their legacy systems

4

Software Change Strategies

Software Maintenance Changes are made in response to changed requirements but the

fundamental software structure is stable Maintenance does not normally involve major changes to the

system’s architecture

Software Re-engineering No new functionality is added to the system but it is restructured and

reorganised to facilitate future changes

Architectural Transformation The architecture of the system is modified generally from a

centralised architecture to a distributed architecture

These strategies may be applied separately or together

Program evolution dynamics: the empirical study of the process of system changes

After major empirical studies: Lehman and Belady proposed that there were a number of

‘laws’ which applied to all systems as they evolved There are sensible observations rather than laws. They are applicable to large systems developed by large

organisations. Perhaps less applicable in other cases

Program Evolution Dynamics

6

Lehman’s System Types

S-system: formally defined, derivable from a specification Matrix manipulation

P-system: requirements based on approximate solution to a problem, but real-world remains stable Games (e.g., Chess) program

E-system: embedded in the real world and changes as the world does Software to predict how economy functions (but economy

is not completely understood)

7

Changes During the System Life Cycle

S-system: un-changed P-system: incremental change

An approximate solution Changes as discrepancies and omissions are identified

E-system: constant change

Examples of Change During Software Development

Activity from which Initial change results Artifacts requiring consequent change

Requirement analysis Requirement specification

System design Architectural design specificationTechnical design specification

Program design Program design specification

Program implementation Program codeProgram documentation

Unit testing Test plansTest scripts

System testing Test plansTest scripts

System delivery User documentationOperator documentationSystem guideProgrammer’s guideTraining classes

Lehman’s Laws

Law Description

Continuing change A program that is used in a real-world environment necessarilymust change or become progressively less useful in thatenvironment.

Increasing complexity As an evolving program changes, its structure tends to becomemore complex. Extra resources must be devoted to preservingand simplifying the structure.

Large program evolution Program evolution is a self-regulating process. Systemattributes such as size, time between releases and the number ofreported errors is approximately invariant for each systemrelease.

Organisational stability Over a programΥs lifetime, its rate of development isapproximately constant and independent of the resourcesdevoted to system development.

Conservation offamiliarity

Over the lifetime of a system, the incremental change in eachrelease is approximately constant.

Continuing growth The functionality offered by systems has to continually increaseto maintain user satisfaction.

Declining quality The quality of systems will appear to be declining unless theyare adapted to changes in their operational environment.

Feedback system Evolution processes incorporate multi-agent, multi-loopfeedback systems and you have to treat them as feedbacksystems to achieve significant product improvement.

Is the cost of maintenance too high?

Is the system reliability unacceptable?

Can the system no longer adapt to further change, and within a reasonable amount of time?

Is system performance still beyond prescribed constraints?

Are system functions of limited usefulness?

Can other systems do the same job better, faster or cheaper?

Is the cost of maintaining the hardware great enough to justify replacing it with cheaper, newer hardware?

System Maintenance vs. Decline

Separate maintenance team May be more objective May find it easier to distinguish how a system should work

from how it does work Part of development team

Will build the system in a way that makes maintenance easier

Problem: May feel over confident, and ignore the documentation to

help maintenance effort

Who Performs Maintenance

Novice Expert

 Language expertise Domain expertise Comprehension strategies expertise The specific program expertise

Skills of The Maintainer

Information Needs

Domain expert’s view Concepts of the domain and their relations Scope and boundaries of the program Goals of the program

User’s view Constraints

Size Timing

Operations of the program Installation

Information Needs

Programmer’s view Dependency graph Program parts (classes, functions) and their dependencies

(call, use inheritance) Algorithms: How are the goals accomplished?   Representations: How are entities and relations of the

domain reflected in the program? Resource allocation: Memory size, timing

Information Sources

Programmer’s knowledge Code Documentation Colleagues on the project

Program Comprehension: Understanding the system Traceability: Locating information in system documentation Perform the required changes

Extending existing functions to accommodate new or changing requirements

Adding new functions to the system Finding the source of system failures or problems Locating and correcting faults Restructuring design and code components Rewriting design and code components Deleting design and code components that are no longer useful

Maintenance Team Responsibilities

Keeping system documentation up-to-date

Answering questions about the way the modified system works

Maintenance Team Responsibilities

Staff Problems Limited understanding (47% of effort is spent on

understanding) Management priorities: rushing a new product to the

market Morale: “second-hand” status accorded to maintenance

team Technical Problems

Artifacts and paradigms (e.g., legacy, non-OO) Testing difficulties (some systems must be available

around a clock)

Maintenance Problems

Unstructured code Insufficient knowledge about system and domain Insufficient documentation Bad image of maintenance department

Causes of Maintenance Problems

Usually greater than development costs Affected by both technical and non-technical

factors Increases as software is maintained.

Maintenance corrupts the software structure so makes further maintenance more difficult.

Ageing software can have high support costs (e.g. old languages, compilers etc.)

Maintenance Costs

Development/Maintenance Costs

Parikh and Zvegintzov (1983) Development time: 2 years Maintenance time: 5 to 6 years

Fjedstad and Hamlen (1979) 39% of effort in development 61% of effort in maintenance

80-20 rule 20% of effort in development 80% of effort in maintenance

Development/Maintenance Costs

Team stability Maintenance costs are reduced if the same staff are involved with them

for some time

Contractual responsibility The developers of a system may have no contractual responsibility for

maintenance so there is no incentive to design for future change

Staff skills Maintenance staff are often inexperienced and have limited domain

knowledge

Program age and structure As programs age, their structure is degraded and they become harder to

understand and change

Maintenance Cost Factors

Application type System novelty Turnover and maintenance staff ability System life span Dependence on a changing environment Hardware characteristics Design quality Code quality Documentation quality Testing quality

Factors Affecting Maintenance Effort