1. Software Maintenance Maurice ter Beek
These slides are based on slides for Software Engineering courses by
Natallia Kokash, Werner Heijstek, Michel Chaudron & Hans van Vliet
Note that the book is misleadingly simple.
Just reading the book is like learning to swim without getting wet.
Software Engineering, lecture 6

2. Outline Definition Software maintenance issues
Maintenance and evolution
Reverse engineering and refactoring
Program comprehension
Maintenance tools
Organization and control of maintenance
M.H. ter Beek, Software Engineering, lecture 6

3. Need for software maintenance
100 billion lines of code
80% of it is unstructured, patched, and badly documented
A multinational bank:
100+ offices
10+ mainframes at a central site
1000+ workstations
24 * 7 availability
100+ application systems
500K+ LOC
Obsolete languages (Fortran, COBOL)
Huge databases
M.H. ter Beek, Software Engineering, lecture 6

4. Definition
The process of modifying a software system or component after delivery to:
correct faults,
improve performance or other attributes, or
adapt to a changed environment
M.H. ter Beek, Software Engineering, lecture 6

5. Distribution of maintenance activities
corrective 21%
perfective 50%
adaptive 25%
preventive 4%
Corrective maintenance: correcting discovered errors
Preventive maintenance: correcting latent errors, by improving maintainability (e.g. improve modularity)
Adaptive maintenance: adapting to changes in the environment (does not lead to changes in functionality)
Perfective maintenance: adapting to new or changed user requirements (e.g. enhanced user interface)
M.H. ter Beek, Software Engineering, lecture 6

6. Growth of maintenance problem
1975: ±75,000 people in maintenance (17%)
1990: 800,000 (47%)
2005: 2,500,000 (76%)
2015: ???
(Numbers from Jones (2006))
M.H. ter Beek, Software Engineering, lecture 6

7. Maintenance or Evolution
Some observations:
Systems are not built from scratch
There’s time pressure on maintenance (more functionality, asap!)
Software is embedded in the real world and becomes part of it, thereby changing it
This leads to a feedback system where the program and its environment evolve in concert
So there is a gradual difference between development and evolution, where the emphasis is on different things. A green field situation is seldom found in software development.
So: design for change;
continuing change: if a system is used, it changes, until it becomes cost-effective to replace the whole system
increasing complexity: entropy increases
program evolution: growth rate is self-regulating (see next slide)
invariant work rate: a few extra people don’t make a big difference (Brooks Law, see also chapter 7)
incremental growth limit: system “determines” its own growth rate, if you go too fast, you get into trouble
Explanation in terms of progressive and anti-regressive activities
M.H. ter Beek, Software Engineering, lecture 6
© SE, Lifecycle, Hans van Vliet

8. Laws of software evolution (Lehman et al., 1974)
Continuing change
Programs must be continually adapted or they become progressively less satisfactory
Increasing complexity
As a program evolves its complexity increases, unless work is done to maintain or reduce it
Self-regulation
Software evolution processes are self-regulating and promote smooth growth of the software (attributes)
M.H. ter Beek, Software Engineering, lecture 6

9. Illustration of the 3rd law (of 8 in total)
System attributes
Self-regulation
Evolution process is self-regulating with distribution of product and process measures close to normal
Time
M.H. ter Beek, Software Engineering, lecture 6

10. Laws of software evolution (Lehman et al., 1974)
Conservation of organizational stability (invariant work rate)
The average effective global activity rate in an evolving system is invariant over the product’s lifetime
Conservation of familiarity (incremental growth)
As a system evolves all associated with it (e.g., developers) must maintain mastery of its content and behavior to achieve satisfactory evolution; excessive growth diminishes that mastery
M.H. ter Beek, Software Engineering, lecture 6

11. Laws of software evolution (… and later)
Continuing growth
The functional content of systems must be continually increased to maintain user satisfaction over their lifetime
Declining quality
The quality of systems declines over time, unless they are rigorously maintained and adapted to its changing environment
Feedback system
Software evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such
M.H. ter Beek, Software Engineering, lecture 6

12. Fighter plane control system
IF not-read1 (V1) GOTO DEF1; display (V1); GOTO C; DEF1: IF not-read2 (V2) GOTO DEF2; display (V2); DEF2: display(3000) C:
M.H. ter Beek, Software Engineering, lecture 6

13. Major causes of maintenance problems
Unstructured code
Insufficient domain knowledge
Insufficient documentation
M.H. ter Beek, Software Engineering, lecture 6

