1. CS 577b Software Engineering II -- Introduction
22 April 2017
Software Maintenance
CS 577b Software Engineering II
Barry Boehm
© USC Center for Software Engineering

2. Outline Software Maintenance Definition & Context
Nature of Software Maintenance
Critical Success Factors in SW Maintenance
Example Survey
People factors
Product factors
Process factors
577b System and Software Support Plan
© 2012 USC-CSSE

3. Definitions IEEE standard [IEEE 1219-98:s3.1.12]:
“the modification of a software product after delivery to correct faults, to improve performance or other attributes , or to adapt the product to a modified environment.”
Develop; deliver; maintain
Distinctions blurred with evolutionary and incremental development
Develop I1
Develop I2; Maintain I1; Rebaseline I3 plans
Develop I3; Maintain I1+I2; Rebaseline I4 plans …
© 2012 USC-CSSE

4. Importance of Software Maintenance
Systems are tightly coupled with their environment
Environment changes require changing its software systems
Technologies and requirements are continuously changing
Software systems must be maintained to reserve their values
Maintenance is important in market competition
New software has advantage over the existing one
Software system must be upgraded to keep its market share
Economic benefits have backed software maintenance and reuse [Boehm 1981, 1999]
© 2012 USC-CSSE

5. Nature of Maintenance
Sustain the software product throughout its operational life cycle
Modification requests are logged and tracked
Impact of the proposed changed is determined
Code and artifacts are modified
Testing is conducted
New version of software product is released
Need training and daily support
© 2012 USC-CSSE

6. Software Maintenance Phenomenology
The Iron Law of Software Maintenance
Software Maintenance production function
The software maintenance manager’s whiteboard
Lehman-Belady “Laws” of evolution dynamics
Effects of COTS on software maintenance
© 2012 USC-CSSE

7. The Iron Law of Software Maintenance
Useful software systems will spend twice as much on software maintenance as they did for development
For CS 577 clients:
Development = (24 weeks)(12 hr/week)(5 persons) = 1440 person-hr
Maintenance = (2)(1440 PH)($50/PH) = $144,000
© 2012 USC-CSSE

8. Magnitude of Software Maintenance
Majority of software costs incur after the first operational release [Boehm 1981]
Maintenance vs Total Software Cost 10 20 30 40 50 60 70 80 90
100
Zelkowitz et
al. (1979)
McKee
(1984)
Moad
(1990)
Erlikh
(2000)
Studies
% of Software Cost
Others
Maintenance
Fig. 1. Software maintenance cost versus total software cost
© 2012 USC-CSSE

9. Life cycle cost ratios (%O&M)
Hardware [Redman 2008]
12% -- Missiles (average)
60% -- Ships (average)
78% -- Aircraft (F-16)
84% -- Ground vehicles (Bradley)
Software [Koskinen 2010]
75-90% -- Business, Command-Control
50-80% -- Complex platforms as above
10-30% -- Simple embedded software
© 2012 USC-CSSE

10. Business Data Processing, 1978
Distribution of Software Maintenance Effort
Business Data Processing, 1978
EMERGENCY
PROGRAM FIXES
LIENTZ-SWANSON
DPMA SURVEY, 1978
487 INSTALLATIONS
ROUTINE
DEBUGGING
ACCOM CHANGES TO INPUT DATA, FILES
ACCOM CHANGES TO
HARDWARE, OS
ENHANCEMENTS FOR USERS
IMPROVE DOCUMENTATION
IMPROVE CODE EFFICIENCY
OTHER
© 2012 USC-CSSE

11. The Software Maintenance Production Function
CUMULATIVE
BENEFIT TO
ORGANIZATION
The Software Maintenance Production Function
EMERGENCY
PROGRAM
FIXES • 20 40 60 80
100
ACCOMMODATE HARDWARE, OS CHANGES
ACCOMMADATE INPUT DATA,
FILE CHANGES
MANDATORY
ENHANCEMENTS
INVESTMENT
SEGMENT
HIGH PAYOFF
DIMINISHING
RETURNS
SECONDARY PERFORMANCE
IMPROVEMENTS
SECONDARY USER
IMPROVE CODE EFFICENCY
IMPROVE DOCUMENTATION
TERTIARY USER
PRIMARY USER
ROUTINE
DEBUGGING
PERCENT OF AVAILABLE SOFTWARE MAINTENANCE BUDGET
© 2012 USC-CSSE

