Transcript No Slide Title

University of Southern California
Center for Systems and Software Engineering
Software Maintenance
CS 577b Software Engineering II
Barry Boehm
Supannika Koolmanojwong
February 22, 2012
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
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
–
–
–
–
02/22/2012
Develop I1
Develop I2; Maintain I1; Rebaseline I3 plans
Develop I3; Maintain I1+I2; Rebaseline I4 plans
…
© 2012 USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
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]
02/22/2012
© 2012 USC-CSSE
4
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
Magnitude of Software
Maintenance
• Majority of software costs incur after the first
operational release [Boehm 1981]
% of Software Cost
Maintenance vs Total Software Cost
100
90
80
70
60
50
40
30
20
10
0
Others
Maintenance
Zelkowitz et
al. (1979)
McKee
(1984)
Moad
(1990)
Erlikh
(2000)
Studies
Fig. 1. Software maintenance cost versus total software cost
02/22/2012
© 2012 USC-CSSE
8
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
9
University of Southern California
Center for Systems and Software Engineering
Distribution of Software Maintenance Effort
Business Data Processing, 1978
EMERGENCY
PROGRAM FIXES
12.4
LIENTZ-SWANSON
ROUTINE
DEBUGGING
DPMA SURVEY, 1978
9.3
487 INSTALLATIONS
17.4
ACCOM CHANGES TO
INPUT DATA, FILES
ACCOM CHANGES TO
HARDWARE, OS
6.2
41.8
ENHANCEMENTS
FOR USERS
IMPROVE
DOCUMENTATION
5.5
4.0
IMPROVE CODE
EFFICIENCY
3.4
OTHER
0
10
20
30
40
50
PERCENT OF SOFTWARE MAINTENANCE EFFORT
02/22/2012
© 2012 USC-CSSE
10
University of Southern California
Center for Systems and Software Engineering
The Software Maintenance Production Function
HIGH PAYOFF
SEGMENT
INVESTMENT
SEGMENT
DIMINISHING
RETURNS
•
SECONDARY USER
ENHANCEMENTS
•
•
•
•
IMPROVE DOCUMENTATION
•
CUMULATIVE
BENEFIT
TO
ORGANIZATION
•
SECONDARY PERFORMANCE
IMPROVEMENTS
TERTIARY USER
ENHANCEMENTS
IMPROVE CODE EFFICENCY
ROUTINE
DEBUGGING
PRIMARY USER
ENHANCEMENTS
MANDATORY
ENHANCEMENTS
•
ACCOMMADATE INPUT DATA,
FILE CHANGES
EMERGENCY
PROGRAM
FIXES
•
0
02/22/2012
20
ACCOMMODATE HARDWARE, OS CHANGES
40
60
80
100
PERCENT OF AVAILABLE SOFTWARE MAINTENANCE BUDGET
© 2012 USC-CSSE
11
University of Southern California
Center for Systems and Software Engineering
The Software Maintenance Manager’s Whiteboard
Personnel
Operations
Finance
•Web Mail Study
•Contract Status Reports •2002 AAP/EEO Reports
•2002 OSHA
•Discounted Cash Flow
•Skills
Safety Report
Analysis
Inventory
Manufacturing
•LIFO Inventory
Support
•Time & Motion Data
Reduction
•P & L Center
•College Recruiting
•Property
Reports
Reorganization Changes Report Changes
•On-Line Production
Control Study
•Springfield Data Link
© 2012 USC-CSSE
02/22/2012
•P & L Center
Reorganization Changes
12
•Applicant Tracking
Study
•Quality Cost Reporting
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
13
University of Southern California
Center for Systems and Software Engineering
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/messagebased
• Encapsulation : use COTS wrappers
– Technology watch investments
– Synchronized COTS upgrade/release strategy
© 2012 USC-CSSE
02/22/2012
14
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
15
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
16
University of Southern California
Center for Systems and Software Engineering
Distribution of Maintenance Problem Items
02/22/2012
© 2012 USC-CSSE
17
University of Southern California
Center for Systems and Software Engineering
02/22/2012
© 2012 USC-CSSE
18
University of Southern California
Center for Systems and Software Engineering
The Model-Clash Spider Web: Master Net
- Stakeholder value propositions (win conditions)
02/22/2012
© 2012 USC-CSSE
19
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
20
University of Southern California
Center for Systems and Software Engineering
Maintainability–Enabler Rating Scales
Rating Scales for Design for Flexibility Scale Factor
Characteristic | Rating
Very Low
Low
Nominal
High
Requirements identify likely sources
of change and growth (SCGs)
Design feasibility evidence shows
ability to accommodate SCGs
Shortfalls in evidence are identified as
risks, covered by risk mitigation plans
External sources of change are
identified, tracked, and planned for
Performers are capable and
incentivized to design and develop for
accommodating SCGs
Percentage of development schedule
devoted to creating and validating
design flexibility
02/22/2012
Very High Extra High
No
Occasionally
(20%)
Partly
(40%)
Moderately
(60%)
Mostly
(80%)
Completely
No
Occasionally
(20%)
Partly
(40%)
Moderately
(60%)
Mostly
(80%)
Completely
No
Occasionally
(20%)
Partly
(40%)
Moderately
(60%)
Mostly
(80%)
Completely
No
Occasionally
(20%)
Partly
(40%)
Moderately
(60%)
Mostly
(80%)
Completely
No
Occasionally
(20%)
Partly
(40%)
Moderately
(60%)
Mostly
(80%)
Completely
5
10
17
25
33
40
© 2012 USC-CSSE
21
University of Southern California
Center for Systems and Software Engineering
Software Understanding Rating / Increment
Can consume 40-60% of maintenance effort
Struc ture
Application
Clarity
Self Desc ript iv eness
SU I nc rement t o
ESLOC
22
02/22/2012
Ver y Low
Very low
c ohesion, high
c oupling,
s paghett i code.
Low
Moderately low
c ohesion, high
c oupling.
No matc h
bet ween
program and
application
world v iews.
Obsc ure c ode;
doc ument at ion
mis s ing,
obs c ure or
obs olete.
Som e
Moderate
c orrelation
c orrelation
bet ween
bet ween
program and
program and
application .
application .
Som e code
Moderate lev el
c ommentary and
of code
headers; s ome
c ommentary ,
usef ul
headers,
doc ument at ion.
doc ument at ion.
50
40
Nom
Reas onably
well s truc tured;
s ome weak
areas .
30
© 2012 USC-CSSE
High
High c ohesion,
low c oupling.
Good
c orrelation
bet ween
program and
application .
Good c ode
c ommentary
and headers ;
usef ul
doc ument at ion;
s ome weak
areas .
20
Ver y High
Strong
modularity ,
inf ormat ion
hiding in
dat a/ control
s truc tures .
Clear mat ch
bet ween
program and
application
world v iews.
Self des c riptiv e
c ode;
doc ument at ion
up-to-date,
well-organized,
with des ign
rationale.
10
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
23
University of Southern California
Center for Systems and Software Engineering
Software Maintenance Processes
• Traditional : IEEE1219-98
• Flow-oriented : Kanban
• Evolutionary: ICSM
02/22/2012
© 2012 USC-CSSE
24
University of Southern California
Center for Systems and Software Engineering
Traditional Maintenance Process
The IEEE1219-98 Maintenance Process Activities
02/22/2012
© 2012 USC-CSSE
25
University of Southern California
Center for Systems and Software Engineering
Kanban Software Maintenance
02/22/2012
© 2012 USC-CSSE
26
University of Southern California
Center for Systems and Software Engineering
The Incremental Commitment Life Cycle Process: Overview
Stage I: Definition
Stage II: Development and Operations
Anchor Point
Milestones
Concurrently engr.
OpCon, rqts, arch,
plans, prototypes
02/22/2012
© 2012 USC-CSSE
Concurrently engr.
Incr.N (ops), N+1
(devel), N+2 (arch)
27
University of Southern California
Center for Systems and Software Engineering
ICM Stage II: Increment View
Rapid
Change
Short
Development
Increments
Foreseeable
Change (Plan)
Increment N Baseline
Short, Stabilized
Development
of Increment N
Increment N Transition/O&M
Stable Development
Increments
High
Assurance
02/22/2012
© 2012 USC-CSSE
28
University of Southern California
Center for Systems and Software Engineering
ICM Stage II: Increment View
A radical idea?
Unforseeable Change
(Adapt)
Rapid
Change
Short
Development
Increments
Agile
Future Increment Baselines
Rebaselining for
Future Increments
Deferrals
Foreseeable
Change (Plan)
Increment N Baseline
Stable Development
Increments
Current V&V
High
Assurance
Resources
Short, Stabilized
Development
of Increment N
Artifacts
Increment N Transition/O&M
Concerns
V&V
of Increment N
Future V&V
Resources
Continuous V&V
No; a commercial best practice and part of DoDI 5000.2
02/22/2012
© 2012 USC-CSSE
29
University of Southern California
Center for Systems and Software Engineering
Agile Change Processing and Rebaselining
Stabilized
Increment-N
Development Team
Agile FutureIncrement
Rebaselining Team
Future Increment
Managers
Defer some Increment-N capabilities
Proposed changes
Recommend handling
in current increment
Negotiate change
disposition
Accept changes
Handle
Accepted
Increment-N
changes
Assess Changes,
Propose Handling
Propose
Changes
Discuss, revise,
defer, or drop
Handle in current
rebaseline
Formulate, analyze options
in context of other changes
Recommend deferrals to future increments
Discuss, resolve deferrals to
future increments
Rebaseline
future-increment
Foundations packages
02/22/2012
Recommend no action,
provide rationale
Change
Proposers
© 2012 USC-CSSE
Prepare for rebaselined
future-increment
development
30
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
31
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
32
University of Southern California
Center for Systems and Software Engineering
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)
02/22/2012
© 2012 USC-CSSE
33
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
34
University of Southern California
Center for Systems and Software Engineering
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
02/22/2012
© 2012 USC-CSSE
35
University of Southern California
Center for Systems and Software Engineering
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.
02/22/2012
© 2012 USC-CSSE
36
University of Southern California
Center for Systems and Software Engineering
References
•
•
[Lientz 1981] Lientz, B.P. & Swanson, E. (1981). "Problems in application
software maintenance". Communications of the ACM 24 (11), 763-769.
[SWEBOK 2004] Software Engineering Body of Knowledge version 2004
http://www.computer.org/portal/web/swebok
02/22/2012
© 2012 USC-CSSE
37