14. Key to maintenance is in development
Higher quality  less (corrective) maintenance
Anticipating changes  less (adaptive and perfective) maintenance
Better tuning to user needs  less (perfective) maintenance
Less code  less maintenance
M.H. ter Beek, Software Engineering, lecture 6

15. Shift in type of maintenance over time
Introductory stage: emphasis on user support
Growth stage: emphasis on correcting faults
Maturity: emphasis on enhancements
Decline: emphasis on technology replacement
M.H. ter Beek, Software Engineering, lecture 6

16. Reverse engineering
Does not involve any adaptation of system (only inspection)
Akin to reconstruction of a lost blueprint
Design recovery: result is at higher level of abstraction
Redocumentation: result is at same level of abstraction
M.H. ter Beek, Software Engineering, lecture 6

17. Restructuring Functionality does not change
From one representation to another, at the same level of abstraction, such as:
From spaghetti code to structured code
Refactoring after a design step in agile approaches (white box)
Black box restructuring: add a wrapper, switch database
With platform change: migration
M.H. ter Beek, Software Engineering, lecture 6

18. Reengineering (renovation)
Functionality does change
Reverse-engineering step is followed by a forward- engineering step in which the changes are made
M.H. ter Beek, Software Engineering, lecture 6

19. Refactoring in case of bad smells (1)
Long method
Large class
Primitive obsession
Long parameter list
Data clumps
Switch statements
Temporary field
Refused bequest
Alternative classes with different interfaces
Parallel inheritance hierarchies
(Fowler, 1999)
M.H. ter Beek, Software Engineering, lecture 6

20. Refactoring in case of bad smells (2)
Lazy class
Data class
Duplicate code
Speculative generality
Message chains
Middle man
Feature envy
Inappropriate intimacy
Divergent change
Shotgun surgery
Incomplete library class
M.H. ter Beek, Software Engineering, lecture 6

21. Categories of bad smells
Bloaters: something has grown too large to handle
Object-oriented abusers: OO possibilities not fully exploited
Change preventers: hinder further evolution of software
Dispensables: things that can be removed
Encapsulators: deal with data communication
Couplers: coupling is too high
(Mäntylä et al., 2003)
M.H. ter Beek, Software Engineering, lecture 6

22. Categories of bad smells
Category
Bad smell
Bloaters
Long method, Large class, Primitive obsession, Long parameter list, Data clumps
OO abusers
Switch statements, Temporary field, Refused bequest, Alternative classes with different interfaces, Parallel inheritance hierarchies
Change preventers
Divergent change, Shortgun surgery
Dispensables
Lazy class, Data class, Duplicate code, Speculative generality
Encapsulators
Message chains, Middle man
Couplers
Feature envy, Inappropriate intimacy
Others
Incomplete library class, Comments
M.H. ter Beek, Software Engineering, lecture 6