12. The Software Maintenance Manager’s Whiteboard
Operations
Web Mail Study
2002 OSHA
Safety Report
P & L Center
Reorganization Changes
Springfield Data Link
Finance
Contract Status Reports
Discounted Cash Flow
Analysis
Property
Report Changes
P & L Center Reorganization Changes
Personnel
2002 AAP/EEO Reports
Skills
Inventory
College Recruiting
Reports
Applicant Tracking Study
Manufacturing
LIFO Inventory Support
Time & Motion Data
Reduction
On-Line Production
Control Study
Quality Cost Reporting
© 2012 USC-CSSE

13. Lehman-Belady “Laws” of Evolution Dynamics
1. Continuing change
2. Increasing complexity
3. Cyclic self-regulation
4. Invariant work rate
5. Conservation of familiarity
© 2012 USC-CSSE

14. Effects of COTS on Software Maintenance
You have no control over COTS evolution
Maintenance headaches scale exponentially with # COTS
You need a pro-active COTS-based-system evolution strategy
Go for dominant open standards
Factor evolution requirements into COTS selection
Evaluate COTS vendors’ evolution track records
Use flexible architectures
CORBA, COM, software bus, layering, event/message-based
Encapsulation : use COTS wrappers
Technology watch investments
Synchronized COTS upgrade/release strategy
© 2012 USC-CSSE

15. Software Maintenance Categories
Correction
Enhancement
Proactive
Preventive
Perfective
Reactive
Corrective
Adaptive
Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems
Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment
Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability
Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults
© 2012 USC-CSSE

16. Outline Software Maintenance Definition & Context
Nature of Software Maintenance
Critical Success Factors in SW Maintenance
Example Survey
People factors
Product factors
Process factors
577b System and Software Support Plan
© 2012 USC-CSSE

17. Distribution of Maintenance Problem Items
© 2012 USC-CSSE

18. © 2012 USC-CSSE

19. The Model-Clash Spider Web: Master Net
- Stakeholder value propositions (win conditions)
© 2012 USC-CSSE

20. Designing Maintainable Products
Modularize around sources of change
Need to identify these
Risk-manage choices of COTS products, cloud services
Fewer is generally better
Compatible, stable, well supported, refreshed
Deliver maintenance & diagnostic software
Debug aids, test tools and cases, CM support
Version control: fewer versions is better
Follow good code and document standards
© 2012 USC-CSSE

21. Maintainability–Enabler Rating Scales
© 2012 USC-CSSE

22. Can consume 40-60% of maintenance effort
Software Understanding Rating / Increment
Can consume 40-60% of maintenance effort
© 2012 USC-CSSE

23. Outline Software Maintenance Definition & Context
Nature of Software Maintenance
Critical Success Factors in SW Maintenance
Example Survey
People factors
Product factors
Process factors
577b System and Software Support Plan
© 2012 USC-CSSE

24. Software Maintenance Processes
Traditional : IEEE
Flow-oriented : Kanban
Evolutionary: ICSM
© 2012 USC-CSSE

25. Traditional Maintenance Process
The IEEE Maintenance Process Activities
© 2012 USC-CSSE

26. Kanban Software Maintenance
© 2012 USC-CSSE

27. The Incremental Commitment Life Cycle Process: Overview
Stage I: Definition
Stage II: Development and Operations
Anchor Point Milestones
Concurrently engr. Incr.N (ops), N+1 (devel), N+2 (arch)
Concurrently engr. OpCon, rqts, arch, plans, prototypes
© 2012 USC-CSSE

28. ICM Stage II: Increment View
© 2012 USC-CSSE

29. ICM Stage II: Increment View A radical idea?
No; a commercial best practice and part of DoDI
© 2012 USC-CSSE

