CSE3308/DMS/2005/26

Software Engineering: Analysis and Design - CSE3308

Software Maintenance

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.1

Lecture Outline
x x x

Maintenance and the SDLC The Cost of Maintenance Types of Maintenance

y Corrective y Adaptive y Perfective y Preventive

x x x x

Alternatives to Maintenance The Maintenance Process The Laws of Change Motivating Maintenance Staff
Lecture 10B.2

CSE3308 - Software Engineering: Analysis and Design, 2005

The First Law of Software Engineering

No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle
Bersoff et al. (1980)

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.3

Sources of Change
x

x x x

New business or market conditions which cause changes in product requirements or business rules New customer needs that demand modification of data, functionality or services delivered by the system Reorganisation and/or business downsizing that changes priorities and team structures Budgetary or scheduling constraints that cause a redefinition of the system MOST CHANGES ARE JUSTIFIED
Lecture 10B.4

CSE3308 - Software Engineering: Analysis and Design, 2005

Maintenance and the SDLC

x

x x

In the Waterfall software development lifecycle, we had a nice little box at the end of the process and one which was generally ignored in descriptions of the process In more advanced lifecycles such as the Spiral Model, maintenance was accorded a much more prominent place Still, maintenance is a relatively neglected aspect of the SDLC Examples: Pressman has no specific chapter on Maintenance, Somerville has 15 pages out of 742 pages
Lecture 10B.5

CSE3308 - Software Engineering: Analysis and Design, 2005

The Cost of Maintenance

x

One study found

y Requirements Definition y Preliminary Design y Detailed Design y Implementation y Testing y Maintenance 3% 3% 5% 7% 15% 67%

x x x

Another study found at least 50%of effort spent on maintenance Another study found between 65% and 75%on maintenance In embedded real-time systems, maintenance costs may be up to 4 times development costs
Lecture 10B.6

CSE3308 - Software Engineering: Analysis and Design, 2005

Why is Maintenance so Costly?

x x

x x x x x x

Most software is between 10 and 15 years old Much of that software is showing its age as it was created when program size and storage space were far more important factors This has lead to inflexible designs, coding and documentation Maintenance is usually done by inexperienced staff unfamiliar with the application Developers dont like maintenance Changes often cause new faults in the system Changes tend to degrade the structure of a program Changes are often not documented
Lecture 10B.7

CSE3308 - Software Engineering: Analysis and Design, 2005

Factors Affecting Maintenance Costs

x

Module Independence
y the ability to modify one part of the system y potential advantage of OO

Programming Language
y the higher the level of the language, the cheaper the maintenance y C a write-only language, some say :-)

x x

Programming Style
y the way in which a program is written

Program Validation and Testing

y the more time and effort spent on design validation and program testing, the fewer errors and the less the need for corrective maintenance

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.8

Factors Affecting Maintenance Costs (2)

x x

Quality of Program Documentation

y the better the documentation, the easier it is to maintain

Configuration Management Techniques

y keeping track of all the system documents and ensuring they are consistent is a major cost of maintenance, therefore good CM tools and practices reduce this cost

Application Domain
y the less well-understood the domain, the greater the likelihood of the need for adaptive maintenance as users and developers begin to understand the domain

Staff Stability
y Maintenance costs are reduced if developers have to maintain their own systems, highly unusual though over the life of a system

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.9

Factors Affecting Maintenance Costs (3)

x

Age of the System

y the older the system, the more likely that its structure has degraded and the harder the maintenance will be y Attracting staff who know the old languages/databases/operating systems becomes harder and more expensive

Dependence of the System on the External Environment

y the higher the dependence, the far more likely that adaptive maintenance will be needed

Hardware Stability
y If the hardware platform will not change over the life of the system, maintenance for this reason will not be needed

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.10

Differences between Maintenance and New Development

x

Constraints of an Existing System

y Changes must conform or be compatible with an existing architecture, design and code constraints

Shorter Time Frames

y Development spans 6 months upwards y Maintenance spans hours or days up to 6 months

Available Test Data

y Development creates all test data from scratch y Maintenance uses existing test data with regression testing, creating new data for the changes

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.11

Types of Maintenance
x x x

So how and why do we spend so much time and effort on maintenance? Maintenance is much more than fixing bugs Commonly divided into three main categories
y Corrective Maintenance y Adaptive Maintenance y Perfective Maintenance

x x

The boundaries between the three types of maintenance are often blurred We can also define another type of maintenance - Preventative Maintenance
Lecture 10B.12

CSE3308 - Software Engineering: Analysis and Design, 2005

Types of Maintenance

Corrective 17%

Adaptive 18%

Perfective 65%

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.13

Corrective Maintenance
x x

Focused on fixing failures Is a reactive process

y failures and their associated faults generally need to be corrected either immediately or in the near future