23. What does this code do?
for (i=1; i<n; i++){ for (j=1; j<n; j++){ if (A[i,j]){ for (k=1; k<n; k++) { if (A[i,k]) A[j,k]=true; }
Warshall’s algorithm to compute the transitive closure of a relation (graph)
Incomprehensible without domain knowledge: “transitive closure”, “relation”, “graph”
M.H. ter Beek, Software Engineering, lecture 6

24. Program comprehension
50% of time
Programming plans
program fragments that correspond to stereotypical actions
Beacons
key features that indicate the presence of a particular structure or operation (e.g., swap operation indicates sorting program)
As-needed strategy vs. systematic strategy for studying program code
Use of outside knowledge (domain knowledge, naming conventions, etc.)
M.H. ter Beek, Software Engineering, lecture 6

25. Software maintenance tools (for program understanding)
Reformatters: tools to ease perceptual processes (neat lay-out)
Tools to gain insight in static structure (dead code, control graph, calling hierarchy, etc.)
Tools to gain insight in dynamic behavior (execution flow, etc.)
Tools that inspect the version history
Cf. lecture 2 (Configuration Management)
M.H. ter Beek, Software Engineering, lecture 6

26. Bug/defect tracking systems
Bugzilla by Mozilla foundation
Test Director by Mercury Interactive
Silk Radar by Segue Software
SQA Manager by Rational software
QA director by Compuware
HP Quality Center
IBM Rational Quality Manager
Information presented through custom-designed dashboards
Micro Focus SilkPerformer
Performs load tests
M.H. ter Beek, Software Engineering, lecture 6

27. Clone (duplicate code) finding tools
Black Duck Suite - software analyzing suite
CCFinder (C/C++, Java, COBOL, Fortran, etc.)
Checkstyle (Java)
CloneAnalyzer (C/C++ and Java / Eclipse plug-in)
Clone Digger (Python and Java)
CloneDR (Ada, C, C++, C#, Java, COBOL, Fortran, Python, VB.net, VB6, PHP4/5, PLSQL, SQL2011, XML, many others)
Copy/Paste Detector (CPD) from PMD (Java, JSP, C, C++, Fortran, PHP)
ConQAT (ABAP, ADA, Cobol, C/C++, C#, Java, PL/I, PL/SQL, Python, Text, Transact SQL, Visual Basic, XML)
JPlag (Java, C#, C, C++, Scheme, natural language text)
Pattern Miner (CP Miner)
Simian (Similarity Analyzer) software
Google CodePro Analytix (Java / Eclipse plug-in)
M.H. ter Beek, Software Engineering, lecture 6

28. Maintenance management tools
ProTeus III Expert CMMS
mid-size maintenance management program for one to four users
schedule preventative maintenance
generate automatic work orders
document equipment maintenance history
track assets and inventory
track personnel
create purchase orders
generate reports
M.H. ter Beek, Software Engineering, lecture 6

29. Resharper NDepend Code inspection, refactoring, navigation, analysis
Tool to manage .NET code
Software quality can be measured using code metrics, visualized using graphs and treemaps, and enforced using standard and custom rules
Also JDepend for Java
Cf. lecture 5 (Software Quality)
M.H. ter Beek, Software Engineering, lecture 6

30. Analyzing software evolution data
Version-centered analysis: study differences between successive versions
History-centered analysis: study evolution from a certain viewpoint (e.g. how often components are changed together)
M.H. ter Beek, Software Engineering, lecture 6

31. Organization of maintenance
W-type: by work type (e.g. design vs. analysis vs. programming vs. testing)
A-type: by application area (e.g. office automation vs. financial systems)
L-type: by life-cycle phase (e.g. development vs. maintenance)
L-type found most often, combinations possible (e.g. L-A vs. A-L)
M.H. ter Beek, Software Engineering, lecture 6

32. Advantages of L-type departmentalization
Clear accountability
Development progress not hindered by unexpected maintenance requests
Better acceptance test by maintenance department
Higher QoS by maintenance department
Higher productivity
M.H. ter Beek, Software Engineering, lecture 6

33. Disadvantages of L-type departmentalization
Demotivation of maintenance personnel because of status differences
Loss of system knowledge during system transfer
Coordination costs
Increased acceptance costs
Possible duplication of communication channels with users
M.H. ter Beek, Software Engineering, lecture 6

34. Product-service continuum and maintenance
Software maintenance can be seen as providing a service (≠ product)
M.H. ter Beek, Software Engineering, lecture 6

35. Service gaps
Expected service as perceived by service provider differs from service expected by customer
Service specification differs from expected service as perceived by service provider
Actual service delivery differs from specified services
Communication about service does not match actual service delivery
M.H. ter Beek, Software Engineering, lecture 6

36. Gap model of service quality
M.H. ter Beek, Software Engineering, lecture 6

37. Maintenance control Configuration control:
Identify, classify change requests
Analyze change requests
Implement changes
Fits in with the iterative-enhancement model of maintenance (first change design, then code)
Opposite of quick-fix model common in reality (first patch code, only then update design and documentation - usually only if time permits)
M.H. ter Beek, Software Engineering, lecture 6

38. Indicators of system decay, i.e. when to reengineer:
Frequent system failures
Overly complex program structure
Running in emulation mode
Very large components/subroutines
Excessive resource requirements
Seriously deficient documentation
High personnel turnover
Different technologies in one system
etc.
M.H. ter Beek, Software Engineering, lecture 6

39. Summary Most of maintenance (inevitably) actually is evolution
Maintenance problems:
Unstructured code
Insufficient knowledge about system and domain
Insufficient documentation
Bad image of maintenance department
Lehman’s 3rd law: a system that is used, will change
M.H. ter Beek, Software Engineering, lecture 6
© SE, Maintenance, Hans van Vliet

40. Software Engineering (3rd Ed.)
1. Introduction
2. Introduction to Software Engineering Management
3. The Software Life Cycle Revisited
4. Configuration Management
5. People Management and Team Organization
6. On Managing Software Quality
7. Cost Estimation
8. Project Planning and Control
9. Requirements Engineering
10. Modeling
11. Software Architecture
12. Software Design
13. Software Testing
14. Software Maintenance
17. Software Reusability
18. Component-Based Software Engineering
19. Service Orientation
20. Global Software Development
M.H. ter Beek, Software Engineering, lecture 6