30. Agile Change Processing and Rebaselining
Assess Changes,
Propose Handling
Stabilized
Increment-N
Development Team
Change
Proposers
Future Increment
Managers
Agile Future-
Increment
Rebaselining Team
Negotiate change
disposition
Formulate, analyze options
in context of other changes
Handle
Accepted
changes
Discuss, resolve deferrals to
future increments
Propose
Changes
Discuss, revise,
defer, or drop
Rebaseline
future-increment
Foundations packages
Prepare for rebaselined
development
Defer some Increment-N capabilities
Recommend handling
in current increment
Accept changes
Handle in current rebaseline
Proposed changes
Recommend no action,
provide rationale
Recommend deferrals to future increments
To handle unpredictable, asynchronous change traffic, it is not possible to do a sequential observe, then orient, then decide process. Instead, it requires handling unforeseen change requests involving new technology or COTS opportunities; changing requirements and priorities; changing external interfaces; low-priority current increment features being deferred to a later increment; and user requests based on experience with currently-fielded increments (including defect fixes).
In the context of the agile rebaselining team in Chart 10, this chart shows how the agile team interacts with the change proposers, current-increment development team, and managers of future increments to evaluate proposed changes and their interactions with each other, and to negotiate rebaselined Milestone B packages for the next increment. Again, there is no precise way to forecast the budget and schedule of this team’s workload. Within an available budget and schedule, the agile team will perform a continuing “handle now; incorporate in next increment rebaseline; defer-or-drop” triage in the top “Assess Changes, Propose Handling” box. Surges in demand would have to be met by surges in needed expertise and funding support.
© 2012 USC-CSSE

31. Outline Software Maintenance Definition & Context
Nature of Software Maintenance
Critical Success Factors in SW Maintenance
Example Survey
People factors
Product factors
Process factors
577b System and Software Support Plan
© 2012 USC-CSSE

32. 577b System and Software Support Plan
Purpose: to guide support stakeholders in successfully operating and maintaining the system
Timing: Builds on OCD, LCP. Developed during Construction Phase. ARB review at TRR. Updated during Transition Phase.
Intended Audience: Support stakeholders, plus developers (target for Transition Plan), users (operational information)
Responsibilities: joint between support stakeholders (normally the leaders) and developers (leaders in 577b)
Completion Criterion: stakeholder concurrence, feasibility of execution, resource realism
© 2012 USC-CSSE

33. Support Plan Contents
1. Support Objectives and Assumptions (why, whereas)
2. Support Strategy and Environment (what, when)
3. Support Responsibilites (who, where)
4. Support Approach (how)
5. Support Resources (how much)
© 2012 USC-CSSE

34. Example Support Objectives and Assumptions
Key driving objectives for support activities
Ensure system safety; top customer satisfaction; competitive speed
Replace inefficient old systems quickly
Provide more promising support career paths
Assumptions required for workability of support plan
Continuity of funding, staffing, executive support
Controllable/negotiable interfaces with other systems
Stability of next-release requirements and schedules
© 2012 USC-CSSE

35. Support Strategy Estimated support lifetime
Under 1 year; over 5 years; until XYZ phased out
Release strategy
Continuous small fixes; annual release; COTS refresh cycle
Early next-release content (evolution rqts.)
Release transition strategy (testing; multisite sequencing)
Release requirements determination
Primary drivers (budget, schedule, staffing, marketplace)
Process (stakeholder win-win, bidding, sub-allocations)
Release process
Normally inception/elaboration/construction/transition
© 2012 USC-CSSE

36. Approach and Resources
Approach: identify differences in the support approach and the development approach in LCP Section 4
E.g., differences in methods, tools, & facilities
Support budgets: Work breakdown structure; initial budgets consistent with FRD Section 2.
© 2012 USC-CSSE

37. References
[Lientz 1981] Lientz, B.P. & Swanson, E. (1981). "Problems in application software maintenance". Communications of the ACM 24 (11),
[SWEBOK 2004] Software Engineering Body of Knowledge version
Koskinen, J., "Software maintenance fundamentals", in Encyclopedia of Software Engineering, P. Laplante, Ed., Taylor & Francis Group, 2009.
Vu Nguyen, "Improved Size and Effort Estimation Models for Software Maintenance," PhD Dissertation, Department of Computer Science, University of Southern California, December 2010.
Redman, Q. “Weapon System Design Using Life Cycle Costs,” Raytheon Presentation, 2008.
© 2012 USC-CSSE