Failures vary in their cost to correct

y Coding - usually relatively cheap y Design - more expensive as they may require changes to several program components y Requirements - most expensive - may require extensive system redesign

Design and Requirements are the source of approximately 80% of failures

Lecture 10B.14

CSE3308 - Software Engineering: Analysis and Design, 2005

Corrective Maintenance (2)

x x

Fixing a fault has a 20 to 50% chance of introducing another fault Reasons for new faults include
y the ripple effect, where a change in one area may cause changes in seemingly unrelated areas y Person who makes the repair is generally not the person who wrote the code or designed the system

Two types of corrective maintenance

y Emergency Repairs - short time frame, often a single program, failure needs to be repaired as soon as possible y Scheduled Repairs - failure doesnt need immediate attention, re-examination of all emergency repairs

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.15

Adaptive Maintenance
x x

The evolution of the system to meet the needs of the user and the business Caused by
y internal needs y external competition y external requirements e.g. changes in law

x x

Essentially we are introducing new requirements to the system Therefore we should treat like a new development in our approach and methods

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.16

Perfective Maintenance
x x

Old proverb says If it isnt broken, dont fix it Perfective maintenance ignores this ancient piece of wisdom Is about improving the quality of a program that already works Aim to achieve
y reduced costs in using the system y increase maintainability of the system y more closely meet the users needs

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.17

Perfective Maintenance (2)

x x

Includes all efforts to polish or refine the quality of the software or the documentation Important that the potential benefits of the perfective maintenance outweigh
y the costs of the maintenance y and the opportunity costs of improvements elsewhere or using the resources on new developments

Therefore before performing perfective maintenance, one should go through an analysis process Nevertheless, a little perfective maintenance can have dramatic effects
Lecture 10B.18

CSE3308 - Software Engineering: Analysis and Design, 2005

Preventative Maintenance
x x x x x

Can be seen as radical perfective maintenance or as an alternative to maintenance More commonly known as Software Reengineering Taking a legacy system and converting its structure or converting to a new language Old system starts as a specification for the new system Common method now is known as wrappers where an entire system is placed in an OO wrapper and treated as one large object
Lecture 10B.19

CSE3308 - Software Engineering: Analysis and Design, 2005

Alternatives to Maintenance
x

Sometimes, maintenance is not enough on its own Partial restructuring integrated with adaptive maintenance
y use for orderly improvement with each system release

Complete restructuring or overhaul of the existing code

y use on highly maintenance-prone system

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.20

Alternatives to Maintenance (2)

x

Complete redesign and rewrite

y Use when more than 20% of program must be changed y Use when program is being upgraded to a new technology y Dont use when the design and function of a system are not known

Retirement of the system and complete redevelopment

y Use when moving to a new technology y use when the costs of maintaining the software and the hardware exceed the cost of re-development

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.21

The Maintenance Process

Below is an ideal process, that is often not achieved
Change Change requests requests

Change Change management management

Impact Impact analysis analysis

System System release release planning planning

Change Change implementation implementation

System System release release

Perfective Perfective maintenance maintenance

Adaptive Adaptive maintenance maintenance

Corrective Corrective maintenance maintenance

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.22

The Maintenance Process (2)

x

Change Management
y Uniquely identify, describe and track the status of all change requests

Impact Analysis
y identifies all systems and system products affected by a change request y makes an estimate of the resources needed to effect the change y analyses the benefits of the change

System Release Planning

y to establish the schedule and contents of a system release y dont want each change request released as they are processed

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.23

The Maintenance Process (3)

x

Change Implementation
y Design Changes y Coding y Testing - must perform regression testing

System Release includes

y documentation y software y training y hardware changes y data conversion

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.24

Lehmans Laws of Software Change

x

Five laws based upon the growth and evolution of a number of large software systems Law of Continuing Change
y A program used in a real-world environment necessarily must change or become less useful in that environment

Law of Increasing Complexity

y As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.25

Lehmans Laws of Software Change (2)

x

Law of Large Program Evolution

y Program evolution is a self-regulating process. System attributes such as size, time between releases and the number of reported errors are approximately invariant for each system release

Law of Organisational Stability

y Over a programs lifetime, its rate of development is approximately constant and independent of the resources devoted to system development

Law of Conservation of Familiarity

y Over the lifetime of a system, the incremental change in each release is approximately constant

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.26

Motivating Maintenance Staff

x x x

Often considered a dead-end in organisations as well as being boring! Critical to the success of the organisation Possible strategies
y Couple software objectives to organisational goals y Couple software maintenance rewards to organisational performance y Integrate software maintenance personnel into operational teams y Create a discretionary, perfective/preventative maintenance budget which allows the maintenance team to decide when to re-engineer the system y Involve maintenance staff early in the software process during standards preparation, reviews and test preparation

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 10B.27