Software Engineering

CS3003
Lecture 2: Software Maintenance and Evolution
 Lecture schedule
Week Lecture Topic Lecturer Week Commencing
1 Introducing the module and software Steve 28th Sept.
engineering
2 Software maintenance and evolution Steve 5th Oct.
3 Software metrics Steve 12th Oct.
4 Test-driven development Giuseppe 19th Oct.
5 Software structure, refactoring and Steve 26th Oct.
code smells
6 Software Complexity Steve 2nd Nov.
Coursework released Tuesday 3rd
November
7 ASK week N/A 9h Nov
8 Software fault-proneness Steve 16th Nov.
9 Clean code Steve 23th Nov.
10 Human factors in software engineering Giuseppe 30th Nov.
11 SE Techniques applied in action Steve 7th Dec.
12 Guest industry lecture (tba) Guest Lecture 14th Dec.
Coursework hand-in Monday 14th
December
 Lab/seminar schedule
Week Seminar Labs Week Commencing
1 No seminar No lab 28th Sept.
2 Seminar Lab (Introduction) 5th Oct.
3 Seminar Lab 12th Oct.
4 Seminar Lab 19th Oct.
5 Seminar Lab 26th Oct.
6 Coursework Brief Seminar No lab 2nd Nov.
7 ASK week ASK week 9th Nov.
8 Seminar Lab 16th Nov.
9 Coursework technique seimar Lab 23th Nov.
10 Seminar Lab 30th Nov.
11 No seminar Work on coursework (no lab.) 7th Dec.
12 No seminar Work on coursework (no lab.) 14th Dec.
Structure of this lecture

 What is software maintenance and evolution?

4
Software Maintenance: definition

The process of modifying a software system or

Process of developing software initially, then

 Maintenance of evolving software is unavoidable,

6
Maintenance prediction (slide taken from
Somerville)
Types of Maintenance?
 adaptive maintenance
• adapting to changes in the environment (both
hardware and software)
 corrective maintenance
• correcting errors
 perfective maintenance
• making what’s there “better”
 preventative maintenance
• “future-proofing” the code for later
The key to maintenance? During
development
 Higher quality code → less corrective maintenance
 Anticipating changes → less adaptive maintenance
 Better development practices → less perfective
maintenance
 Better tuning to user needs → less maintenance overall
 Less code → less maintenance overall
 Avoid code ‘bloat’
 Avoid smells emerging

9
 Some harsh facts
 Maintenance is expensive:
 Sommerville reports 70% software costs
 Costs vary across application domain (e.g. real time, embedded,
games)
 Classic example: US airforce project: $30 per line code to develop and
$4,000 per line code to maintain
 Mainteance is difficult:
 47% effort goes into understanding the system and identifying
dependencies (Pfleeger)
 Making changes is also risky because of side effects, ripple effects and
dependencies
 Can be a low morale job
Factors that affect maintenance &
evolution
(1) Team stability
(2) Poor development practice (quality)
(3) Staff skills
(4) Program age and structure
(5) The amount of “technical debt” in a system
(1) The result of not doing maintenance when you
should
(2) That “ignored” maintenance will come back to
haunt you later
https://www.linkedin.com/pulse/technical-debt-infinite-mortgage-your-system-julien-dollon/
Two factors that help manage
software evolution
1. Change management
 Many change requests are generated for most systems
– Fall into the different maintenance categories (see
earlier slide on types of maintenance)
 Need to ensure that change is implemented rationally
 Factors considered include:
 Urgency, Value, Impact, Benefit, Cost
 Usually companies have a team who analyse (and
prioritise) change requests
 In XP customers involved in prioritising changes

13
2. Version control
 A repository of the first version of the system and all
subsequent changes made to it.
 Subsequent versions stored in the form of ‘diffs’ (deltas)
 All software has multiple versions (branches?)
 Different platforms
 Different customer variants
 Different stages in the lifecycle
 Need to be able to:
 Recreate old versions
 Keep track of and control changes
 Support independent development

14
Why is version control important?
 Stops changes being made to the wrong version
 Prevents the wrong version being delivered to a user
 Controlling change is a major issue
 “Requirements creep”
 Many change requests will be generated
 Allows the right files to be associated with the right version/release
 A change can be rolled back
 Concurrent changes by developers controlled
 The evolution of the system tracked
 New releases, versions, families of software can be developed in a
more organised way
 Can help in fault identification
 Who and when made a particular change is recorded

15
Five Relevant Topics to Maintenance
(and system evolution)
1. Software Evolution Theory
 Lehman’s Laws of Software Evolution
 1. Continuing Change: A system must be continually adapted
else it becomes progressively less satisfactory in use
 2. Increasing Complexity: As a system evolves its complexity
increases unless work is done to maintain or reduce it
 3. Continuing Growth: The functional capability of systems
must be continually increased to maintain user satisfaction
over the system lifetime
 4. Declining Quality: Unless rigorously adapted to take into
account changes in the operational environment, the quality
of a system will appear to decline as it is evolved
 5. Feedback System: Evolution processes are multi-level,
multi-loop, multi-agent feedback systems

17
2. Defensive programming
 Definition: A technique where you assume the worst for all inputs
 Helps maintenance because you are insuring for the future
 Rules of defensive programming
 Rule 1: Never assume anything about the input
 Most problems in code come from unexpected input
 A negative age or an age >150!
 Rule 2: Use standards
 Use a proper coding standard and stick to it
 Even things like the position of brackets in Java
 Rule 3: Keep your code as simple as possible
 Reuse wherever possible because it is usually more
trusted and documented

18
 Defensive programming (cont.)
• Defensive programming conforms to the “fail
fast” principle
– Get the bugs out of the systems asap
• Techniques:
– Use diagnostic code
– Standardise error handling
– Use exception handling and assertions
– Always test external API and library references
– Assume nothing about the input!
3. Mob programming
 Definition: a software development approach where the whole team
works on the same thing, at the same time, in the same space, and
at the same computer.
 Builds on principles of lean manufacturing, extreme
programming, and lean software development
 Covers definition of user stories or requirements, designing, coding,
testing, deploying software, and working with the customer and
business experts.
 Work is handled in working meetings or workshops:
 all involved in creating the software are considered to be
team members, including the customer and business experts.
 Also works for distributed teams in the same virtual space
using screen sharing

20
4. Bathtub curve

21
 What affects the shape of the
bathtub?
• If the system is poor:
– There will be high numbers of problems at the start and it will
take longer to reach the stability period
– The period of ‘constant failure rate’ in the middle will be
shorter
– The decline will be much quicker
• So, what would a good system’s bathtub look like?
– Low numbers of problems at the start
• Reach the ‘constant failure rate’ stage quickly
– Long period of ‘constant failure rate’
– A slow decline
 5. Brooks’ Law
• “Adding human resources to a late software
project makes it later”
• Why?
– Ramp-up
• Getting staff trained up on “what’s happening” with the
project
– Complexity of communication
• With two people in a team, there is only one
communication channel (between person x and person y)
• With five people there are ten!
Reading for the week
 Sommerville Eds. 9 & 10, Chapter 9
 Sommerville Eds. 9 & 10, Chapter 25
 Most popular OSS version control tools reviewed:
http://www.smashingmagazine.com/2008/09/18/the-top-7
-open-source-version-control-systems
/
 Software Systems as Cities: A Controlled Experiment,
Richard Wettel, Michele Lanza, and Romain Robbes, In
Proceedings of ICSE 2011 (33rd International
Conference on Software Engineering), pp. 551 - 560,
ACM Press, 2011
 Lots more reading in the seminar sheet
24